Skip to contentSkip to conversation

add support for Mediatek High-Speed DMA controller on MT7622 and MT7623 SoC

PATCH Superseded [email protected] 3 participants 11 messages Feb 17, 2018 – Mar 2, 2018

Subsystems (4)

v5 of 7 Superseded Latest is v7 →

lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

v5 cover add support for Mediatek High-Speed DMA controller on MT7622 and MT7623 SoC

From: Sean Wang <[email protected]>

Changes since v4:
- rebase to 4.16-rc1
- fold back patch 4 and 5 in v4 into the original commit
- add the missing header included
- fix typo and add more explanation in existing comments
- fix the comments with kernel-doc style which uses /** as the begin
- begin the multi-line comments with /*

Changes since v3:
- enhance dt-binding documents based on Rob's comments
- make consistent among all comments
- perfer ordering declarations longest to shortest
- fix warning reported from kbuild test robot
- add patch 4 and 5 to keep Fengguang and Julia's effort

Changes since v2:
- remove extra tasklets and refactor driver for letting descriptors being processed ASAP.
- add more comments stating the relevant logic
- remove unused macro and variables
- change to use the disclaimer with SPDX identifier
- add mt7622 support
- refine hardware initialization sequence
- add tx_status support for DMA_RESIDUE_GRANULARITY_SEGMENT
- refine remove handler with killing vc's tasklet

Changes since v1:
- fix typo in the commit message.
- delete status shown in the dt-binding example.

This patchset introduces support for MediaTek High-Speed DMA controller (MTK-HSDMA) Currently, the driver is already tested successfully with dmatest module on MT7622 and MT7623 SoC.

MTK-HSDMA on MT7622/23 SoC has a single ring which is dedicated for doing memory-to-memory transfer through ring-based descriptor management. Even though there is only a single ring available inside HSDMA, the driver is being extended to the support for multiple virtual channels processing simultaneously by means of DMA_VIRTUAL_CHANNELS.

Sean Wang (3):
dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller
bindings
dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622

    and MT7623 SoC

dmaengine: mediatek: update MAINTAINERS entry with MediaTek DMA driver

 .../devicetree/bindings/dma/mtk-hsdma.txt          |   33 +
 MAINTAINERS                                        |    9 +
 drivers/dma/Kconfig                                |    2 +
 drivers/dma/Makefile                               |    1 +
 drivers/dma/mediatek/Kconfig                       |   13 +
 drivers/dma/mediatek/Makefile                      |    1 +
 drivers/dma/mediatek/mtk-hsdma.c                   | 1054 ++++++++++++++++++++
 7 files changed, 1113 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
 create mode 100644 drivers/dma/mediatek/Kconfig
 create mode 100644 drivers/dma/mediatek/Makefile
 create mode 100644 drivers/dma/mediatek/mtk-hsdma.c
Signature · 1 line
2.7.4
author maintainer
#1 lore raw

PATCH v5 1/3 dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings

From: Sean Wang <[email protected]>

Document the devicetree bindings for MediaTek High-Speed DMA controller which could be found on MT7623 SoC or other similar Mediatek SoCs.

---
 .../devicetree/bindings/dma/mtk-hsdma.txt          | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
Documentation/devicetree/bindings/dma/mtk-hsdma.txt new file +33 -0
new file mode 100644
index 0000000..4bb31735
@@ -0,0 +1,33 @@
+MediaTek High-Speed DMA Controller
+==================================
+
+This device follows the generic DMA bindings defined in dma/dma.txt.
+
+Required properties:
+
+- compatible:	Must be one of
+		  "mediatek,mt7622-hsdma": for MT7622 SoC
+		  "mediatek,mt7623-hsdma": for MT7623 SoC
+- reg:		Should contain the register's base address and length.
+- interrupts:	Should contain a reference to the interrupt used by this
+		device.
+- clocks:	Should be the clock specifiers corresponding to the entry in
+		clock-names property.
+- clock-names:	Should contain "hsdma" entries.
+- power-domains: Phandle to the power domain that the device is part of
+- #dma-cells: 	The length of the DMA specifier, must be <1>. This one cell
+		in dmas property of a client device represents the channel
+		number.
+Example:
+
+        hsdma: dma-controller@1b007000 {
+		compatible = "mediatek,mt7623-hsdma";
+		reg = <0 0x1b007000 0 0x1000>;
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&ethsys CLK_ETHSYS_HSDMA>;
+		clock-names = "hsdma";
+		power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+		#dma-cells = <1>;
+	};
+
+DMA clients must use the format described in dma/dma.txt file.
author maintainer
#3 lore raw

PATCH v5 2/3 dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

In reply to [email protected]

From: Sean Wang <[email protected]>

MediaTek High-Speed DMA controller (HSDMA) on MT7622 and MT7623 SoC has a single ring is dedicated to memory-to-memory transfer through ring based descriptor management.

Even though there is only one physical ring available inside HSDMA, the driver can be easily extended to the support of multiple virtual channels processing simultaneously by means of DMA_VIRTUAL_CHANNELS effort.

Cc Randy Dunlap <[email protected]>
Cc Fengguang Wu <[email protected]>
Cc Julia Lawall <[email protected]>
---
 drivers/dma/Kconfig              |    2 +
 drivers/dma/Makefile             |    1 +
 drivers/dma/mediatek/Kconfig     |   13 +
 drivers/dma/mediatek/Makefile    |    1 +
 drivers/dma/mediatek/mtk-hsdma.c | 1054 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 1071 insertions(+)
 create mode 100644 drivers/dma/mediatek/Kconfig
 create mode 100644 drivers/dma/mediatek/Makefile
 create mode 100644 drivers/dma/mediatek/mtk-hsdma.c
drivers/dma/Kconfig +2 -0
index 27df3e2..86ace76 100644
@@ -633,6 +633,8 @@ config ZX_DMA
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
+source "drivers/dma/mediatek/Kconfig"
+
 source "drivers/dma/qcom/Kconfig"
 
 source "drivers/dma/dw/Kconfig"
drivers/dma/Makefile +1 -0
index b9dca8a..7a57b97 100644
@@ -75,5 +75,6 @@ obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx_dma.o
 obj-$(CONFIG_ST_FDMA) += st_fdma.o
 
+obj-y += mediatek/
 obj-y += qcom/
 obj-y += xilinx/
drivers/dma/mediatek/Kconfig new file +13 -0
new file mode 100644
index 0000000..27bac0b
@@ -0,0 +1,13 @@
+
+config MTK_HSDMA
+	tristate "MediaTek High-Speed DMA controller support"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	---help---
+	  Enable support for High-Speed DMA controller on MediaTek
+	  SoCs.
+
+	  This controller provides the channels which is dedicated to
+	  memory-to-memory transfer to offload from CPU through ring-
+	  based descriptor management.
drivers/dma/mediatek/Makefile new file +1 -0
new file mode 100644
index 0000000..6e778f8
@@ -0,0 +1 @@
+obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
drivers/dma/mediatek/mtk-hsdma.c new file +1054 -0

1,054 lines not on this page · raw message

author maintainer
#10 lore raw

PATCH v5 3/3 dmaengine: mediatek: update MAINTAINERS entry with MediaTek DMA driver

In reply to [email protected]

From: Sean Wang <[email protected]>

I work for MediaTek and maintain SoC targeting to home gateway and also will keep extending and testing the function.

---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)
MAINTAINERS +9 -0
index 3bdc260..d3c33d7 100644
@@ -8785,6 +8785,15 @@ M:	Sean Wang <[email protected]>
 S:	Maintained
 F:	drivers/media/rc/mtk-cir.c
 
+MEDIATEK DMA DRIVER
+M:	Sean Wang <[email protected]>
+L:	[email protected]
+L:	[email protected] (moderated for non-subscribers)
+L:	[email protected] (moderated for non-subscribers)
+S:	Maintained
+F:	Documentation/devicetree/bindings/dma/mtk-*
+F:	drivers/dma/mediatek/
+
 MEDIATEK PMIC LED DRIVER
 M:	Sean Wang <[email protected]>
 S:	Maintained
maintainer Reviewed-by on v5 1/3
#2 lore raw

Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings

In reply to [email protected]
Quoted 10 lines · On Sun, Feb 18, 2018 at 03:08:29AM +0800, [email protected] wrote:

From: Sean Wang <[email protected]>

Document the devicetree bindings for MediaTek High-Speed DMA controller which could be found on MT7623 SoC or other similar Mediatek SoCs.

---
 .../devicetree/bindings/dma/mtk-hsdma.txt          | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt

---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw

Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

In reply to [email protected]

drivers/dma/mediatek/mtk-hsdma.c line 1

Quoted 2 lines · On Sun, Feb 18, 2018 at 03:08:30AM +0800, [email protected] wrote:
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
@@ -0,0 +1,1054 @@
+// SPDX-License-Identifier: GPL-2.0

// Copyright ...

The copyright line needs to follow SPDX tag line

Quoted 8 lines
drivers/dma/mediatek/mtk-hsdma.c new file +8 -0
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/iopoll.h>

drivers/dma/mediatek/mtk-hsdma.c line 27

Quoted 10 lines
drivers/dma/mediatek/mtk-hsdma.c new file +10 -0
+#include <linux/jiffies.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/refcount.h>
+#include <linux/slab.h>

that's a lot of headers, do u need all those?

drivers/dma/mediatek/mtk-hsdma.c line 31

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+
+#include "../virt-dma.h"
+
+#define MTK_DMA_DEV KBUILD_MODNAME

why do you need this?

drivers/dma/mediatek/mtk-hsdma.c line 35

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+
+#define MTK_HSDMA_USEC_POLL		20
+#define MTK_HSDMA_TIMEOUT_POLL		200000
+#define MTK_HSDMA_DMA_BUSWIDTHS		BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)

Undefined buswidth??

drivers/dma/mediatek/mtk-hsdma.c line 114

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+/**
+ * struct mtk_hsdma_pdesc - This is the struct holding info describing physical
+ *			    descriptor (PD) and its placement must be kept at
+ *			    4-bytes alignment in little endian order.
+ * @desc[1-4]:		    The control pad used to indicate hardware how to

pls align to 80char or lesser

drivers/dma/mediatek/mtk-hsdma.c line 167

Quoted 12 lines
drivers/dma/mediatek/mtk-hsdma.c new file +12 -0
+/**
+ * struct mtk_hsdma_ring - This struct holds info describing underlying ring
+ *			   space
+ * @txd:		   The descriptor TX ring which describes DMA source
+ *			   information
+ * @rxd:		   The descriptor RX ring which describes DMA
+ *			   destination information
+ * @cb:			   The extra information pointed at by RX ring
+ * @tphys:		   The physical addr of TX ring
+ * @rphys:		   The physical addr of RX ring
+ * @cur_tptr:		   Pointer to the next free descriptor used by the host
+ * @cur_rptr:		   Pointer to the last done descriptor by the device

here alignment and 80 char wrap will help too and few other places...

drivers/dma/mediatek/mtk-hsdma.c line 207

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+struct mtk_hsdma_vchan {
+	struct virt_dma_chan vc;
+	struct completion issue_completion;
+	bool issue_synchronize;
+	/* protected by vc.lock */

this should be at comments above...

drivers/dma/mediatek/mtk-hsdma.c line 256

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+static struct mtk_hsdma_device *to_hsdma_dev(struct dma_chan *chan)
+{
+	return container_of(chan->device, struct mtk_hsdma_device,
+			    ddev);

and this can fit in a line

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+static int mtk_hsdma_alloc_pchan(struct mtk_hsdma_device *hsdma,
+				 struct mtk_hsdma_pchan *pc)
+{
+	struct mtk_hsdma_ring *ring = &pc->ring;
+	int err;

drivers/dma/mediatek/mtk-hsdma.c line 334

Quoted 10 lines
drivers/dma/mediatek/mtk-hsdma.c new file +10 -0
+
+	memset(pc, 0, sizeof(*pc));
+
+	/*
+	 * Allocate ring space where [0 ... MTK_DMA_SIZE - 1] is for TX ring
+	 * and [MTK_DMA_SIZE ... 2 * MTK_DMA_SIZE - 1] is for RX ring.
+	 */
+	pc->sz_ring = 2 * MTK_DMA_SIZE * sizeof(*ring->txd);
+	ring->txd = dma_zalloc_coherent(hsdma2dev(hsdma), pc->sz_ring,
+					&ring->tphys, GFP_ATOMIC);

GFP_NOWAIT please

drivers/dma/mediatek/mtk-hsdma.c line 343

Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+	if (!ring->txd)
+		return -ENOMEM;
+
+	ring->rxd = &ring->txd[MTK_DMA_SIZE];
+	ring->rphys = ring->tphys + MTK_DMA_SIZE * sizeof(*ring->txd);
+	ring->cur_tptr = 0;
+	ring->cur_rptr = MTK_DMA_SIZE - 1;
+
+	ring->cb = kcalloc(MTK_DMA_SIZE, sizeof(*ring->cb), GFP_KERNEL);

this is inconsistent with your own pattern! make it GFP_NOWAIT pls

Quoted 71 lines
drivers/dma/mediatek/mtk-hsdma.c new file +71 -0
+static int mtk_hsdma_issue_pending_vdesc(struct mtk_hsdma_device *hsdma,
+					 struct mtk_hsdma_pchan *pc,
+					 struct mtk_hsdma_vdesc *hvd)
+{
+	struct mtk_hsdma_ring *ring = &pc->ring;
+	struct mtk_hsdma_pdesc *txd, *rxd;
+	u16 reserved, prev, tlen, num_sgs;
+	unsigned long flags;
+
+	/* Protect against PC is accessed by multiple VCs simultaneously */
+	spin_lock_irqsave(&hsdma->lock, flags);
+
+	/*
+	 * Reserve rooms, where pc->nr_free is used to track how many free
+	 * rooms in the ring being updated in user and IRQ context.
+	 */
+	num_sgs = DIV_ROUND_UP(hvd->len, MTK_HSDMA_MAX_LEN);
+	reserved = min_t(u16, num_sgs, atomic_read(&pc->nr_free));
+
+	if (!reserved) {
+		spin_unlock_irqrestore(&hsdma->lock, flags);
+		return -ENOSPC;
+	}
+
+	atomic_sub(reserved, &pc->nr_free);
+
+	while (reserved--) {
+		/* Limit size by PD capability for valid data moving */
+		tlen = (hvd->len > MTK_HSDMA_MAX_LEN) ?
+		       MTK_HSDMA_MAX_LEN : hvd->len;
+
+		/*
+		 * Setup PDs using the remaining VD info mapped on those
+		 * reserved rooms. And since RXD is shared memory between the
+		 * host and the device allocated by dma_alloc_coherent call,
+		 * the helper macro WRITE_ONCE can ensure the data written to
+		 * RAM would really happens.
+		 */
+		txd = &ring->txd[ring->cur_tptr];
+		WRITE_ONCE(txd->desc1, hvd->src);
+		WRITE_ONCE(txd->desc2,
+			   hsdma->soc->ls0 | MTK_HSDMA_DESC_PLEN(tlen));
+
+		rxd = &ring->rxd[ring->cur_tptr];
+		WRITE_ONCE(rxd->desc1, hvd->dest);
+		WRITE_ONCE(rxd->desc2, MTK_HSDMA_DESC_PLEN(tlen));
+
+		/* Associate VD, the PD belonged to */
+		ring->cb[ring->cur_tptr].vd = &hvd->vd;
+
+		/* Move forward the pointer of TX ring */
+		ring->cur_tptr = MTK_HSDMA_NEXT_DESP_IDX(ring->cur_tptr,
+							 MTK_DMA_SIZE);
+
+		/* Update VD with remaining data */
+		hvd->src  += tlen;
+		hvd->dest += tlen;
+		hvd->len  -= tlen;
+	}
+
+	/*
+	 * Tagging flag for the last PD for VD will be responsible for
+	 * completing VD.
+	 */
+	if (!hvd->len) {
+		prev = MTK_HSDMA_LAST_DESP_IDX(ring->cur_tptr, MTK_DMA_SIZE);
+		ring->cb[prev].flag = MTK_HSDMA_VDESC_FINISHED;
+	}
+
+	/* Ensure all changes indeed done before we're going on */
+	wmb();

drivers/dma/mediatek/mtk-hsdma.c line 497

Quoted 10 lines
drivers/dma/mediatek/mtk-hsdma.c new file +10 -0
+
+	/*
+	 * Updating into hardware the pointer of TX ring lets HSDMA to take
+	 * action for those pending PDs.
+	 */
+	mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr);
+
+	spin_unlock_irqrestore(&hsdma->lock, flags);
+
+	return !hvd->len ? 0 : -ENOSPC;

you already wrote and started txn, so why this?

Quoted 17 lines
drivers/dma/mediatek/mtk-hsdma.c new file +17 -0
+static void mtk_hsdma_free_rooms_in_ring(struct mtk_hsdma_device *hsdma)
+{
+	struct mtk_hsdma_vchan *hvc;
+	struct mtk_hsdma_pdesc *rxd;
+	struct mtk_hsdma_vdesc *hvd;
+	struct mtk_hsdma_pchan *pc;
+	struct mtk_hsdma_cb *cb;
+	__le32 desc2;
+	u32 status;
+	u16 next;
+	int i;
+
+	pc = hsdma->pc;
+
+	/* Read IRQ status */
+	status = mtk_dma_read(hsdma, MTK_HSDMA_INT_STATUS);
+

drivers/dma/mediatek/mtk-hsdma.c line 564

Quoted 10 lines
drivers/dma/mediatek/mtk-hsdma.c new file +10 -0
+	/*
+	 * Ack the pending IRQ all to let hardware know software is handling
+	 * those finished physical descriptors. Otherwise, the hardware would
+	 * keep the used IRQ line in certain trigger state.
+	 */
+	mtk_dma_write(hsdma, MTK_HSDMA_INT_STATUS, status);
+
+	while (1) {
+		next = MTK_HSDMA_NEXT_DESP_IDX(pc->ring.cur_rptr,
+					       MTK_DMA_SIZE);

shouldn't we check if next is in range, we can crash if we get bad value from hardware..

drivers/dma/mediatek/mtk-hsdma.c line 573

Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+		rxd = &pc->ring.rxd[next];
+
+		/*
+		 * If MTK_HSDMA_DESC_DDONE is no specified, that means data
+		 * moving for the PD is still under going.
+		 */
+		desc2 = READ_ONCE(rxd->desc2);
+		if (!(desc2 & hsdma->soc->ddone))
+			break;

okay this is one break

drivers/dma/mediatek/mtk-hsdma.c line 578

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+
+		cb = &pc->ring.cb[next];
+		if (unlikely(!cb->vd)) {
+			dev_err(hsdma2dev(hsdma), "cb->vd cannot be null\n");
+			break;

and other for null, i feel we need to have checks for while(1) to break, this can run infinitely if something bad happens, a fail safe would be good, that too this being invoked from isr.

Quoted 12 lines
drivers/dma/mediatek/mtk-hsdma.c new file +12 -0
+static enum dma_status mtk_hsdma_tx_status(struct dma_chan *c,
+					   dma_cookie_t cookie,
+					   struct dma_tx_state *txstate)
+{
+	struct mtk_hsdma_vchan *hvc = to_hsdma_vchan(c);
+	struct mtk_hsdma_vdesc *hvd;
+	struct virt_dma_desc *vd;
+	enum dma_status ret;
+	unsigned long flags;
+	size_t bytes = 0;
+
+	ret = dma_cookie_status(c, cookie, txstate);

drivers/dma/mediatek/mtk-hsdma.c line 692

Quoted 10 lines
drivers/dma/mediatek/mtk-hsdma.c new file +10 -0
+	if (ret == DMA_COMPLETE || !txstate)
+		return ret;
+
+	spin_lock_irqsave(&hvc->vc.lock, flags);
+	vd = mtk_hsdma_find_active_desc(c, cookie);
+	spin_unlock_irqrestore(&hvc->vc.lock, flags);
+
+	if (vd) {
+		hvd = to_hsdma_vdesc(vd);
+		bytes = hvd->residue;

for active descriptor, shouldn't you read counters from hardware?

drivers/dma/mediatek/mtk-hsdma.c line 720

Quoted 7 lines
drivers/dma/mediatek/mtk-hsdma.c new file +7 -0
+static struct dma_async_tx_descriptor *
+mtk_hsdma_prep_dma_memcpy(struct dma_chan *c, dma_addr_t dest,
+			  dma_addr_t src, size_t len, unsigned long flags)
+{
+	struct mtk_hsdma_vdesc *hvd;
+
+	hvd = kzalloc(sizeof(*hvd), GFP_NOWAIT);

GFP_NOWAIT here too

drivers/dma/mediatek/mtk-hsdma.c line 767

Quoted 3 lines
drivers/dma/mediatek/mtk-hsdma.c new file +3 -0
+static int mtk_hsdma_terminate_all(struct dma_chan *c)
+{
+	mtk_hsdma_free_inactive_desc(c, false);

only inactive, active ones need to be freed and channel cleaned

Signature · 1 line
~Vinod
author maintainer
#5 lore raw

Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

Quoted 8 lines · Vinod Koul

drivers/dma/mediatek/mtk-hsdma.c line 1

Quoted 2 lines · On Sun, Feb 18, 2018 at 03:08:30AM +0800, [email protected] wrote:
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
@@ -0,0 +1,1054 @@
+// SPDX-License-Identifier: GPL-2.0

// Copyright ...

The copyright line needs to follow SPDX tag line

okay, I will make it reorder and be something like that

// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2017-2018 MediaTek Inc.
* Author: Sean Wang <[email protected]>
*
* Driver for MediaTek High-Speed DMA Controller
*
*/

Quoted 12 lines
Quoted 12 lines
drivers/dma/mediatek/mtk-hsdma.c new file +12 -0
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/iopoll.h>
+#include <linux/jiffies.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of.h>
Quoted 9 lines

drivers/dma/mediatek/mtk-hsdma.c line 27

Quoted 6 lines
drivers/dma/mediatek/mtk-hsdma.c new file +6 -0
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/refcount.h>
+#include <linux/slab.h>

that's a lot of headers, do u need all those?

okay, I will have more checks whether some header listed here is not necessary

Quoted 7 lines

drivers/dma/mediatek/mtk-hsdma.c line 31

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+
+#include "../virt-dma.h"
+
+#define MTK_DMA_DEV KBUILD_MODNAME

why do you need this?

the point is I learned from other subsystem makes the driver name be same with the module name with KBUILD_MODNAME.

If you really don't like it, I can just change it into

#define MTK_DMA_DEV "mtk-hsdma"

Quoted 7 lines

drivers/dma/mediatek/mtk-hsdma.c line 35

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+
+#define MTK_HSDMA_USEC_POLL		20
+#define MTK_HSDMA_TIMEOUT_POLL		200000
+#define MTK_HSDMA_DMA_BUSWIDTHS		BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)

Undefined buswidth??

Quoted 8 lines

drivers/dma/mediatek/mtk-hsdma.c line 114

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+/**
+ * struct mtk_hsdma_pdesc - This is the struct holding info describing physical
+ *			    descriptor (PD) and its placement must be kept at
+ *			    4-bytes alignment in little endian order.
+ * @desc[1-4]:		    The control pad used to indicate hardware how to

pls align to 80char or lesser

weird, it seems the line is already with 80 char and pass the checkpatch.pl. or do I misunderstand something ?

Quoted 13 lines

drivers/dma/mediatek/mtk-hsdma.c line 167

Quoted 12 lines
drivers/dma/mediatek/mtk-hsdma.c new file +12 -0
+/**
+ * struct mtk_hsdma_ring - This struct holds info describing underlying ring
+ *			   space
+ * @txd:		   The descriptor TX ring which describes DMA source
+ *			   information
+ * @rxd:		   The descriptor RX ring which describes DMA
+ *			   destination information
+ * @cb:			   The extra information pointed at by RX ring
+ * @tphys:		   The physical addr of TX ring
+ * @rphys:		   The physical addr of RX ring
+ * @cur_tptr:		   Pointer to the next free descriptor used by the host
+ * @cur_rptr:		   Pointer to the last done descriptor by the device
Quoted 2 lines

here alignment and 80 char wrap will help too and few other places...

Also weird, it seems the line is already with 80 char and pass the checkpatch.pl. or do I misunderstand something ?

Quoted 9 lines

drivers/dma/mediatek/mtk-hsdma.c line 207

Quoted 6 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+struct mtk_hsdma_vchan {
+	struct virt_dma_chan vc;
+	struct completion issue_completion;
+	bool issue_synchronize;
+	/* protected by vc.lock */

this should be at comments above...

Quoted 7 lines

drivers/dma/mediatek/mtk-hsdma.c line 256

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+static struct mtk_hsdma_device *to_hsdma_dev(struct dma_chan *chan)
+{
+	return container_of(chan->device, struct mtk_hsdma_device,
+			    ddev);

and this can fit in a line

Thanks, I will improve it.

Quoted 9 lines
Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+static int mtk_hsdma_alloc_pchan(struct mtk_hsdma_device *hsdma,
+				 struct mtk_hsdma_pchan *pc)
+{
+	struct mtk_hsdma_ring *ring = &pc->ring;
+	int err;
+
+	memset(pc, 0, sizeof(*pc));
+
+	/*
Quoted 9 lines

drivers/dma/mediatek/mtk-hsdma.c line 334

Quoted 6 lines
drivers/dma/mediatek/mtk-hsdma.c new file +6 -0
+	 * Allocate ring space where [0 ... MTK_DMA_SIZE - 1] is for TX ring
+	 * and [MTK_DMA_SIZE ... 2 * MTK_DMA_SIZE - 1] is for RX ring.
+	 */
+	pc->sz_ring = 2 * MTK_DMA_SIZE * sizeof(*ring->txd);
+	ring->txd = dma_zalloc_coherent(hsdma2dev(hsdma), pc->sz_ring,
+					&ring->tphys, GFP_ATOMIC);

GFP_NOWAIT please

Thanks, I will improve it with GFP_NOWAIT.

Quoted 12 lines

drivers/dma/mediatek/mtk-hsdma.c line 343

Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+	if (!ring->txd)
+		return -ENOMEM;
+
+	ring->rxd = &ring->txd[MTK_DMA_SIZE];
+	ring->rphys = ring->tphys + MTK_DMA_SIZE * sizeof(*ring->txd);
+	ring->cur_tptr = 0;
+	ring->cur_rptr = MTK_DMA_SIZE - 1;
+
+	ring->cb = kcalloc(MTK_DMA_SIZE, sizeof(*ring->cb), GFP_KERNEL);

this is inconsistent with your own pattern! make it GFP_NOWAIT pls

Ditto, I will improve it with GFP_NOWAIT.

Quoted 75 lines
Quoted 75 lines
drivers/dma/mediatek/mtk-hsdma.c new file +75 -0
+static int mtk_hsdma_issue_pending_vdesc(struct mtk_hsdma_device *hsdma,
+					 struct mtk_hsdma_pchan *pc,
+					 struct mtk_hsdma_vdesc *hvd)
+{
+	struct mtk_hsdma_ring *ring = &pc->ring;
+	struct mtk_hsdma_pdesc *txd, *rxd;
+	u16 reserved, prev, tlen, num_sgs;
+	unsigned long flags;
+
+	/* Protect against PC is accessed by multiple VCs simultaneously */
+	spin_lock_irqsave(&hsdma->lock, flags);
+
+	/*
+	 * Reserve rooms, where pc->nr_free is used to track how many free
+	 * rooms in the ring being updated in user and IRQ context.
+	 */
+	num_sgs = DIV_ROUND_UP(hvd->len, MTK_HSDMA_MAX_LEN);
+	reserved = min_t(u16, num_sgs, atomic_read(&pc->nr_free));
+
+	if (!reserved) {
+		spin_unlock_irqrestore(&hsdma->lock, flags);
+		return -ENOSPC;
+	}
+
+	atomic_sub(reserved, &pc->nr_free);
+
+	while (reserved--) {
+		/* Limit size by PD capability for valid data moving */
+		tlen = (hvd->len > MTK_HSDMA_MAX_LEN) ?
+		       MTK_HSDMA_MAX_LEN : hvd->len;
+
+		/*
+		 * Setup PDs using the remaining VD info mapped on those
+		 * reserved rooms. And since RXD is shared memory between the
+		 * host and the device allocated by dma_alloc_coherent call,
+		 * the helper macro WRITE_ONCE can ensure the data written to
+		 * RAM would really happens.
+		 */
+		txd = &ring->txd[ring->cur_tptr];
+		WRITE_ONCE(txd->desc1, hvd->src);
+		WRITE_ONCE(txd->desc2,
+			   hsdma->soc->ls0 | MTK_HSDMA_DESC_PLEN(tlen));
+
+		rxd = &ring->rxd[ring->cur_tptr];
+		WRITE_ONCE(rxd->desc1, hvd->dest);
+		WRITE_ONCE(rxd->desc2, MTK_HSDMA_DESC_PLEN(tlen));
+
+		/* Associate VD, the PD belonged to */
+		ring->cb[ring->cur_tptr].vd = &hvd->vd;
+
+		/* Move forward the pointer of TX ring */
+		ring->cur_tptr = MTK_HSDMA_NEXT_DESP_IDX(ring->cur_tptr,
+							 MTK_DMA_SIZE);
+
+		/* Update VD with remaining data */
+		hvd->src  += tlen;
+		hvd->dest += tlen;
+		hvd->len  -= tlen;
+	}
+
+	/*
+	 * Tagging flag for the last PD for VD will be responsible for
+	 * completing VD.
+	 */
+	if (!hvd->len) {
+		prev = MTK_HSDMA_LAST_DESP_IDX(ring->cur_tptr, MTK_DMA_SIZE);
+		ring->cb[prev].flag = MTK_HSDMA_VDESC_FINISHED;
+	}
+
+	/* Ensure all changes indeed done before we're going on */
+	wmb();
+
+	/*
+	 * Updating into hardware the pointer of TX ring lets HSDMA to take
+	 * action for those pending PDs.
Quoted 9 lines

drivers/dma/mediatek/mtk-hsdma.c line 497

Quoted 6 lines
drivers/dma/mediatek/mtk-hsdma.c new file +6 -0
+	 */
+	mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr);
+
+	spin_unlock_irqrestore(&hsdma->lock, flags);
+
+	return !hvd->len ? 0 : -ENOSPC;

you already wrote and started txn, so why this?

it's possible just partial virtual descriptor fits into hardware and then return -ENOSPC. And it will start it to complete the remaining part as soon as possible when some rooms is being freed.

Quoted 22 lines
Quoted 22 lines
drivers/dma/mediatek/mtk-hsdma.c new file +22 -0
+static void mtk_hsdma_free_rooms_in_ring(struct mtk_hsdma_device *hsdma)
+{
+	struct mtk_hsdma_vchan *hvc;
+	struct mtk_hsdma_pdesc *rxd;
+	struct mtk_hsdma_vdesc *hvd;
+	struct mtk_hsdma_pchan *pc;
+	struct mtk_hsdma_cb *cb;
+	__le32 desc2;
+	u32 status;
+	u16 next;
+	int i;
+
+	pc = hsdma->pc;
+
+	/* Read IRQ status */
+	status = mtk_dma_read(hsdma, MTK_HSDMA_INT_STATUS);
+
+	/*
+	 * Ack the pending IRQ all to let hardware know software is handling
+	 * those finished physical descriptors. Otherwise, the hardware would
+	 * keep the used IRQ line in certain trigger state.
+	 */
Quoted 8 lines

drivers/dma/mediatek/mtk-hsdma.c line 564

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+	mtk_dma_write(hsdma, MTK_HSDMA_INT_STATUS, status);
+
+	while (1) {
+		next = MTK_HSDMA_NEXT_DESP_IDX(pc->ring.cur_rptr,
+					       MTK_DMA_SIZE);

shouldn't we check if next is in range, we can crash if we get bad value from hardware..

okay, there are checks for next with ddone bit check and null check in the corresponding descriptor as the following.

Quoted 12 lines

drivers/dma/mediatek/mtk-hsdma.c line 573

Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+		rxd = &pc->ring.rxd[next];
+
+		/*
+		 * If MTK_HSDMA_DESC_DDONE is no specified, that means data
+		 * moving for the PD is still under going.
+		 */
+		desc2 = READ_ONCE(rxd->desc2);
+		if (!(desc2 & hsdma->soc->ddone))
+			break;

okay this is one break

Quoted 10 lines

drivers/dma/mediatek/mtk-hsdma.c line 578

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+
+		cb = &pc->ring.cb[next];
+		if (unlikely(!cb->vd)) {
+			dev_err(hsdma2dev(hsdma), "cb->vd cannot be null\n");
+			break;

and other for null, i feel we need to have checks for while(1) to break, this can run infinitely if something bad happens, a fail safe would be good, that too this being invoked from isr.

Agreed, I will have more consideration to add a way for fail safe, such as timeout.

Quoted 16 lines
Quoted 16 lines
drivers/dma/mediatek/mtk-hsdma.c new file +16 -0
+static enum dma_status mtk_hsdma_tx_status(struct dma_chan *c,
+					   dma_cookie_t cookie,
+					   struct dma_tx_state *txstate)
+{
+	struct mtk_hsdma_vchan *hvc = to_hsdma_vchan(c);
+	struct mtk_hsdma_vdesc *hvd;
+	struct virt_dma_desc *vd;
+	enum dma_status ret;
+	unsigned long flags;
+	size_t bytes = 0;
+
+	ret = dma_cookie_status(c, cookie, txstate);
+	if (ret == DMA_COMPLETE || !txstate)
+		return ret;
+
+	spin_lock_irqsave(&hvc->vc.lock, flags);
Quoted 9 lines

drivers/dma/mediatek/mtk-hsdma.c line 692

Quoted 6 lines
drivers/dma/mediatek/mtk-hsdma.c new file +6 -0
+	vd = mtk_hsdma_find_active_desc(c, cookie);
+	spin_unlock_irqrestore(&hvc->vc.lock, flags);
+
+	if (vd) {
+		hvd = to_hsdma_vdesc(vd);
+		bytes = hvd->residue;

for active descriptor, shouldn't you read counters from hardware?

the hardware doesn't support counters for residue for any active descriptor. this residue is completely maintained in software way.

Quoted 9 lines

drivers/dma/mediatek/mtk-hsdma.c line 720

Quoted 7 lines
drivers/dma/mediatek/mtk-hsdma.c new file +7 -0
+static struct dma_async_tx_descriptor *
+mtk_hsdma_prep_dma_memcpy(struct dma_chan *c, dma_addr_t dest,
+			  dma_addr_t src, size_t len, unsigned long flags)
+{
+	struct mtk_hsdma_vdesc *hvd;
+
+	hvd = kzalloc(sizeof(*hvd), GFP_NOWAIT);

GFP_NOWAIT here too

It's already GFP_NOWAIT. And I will check more with all memory allocation with the GFP_NOWAIT.

Quoted 7 lines

drivers/dma/mediatek/mtk-hsdma.c line 767

Quoted 4 lines
drivers/dma/mediatek/mtk-hsdma.c new file +3 -0
+static int mtk_hsdma_terminate_all(struct dma_chan *c)
+{
+	mtk_hsdma_free_inactive_desc(c, false);

only inactive, active ones need to be freed and channel cleaned

okay, also make all active ones to be freed.
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw

Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

Quoted 12 lines · Sean Wang
Quoted 8 lines · Vinod Koul

drivers/dma/mediatek/mtk-hsdma.c line 1

Quoted 2 lines · On Sun, Feb 18, 2018 at 03:08:30AM +0800, [email protected] wrote:
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
@@ -0,0 +1,1054 @@
+// SPDX-License-Identifier: GPL-2.0

// Copyright ...

The copyright line needs to follow SPDX tag line

okay, I will make it reorder and be something like that

Quoted 8 lines

// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2017-2018 MediaTek Inc.
* Author: Sean Wang <[email protected]>
*
* Driver for MediaTek High-Speed DMA Controller
*
*/

It needs to be:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018 MediaTek Inc.

/*
* whatever else you want
*/

The first two lines are in C99 style comment and need to have SPDX tag and Copyright info

Quoted 6 lines

the point is I learned from other subsystem makes the driver name be same with the module name with KBUILD_MODNAME.

If you really don't like it, I can just change it into

#define MTK_DMA_DEV "mtk-hsdma"

It is used only once, why not use KBUILD_MODNAME directly?

Quoted 7 lines
Quoted 7 lines

drivers/dma/mediatek/mtk-hsdma.c line 35

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+
+#define MTK_HSDMA_USEC_POLL		20
+#define MTK_HSDMA_TIMEOUT_POLL		200000
+#define MTK_HSDMA_DMA_BUSWIDTHS		BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)

Undefined buswidth??

??

Quoted 11 lines
Quoted 8 lines

drivers/dma/mediatek/mtk-hsdma.c line 114

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+/**
+ * struct mtk_hsdma_pdesc - This is the struct holding info describing physical
+ *			    descriptor (PD) and its placement must be kept at
+ *			    4-bytes alignment in little endian order.
+ * @desc[1-4]:		    The control pad used to indicate hardware how to

pls align to 80char or lesser

weird, it seems the line is already with 80 char and pass the checkpatch.pl. or do I misunderstand something ?

Okay please check. With text it helps to wrap before that

Quoted 13 lines
Quoted 12 lines

drivers/dma/mediatek/mtk-hsdma.c line 497

Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+	/*
+	 * Updating into hardware the pointer of TX ring lets HSDMA to take
+	 * action for those pending PDs.
+	 */
+	mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr);
+
+	spin_unlock_irqrestore(&hsdma->lock, flags);
+
+	return !hvd->len ? 0 : -ENOSPC;

you already wrote and started txn, so why this?

Quoted 3 lines

it's possible just partial virtual descriptor fits into hardware and then return -ENOSPC. And it will start it to complete the remaining part as soon as possible when some rooms is being freed.

Either ways you have issued the descriptor, so you succeed right?

Quoted 5 lines
Quoted 2 lines

shouldn't we check if next is in range, we can crash if we get bad value from hardware..

okay, there are checks for next with ddone bit check and null check in the corresponding descriptor as the following.

what if you get bad next value

Quoted 2 lines
Quoted 2 lines

drivers/dma/mediatek/mtk-hsdma.c line 565

Quoted 2 lines
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
+		rxd = &pc->ring.rxd[next];

resulting in bad ref here

Signature · 1 line
~Vinod
author maintainer
#7 lore raw

Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

Hi, Vinod

Quoted 27 lines · Vinod Koul
Quoted 12 lines · Sean Wang
Quoted 8 lines · Vinod Koul

drivers/dma/mediatek/mtk-hsdma.c line 1

Quoted 2 lines · On Sun, Feb 18, 2018 at 03:08:30AM +0800, [email protected] wrote:
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
@@ -0,0 +1,1054 @@
+// SPDX-License-Identifier: GPL-2.0

// Copyright ...

The copyright line needs to follow SPDX tag line

okay, I will make it reorder and be something like that

Quoted 8 lines

// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2017-2018 MediaTek Inc.
* Author: Sean Wang <[email protected]>
*
* Driver for MediaTek High-Speed DMA Controller
*
*/

It needs to be:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018 MediaTek Inc.

Quoted 6 lines

/*
* whatever else you want
*/

The first two lines are in C99 style comment and need to have SPDX tag and Copyright info

Sure, I can do it using C99 style comments at the first two lines.

In addition, I'm really curious where we can find a reference to the rule and if it 's a strict rule for all the drivers.

Because I'm considering whether I should turn other driver into using the same rule.

Quoted 9 lines
Quoted 6 lines

the point is I learned from other subsystem makes the driver name be same with the module name with KBUILD_MODNAME.

If you really don't like it, I can just change it into

#define MTK_DMA_DEV "mtk-hsdma"

It is used only once, why not use KBUILD_MODNAME directly?

Yup, it can use KBUILD_MODNAME directly.

Quoted 9 lines
Quoted 7 lines
Quoted 7 lines

drivers/dma/mediatek/mtk-hsdma.c line 35

Quoted 5 lines
drivers/dma/mediatek/mtk-hsdma.c new file +4 -0
+
+#define MTK_HSDMA_USEC_POLL		20
+#define MTK_HSDMA_TIMEOUT_POLL		200000
+#define MTK_HSDMA_DMA_BUSWIDTHS		BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)

Undefined buswidth??

??

Sorry for I didn't answer the question in the short time.

After spending some time on a confirmation with design, it is DMA_SLAVE_BUSWIDTH_4_BYTES and not be configurable.

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
drivers/dma/mediatek/mtk-hsdma.c new file +5 -0
+/**
+ * struct mtk_hsdma_pdesc - This is the struct holding info describing physical
+ *			    descriptor (PD) and its placement must be kept at
+ *			    4-bytes alignment in little endian order.
+ * @desc[1-4]:		    The control pad used to indicate hardware how to
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

pls align to 80char or lesser

weird, it seems the line is already with 80 char and pass the checkpatch.pl. or do I misunderstand something ?

Okay please check. With text it helps to wrap before that

After check again, these lines are all already aligned to 80 chars

Quoted 13 lines
Quoted 13 lines
Quoted 12 lines

drivers/dma/mediatek/mtk-hsdma.c line 497

Quoted 9 lines
drivers/dma/mediatek/mtk-hsdma.c new file +9 -0
+	/*
+	 * Updating into hardware the pointer of TX ring lets HSDMA to take
+	 * action for those pending PDs.
+	 */
+	mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr);
+
+	spin_unlock_irqrestore(&hsdma->lock, flags);
+
+	return !hvd->len ? 0 : -ENOSPC;

you already wrote and started txn, so why this?

Quoted 6 lines
Quoted 3 lines

it's possible just partial virtual descriptor fits into hardware and then return -ENOSPC. And it will start it to complete the remaining part as soon as possible when some rooms is being freed.

Either ways you have issued the descriptor, so you succeed right?

I think I should get your points.

I guessed what you meant is that it should be returning 0 instead of -ENOSPC for all successful descriptor issuing either in part or in full

I will refine this flow based on the thought.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

shouldn't we check if next is in range, we can crash if we get bad value from hardware..

okay, there are checks for next with ddone bit check and null check in the corresponding descriptor as the following.

what if you get bad next value

next is not hardware value. it's maintained by software which is always between 0 to MTK_DMA_SIZE - 1, and definitely doesn't get a bad value.

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines

drivers/dma/mediatek/mtk-hsdma.c line 565

Quoted 2 lines
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
+		rxd = &pc->ring.rxd[next];

resulting in bad ref here

rxd is also definitely a good ref

Quoted 1 line

---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw

Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

Quoted 37 lines · Sean Wang

Hi, Vinod

Quoted 27 lines · Vinod Koul
Quoted 12 lines · Sean Wang
Quoted 8 lines · Vinod Koul

drivers/dma/mediatek/mtk-hsdma.c line 1

Quoted 2 lines · On Sun, Feb 18, 2018 at 03:08:30AM +0800, [email protected] wrote:
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
@@ -0,0 +1,1054 @@
+// SPDX-License-Identifier: GPL-2.0

// Copyright ...

The copyright line needs to follow SPDX tag line

okay, I will make it reorder and be something like that

Quoted 8 lines

// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2017-2018 MediaTek Inc.
* Author: Sean Wang <[email protected]>
*
* Driver for MediaTek High-Speed DMA Controller
*
*/

It needs to be:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018 MediaTek Inc.

Quoted 6 lines

/*
* whatever else you want
*/

The first two lines are in C99 style comment and need to have SPDX tag and Copyright info

Quoted 7 lines

Sure, I can do it using C99 style comments at the first two lines.

In addition, I'm really curious where we can find a reference to the rule and if it 's a strict rule for all the drivers.

Because I'm considering whether I should turn other driver into using the same rule.

Yes that seems to be the rule now https://lkml.org/lkml/2017/11/2/715

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines

drivers/dma/mediatek/mtk-hsdma.c line 35

Quoted 3 lines
drivers/dma/mediatek/mtk-hsdma.c new file +3 -0
+#define MTK_HSDMA_USEC_POLL		20
+#define MTK_HSDMA_TIMEOUT_POLL		200000
+#define MTK_HSDMA_DMA_BUSWIDTHS		BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)

Undefined buswidth??

Quoted 6 lines
Quoted 1 line

??

Sorry for I didn't answer the question in the short time.

After spending some time on a confirmation with design, it is DMA_SLAVE_BUSWIDTH_4_BYTES and not be configurable.

Then it should be DMA_SLAVE_BUSWIDTH_4_BYTES and not DMA_SLAVE_BUSWIDTH_UNDEFINED...

Quoted 13 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

shouldn't we check if next is in range, we can crash if we get bad value from hardware..

okay, there are checks for next with ddone bit check and null check in the corresponding descriptor as the following.

what if you get bad next value

next is not hardware value. it's maintained by software which is always between 0 to MTK_DMA_SIZE - 1, and definitely doesn't get a bad value.

Quoted 1 line
Quoted 1 line
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

drivers/dma/mediatek/mtk-hsdma.c line 565

Quoted 1 line
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
+		rxd = &pc->ring.rxd[next];

resulting in bad ref here

rxd is also definitely a good ref

not if next is out of range, say you read -1 or 200000?

Signature · 1 line
~Vinod
author maintainer
#9 lore raw

Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC

Quoted 40 lines · Vinod Koul
Quoted 39 lines · Sean Wang

Hi, Vinod

Quoted 27 lines · Vinod Koul
Quoted 12 lines · Sean Wang
Quoted 8 lines · Vinod Koul

drivers/dma/mediatek/mtk-hsdma.c line 1

Quoted 2 lines · On Sun, Feb 18, 2018 at 03:08:30AM +0800, [email protected] wrote:
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
@@ -0,0 +1,1054 @@
+// SPDX-License-Identifier: GPL-2.0

// Copyright ...

The copyright line needs to follow SPDX tag line

okay, I will make it reorder and be something like that

Quoted 8 lines

// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2017-2018 MediaTek Inc.
* Author: Sean Wang <[email protected]>
*
* Driver for MediaTek High-Speed DMA Controller
*
*/

It needs to be:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018 MediaTek Inc.

Quoted 6 lines

/*
* whatever else you want
*/

The first two lines are in C99 style comment and need to have SPDX tag and Copyright info

Sure, I can do it using C99 style comments at the first two lines.

Quoted 8 lines
Quoted 5 lines

In addition, I'm really curious where we can find a reference to the rule and if it 's a strict rule for all the drivers.

Because I'm considering whether I should turn other driver into using the same rule.

Yes that seems to be the rule now https://lkml.org/lkml/2017/11/2/715

Where could I find the rule for the copyright line needed to follow SPDX tag line ?

currently, I still seen tons of drivers putting its copyright inside /* ...
*
*/

Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines

drivers/dma/mediatek/mtk-hsdma.c line 35

Quoted 3 lines
drivers/dma/mediatek/mtk-hsdma.c new file +3 -0
+#define MTK_HSDMA_USEC_POLL		20
+#define MTK_HSDMA_TIMEOUT_POLL		200000
+#define MTK_HSDMA_DMA_BUSWIDTHS		BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)

Undefined buswidth??

??

Quoted 8 lines
Quoted 4 lines

Sorry for I didn't answer the question in the short time.

After spending some time on a confirmation with design, it is DMA_SLAVE_BUSWIDTH_4_BYTES and not be configurable.

Then it should be DMA_SLAVE_BUSWIDTH_4_BYTES and not DMA_SLAVE_BUSWIDTH_UNDEFINED...

understood, I will do it.

Quoted 13 lines
Quoted 13 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

shouldn't we check if next is in range, we can crash if we get bad value from hardware..

okay, there are checks for next with ddone bit check and null check in the corresponding descriptor as the following.

what if you get bad next value

next is not hardware value. it's maintained by software which is always between 0 to MTK_DMA_SIZE - 1, and definitely doesn't get a bad value.

Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

drivers/dma/mediatek/mtk-hsdma.c line 565

Quoted 1 line
drivers/dma/mediatek/mtk-hsdma.c new file +1 -0
+		rxd = &pc->ring.rxd[next];

resulting in bad ref here

rxd is also definitely a good ref

not if next is out of range, say you read -1 or 200000?

next must be in range because next is calculated by MTK_HSDMA_NEXT_DESP_IDX macro which is just a modulo operation with MTK_DMA_SIZE.

Currently, MTK_DMA_SIZE is equal to 64 and thus next must be 0 to 63 and wraparound.

As to MTK_HSDMA_NEXT_DESP_IDX , it is defined as the following
#define MTK_HSDMA_NEXT_DESP_IDX(x, y) (((x) + 1) & ((y) - 1))
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html