linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] Add SFC support for Ingenic SoCs.
@ 2022-07-22 16:48 周琰杰 (Zhou Yanjie)
  2022-07-22 16:48 ` [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs 周琰杰 (Zhou Yanjie)
                   ` (3 more replies)
  0 siblings, 4 replies; 39+ messages in thread
From: 周琰杰 (Zhou Yanjie) @ 2022-07-22 16:48 UTC (permalink / raw)
  To: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.

Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.

周琰杰 (Zhou Yanjie) (3):
  mtd: spi-nor: Use the spi-mem poll status APIs.
  dt-bindings: SPI: Add Ingenic SFC bindings.
  SPI: Ingenic: Add SFC support for Ingenic SoCs.

 .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
 drivers/mtd/spi-nor/core.c                         |  42 +-
 drivers/spi/Kconfig                                |   9 +
 drivers/spi/Makefile                               |   1 +
 drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
 5 files changed, 768 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
 create mode 100755 drivers/spi/spi-ingenic-sfc.c

-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs.
  2022-07-22 16:48 [PATCH 0/3] Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
@ 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie)
  2022-07-23  8:30   ` Sergey Shtylyov
  2022-07-22 16:48 ` [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings 周琰杰 (Zhou Yanjie)
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 39+ messages in thread
From: 周琰杰 (Zhou Yanjie) @ 2022-07-22 16:48 UTC (permalink / raw)
  To: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

With advanced controllers (such as Ingenic SFC), it is possible to poll
the status register of the device. This could be done to offload the CPU
during a erase or write operation. Make use of spi-mem poll status APIs
to handle this feature.

Previously, when erasing large area (e.g. 32MiB), in non-offload case,
CPU load could reach ~90% and would generate ~3.92 million interrupts,
now it decrease to ~15% CPU load and 0.15 million interrupts.

This should also fix the high CPU usage for system which don't have a
dedicated poll status block logic (decrease to ~80% CPU load and ~1.61
million interrupts.).

Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
 drivers/mtd/spi-nor/core.c | 42 ++++++++++++++++++++++++++++++++----------
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 502967c..6a31132 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -617,19 +617,41 @@ static int spi_nor_wait_till_ready_with_timeout(struct spi_nor *nor,
 	unsigned long deadline;
 	int timeout = 0, ret;
 
-	deadline = jiffies + timeout_jiffies;
+	if (nor->spimem && !nor->params->ready) {
+		struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDSR, 0),
+						       SPI_MEM_OP_NO_ADDR,
+						       SPI_MEM_OP_NO_DUMMY,
+						       SPI_MEM_OP_DATA_IN(1, nor->bouncebuf, 0));
 
-	while (!timeout) {
-		if (time_after_eq(jiffies, deadline))
-			timeout = 1;
+		if (nor->reg_proto == SNOR_PROTO_8_8_8_DTR) {
+			op.addr.nbytes = nor->params->rdsr_addr_nbytes;
+			op.dummy.nbytes = nor->params->rdsr_dummy;
+			/*
+			 * We don't want to read only one byte in DTR mode. So,
+			 * read 2 and then discard the second byte.
+			 */
+			op.data.nbytes = 2;
+		}
 
-		ret = spi_nor_ready(nor);
-		if (ret < 0)
-			return ret;
-		if (ret)
-			return 0;
+		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
+		return spi_mem_poll_status(nor->spimem, &op, SR_WIP, 0, 0, 10,
+						       jiffies_to_msecs(timeout_jiffies));
+	} else {
+		deadline = jiffies + timeout_jiffies;
 
-		cond_resched();
+		while (!timeout) {
+			if (time_after_eq(jiffies, deadline))
+				timeout = 1;
+
+			ret = spi_nor_ready(nor);
+			if (ret < 0)
+				return ret;
+			if (ret)
+				return 0;
+
+			cond_resched();
+		}
 	}
 
 	dev_dbg(nor->dev, "flash operation timed out\n");
-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 39+ messages in thread

* [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-22 16:48 [PATCH 0/3] Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
  2022-07-22 16:48 ` [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs 周琰杰 (Zhou Yanjie)
@ 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie)
  2022-07-22 17:46   ` Krzysztof Kozlowski
  2022-07-22 22:44   ` Rob Herring
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
  2022-07-23 14:47 ` [PATCH 0/3] " Tomasz Maciej Nowak
  3 siblings, 2 replies; 39+ messages in thread
From: 周琰杰 (Zhou Yanjie) @ 2022-07-22 16:48 UTC (permalink / raw)
  To: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
and the X2000 SoC from Ingenic.

Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
 .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml

diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
new file mode 100644
index 00000000..b7c4cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for SFC in Ingenic SoCs
+
+maintainers:
+  - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+
+description:
+  The SPI Flash Controller in Ingenic SoCs.
+
+properties:
+  compatible:
+    oneOf:
+      - enum:
+          - ingenic,x1000-sfc
+          - ingenic,x1600-sfc
+          - ingenic,x2000-sfc
+      - items:
+          - enum:
+              - ingenic,x1830-sfc
+          - const: ingenic,x1000-sfc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    const: sfc
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/ingenic,x1000-cgu.h>
+
+	sfc: spi@13440000 {
+		compatible = "ingenic,x1000-sfc";
+		reg = <0x13440000 0x1000>;
+
+		interrupt-parent = <&intc>;
+		interrupts = <7>;
+
+		clocks = <&cgu X1000_CLK_SFC>;
+		clock-names = "sfc";
+
+		status = "disabled";
+	};
+...
-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 39+ messages in thread

* [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 [PATCH 0/3] Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
  2022-07-22 16:48 ` [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs 周琰杰 (Zhou Yanjie)
  2022-07-22 16:48 ` [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings 周琰杰 (Zhou Yanjie)
@ 2022-07-22 16:48 ` 周琰杰 (Zhou Yanjie)
  2022-07-22 18:07   ` Krzysztof Kozlowski
                     ` (4 more replies)
  2022-07-23 14:47 ` [PATCH 0/3] " Tomasz Maciej Nowak
  3 siblings, 5 replies; 39+ messages in thread
From: 周琰杰 (Zhou Yanjie) @ 2022-07-22 16:48 UTC (permalink / raw)
  To: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
from Ingenic.

Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
 drivers/spi/Kconfig           |   9 +
 drivers/spi/Makefile          |   1 +
 drivers/spi/spi-ingenic-sfc.c | 662 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 672 insertions(+)
 create mode 100644 drivers/spi/spi-ingenic-sfc.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 3b1044e..1077bd3 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -437,6 +437,15 @@ config SPI_INGENIC
 	  To compile this driver as a module, choose M here: the module
 	  will be called spi-ingenic.
 
+config SPI_INGENIC_SFC
+	tristate "Ingenic SoCs SPI Flash Controller"
+	depends on MACH_INGENIC || COMPILE_TEST
+	help
+	  This enables support for the Ingenic SoCs SPI flash controller.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called ingenic-sfc.
+
 config SPI_INTEL
 	tristate
 
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 0f44eb6..f3e42c0 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)		+= spi-hisi-sfc-v3xx.o
 obj-$(CONFIG_SPI_IMG_SPFI)		+= spi-img-spfi.o
 obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
 obj-$(CONFIG_SPI_INGENIC)		+= spi-ingenic.o
+obj-$(CONFIG_SPI_INGENIC_SFC)	+= spi-ingenic-sfc.o
 obj-$(CONFIG_SPI_INTEL)			+= spi-intel.o
 obj-$(CONFIG_SPI_INTEL_PCI)		+= spi-intel-pci.o
 obj-$(CONFIG_SPI_INTEL_PLATFORM)	+= spi-intel-platform.o
diff --git a/drivers/spi/spi-ingenic-sfc.c b/drivers/spi/spi-ingenic-sfc.c
new file mode 100644
index 00000000..a565546
--- /dev/null
+++ b/drivers/spi/spi-ingenic-sfc.c
@@ -0,0 +1,662 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Ingenic SoCs SPI Flash Controller Driver
+ * Copyright (c) 2022 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi-mem.h>
+
+/* SFC register offsets */
+#define SFC_REG_GLB						0x0000
+#define SFC_REG_DEV_CONF				0x0004
+#define SFC_REG_DEV_STA_EXP				0x0008
+#define SFC_REG_DEV_STA_RT				0x000c
+#define SFC_REG_DEV_STA_MSK				0x0010
+#define SFC_REG_TRAN_CONF(n)			(0x0014 + n * 4)
+#define SFC_REG_TRAN_CFG0(n)			(0x0014 + n * 4)
+#define SFC_REG_TRAN_LEN				0x002c
+#define SFC_REG_DEV_ADDR(n)				(0x0030 + n * 4)
+#define SFC_REG_DEV_ADDR_PLUS(n)		(0x0048 + n * 4)
+#define SFC_REG_MEM_ADDR				0x0060
+#define SFC_REG_TRIG					0x0064
+#define SFC_REG_SR						0x0068
+#define SFC_REG_SCR						0x006c
+#define SFC_REG_INTC					0x0070
+#define SFC_REG_FSM						0x0074
+#define SFC_REG_CGE						0x0078
+#define SFC_REG_TRAN_CFG1(n)			(0x009c + n * 4)
+#define SFC_REG_DR						0x1000
+
+/* bits within the GLB register */
+#define GLB_TRAN_DIR_MASK				GENMASK(13, 13)
+#define GLB_TRAN_DIR_WRITE				0x1
+#define GLB_TRAN_DIR_READ				0x0
+#define GLB_THRESHOLD_MASK				GENMASK(12, 7)
+#define GLB_OP_MODE_MASK				GENMASK(6, 6)
+#define GLB_OP_MODE_DMA					0x1
+#define GLB_OP_MODE_SLAVE				0x0
+#define GLB_PHASE_NUM_MASK				GENMASK(5, 3)
+#define GLB_WP_EN						BIT(2)
+#define GLB_BURST_MD_MASK				GENMASK(1, 0)
+#define GLB_BURST_MD_INCR32				0x3
+#define GLB_BURST_MD_INCR16				0x2
+#define GLB_BURST_MD_INCR8				0x1
+#define GLB_BURST_MD_INCR4				0x0
+
+/* bits within the DEV_CONF register */
+#define DEV_CONF_SMP_DELAY_MASK			GENMASK(20, 16)
+#define DEV_CONF_SMP_DELAY_180DEG		0x4
+#define DEV_CONF_SMP_DELAY_HALF_CYCLE	0x1
+#define DEV_CONF_CMD_TYPE_MASK			GENMASK(15, 15)
+#define DEV_CONF_CMD_TYPE_16BIT			0x1
+#define DEV_CONF_CMD_TYPE_8BIT			0x0
+#define DEV_CONF_STA_TYPE_MASK			GENMASK(14, 13)
+#define DEV_CONF_THOLD_MASK				GENMASK(12, 11)
+#define DEV_CONF_TSETUP_MASK			GENMASK(10, 9)
+#define DEV_CONF_TSH_MASK				GENMASK(8, 5)
+#define DEV_CONF_CPHA					BIT(4)
+#define DEV_CONF_CPOL					BIT(3)
+#define DEV_CONF_CE_DL					BIT(2)
+#define DEV_CONF_HOLD_DL				BIT(1)
+#define DEV_CONF_WP_DL					BIT(0)
+
+/* bits within the TRAN_CONF(n) register */
+#define TRAN_CONF_TRAN_MODE_MASK		GENMASK(31, 29)
+#define TRAN_CONF_ADDR_WIDTH_MASK		GENMASK(28, 26)
+#define TRAN_CONF_POLL_EN				BIT(25)
+#define TRAN_CONF_CMD_EN				BIT(24)
+#define TRAN_CONF_PHASE_FORMAT_MASK		GENMASK(23, 23)
+#define TRAN_CONF_DMY_BITS_MASK			GENMASK(22, 17)
+#define TRAN_CONF_DATA_EN				BIT(16)
+#define TRAN_CONF_CMD_MASK				GENMASK(15, 0)
+
+/* bits within the TRIG register */
+#define TRIG_FLUSH						BIT(2)
+#define TRIG_STOP						BIT(1)
+#define TRIG_START						BIT(0)
+
+/* bits within the SR register */
+#define SR_FIFO_NUM_MASK				GENMASK(22, 16)
+#define SR_END							BIT(4)
+#define SR_TRAN_REQ						BIT(3)
+#define SR_RECE_REQ						BIT(2)
+#define SR_OVER							BIT(1)
+#define SR_UNDER						BIT(0)
+
+/* bits within the SCR register */
+#define SCR_CLR_END						BIT(4)
+#define SCR_CLR_TREQ					BIT(3)
+#define SCR_CLR_RREQ					BIT(2)
+#define SCR_CLR_OVER					BIT(1)
+#define SCR_CLR_UNDER					BIT(0)
+
+/* bits within the INTC register */
+#define INTC_MASK_END					BIT(4)
+#define INTC_MASK_TREQ					BIT(3)
+#define INTC_MASK_RREQ					BIT(2)
+#define INTC_MASK_OVER					BIT(1)
+#define INTC_MASK_UNDER					BIT(0)
+
+/* bits within the TRAN_CFG1(n) register */
+#define TRAN_CFG1_TRAN_MODE_MASK		GENMASK(7, 4)
+
+#define TRAN_MODE_STANDARD				0
+#define TRAN_MODE_DUAL_DATA				1
+#define TRAN_MODE_DUAL_IO				2
+#define TRAN_MODE_DUAL_FULL				3
+#define TRAN_MODE_QUAD_DATA				5
+#define TRAN_MODE_QUAD_IO				6
+#define TRAN_MODE_QUAD_FULL				7
+#define TRAN_MODE_OCTAL_DATA			9
+#define TRAN_MODE_OCTAL_IO				10
+#define TRAN_MODE_OCTAL_FULL			11
+
+#define INGENIC_SFC_FIFO_SIZE			(64 * 4)
+
+#define INGENIC_SFC_TRANSFER_TIMEOUT	1000
+
+enum ingenic_sfc_version {
+	ID_X1000,
+	ID_X1600,
+	ID_X2000,
+};
+
+struct ingenic_soc_info {
+	enum ingenic_sfc_version version;
+
+	unsigned int max_bus_width;
+
+	const u32 tran_mode_mask;
+};
+
+struct ingenic_sfc {
+	const struct ingenic_soc_info *soc_info;
+
+	void __iomem *base;
+	struct device *dev;
+	struct clk *clk;
+	int irq;
+
+	struct completion completion;
+};
+
+static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
+{
+	struct ingenic_sfc *sfc = data;
+
+	writel(0x1f, sfc->base + SFC_REG_INTC);
+
+	complete(&sfc->completion);
+
+	return IRQ_HANDLED;
+}
+
+static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+	uintptr_t addr = (uintptr_t)op->data.buf.in;
+
+	if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
+		op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
+
+	return 0;
+}
+
+static bool ingenic_sfc_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+	struct spi_device *spi = mem->spi;
+	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
+	uintptr_t addr = (uintptr_t)op->data.buf.in;
+
+	/* The controller only supports Standard SPI mode, Duall mode, Quad mode and Octal mode. */
+	if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
+		op->addr.buswidth > sfc->soc_info->max_bus_width ||
+		op->dummy.buswidth > sfc->soc_info->max_bus_width ||
+		op->data.buswidth > sfc->soc_info->max_bus_width)
+		return false;
+
+	/* Max 32 dummy clock cycles supported */
+	if (op->dummy.nbytes && op->dummy.nbytes * 8 / op->dummy.buswidth > 32)
+		return false;
+
+	/* Max rx data length, check controller limits and alignment */
+	if (op->data.dir == SPI_MEM_DATA_IN &&
+		op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
+		return false;
+
+	/* Max 6 bytes address width supported */
+	if (op->addr.nbytes > 6)
+		return false;
+
+	return spi_mem_default_supports_op(mem, op);
+}
+
+static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, const struct spi_mem_op *op)
+{
+	int val;
+
+	val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
+			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
+	val &= ~sfc->soc_info->tran_mode_mask;
+	if (op->cmd.buswidth == 8)
+		val |= (TRAN_MODE_OCTAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->cmd.buswidth == 4)
+		val |= (TRAN_MODE_QUAD_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->cmd.buswidth == 2)
+		val |= (TRAN_MODE_DUAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->addr.buswidth == 8)
+		val |= (TRAN_MODE_OCTAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->addr.buswidth == 4)
+		val |= (TRAN_MODE_QUAD_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->addr.buswidth == 2)
+		val |= (TRAN_MODE_DUAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->data.buswidth == 8)
+		val |= (TRAN_MODE_OCTAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->data.buswidth == 4)
+		val |= (TRAN_MODE_QUAD_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else if (op->data.buswidth == 2)
+		val |= (TRAN_MODE_DUAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	else
+		val |= (TRAN_MODE_STANDARD << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
+				sfc->soc_info->tran_mode_mask;
+	writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
+			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
+}
+
+/*
+ * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
+ * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
+ */
+static void ingenic_sfc_read_rxfifo(struct ingenic_sfc *sfc, u8 *to, unsigned int len)
+{
+	void __iomem *from;
+
+	from = sfc->base + SFC_REG_DR;
+
+	for (; len >= 4; len -= 4, to += 4) {
+		u32 val = __raw_readl(from);
+		memcpy(to, &val, 4);
+	}
+
+	if (len) {
+		u32 val = __raw_readl(from);
+		memcpy(to, &val, len);
+	}
+}
+
+static int ingenic_sfc_exec_op_pio(struct ingenic_sfc *sfc, const struct spi_mem_op *op)
+{
+	int ret, val;
+
+	val = readl(sfc->base + SFC_REG_GLB);
+	u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
+	u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
+	writel(val, sfc->base + SFC_REG_GLB);
+
+	val = TRAN_CONF_CMD_EN | op->cmd.opcode;
+
+	if (op->addr.nbytes > 0) {
+		val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
+
+		writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
+		writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
+	}
+
+	if (op->dummy.nbytes > 0)
+		val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
+				op->dummy.nbytes * 8 / op->dummy.buswidth);
+
+	if (op->data.nbytes > 0)
+		val |= TRAN_CONF_DATA_EN;
+
+	writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
+	writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
+
+	ingenic_sfc_set_transfer_mode(sfc, op);
+
+	writel(0x1f, sfc->base + SFC_REG_SCR);
+	writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + SFC_REG_INTC);
+
+	writel(0, sfc->base + SFC_REG_MEM_ADDR);
+
+	writel(TRIG_FLUSH, sfc->base + SFC_REG_TRIG);
+	writel(TRIG_START, sfc->base + SFC_REG_TRIG);
+
+	ret = wait_for_completion_timeout(&sfc->completion,
+			msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
+	if (!ret) {
+		writel(0x1f, sfc->base + SFC_REG_INTC);
+		writel(0x1f, sfc->base + SFC_REG_SCR);
+		dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", __LINE__);
+		return -ETIMEDOUT;
+	}
+
+	ingenic_sfc_read_rxfifo(sfc, op->data.buf.in, op->data.nbytes);
+	readl_poll_timeout(sfc->base + SFC_REG_SR, val, val & SR_END, 10, 0);
+
+	writel(INTC_MASK_END | INTC_MASK_RREQ, sfc->base + SFC_REG_SCR);
+	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
+
+	return 0;
+}
+
+static int ingenic_sfc_exec_op_dma(struct ingenic_sfc *sfc, const struct spi_mem_op *op)
+{
+	dma_addr_t addr;
+	int ret, val;
+
+	val = readl(sfc->base + SFC_REG_GLB);
+	u32p_replace_bits(&val, op->data.dir == SPI_MEM_DATA_IN ?
+			GLB_TRAN_DIR_READ : GLB_TRAN_DIR_WRITE, GLB_TRAN_DIR_MASK);
+	u32p_replace_bits(&val, GLB_OP_MODE_DMA, GLB_OP_MODE_MASK);
+	writel(val, sfc->base + SFC_REG_GLB);
+
+	val = TRAN_CONF_CMD_EN | op->cmd.opcode;
+
+	if (op->addr.nbytes > 0) {
+		val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
+		writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
+		writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
+	}
+
+	if (op->dummy.nbytes > 0)
+		val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
+				op->dummy.nbytes * 8 / op->dummy.buswidth);
+
+	if (op->data.nbytes > 0)
+		val |= TRAN_CONF_DATA_EN;
+
+	writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
+	writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
+
+	ingenic_sfc_set_transfer_mode(sfc, op);
+
+	writel(0x1f, sfc->base + SFC_REG_SCR);
+	writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
+
+	switch (op->data.dir) {
+	case SPI_MEM_DATA_IN:
+		addr = dma_map_single(sfc->dev, op->data.buf.in, op->data.nbytes, DMA_FROM_DEVICE);
+		if (dma_mapping_error(sfc->dev, addr)) {
+			dev_err(sfc->dev, "RX DMA memory not mapped\n");
+			return -ENOMEM;
+		}
+
+		writel(addr, sfc->base + SFC_REG_MEM_ADDR);
+		break;
+
+	case SPI_MEM_DATA_OUT:
+		addr = dma_map_single(sfc->dev, (void *)op->data.buf.out,
+				op->data.nbytes, DMA_TO_DEVICE);
+		if (dma_mapping_error(sfc->dev, addr)) {
+			dev_err(sfc->dev, "TX DMA memory not mapped\n");
+			return -ENOMEM;
+		}
+
+		writel(addr, sfc->base + SFC_REG_MEM_ADDR);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	writel(TRIG_START, sfc->base + SFC_REG_TRIG);
+
+	ret = wait_for_completion_timeout(&sfc->completion,
+			msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
+	if (!ret) {
+		writel(0x1f, sfc->base + SFC_REG_INTC);
+		writel(0x1f, sfc->base + SFC_REG_SCR);
+		dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", __LINE__);
+		return -ETIMEDOUT;
+	}
+
+	dma_unmap_single(sfc->dev, addr, op->data.nbytes,
+			op->data.dir == SPI_MEM_DATA_IN ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
+
+	writel(INTC_MASK_END, sfc->base + SFC_REG_SCR);
+	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
+
+	return 0;
+}
+
+static int ingenic_sfc_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+	struct spi_device *spi = mem->spi;
+	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
+	uintptr_t addr = (uintptr_t)op->data.buf.in;
+
+	init_completion(&sfc->completion);
+
+	switch (op->data.dir) {
+	case SPI_MEM_DATA_IN:
+		if (sfc->soc_info->version >= ID_X1600 || IS_ALIGNED(addr, 4))
+			break;
+
+		fallthrough;
+
+	case SPI_MEM_NO_DATA:
+		return ingenic_sfc_exec_op_pio(sfc, op);
+
+	default:
+		break;
+	}
+
+	return ingenic_sfc_exec_op_dma(sfc, op);
+}
+
+static int ingenic_sfc_poll_status(struct spi_mem *mem, const struct spi_mem_op *op,
+			u16 mask, u16 match, unsigned long initial_delay_us,
+			unsigned long polling_delay_us, unsigned long timeout_ms)
+{
+	struct spi_device *spi = mem->spi;
+	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
+	int ret, val;
+
+	init_completion(&sfc->completion);
+
+	val = readl(sfc->base + SFC_REG_GLB);
+	u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
+	u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
+	writel(val, sfc->base + SFC_REG_GLB);
+
+	writel(match, sfc->base + SFC_REG_DEV_STA_EXP);
+	writel(mask, sfc->base + SFC_REG_DEV_STA_MSK);
+
+	val = TRAN_CONF_POLL_EN | TRAN_CONF_CMD_EN | op->cmd.opcode;
+
+	if (op->addr.nbytes > 0) {
+		val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
+
+		writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
+		writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
+	}
+
+	if (op->dummy.nbytes > 0)
+		val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
+				op->dummy.nbytes * 8 / op->dummy.buswidth);
+
+	if (op->data.nbytes > 0)
+		val |= TRAN_CONF_DATA_EN;
+
+	writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
+	writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
+
+	ingenic_sfc_set_transfer_mode(sfc, op);
+
+	writel(0x1f, sfc->base + SFC_REG_SCR);
+	writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
+
+	writel(0, sfc->base + SFC_REG_MEM_ADDR);
+
+	writel(TRIG_START, sfc->base + SFC_REG_TRIG);
+
+	ret = wait_for_completion_timeout(&sfc->completion,
+			msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
+	if (!ret) {
+		writel(0x1f, sfc->base + SFC_REG_INTC);
+		writel(0x1f, sfc->base + SFC_REG_SCR);
+		dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", __LINE__);
+		return -ETIMEDOUT;
+	}
+
+	writel(SCR_CLR_END, sfc->base + SFC_REG_SCR);
+	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
+
+	return 0;
+}
+
+static const struct spi_controller_mem_ops ingenic_sfc_mem_ops = {
+	.adjust_op_size = ingenic_sfc_adjust_op_size,
+	.supports_op = ingenic_sfc_supports_op,
+	.exec_op = ingenic_sfc_exec_op,
+	.poll_status = ingenic_sfc_poll_status,
+};
+
+static int ingenic_sfc_setup(struct spi_device *spi)
+{
+	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
+	unsigned long rate;
+	int ret, val;
+
+	if (!spi->max_speed_hz)
+		return -EINVAL;
+
+	ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
+	if (ret)
+		return -EINVAL;
+
+	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
+	writel(0, sfc->base + SFC_REG_DEV_CONF);
+	writel(0, sfc->base + SFC_REG_CGE);
+
+	val = readl(sfc->base + SFC_REG_GLB);
+	u32p_replace_bits(&val, 64 - 1, GLB_THRESHOLD_MASK);
+	writel(val, sfc->base + SFC_REG_GLB);
+
+	val = readl(sfc->base + SFC_REG_DEV_CONF);
+
+	/* cpha bit:0 , cpol bit:0 */
+	val &= ~(DEV_CONF_CPHA | DEV_CONF_CPOL);
+	val |= spi->mode & SPI_CPHA ? DEV_CONF_CPHA : 0;
+	val |= spi->mode & SPI_CPOL ? DEV_CONF_CPOL : 0;
+
+	/* ce_dl bit:1, hold bit:1, wp bit:1 */
+	val |= (DEV_CONF_CE_DL | DEV_CONF_HOLD_DL | DEV_CONF_WP_DL);
+
+	writel(val, sfc->base + SFC_REG_DEV_CONF);
+
+	val = readl(sfc->base + SFC_REG_GLB);
+	u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
+	writel(val, sfc->base + SFC_REG_GLB);
+
+	rate = clk_get_rate(sfc->clk);
+	val = readl(sfc->base + SFC_REG_DEV_CONF);
+	if (sfc->soc_info->version >= ID_X1600 && rate >= 200000000)
+		u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_180DEG, DEV_CONF_SMP_DELAY_MASK);
+	else if (sfc->soc_info->version == ID_X1000 && rate >= 100000000)
+		u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_HALF_CYCLE, DEV_CONF_SMP_DELAY_MASK);
+	writel(val, sfc->base + SFC_REG_DEV_CONF);
+
+	return 0;
+}
+
+static int ingenic_sfc_probe(struct platform_device *pdev)
+{
+	struct ingenic_sfc *sfc;
+	struct spi_controller *ctlr;
+	int ret;
+
+	ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
+	if (!ctlr)
+		return -ENOMEM;
+
+	sfc = spi_controller_get_devdata(ctlr);
+
+	sfc->soc_info = of_device_get_match_data(&pdev->dev);
+	if (!sfc->soc_info) {
+		dev_err(&pdev->dev, "No of match data provided\n");
+		ret = -ENODEV;
+		goto err_put_master;
+	}
+
+	sfc->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(sfc->base)) {
+		ret = PTR_ERR(sfc->base);
+		goto err_put_master;
+	}
+
+	sfc->clk = devm_clk_get(&pdev->dev, "sfc");
+	if (IS_ERR(sfc->clk)) {
+		ret = IS_ERR(sfc->clk);
+		goto err_put_master;
+	}
+
+	ret = clk_prepare_enable(sfc->clk);
+	if (ret)
+		goto err_put_master;
+
+	sfc->irq = platform_get_irq(pdev, 0);
+	if (sfc->irq < 0) {
+		ret = sfc->irq;
+		goto err_put_master;
+	}
+
+	sfc->dev = &pdev->dev;
+
+	platform_set_drvdata(pdev, sfc);
+
+	ret = devm_request_irq(&pdev->dev, sfc->irq, ingenic_sfc_irq_handler, 0,
+			dev_name(&pdev->dev), sfc);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", sfc->irq, ret);
+		goto err_put_master;
+	}
+
+	ctlr->bus_num = -1;
+	ctlr->num_chipselect = 1;
+	ctlr->mem_ops = &ingenic_sfc_mem_ops;
+	ctlr->dev.of_node = pdev->dev.of_node;
+	ctlr->setup = ingenic_sfc_setup;
+	ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
+			SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
+	if (sfc->soc_info->version >= ID_X2000)
+		ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
+
+	ret = devm_spi_register_controller(&pdev->dev, ctlr);
+	if (ret)
+		goto err_put_master;
+
+	return 0;
+
+err_put_master:
+	spi_master_put(ctlr);
+
+	return ret;
+}
+
+static const struct ingenic_soc_info x1000_soc_info = {
+	.version = ID_X1000,
+
+	.max_bus_width = 4,
+
+	.tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
+};
+
+static const struct ingenic_soc_info x1600_soc_info = {
+	.version = ID_X1600,
+
+	.max_bus_width = 4,
+
+	.tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
+};
+
+static const struct ingenic_soc_info x2000_soc_info = {
+	.version = ID_X2000,
+
+	.max_bus_width = 8,
+
+	.tran_mode_mask = TRAN_CFG1_TRAN_MODE_MASK,
+};
+
+static const struct of_device_id ingenic_sfc_of_matches[] = {
+	{ .compatible = "ingenic,x1000-sfc", .data = &x1000_soc_info },
+	{ .compatible = "ingenic,x1600-sfc", .data = &x1600_soc_info },
+	{ .compatible = "ingenic,x2000-sfc", .data = &x2000_soc_info },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ingenic_sfc_of_matches);
+
+static struct platform_driver ingenic_sfc_driver = {
+	.driver = {
+		.name = "ingenic-sfc",
+		.of_match_table = ingenic_sfc_of_matches,
+	},
+	.probe = ingenic_sfc_probe,
+};
+module_platform_driver(ingenic_sfc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>");
+MODULE_DESCRIPTION("Ingenic SoCs SPI Flash Controller Driver");
-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-22 16:48 ` [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings 周琰杰 (Zhou Yanjie)
@ 2022-07-22 17:46   ` Krzysztof Kozlowski
  2022-07-23 16:50     ` Zhou Yanjie
  2022-07-22 22:44   ` Rob Herring
  1 sibling, 1 reply; 39+ messages in thread
From: Krzysztof Kozlowski @ 2022-07-22 17:46 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie),
	tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
> and the X2000 SoC from Ingenic.
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>  .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
> new file mode 100644
> index 00000000..b7c4cf4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#

File name should be rather based on first compatible, so
ingenic,x1000-sfc.yaml

> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bindings for SFC in Ingenic SoCs
> +
> +maintainers:
> +  - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> +
> +description:
> +  The SPI Flash Controller in Ingenic SoCs.
> +

You miss here allOf referencing spi-controller.

> +properties:
> +  compatible:
> +    oneOf:
> +      - enum:
> +          - ingenic,x1000-sfc
> +          - ingenic,x1600-sfc
> +          - ingenic,x2000-sfc
> +      - items:
> +          - enum:
> +              - ingenic,x1830-sfc
> +          - const: ingenic,x1000-sfc
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    const: sfc

Remove the clock-names entirely, no benefits.

> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/ingenic,x1000-cgu.h>
> +
> +	sfc: spi@13440000 {
> +		compatible = "ingenic,x1000-sfc";


Use 4 spaces for example indentation.

> +		reg = <0x13440000 0x1000>;
> +
> +		interrupt-parent = <&intc>;
> +		interrupts = <7>;
> +
> +		clocks = <&cgu X1000_CLK_SFC>;
> +		clock-names = "sfc";
> +
> +		status = "disabled";

No status in example.

> +	};
> +...


Best regards,
Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
@ 2022-07-22 18:07   ` Krzysztof Kozlowski
  2022-07-23 16:53     ` Zhou Yanjie
  2022-07-22 18:38   ` Mark Brown
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 39+ messages in thread
From: Krzysztof Kozlowski @ 2022-07-22 18:07 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie),
	tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
> from Ingenic.
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>  drivers/spi/Kconfig           |   9 +
>  drivers/spi/Makefile          |   1 +
>  drivers/spi/spi-ingenic-sfc.c | 662 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 672 insertions(+)
>  create mode 100644 drivers/spi/spi-ingenic-sfc.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 3b1044e..1077bd3 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -437,6 +437,15 @@ config SPI_INGENIC
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called spi-ingenic.
>  
> +config SPI_INGENIC_SFC
> +	tristate "Ingenic SoCs SPI Flash Controller"
> +	depends on MACH_INGENIC || COMPILE_TEST
> +	help
> +	  This enables support for the Ingenic SoCs SPI flash controller.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called ingenic-sfc.
> +
>  config SPI_INTEL
>  	tristate
>  
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 0f44eb6..f3e42c0 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)		+= spi-hisi-sfc-v3xx.o
>  obj-$(CONFIG_SPI_IMG_SPFI)		+= spi-img-spfi.o
>  obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
>  obj-$(CONFIG_SPI_INGENIC)		+= spi-ingenic.o
> +obj-$(CONFIG_SPI_INGENIC_SFC)	+= spi-ingenic-sfc.o
>  obj-$(CONFIG_SPI_INTEL)			+= spi-intel.o
>  obj-$(CONFIG_SPI_INTEL_PCI)		+= spi-intel-pci.o
>  obj-$(CONFIG_SPI_INTEL_PLATFORM)	+= spi-intel-platform.o
> diff --git a/drivers/spi/spi-ingenic-sfc.c b/drivers/spi/spi-ingenic-sfc.c
> new file mode 100644
> index 00000000..a565546
> --- /dev/null
> +++ b/drivers/spi/spi-ingenic-sfc.c
> @@ -0,0 +1,662 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Ingenic SoCs SPI Flash Controller Driver
> + * Copyright (c) 2022 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/interrupt.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/spi/spi.h>
> +#include <linux/spi/spi-mem.h>
> +
> +/* SFC register offsets */
> +#define SFC_REG_GLB						0x0000
> +#define SFC_REG_DEV_CONF				0x0004
> +#define SFC_REG_DEV_STA_EXP				0x0008
> +#define SFC_REG_DEV_STA_RT				0x000c
> +#define SFC_REG_DEV_STA_MSK				0x0010
> +#define SFC_REG_TRAN_CONF(n)			(0x0014 + n * 4)
> +#define SFC_REG_TRAN_CFG0(n)			(0x0014 + n * 4)
> +#define SFC_REG_TRAN_LEN				0x002c
> +#define SFC_REG_DEV_ADDR(n)				(0x0030 + n * 4)
> +#define SFC_REG_DEV_ADDR_PLUS(n)		(0x0048 + n * 4)
> +#define SFC_REG_MEM_ADDR				0x0060
> +#define SFC_REG_TRIG					0x0064
> +#define SFC_REG_SR						0x0068
> +#define SFC_REG_SCR						0x006c
> +#define SFC_REG_INTC					0x0070
> +#define SFC_REG_FSM						0x0074
> +#define SFC_REG_CGE						0x0078
> +#define SFC_REG_TRAN_CFG1(n)			(0x009c + n * 4)
> +#define SFC_REG_DR						0x1000
> +
> +/* bits within the GLB register */
> +#define GLB_TRAN_DIR_MASK				GENMASK(13, 13)
> +#define GLB_TRAN_DIR_WRITE				0x1
> +#define GLB_TRAN_DIR_READ				0x0
> +#define GLB_THRESHOLD_MASK				GENMASK(12, 7)
> +#define GLB_OP_MODE_MASK				GENMASK(6, 6)
> +#define GLB_OP_MODE_DMA					0x1
> +#define GLB_OP_MODE_SLAVE				0x0
> +#define GLB_PHASE_NUM_MASK				GENMASK(5, 3)
> +#define GLB_WP_EN						BIT(2)
> +#define GLB_BURST_MD_MASK				GENMASK(1, 0)
> +#define GLB_BURST_MD_INCR32				0x3
> +#define GLB_BURST_MD_INCR16				0x2
> +#define GLB_BURST_MD_INCR8				0x1
> +#define GLB_BURST_MD_INCR4				0x0
> +
> +/* bits within the DEV_CONF register */
> +#define DEV_CONF_SMP_DELAY_MASK			GENMASK(20, 16)
> +#define DEV_CONF_SMP_DELAY_180DEG		0x4
> +#define DEV_CONF_SMP_DELAY_HALF_CYCLE	0x1
> +#define DEV_CONF_CMD_TYPE_MASK			GENMASK(15, 15)
> +#define DEV_CONF_CMD_TYPE_16BIT			0x1
> +#define DEV_CONF_CMD_TYPE_8BIT			0x0
> +#define DEV_CONF_STA_TYPE_MASK			GENMASK(14, 13)
> +#define DEV_CONF_THOLD_MASK				GENMASK(12, 11)
> +#define DEV_CONF_TSETUP_MASK			GENMASK(10, 9)
> +#define DEV_CONF_TSH_MASK				GENMASK(8, 5)
> +#define DEV_CONF_CPHA					BIT(4)
> +#define DEV_CONF_CPOL					BIT(3)
> +#define DEV_CONF_CE_DL					BIT(2)
> +#define DEV_CONF_HOLD_DL				BIT(1)
> +#define DEV_CONF_WP_DL					BIT(0)
> +
> +/* bits within the TRAN_CONF(n) register */
> +#define TRAN_CONF_TRAN_MODE_MASK		GENMASK(31, 29)
> +#define TRAN_CONF_ADDR_WIDTH_MASK		GENMASK(28, 26)
> +#define TRAN_CONF_POLL_EN				BIT(25)
> +#define TRAN_CONF_CMD_EN				BIT(24)
> +#define TRAN_CONF_PHASE_FORMAT_MASK		GENMASK(23, 23)
> +#define TRAN_CONF_DMY_BITS_MASK			GENMASK(22, 17)
> +#define TRAN_CONF_DATA_EN				BIT(16)
> +#define TRAN_CONF_CMD_MASK				GENMASK(15, 0)
> +
> +/* bits within the TRIG register */
> +#define TRIG_FLUSH						BIT(2)
> +#define TRIG_STOP						BIT(1)
> +#define TRIG_START						BIT(0)
> +
> +/* bits within the SR register */
> +#define SR_FIFO_NUM_MASK				GENMASK(22, 16)
> +#define SR_END							BIT(4)
> +#define SR_TRAN_REQ						BIT(3)
> +#define SR_RECE_REQ						BIT(2)
> +#define SR_OVER							BIT(1)
> +#define SR_UNDER						BIT(0)
> +
> +/* bits within the SCR register */
> +#define SCR_CLR_END						BIT(4)
> +#define SCR_CLR_TREQ					BIT(3)
> +#define SCR_CLR_RREQ					BIT(2)
> +#define SCR_CLR_OVER					BIT(1)
> +#define SCR_CLR_UNDER					BIT(0)
> +
> +/* bits within the INTC register */
> +#define INTC_MASK_END					BIT(4)
> +#define INTC_MASK_TREQ					BIT(3)
> +#define INTC_MASK_RREQ					BIT(2)
> +#define INTC_MASK_OVER					BIT(1)
> +#define INTC_MASK_UNDER					BIT(0)
> +
> +/* bits within the TRAN_CFG1(n) register */
> +#define TRAN_CFG1_TRAN_MODE_MASK		GENMASK(7, 4)
> +
> +#define TRAN_MODE_STANDARD				0
> +#define TRAN_MODE_DUAL_DATA				1
> +#define TRAN_MODE_DUAL_IO				2
> +#define TRAN_MODE_DUAL_FULL				3
> +#define TRAN_MODE_QUAD_DATA				5
> +#define TRAN_MODE_QUAD_IO				6
> +#define TRAN_MODE_QUAD_FULL				7
> +#define TRAN_MODE_OCTAL_DATA			9
> +#define TRAN_MODE_OCTAL_IO				10
> +#define TRAN_MODE_OCTAL_FULL			11
> +
> +#define INGENIC_SFC_FIFO_SIZE			(64 * 4)
> +
> +#define INGENIC_SFC_TRANSFER_TIMEOUT	1000
> +
> +enum ingenic_sfc_version {
> +	ID_X1000,
> +	ID_X1600,
> +	ID_X2000,
> +};
> +
> +struct ingenic_soc_info {
> +	enum ingenic_sfc_version version;
> +

No need for blank line.

> +	unsigned int max_bus_width;
> +

Remove as well.

> +	const u32 tran_mode_mask;
> +};
> +
> +struct ingenic_sfc {
> +	const struct ingenic_soc_info *soc_info;
> +
> +	void __iomem *base;
> +	struct device *dev;
> +	struct clk *clk;
> +	int irq;
> +
> +	struct completion completion;
> +};
> +
> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
> +{
> +	struct ingenic_sfc *sfc = data;
> +
> +	writel(0x1f, sfc->base + SFC_REG_INTC);
> +
> +	complete(&sfc->completion);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
> +{
> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
> +
> +	if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
> +		op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
> +
> +	return 0;
> +}
> +
> +static bool ingenic_sfc_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> +	struct spi_device *spi = mem->spi;
> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
> +
> +	/* The controller only supports Standard SPI mode, Duall mode, Quad mode and Octal mode. */
> +	if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
> +		op->addr.buswidth > sfc->soc_info->max_bus_width ||
> +		op->dummy.buswidth > sfc->soc_info->max_bus_width ||
> +		op->data.buswidth > sfc->soc_info->max_bus_width)
> +		return false;
> +
> +	/* Max 32 dummy clock cycles supported */
> +	if (op->dummy.nbytes && op->dummy.nbytes * 8 / op->dummy.buswidth > 32)
> +		return false;
> +
> +	/* Max rx data length, check controller limits and alignment */
> +	if (op->data.dir == SPI_MEM_DATA_IN &&
> +		op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
> +		return false;
> +
> +	/* Max 6 bytes address width supported */
> +	if (op->addr.nbytes > 6)
> +		return false;
> +
> +	return spi_mem_default_supports_op(mem, op);
> +}
> +
> +static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, const struct spi_mem_op *op)
> +{
> +	int val;
> +
> +	val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
> +			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));

This is no really readable.

> +	val &= ~sfc->soc_info->tran_mode_mask;
> +	if (op->cmd.buswidth == 8)
> +		val |= (TRAN_MODE_OCTAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->cmd.buswidth == 4)
> +		val |= (TRAN_MODE_QUAD_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->cmd.buswidth == 2)
> +		val |= (TRAN_MODE_DUAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->addr.buswidth == 8)
> +		val |= (TRAN_MODE_OCTAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->addr.buswidth == 4)
> +		val |= (TRAN_MODE_QUAD_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->addr.buswidth == 2)
> +		val |= (TRAN_MODE_DUAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->data.buswidth == 8)
> +		val |= (TRAN_MODE_OCTAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->data.buswidth == 4)
> +		val |= (TRAN_MODE_QUAD_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->data.buswidth == 2)
> +		val |= (TRAN_MODE_DUAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else
> +		val |= (TRAN_MODE_STANDARD << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
> +			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));

Not readable.

> +}
> +
> +/*
> + * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
> + * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
> + */

(...)

> +	sfc->dev = &pdev->dev;
> +
> +	platform_set_drvdata(pdev, sfc);
> +
> +	ret = devm_request_irq(&pdev->dev, sfc->irq, ingenic_sfc_irq_handler, 0,
> +			dev_name(&pdev->dev), sfc);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", sfc->irq, ret);
> +		goto err_put_master;
> +	}
> +
> +	ctlr->bus_num = -1;
> +	ctlr->num_chipselect = 1;
> +	ctlr->mem_ops = &ingenic_sfc_mem_ops;
> +	ctlr->dev.of_node = pdev->dev.of_node;
> +	ctlr->setup = ingenic_sfc_setup;
> +	ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
> +			SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
> +	if (sfc->soc_info->version >= ID_X2000)
> +		ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
> +
> +	ret = devm_spi_register_controller(&pdev->dev, ctlr);
> +	if (ret)
> +		goto err_put_master;
> +
> +	return 0;
> +
> +err_put_master:
> +	spi_master_put(ctlr);

What about unpreparing clocks? Is it part of spi_master_put()?

> +
> +	return ret;
> +}
> +
> +static const struct ingenic_soc_info x1000_soc_info = {
> +	.version = ID_X1000,
> +

No need for blank lines after each field.


Best regards,
Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
  2022-07-22 18:07   ` Krzysztof Kozlowski
@ 2022-07-22 18:38   ` Mark Brown
  2022-07-23 17:06     ` Zhou Yanjie
  2022-07-22 20:03   ` Paul Cercueil
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 39+ messages in thread
From: Mark Brown @ 2022-07-22 18:38 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie)
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd, linux-spi,
	linux-mips, linux-kernel, devicetree, aidanmacdonald.0x0, tmn505,
	paul, dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu,
	sernia.zhou, reimu


[-- Attachment #1.1: Type: text/plain, Size: 2329 bytes --]

On Sat, Jul 23, 2022 at 12:48:30AM +0800, 周琰杰 (Zhou Yanjie) wrote:

This looks mostly good, a few small issues though:

> +++ b/drivers/spi/spi-ingenic-sfc.c
> @@ -0,0 +1,662 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Ingenic SoCs SPI Flash Controller Driver

Please make the entire comment a C++ one so things look more
intentional.

> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
> +{
> +	struct ingenic_sfc *sfc = data;
> +
> +	writel(0x1f, sfc->base + SFC_REG_INTC);
> +
> +	complete(&sfc->completion);
> +
> +	return IRQ_HANDLED;
> +}

This doesn't pay any attention to any status registers in the chip so
won't work if the interrupt is shared and won't notice any error reports
from the device...

> +static int ingenic_sfc_setup(struct spi_device *spi)
> +{
> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
> +	unsigned long rate;
> +	int ret, val;
> +
> +	if (!spi->max_speed_hz)
> +		return -EINVAL;
> +
> +	ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
> +	if (ret)
> +		return -EINVAL;

The setup() operation should be safe for use on one device while another
device is active.  It's not going to be a problem until there's a
version of the IP with more than one chip select, but that could happen
some time (and someone might decide to make a board using GPIO chip
selects...) but this should really go into the data path.

> +	ret = clk_prepare_enable(sfc->clk);
> +	if (ret)
> +		goto err_put_master;

Nothing ever disables this clock.  It might also be nice to enable the
clock only when the controller is in use, that bit is not super
important though.

> +	ret = devm_request_irq(&pdev->dev, sfc->irq, ingenic_sfc_irq_handler, 0,
> +			dev_name(&pdev->dev), sfc);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", sfc->irq, ret);
> +		goto err_put_master;
> +	}

It's not safe to use devm here...

> +	ret = devm_spi_register_controller(&pdev->dev, ctlr);
> +	if (ret)
> +		goto err_put_master;

...unregistering the controller may free the driver data structure and
the interrupt handler uses it so we could attempt to use freed data in
the window between the controller being unregistered and the interrupt
being freed.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
  2022-07-22 18:07   ` Krzysztof Kozlowski
  2022-07-22 18:38   ` Mark Brown
@ 2022-07-22 20:03   ` Paul Cercueil
  2022-07-23 17:26     ` Zhou Yanjie
  2022-07-23 15:15   ` Christophe JAILLET
  2022-07-24  0:43   ` kernel test robot
  4 siblings, 1 reply; 39+ messages in thread
From: Paul Cercueil @ 2022-07-22 20:03 UTC (permalink / raw)
  To: 周琰杰
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt, linux-mtd,
	linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, dongsheng.qiu, aric.pzqi, rick.tyliu,
	jinghui.liu, sernia.zhou, reimu

Hi Zhou,


Le sam., juil. 23 2022 at 00:48:30 +0800, 周琰杰 (Zhou Yanjie) 
<zhouyanjie@wanyeetech.com> a écrit :
> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
> from Ingenic.
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>  drivers/spi/Kconfig           |   9 +
>  drivers/spi/Makefile          |   1 +
>  drivers/spi/spi-ingenic-sfc.c | 662 
> ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 672 insertions(+)
>  create mode 100644 drivers/spi/spi-ingenic-sfc.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 3b1044e..1077bd3 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -437,6 +437,15 @@ config SPI_INGENIC
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called spi-ingenic.
> 
> +config SPI_INGENIC_SFC
> +	tristate "Ingenic SoCs SPI Flash Controller"
> +	depends on MACH_INGENIC || COMPILE_TEST
> +	help
> +	  This enables support for the Ingenic SoCs SPI flash controller.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called ingenic-sfc.
> +
>  config SPI_INTEL
>  	tristate
> 
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 0f44eb6..f3e42c0 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)		+= 
> spi-hisi-sfc-v3xx.o
>  obj-$(CONFIG_SPI_IMG_SPFI)		+= spi-img-spfi.o
>  obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
>  obj-$(CONFIG_SPI_INGENIC)		+= spi-ingenic.o
> +obj-$(CONFIG_SPI_INGENIC_SFC)	+= spi-ingenic-sfc.o
>  obj-$(CONFIG_SPI_INTEL)			+= spi-intel.o
>  obj-$(CONFIG_SPI_INTEL_PCI)		+= spi-intel-pci.o
>  obj-$(CONFIG_SPI_INTEL_PLATFORM)	+= spi-intel-platform.o
> diff --git a/drivers/spi/spi-ingenic-sfc.c 
> b/drivers/spi/spi-ingenic-sfc.c
> new file mode 100644
> index 00000000..a565546
> --- /dev/null
> +++ b/drivers/spi/spi-ingenic-sfc.c
> @@ -0,0 +1,662 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

Dual-license driver? That's not what MODULE_LICENSE() says.

> +/*
> + * Ingenic SoCs SPI Flash Controller Driver
> + * Copyright (c) 2022 周琰杰 (Zhou Yanjie) 
> <zhouyanjie@wanyeetech.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/interrupt.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/spi/spi.h>
> +#include <linux/spi/spi-mem.h>
> +
> +/* SFC register offsets */
> +#define SFC_REG_GLB						0x0000
> +#define SFC_REG_DEV_CONF				0x0004
> +#define SFC_REG_DEV_STA_EXP				0x0008
> +#define SFC_REG_DEV_STA_RT				0x000c
> +#define SFC_REG_DEV_STA_MSK				0x0010
> +#define SFC_REG_TRAN_CONF(n)			(0x0014 + n * 4)
> +#define SFC_REG_TRAN_CFG0(n)			(0x0014 + n * 4)

You should protect the macro parameter. If you do for instance 
SFC_REG_TRAN_CONF(x + 1) it would resolve to (0x0014 + x + 1 * 4) which 
is not what you'd want.

Also - looks like SFC_REG_TRAN_CONF() and SFC_REG_TRAN_CFG0() are the 
same thing, that's on purpose?

> +#define SFC_REG_TRAN_LEN				0x002c
> +#define SFC_REG_DEV_ADDR(n)				(0x0030 + n * 4)
> +#define SFC_REG_DEV_ADDR_PLUS(n)		(0x0048 + n * 4)
> +#define SFC_REG_MEM_ADDR				0x0060
> +#define SFC_REG_TRIG					0x0064
> +#define SFC_REG_SR						0x0068
> +#define SFC_REG_SCR						0x006c
> +#define SFC_REG_INTC					0x0070
> +#define SFC_REG_FSM						0x0074
> +#define SFC_REG_CGE						0x0078
> +#define SFC_REG_TRAN_CFG1(n)			(0x009c + n * 4)
> +#define SFC_REG_DR						0x1000
> +
> +/* bits within the GLB register */
> +#define GLB_TRAN_DIR_MASK				GENMASK(13, 13)
> +#define GLB_TRAN_DIR_WRITE				0x1
> +#define GLB_TRAN_DIR_READ				0x0

When it's a single bit - just use BIT().

> +#define GLB_THRESHOLD_MASK				GENMASK(12, 7)
> +#define GLB_OP_MODE_MASK				GENMASK(6, 6)

Same here, and I see it a few times below as well.

> +#define GLB_OP_MODE_DMA					0x1
> +#define GLB_OP_MODE_SLAVE				0x0
> +#define GLB_PHASE_NUM_MASK				GENMASK(5, 3)
> +#define GLB_WP_EN						BIT(2)
> +#define GLB_BURST_MD_MASK				GENMASK(1, 0)
> +#define GLB_BURST_MD_INCR32				0x3
> +#define GLB_BURST_MD_INCR16				0x2
> +#define GLB_BURST_MD_INCR8				0x1
> +#define GLB_BURST_MD_INCR4				0x0
> +
> +/* bits within the DEV_CONF register */
> +#define DEV_CONF_SMP_DELAY_MASK			GENMASK(20, 16)
> +#define DEV_CONF_SMP_DELAY_180DEG		0x4
> +#define DEV_CONF_SMP_DELAY_HALF_CYCLE	0x1
> +#define DEV_CONF_CMD_TYPE_MASK			GENMASK(15, 15)
> +#define DEV_CONF_CMD_TYPE_16BIT			0x1
> +#define DEV_CONF_CMD_TYPE_8BIT			0x0
> +#define DEV_CONF_STA_TYPE_MASK			GENMASK(14, 13)
> +#define DEV_CONF_THOLD_MASK				GENMASK(12, 11)
> +#define DEV_CONF_TSETUP_MASK			GENMASK(10, 9)
> +#define DEV_CONF_TSH_MASK				GENMASK(8, 5)
> +#define DEV_CONF_CPHA					BIT(4)
> +#define DEV_CONF_CPOL					BIT(3)
> +#define DEV_CONF_CE_DL					BIT(2)
> +#define DEV_CONF_HOLD_DL				BIT(1)
> +#define DEV_CONF_WP_DL					BIT(0)
> +
> +/* bits within the TRAN_CONF(n) register */
> +#define TRAN_CONF_TRAN_MODE_MASK		GENMASK(31, 29)
> +#define TRAN_CONF_ADDR_WIDTH_MASK		GENMASK(28, 26)
> +#define TRAN_CONF_POLL_EN				BIT(25)
> +#define TRAN_CONF_CMD_EN				BIT(24)
> +#define TRAN_CONF_PHASE_FORMAT_MASK		GENMASK(23, 23)
> +#define TRAN_CONF_DMY_BITS_MASK			GENMASK(22, 17)
> +#define TRAN_CONF_DATA_EN				BIT(16)
> +#define TRAN_CONF_CMD_MASK				GENMASK(15, 0)
> +
> +/* bits within the TRIG register */
> +#define TRIG_FLUSH						BIT(2)
> +#define TRIG_STOP						BIT(1)
> +#define TRIG_START						BIT(0)
> +
> +/* bits within the SR register */
> +#define SR_FIFO_NUM_MASK				GENMASK(22, 16)
> +#define SR_END							BIT(4)
> +#define SR_TRAN_REQ						BIT(3)
> +#define SR_RECE_REQ						BIT(2)
> +#define SR_OVER							BIT(1)
> +#define SR_UNDER						BIT(0)
> +
> +/* bits within the SCR register */
> +#define SCR_CLR_END						BIT(4)
> +#define SCR_CLR_TREQ					BIT(3)
> +#define SCR_CLR_RREQ					BIT(2)
> +#define SCR_CLR_OVER					BIT(1)
> +#define SCR_CLR_UNDER					BIT(0)
> +
> +/* bits within the INTC register */
> +#define INTC_MASK_END					BIT(4)
> +#define INTC_MASK_TREQ					BIT(3)
> +#define INTC_MASK_RREQ					BIT(2)
> +#define INTC_MASK_OVER					BIT(1)
> +#define INTC_MASK_UNDER					BIT(0)
> +
> +/* bits within the TRAN_CFG1(n) register */
> +#define TRAN_CFG1_TRAN_MODE_MASK		GENMASK(7, 4)
> +
> +#define TRAN_MODE_STANDARD				0
> +#define TRAN_MODE_DUAL_DATA				1
> +#define TRAN_MODE_DUAL_IO				2
> +#define TRAN_MODE_DUAL_FULL				3
> +#define TRAN_MODE_QUAD_DATA				5
> +#define TRAN_MODE_QUAD_IO				6
> +#define TRAN_MODE_QUAD_FULL				7
> +#define TRAN_MODE_OCTAL_DATA			9
> +#define TRAN_MODE_OCTAL_IO				10
> +#define TRAN_MODE_OCTAL_FULL			11
> +
> +#define INGENIC_SFC_FIFO_SIZE			(64 * 4)
> +
> +#define INGENIC_SFC_TRANSFER_TIMEOUT	1000

Maybe add the unit name in the macro as well - 
INGENIC_SFC_TRANSFER_TIMEOUT_MS.

> +
> +enum ingenic_sfc_version {
> +	ID_X1000,
> +	ID_X1600,
> +	ID_X2000,
> +};
> +
> +struct ingenic_soc_info {
> +	enum ingenic_sfc_version version;
> +
> +	unsigned int max_bus_width;
> +
> +	const u32 tran_mode_mask;
> +};
> +
> +struct ingenic_sfc {
> +	const struct ingenic_soc_info *soc_info;
> +
> +	void __iomem *base;
> +	struct device *dev;
> +	struct clk *clk;
> +	int irq;
> +
> +	struct completion completion;
> +};
> +
> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
> +{
> +	struct ingenic_sfc *sfc = data;
> +
> +	writel(0x1f, sfc->base + SFC_REG_INTC);
> +
> +	complete(&sfc->completion);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct 
> spi_mem_op *op)
> +{
> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
> +
> +	if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
> +		op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
> +
> +	return 0;
> +}
> +
> +static bool ingenic_sfc_supports_op(struct spi_mem *mem, const 
> struct spi_mem_op *op)
> +{
> +	struct spi_device *spi = mem->spi;
> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
> +
> +	/* The controller only supports Standard SPI mode, Duall mode, Quad 
> mode and Octal mode. */

Dual*

> +	if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
> +		op->addr.buswidth > sfc->soc_info->max_bus_width ||
> +		op->dummy.buswidth > sfc->soc_info->max_bus_width ||
> +		op->data.buswidth > sfc->soc_info->max_bus_width)
> +		return false;
> +
> +	/* Max 32 dummy clock cycles supported */
> +	if (op->dummy.nbytes && op->dummy.nbytes * 8 / op->dummy.buswidth > 
> 32)
> +		return false;
> +
> +	/* Max rx data length, check controller limits and alignment */
> +	if (op->data.dir == SPI_MEM_DATA_IN &&
> +		op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))

This does the same check than in ingenic_sfc_adjust_op_size(), maybe 
move it to a new inline function?

> +		return false;
> +
> +	/* Max 6 bytes address width supported */
> +	if (op->addr.nbytes > 6)
> +		return false;
> +
> +	return spi_mem_default_supports_op(mem, op);
> +}
> +
> +static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, 
> const struct spi_mem_op *op)
> +{
> +	int val;
> +
> +	val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
> +			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));

As Krzysztof said - ugh.

Also, instead of having a "version" enum in your soc_info, why not just 
have a "reg_conf" field that gives you directly the right register?


> +	val &= ~sfc->soc_info->tran_mode_mask;
> +	if (op->cmd.buswidth == 8)
> +		val |= (TRAN_MODE_OCTAL_FULL << 
> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;

Looks like you're really trying to reinvent the wheel.

val |= FIELD_PREP(sfc->soc_info->tran_mode_mask, TRAN_MODE_OCTAL_FULL);

using <linux/bitfield.h>.

Also, just define a 'mode' variable and set it in your if/else blocks, 
that would look much better. Then you can set val |= FIELD_PREP(..., 
mode) at the end.

> +	else if (op->cmd.buswidth == 4)
> +		val |= (TRAN_MODE_QUAD_FULL << (ffs(sfc->soc_info->tran_mode_mask) 
> - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->cmd.buswidth == 2)
> +		val |= (TRAN_MODE_DUAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) 
> - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->addr.buswidth == 8)
> +		val |= (TRAN_MODE_OCTAL_IO << (ffs(sfc->soc_info->tran_mode_mask) 
> - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->addr.buswidth == 4)
> +		val |= (TRAN_MODE_QUAD_IO << (ffs(sfc->soc_info->tran_mode_mask) - 
> 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->addr.buswidth == 2)
> +		val |= (TRAN_MODE_DUAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 
> 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->data.buswidth == 8)
> +		val |= (TRAN_MODE_OCTAL_DATA << 
> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->data.buswidth == 4)
> +		val |= (TRAN_MODE_QUAD_DATA << (ffs(sfc->soc_info->tran_mode_mask) 
> - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else if (op->data.buswidth == 2)
> +		val |= (TRAN_MODE_DUAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) 
> - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	else
> +		val |= (TRAN_MODE_STANDARD << (ffs(sfc->soc_info->tran_mode_mask) 
> - 1)) &
> +				sfc->soc_info->tran_mode_mask;
> +	writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
> +			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
> +}
> +
> +/*
> + * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
> + * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
> + */
> +static void ingenic_sfc_read_rxfifo(struct ingenic_sfc *sfc, u8 *to, 
> unsigned int len)
> +{
> +	void __iomem *from;
> +
> +	from = sfc->base + SFC_REG_DR;
> +
> +	for (; len >= 4; len -= 4, to += 4) {
> +		u32 val = __raw_readl(from);
> +		memcpy(to, &val, 4);

No need to use memcpy for 4 bytes. You can do: put_unaligned(val, (u32 
*)to);

> +	}
> +
> +	if (len) {
> +		u32 val = __raw_readl(from);
> +		memcpy(to, &val, len);

Hmm, I'm not sure that is endian-safe. I would prefer if you copied 
byte by byte.

> +	}
> +}
> +
> +static int ingenic_sfc_exec_op_pio(struct ingenic_sfc *sfc, const 
> struct spi_mem_op *op)
> +{
> +	int ret, val;
> +
> +	val = readl(sfc->base + SFC_REG_GLB);
> +	u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
> +	u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
> +	writel(val, sfc->base + SFC_REG_GLB);

By the way, have you considered using regmap?

It would give you things like regmap_update_bits() for this kind of 
things, and regmap_field() to handle your conf register being at a 
different address across SoCs.

> +
> +	val = TRAN_CONF_CMD_EN | op->cmd.opcode;
> +
> +	if (op->addr.nbytes > 0) {
> +		val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
> +
> +		writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
> +		writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
> +	}
> +
> +	if (op->dummy.nbytes > 0)
> +		val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
> +				op->dummy.nbytes * 8 / op->dummy.buswidth);
> +
> +	if (op->data.nbytes > 0)
> +		val |= TRAN_CONF_DATA_EN;
> +
> +	writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
> +	writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
> +
> +	ingenic_sfc_set_transfer_mode(sfc, op);
> +
> +	writel(0x1f, sfc->base + SFC_REG_SCR);

Random 0x1f value here, maybe use a macro?

> +	writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + SFC_REG_INTC);
> +
> +	writel(0, sfc->base + SFC_REG_MEM_ADDR);
> +
> +	writel(TRIG_FLUSH, sfc->base + SFC_REG_TRIG);
> +	writel(TRIG_START, sfc->base + SFC_REG_TRIG);
> +
> +	ret = wait_for_completion_timeout(&sfc->completion,
> +			msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
> +	if (!ret) {
> +		writel(0x1f, sfc->base + SFC_REG_INTC);
> +		writel(0x1f, sfc->base + SFC_REG_SCR);
> +		dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", 
> __LINE__);
> +		return -ETIMEDOUT;
> +	}
> +
> +	ingenic_sfc_read_rxfifo(sfc, op->data.buf.in, op->data.nbytes);
> +	readl_poll_timeout(sfc->base + SFC_REG_SR, val, val & SR_END, 10, 
> 0);

Infinite timeout? Is that very wise?

> +
> +	writel(INTC_MASK_END | INTC_MASK_RREQ, sfc->base + SFC_REG_SCR);
> +	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
> +
> +	return 0;
> +}
> +
> +static int ingenic_sfc_exec_op_dma(struct ingenic_sfc *sfc, const 
> struct spi_mem_op *op)
> +{
> +	dma_addr_t addr;
> +	int ret, val;
> +
> +	val = readl(sfc->base + SFC_REG_GLB);
> +	u32p_replace_bits(&val, op->data.dir == SPI_MEM_DATA_IN ?
> +			GLB_TRAN_DIR_READ : GLB_TRAN_DIR_WRITE, GLB_TRAN_DIR_MASK);
> +	u32p_replace_bits(&val, GLB_OP_MODE_DMA, GLB_OP_MODE_MASK);
> +	writel(val, sfc->base + SFC_REG_GLB);
> +
> +	val = TRAN_CONF_CMD_EN | op->cmd.opcode;
> +
> +	if (op->addr.nbytes > 0) {
> +		val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
> +		writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
> +		writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
> +	}
> +
> +	if (op->dummy.nbytes > 0)
> +		val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
> +				op->dummy.nbytes * 8 / op->dummy.buswidth);
> +
> +	if (op->data.nbytes > 0)
> +		val |= TRAN_CONF_DATA_EN;

There's a lot of code duplication here with ingenic_sfc_exec_op_pio(). 
A lot can be factorized.

> +
> +	writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
> +	writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
> +
> +	ingenic_sfc_set_transfer_mode(sfc, op);
> +
> +	writel(0x1f, sfc->base + SFC_REG_SCR);
> +	writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
> +
> +	switch (op->data.dir) {
> +	case SPI_MEM_DATA_IN:
> +		addr = dma_map_single(sfc->dev, op->data.buf.in, op->data.nbytes, 
> DMA_FROM_DEVICE);
> +		if (dma_mapping_error(sfc->dev, addr)) {
> +			dev_err(sfc->dev, "RX DMA memory not mapped\n");
> +			return -ENOMEM;
> +		}
> +
> +		writel(addr, sfc->base + SFC_REG_MEM_ADDR);
> +		break;
> +
> +	case SPI_MEM_DATA_OUT:
> +		addr = dma_map_single(sfc->dev, (void *)op->data.buf.out,
> +				op->data.nbytes, DMA_TO_DEVICE);
> +		if (dma_mapping_error(sfc->dev, addr)) {
> +			dev_err(sfc->dev, "TX DMA memory not mapped\n");
> +			return -ENOMEM;
> +		}
> +
> +		writel(addr, sfc->base + SFC_REG_MEM_ADDR);
> +		break;
> +
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	writel(TRIG_START, sfc->base + SFC_REG_TRIG);
> +
> +	ret = wait_for_completion_timeout(&sfc->completion,
> +			msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
> +	if (!ret) {
> +		writel(0x1f, sfc->base + SFC_REG_INTC);
> +		writel(0x1f, sfc->base + SFC_REG_SCR);
> +		dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", 
> __LINE__);
> +		return -ETIMEDOUT;
> +	}
> +
> +	dma_unmap_single(sfc->dev, addr, op->data.nbytes,
> +			op->data.dir == SPI_MEM_DATA_IN ? DMA_FROM_DEVICE : 
> DMA_TO_DEVICE);

Use a small inline function for that too. My personal rule is that ?: 
is fine if the line fits in 80 characters, but if you have to break, 
then you really need to move it somewhere else.

> +
> +	writel(INTC_MASK_END, sfc->base + SFC_REG_SCR);
> +	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
> +
> +	return 0;
> +}
> +
> +static int ingenic_sfc_exec_op(struct spi_mem *mem, const struct 
> spi_mem_op *op)
> +{
> +	struct spi_device *spi = mem->spi;
> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
> +
> +	init_completion(&sfc->completion);
> +
> +	switch (op->data.dir) {
> +	case SPI_MEM_DATA_IN:
> +		if (sfc->soc_info->version >= ID_X1600 || IS_ALIGNED(addr, 4))
> +			break;
> +
> +		fallthrough;
> +
> +	case SPI_MEM_NO_DATA:
> +		return ingenic_sfc_exec_op_pio(sfc, op);
> +
> +	default:
> +		break;
> +	}
> +
> +	return ingenic_sfc_exec_op_dma(sfc, op);
> +}
> +
> +static int ingenic_sfc_poll_status(struct spi_mem *mem, const struct 
> spi_mem_op *op,
> +			u16 mask, u16 match, unsigned long initial_delay_us,
> +			unsigned long polling_delay_us, unsigned long timeout_ms)
> +{
> +	struct spi_device *spi = mem->spi;
> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
> +	int ret, val;
> +
> +	init_completion(&sfc->completion);
> +
> +	val = readl(sfc->base + SFC_REG_GLB);
> +	u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
> +	u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
> +	writel(val, sfc->base + SFC_REG_GLB);
> +
> +	writel(match, sfc->base + SFC_REG_DEV_STA_EXP);
> +	writel(mask, sfc->base + SFC_REG_DEV_STA_MSK);
> +
> +	val = TRAN_CONF_POLL_EN | TRAN_CONF_CMD_EN | op->cmd.opcode;
> +
> +	if (op->addr.nbytes > 0) {
> +		val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
> +
> +		writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
> +		writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
> +	}
> +
> +	if (op->dummy.nbytes > 0)
> +		val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
> +				op->dummy.nbytes * 8 / op->dummy.buswidth);
> +
> +	if (op->data.nbytes > 0)
> +		val |= TRAN_CONF_DATA_EN;
> +
> +	writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
> +	writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
> +
> +	ingenic_sfc_set_transfer_mode(sfc, op);
> +
> +	writel(0x1f, sfc->base + SFC_REG_SCR);
> +	writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
> +
> +	writel(0, sfc->base + SFC_REG_MEM_ADDR);
> +
> +	writel(TRIG_START, sfc->base + SFC_REG_TRIG);
> +
> +	ret = wait_for_completion_timeout(&sfc->completion,
> +			msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
> +	if (!ret) {
> +		writel(0x1f, sfc->base + SFC_REG_INTC);
> +		writel(0x1f, sfc->base + SFC_REG_SCR);
> +		dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", 
> __LINE__);
> +		return -ETIMEDOUT;
> +	}
> +
> +	writel(SCR_CLR_END, sfc->base + SFC_REG_SCR);
> +	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
> +
> +	return 0;
> +}
> +
> +static const struct spi_controller_mem_ops ingenic_sfc_mem_ops = {
> +	.adjust_op_size = ingenic_sfc_adjust_op_size,
> +	.supports_op = ingenic_sfc_supports_op,
> +	.exec_op = ingenic_sfc_exec_op,
> +	.poll_status = ingenic_sfc_poll_status,
> +};
> +
> +static int ingenic_sfc_setup(struct spi_device *spi)
> +{
> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
> +	unsigned long rate;
> +	int ret, val;
> +
> +	if (!spi->max_speed_hz)
> +		return -EINVAL;

Maybe set a sane default?

> +
> +	ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
> +	if (ret)
> +		return -EINVAL;
> +
> +	writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
> +	writel(0, sfc->base + SFC_REG_DEV_CONF);
> +	writel(0, sfc->base + SFC_REG_CGE);
> +
> +	val = readl(sfc->base + SFC_REG_GLB);
> +	u32p_replace_bits(&val, 64 - 1, GLB_THRESHOLD_MASK);
> +	writel(val, sfc->base + SFC_REG_GLB);
> +
> +	val = readl(sfc->base + SFC_REG_DEV_CONF);
> +
> +	/* cpha bit:0 , cpol bit:0 */
> +	val &= ~(DEV_CONF_CPHA | DEV_CONF_CPOL);
> +	val |= spi->mode & SPI_CPHA ? DEV_CONF_CPHA : 0;
> +	val |= spi->mode & SPI_CPOL ? DEV_CONF_CPOL : 0;
> +
> +	/* ce_dl bit:1, hold bit:1, wp bit:1 */
> +	val |= (DEV_CONF_CE_DL | DEV_CONF_HOLD_DL | DEV_CONF_WP_DL);
> +
> +	writel(val, sfc->base + SFC_REG_DEV_CONF);
> +
> +	val = readl(sfc->base + SFC_REG_GLB);
> +	u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
> +	writel(val, sfc->base + SFC_REG_GLB);
> +
> +	rate = clk_get_rate(sfc->clk);

I'd suggest using clk_round_rate() before clk_set_rate() because then 
you know what frequency it's going to be, and you don't have to call 
clk_get_rate() afterwards.

Cheers,
-Paul

> +	val = readl(sfc->base + SFC_REG_DEV_CONF);
> +	if (sfc->soc_info->version >= ID_X1600 && rate >= 200000000)
> +		u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_180DEG, 
> DEV_CONF_SMP_DELAY_MASK);
> +	else if (sfc->soc_info->version == ID_X1000 && rate >= 100000000)
> +		u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_HALF_CYCLE, 
> DEV_CONF_SMP_DELAY_MASK);
> +	writel(val, sfc->base + SFC_REG_DEV_CONF);
> +
> +	return 0;
> +}
> +
> +static int ingenic_sfc_probe(struct platform_device *pdev)
> +{
> +	struct ingenic_sfc *sfc;
> +	struct spi_controller *ctlr;
> +	int ret;
> +
> +	ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
> +	if (!ctlr)
> +		return -ENOMEM;
> +
> +	sfc = spi_controller_get_devdata(ctlr);
> +
> +	sfc->soc_info = of_device_get_match_data(&pdev->dev);
> +	if (!sfc->soc_info) {
> +		dev_err(&pdev->dev, "No of match data provided\n");
> +		ret = -ENODEV;
> +		goto err_put_master;
> +	}
> +
> +	sfc->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(sfc->base)) {
> +		ret = PTR_ERR(sfc->base);
> +		goto err_put_master;
> +	}
> +
> +	sfc->clk = devm_clk_get(&pdev->dev, "sfc");
> +	if (IS_ERR(sfc->clk)) {
> +		ret = IS_ERR(sfc->clk);
> +		goto err_put_master;
> +	}
> +
> +	ret = clk_prepare_enable(sfc->clk);
> +	if (ret)
> +		goto err_put_master;
> +
> +	sfc->irq = platform_get_irq(pdev, 0);
> +	if (sfc->irq < 0) {
> +		ret = sfc->irq;
> +		goto err_put_master;
> +	}
> +
> +	sfc->dev = &pdev->dev;
> +
> +	platform_set_drvdata(pdev, sfc);
> +
> +	ret = devm_request_irq(&pdev->dev, sfc->irq, 
> ingenic_sfc_irq_handler, 0,
> +			dev_name(&pdev->dev), sfc);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", 
> sfc->irq, ret);
> +		goto err_put_master;
> +	}
> +
> +	ctlr->bus_num = -1;
> +	ctlr->num_chipselect = 1;
> +	ctlr->mem_ops = &ingenic_sfc_mem_ops;
> +	ctlr->dev.of_node = pdev->dev.of_node;
> +	ctlr->setup = ingenic_sfc_setup;
> +	ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
> +			SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
> +	if (sfc->soc_info->version >= ID_X2000)
> +		ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
> +
> +	ret = devm_spi_register_controller(&pdev->dev, ctlr);
> +	if (ret)
> +		goto err_put_master;
> +
> +	return 0;
> +
> +err_put_master:
> +	spi_master_put(ctlr);
> +
> +	return ret;
> +}
> +
> +static const struct ingenic_soc_info x1000_soc_info = {
> +	.version = ID_X1000,
> +
> +	.max_bus_width = 4,
> +
> +	.tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
> +};
> +
> +static const struct ingenic_soc_info x1600_soc_info = {
> +	.version = ID_X1600,
> +
> +	.max_bus_width = 4,
> +
> +	.tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
> +};
> +
> +static const struct ingenic_soc_info x2000_soc_info = {
> +	.version = ID_X2000,
> +
> +	.max_bus_width = 8,
> +
> +	.tran_mode_mask = TRAN_CFG1_TRAN_MODE_MASK,
> +};
> +
> +static const struct of_device_id ingenic_sfc_of_matches[] = {
> +	{ .compatible = "ingenic,x1000-sfc", .data = &x1000_soc_info },
> +	{ .compatible = "ingenic,x1600-sfc", .data = &x1600_soc_info },
> +	{ .compatible = "ingenic,x2000-sfc", .data = &x2000_soc_info },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, ingenic_sfc_of_matches);
> +
> +static struct platform_driver ingenic_sfc_driver = {
> +	.driver = {
> +		.name = "ingenic-sfc",
> +		.of_match_table = ingenic_sfc_of_matches,
> +	},
> +	.probe = ingenic_sfc_probe,
> +};
> +module_platform_driver(ingenic_sfc_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>");
> +MODULE_DESCRIPTION("Ingenic SoCs SPI Flash Controller Driver");
> --
> 2.7.4
> 



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-22 16:48 ` [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings 周琰杰 (Zhou Yanjie)
  2022-07-22 17:46   ` Krzysztof Kozlowski
@ 2022-07-22 22:44   ` Rob Herring
  1 sibling, 0 replies; 39+ messages in thread
From: Rob Herring @ 2022-07-22 22:44 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie)
  Cc: tudor.ambarus, p.yadav, krzysztof.kozlowski+dt, broonie,
	linux-kernel, robh+dt, linux-mips, linux-spi, michael, tmn505,
	reimu, miquel.raynal, paul, rick.tyliu, richard, aric.pzqi,
	linux-mtd, devicetree, aidanmacdonald.0x0, jinghui.liu,
	sernia.zhou, dongsheng.qiu, vigneshr

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Sat, 23 Jul 2022 00:48:29 +0800, 周琰杰 (Zhou Yanjie) wrote:
> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
> and the X2000 SoC from Ingenic.
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>  .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/spi/ingenic,sfc.yaml:52:1: [error] syntax error: found character '\t' that cannot start any token (syntax)

dtschema/dtc warnings/errors:
make[1]: *** Deleting file 'Documentation/devicetree/bindings/spi/ingenic,sfc.example.dts'
Documentation/devicetree/bindings/spi/ingenic,sfc.yaml:52:1: found a tab character where an indentation space is expected
make[1]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/spi/ingenic,sfc.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/spi/ingenic,sfc.yaml:52:1: found a tab character where an indentation space is expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml: ignoring, error parsing file
make: *** [Makefile:1404: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.



[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs.
  2022-07-22 16:48 ` [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs 周琰杰 (Zhou Yanjie)
@ 2022-07-23  8:30   ` Sergey Shtylyov
  0 siblings, 0 replies; 39+ messages in thread
From: Sergey Shtylyov @ 2022-07-23  8:30 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie),
	tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Hello!

On 7/22/22 7:48 PM, 周琰杰 (Zhou Yanjie) wrote:

> With advanced controllers (such as Ingenic SFC), it is possible to poll
> the status register of the device. This could be done to offload the CPU
> during a erase or write operation. Make use of spi-mem poll status APIs
> to handle this feature.
> 
> Previously, when erasing large area (e.g. 32MiB), in non-offload case,
> CPU load could reach ~90% and would generate ~3.92 million interrupts,
> now it decrease to ~15% CPU load and 0.15 million interrupts.
> 
> This should also fix the high CPU usage for system which don't have a
> dedicated poll status block logic (decrease to ~80% CPU load and ~1.61
> million interrupts.).
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>  drivers/mtd/spi-nor/core.c | 42 ++++++++++++++++++++++++++++++++----------
>  1 file changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 502967c..6a31132 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -617,19 +617,41 @@ static int spi_nor_wait_till_ready_with_timeout(struct spi_nor *nor,
>  	unsigned long deadline;
>  	int timeout = 0, ret;
>  
> -	deadline = jiffies + timeout_jiffies;
> +	if (nor->spimem && !nor->params->ready) {
> +		struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDSR, 0),
> +						       SPI_MEM_OP_NO_ADDR,
> +						       SPI_MEM_OP_NO_DUMMY,
> +						       SPI_MEM_OP_DATA_IN(1, nor->bouncebuf, 0));

   Strange indentation...

[...]
> +		return spi_mem_poll_status(nor->spimem, &op, SR_WIP, 0, 0, 10,
> +						       jiffies_to_msecs(timeout_jiffies));

   Here as well...

[...]

MBR, Sergey

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 [PATCH 0/3] Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
                   ` (2 preceding siblings ...)
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
@ 2022-07-23 14:47 ` Tomasz Maciej Nowak
  2022-07-24  1:25   ` Zhou Yanjie
  3 siblings, 1 reply; 39+ messages in thread
From: Tomasz Maciej Nowak @ 2022-07-23 14:47 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie),
	tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, paul, dongsheng.qiu, aric.pzqi, rick.tyliu,
	jinghui.liu, sernia.zhou, reimu

W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
> 
> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
> 
> 周琰杰 (Zhou Yanjie) (3):
>   mtd: spi-nor: Use the spi-mem poll status APIs.
>   dt-bindings: SPI: Add Ingenic SFC bindings.
>   SPI: Ingenic: Add SFC support for Ingenic SoCs.
> 
>  .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>  drivers/mtd/spi-nor/core.c                         |  42 +-
>  drivers/spi/Kconfig                                |   9 +
>  drivers/spi/Makefile                               |   1 +
>  drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>  5 files changed, 768 insertions(+), 10 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>  create mode 100755 drivers/spi/spi-ingenic-sfc.c
> 

Even tough it's still early in revision process, I'll add my
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>

The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
but with 256 MiB RAM. No bugs yet observed on my side.

-- 
TMN

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
                     ` (2 preceding siblings ...)
  2022-07-22 20:03   ` Paul Cercueil
@ 2022-07-23 15:15   ` Christophe JAILLET
  2022-07-23 15:15     ` Christophe JAILLET
  2022-07-24  1:22     ` Zhou Yanjie
  2022-07-24  0:43   ` kernel test robot
  4 siblings, 2 replies; 39+ messages in thread
From: Christophe JAILLET @ 2022-07-23 15:15 UTC (permalink / raw)
  To: linux-mtd
  Cc: linux-mips, linux-spi, linux-kernel, devicetree, linux-mtd,
	linux-spi, linux-kernel, devicetree

Le 22/07/2022 à 18:48, 周琰杰 (Zhou Yanjie) a écrit :
> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
> from Ingenic.
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>   drivers/spi/Kconfig           |   9 +
>   drivers/spi/Makefile          |   1 +
>   drivers/spi/spi-ingenic-sfc.c | 662 ++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 672 insertions(+)
>   create mode 100644 drivers/spi/spi-ingenic-sfc.c
> 

[...]

> +static int ingenic_sfc_probe(struct platform_device *pdev)
> +{
> +	struct ingenic_sfc *sfc;
> +	struct spi_controller *ctlr;
> +	int ret;
> +
> +	ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
> +	if (!ctlr)
> +		return -ENOMEM;

devm_spi_alloc_master()? (+ error handling simplification)
Or there should be a .remove() function.

CJ

> +
> +	sfc = spi_controller_get_devdata(ctlr);
> +
> +	sfc->soc_info = of_device_get_match_data(&pdev->dev);
> +	if (!sfc->soc_info) {
> +		dev_err(&pdev->dev, "No of match data provided\n");
> +		ret = -ENODEV;
> +		goto err_put_master;
> +	}
> +

[...]


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-23 15:15   ` Christophe JAILLET
@ 2022-07-23 15:15     ` Christophe JAILLET
  2022-07-24  1:22     ` Zhou Yanjie
  1 sibling, 0 replies; 39+ messages in thread
From: Christophe JAILLET @ 2022-07-23 15:15 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie),
	tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Le 22/07/2022 à 18:48, 周琰杰 (Zhou Yanjie) a écrit :
> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
> from Ingenic.
> 
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>   drivers/spi/Kconfig           |   9 +
>   drivers/spi/Makefile          |   1 +
>   drivers/spi/spi-ingenic-sfc.c | 662 ++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 672 insertions(+)
>   create mode 100644 drivers/spi/spi-ingenic-sfc.c
> 

[...]

> +static int ingenic_sfc_probe(struct platform_device *pdev)
> +{
> +	struct ingenic_sfc *sfc;
> +	struct spi_controller *ctlr;
> +	int ret;
> +
> +	ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
> +	if (!ctlr)
> +		return -ENOMEM;

devm_spi_alloc_master()? (+ error handling simplification)
Or there should be a .remove() function.

CJ

> +
> +	sfc = spi_controller_get_devdata(ctlr);
> +
> +	sfc->soc_info = of_device_get_match_data(&pdev->dev);
> +	if (!sfc->soc_info) {
> +		dev_err(&pdev->dev, "No of match data provided\n");
> +		ret = -ENODEV;
> +		goto err_put_master;
> +	}
> +

[...]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-22 17:46   ` Krzysztof Kozlowski
@ 2022-07-23 16:50     ` Zhou Yanjie
  2022-07-23 17:43       ` Krzysztof Kozlowski
  0 siblings, 1 reply; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-23 16:50 UTC (permalink / raw)
  To: Krzysztof Kozlowski, tudor.ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Hi Krzysztof,

On 2022/7/23 上午1:46, Krzysztof Kozlowski wrote:
> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
>> and the X2000 SoC from Ingenic.
>>
>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> ---
>>   .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>>   1 file changed, 64 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>> new file mode 100644
>> index 00000000..b7c4cf4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>> @@ -0,0 +1,64 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
> File name should be rather based on first compatible, so
> ingenic,x1000-sfc.yaml


No offense, does it really need to be named that way?
I can't seem to find documentation with instructions on this :(

The use of "ingenic,sfc.yaml" indicates that this is the documentation
for the SFC module for all Ingenic SoCs, without misleading people into
thinking it's only for a specific model of SoC. And there seem to be many
other yaml documents that use similar names (eg. fsl,spi-fsl-qspi.yaml,
spi-rockchip.yaml, spi-nxp-fspi.yaml, ingenic,spi.yaml, spi-sifive.yaml,
omap-spi.yaml), maybe these yaml files that are not named with first
compatible are also for the same consideration. :)


>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Bindings for SFC in Ingenic SoCs
>> +
>> +maintainers:
>> +  - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> +
>> +description:
>> +  The SPI Flash Controller in Ingenic SoCs.
>> +
> You miss here allOf referencing spi-controller.


Sure, will add it in the next version.


>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - enum:
>> +          - ingenic,x1000-sfc
>> +          - ingenic,x1600-sfc
>> +          - ingenic,x2000-sfc
>> +      - items:
>> +          - enum:
>> +              - ingenic,x1830-sfc
>> +          - const: ingenic,x1000-sfc
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  clock-names:
>> +    const: sfc
> Remove the clock-names entirely, no benefits.


Sure.


>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - interrupts
>> +  - clocks
>> +  - clock-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/ingenic,x1000-cgu.h>
>> +
>> +	sfc: spi@13440000 {
>> +		compatible = "ingenic,x1000-sfc";
>
> Use 4 spaces for example indentation.


My fault, will fix it in the next version.


>> +		reg = <0x13440000 0x1000>;
>> +
>> +		interrupt-parent = <&intc>;
>> +		interrupts = <7>;
>> +
>> +		clocks = <&cgu X1000_CLK_SFC>;
>> +		clock-names = "sfc";
>> +
>> +		status = "disabled";
> No status in example.


Sure, will remove it in the next version.


Thanks and beset regards!


>
>> +	};
>> +...
>
> Best regards,
> Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 18:07   ` Krzysztof Kozlowski
@ 2022-07-23 16:53     ` Zhou Yanjie
  0 siblings, 0 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-23 16:53 UTC (permalink / raw)
  To: Krzysztof Kozlowski, tudor.ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Hi Krzysztof,

On 2022/7/23 上午2:07, Krzysztof Kozlowski wrote:
> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
>> from Ingenic.
>>
>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> ---
>>   drivers/spi/Kconfig           |   9 +
>>   drivers/spi/Makefile          |   1 +
>>   drivers/spi/spi-ingenic-sfc.c | 662 ++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 672 insertions(+)
>>   create mode 100644 drivers/spi/spi-ingenic-sfc.c
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 3b1044e..1077bd3 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -437,6 +437,15 @@ config SPI_INGENIC
>>   	  To compile this driver as a module, choose M here: the module
>>   	  will be called spi-ingenic.
>>   
>> +config SPI_INGENIC_SFC
>> +	tristate "Ingenic SoCs SPI Flash Controller"
>> +	depends on MACH_INGENIC || COMPILE_TEST
>> +	help
>> +	  This enables support for the Ingenic SoCs SPI flash controller.
>> +
>> +	  To compile this driver as a module, choose M here: the module
>> +	  will be called ingenic-sfc.
>> +
>>   config SPI_INTEL
>>   	tristate
>>   
>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>> index 0f44eb6..f3e42c0 100644
>> --- a/drivers/spi/Makefile
>> +++ b/drivers/spi/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)		+= spi-hisi-sfc-v3xx.o
>>   obj-$(CONFIG_SPI_IMG_SPFI)		+= spi-img-spfi.o
>>   obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
>>   obj-$(CONFIG_SPI_INGENIC)		+= spi-ingenic.o
>> +obj-$(CONFIG_SPI_INGENIC_SFC)	+= spi-ingenic-sfc.o
>>   obj-$(CONFIG_SPI_INTEL)			+= spi-intel.o
>>   obj-$(CONFIG_SPI_INTEL_PCI)		+= spi-intel-pci.o
>>   obj-$(CONFIG_SPI_INTEL_PLATFORM)	+= spi-intel-platform.o
>> diff --git a/drivers/spi/spi-ingenic-sfc.c b/drivers/spi/spi-ingenic-sfc.c
>> new file mode 100644
>> index 00000000..a565546
>> --- /dev/null
>> +++ b/drivers/spi/spi-ingenic-sfc.c
>> @@ -0,0 +1,662 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +/*
>> + * Ingenic SoCs SPI Flash Controller Driver
>> + * Copyright (c) 2022 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/completion.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/module.h>
>> +#include <linux/mtd/mtd.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/spi/spi.h>
>> +#include <linux/spi/spi-mem.h>
>> +
>> +/* SFC register offsets */
>> +#define SFC_REG_GLB						0x0000
>> +#define SFC_REG_DEV_CONF				0x0004
>> +#define SFC_REG_DEV_STA_EXP				0x0008
>> +#define SFC_REG_DEV_STA_RT				0x000c
>> +#define SFC_REG_DEV_STA_MSK				0x0010
>> +#define SFC_REG_TRAN_CONF(n)			(0x0014 + n * 4)
>> +#define SFC_REG_TRAN_CFG0(n)			(0x0014 + n * 4)
>> +#define SFC_REG_TRAN_LEN				0x002c
>> +#define SFC_REG_DEV_ADDR(n)				(0x0030 + n * 4)
>> +#define SFC_REG_DEV_ADDR_PLUS(n)		(0x0048 + n * 4)
>> +#define SFC_REG_MEM_ADDR				0x0060
>> +#define SFC_REG_TRIG					0x0064
>> +#define SFC_REG_SR						0x0068
>> +#define SFC_REG_SCR						0x006c
>> +#define SFC_REG_INTC					0x0070
>> +#define SFC_REG_FSM						0x0074
>> +#define SFC_REG_CGE						0x0078
>> +#define SFC_REG_TRAN_CFG1(n)			(0x009c + n * 4)
>> +#define SFC_REG_DR						0x1000
>> +
>> +/* bits within the GLB register */
>> +#define GLB_TRAN_DIR_MASK				GENMASK(13, 13)
>> +#define GLB_TRAN_DIR_WRITE				0x1
>> +#define GLB_TRAN_DIR_READ				0x0
>> +#define GLB_THRESHOLD_MASK				GENMASK(12, 7)
>> +#define GLB_OP_MODE_MASK				GENMASK(6, 6)
>> +#define GLB_OP_MODE_DMA					0x1
>> +#define GLB_OP_MODE_SLAVE				0x0
>> +#define GLB_PHASE_NUM_MASK				GENMASK(5, 3)
>> +#define GLB_WP_EN						BIT(2)
>> +#define GLB_BURST_MD_MASK				GENMASK(1, 0)
>> +#define GLB_BURST_MD_INCR32				0x3
>> +#define GLB_BURST_MD_INCR16				0x2
>> +#define GLB_BURST_MD_INCR8				0x1
>> +#define GLB_BURST_MD_INCR4				0x0
>> +
>> +/* bits within the DEV_CONF register */
>> +#define DEV_CONF_SMP_DELAY_MASK			GENMASK(20, 16)
>> +#define DEV_CONF_SMP_DELAY_180DEG		0x4
>> +#define DEV_CONF_SMP_DELAY_HALF_CYCLE	0x1
>> +#define DEV_CONF_CMD_TYPE_MASK			GENMASK(15, 15)
>> +#define DEV_CONF_CMD_TYPE_16BIT			0x1
>> +#define DEV_CONF_CMD_TYPE_8BIT			0x0
>> +#define DEV_CONF_STA_TYPE_MASK			GENMASK(14, 13)
>> +#define DEV_CONF_THOLD_MASK				GENMASK(12, 11)
>> +#define DEV_CONF_TSETUP_MASK			GENMASK(10, 9)
>> +#define DEV_CONF_TSH_MASK				GENMASK(8, 5)
>> +#define DEV_CONF_CPHA					BIT(4)
>> +#define DEV_CONF_CPOL					BIT(3)
>> +#define DEV_CONF_CE_DL					BIT(2)
>> +#define DEV_CONF_HOLD_DL				BIT(1)
>> +#define DEV_CONF_WP_DL					BIT(0)
>> +
>> +/* bits within the TRAN_CONF(n) register */
>> +#define TRAN_CONF_TRAN_MODE_MASK		GENMASK(31, 29)
>> +#define TRAN_CONF_ADDR_WIDTH_MASK		GENMASK(28, 26)
>> +#define TRAN_CONF_POLL_EN				BIT(25)
>> +#define TRAN_CONF_CMD_EN				BIT(24)
>> +#define TRAN_CONF_PHASE_FORMAT_MASK		GENMASK(23, 23)
>> +#define TRAN_CONF_DMY_BITS_MASK			GENMASK(22, 17)
>> +#define TRAN_CONF_DATA_EN				BIT(16)
>> +#define TRAN_CONF_CMD_MASK				GENMASK(15, 0)
>> +
>> +/* bits within the TRIG register */
>> +#define TRIG_FLUSH						BIT(2)
>> +#define TRIG_STOP						BIT(1)
>> +#define TRIG_START						BIT(0)
>> +
>> +/* bits within the SR register */
>> +#define SR_FIFO_NUM_MASK				GENMASK(22, 16)
>> +#define SR_END							BIT(4)
>> +#define SR_TRAN_REQ						BIT(3)
>> +#define SR_RECE_REQ						BIT(2)
>> +#define SR_OVER							BIT(1)
>> +#define SR_UNDER						BIT(0)
>> +
>> +/* bits within the SCR register */
>> +#define SCR_CLR_END						BIT(4)
>> +#define SCR_CLR_TREQ					BIT(3)
>> +#define SCR_CLR_RREQ					BIT(2)
>> +#define SCR_CLR_OVER					BIT(1)
>> +#define SCR_CLR_UNDER					BIT(0)
>> +
>> +/* bits within the INTC register */
>> +#define INTC_MASK_END					BIT(4)
>> +#define INTC_MASK_TREQ					BIT(3)
>> +#define INTC_MASK_RREQ					BIT(2)
>> +#define INTC_MASK_OVER					BIT(1)
>> +#define INTC_MASK_UNDER					BIT(0)
>> +
>> +/* bits within the TRAN_CFG1(n) register */
>> +#define TRAN_CFG1_TRAN_MODE_MASK		GENMASK(7, 4)
>> +
>> +#define TRAN_MODE_STANDARD				0
>> +#define TRAN_MODE_DUAL_DATA				1
>> +#define TRAN_MODE_DUAL_IO				2
>> +#define TRAN_MODE_DUAL_FULL				3
>> +#define TRAN_MODE_QUAD_DATA				5
>> +#define TRAN_MODE_QUAD_IO				6
>> +#define TRAN_MODE_QUAD_FULL				7
>> +#define TRAN_MODE_OCTAL_DATA			9
>> +#define TRAN_MODE_OCTAL_IO				10
>> +#define TRAN_MODE_OCTAL_FULL			11
>> +
>> +#define INGENIC_SFC_FIFO_SIZE			(64 * 4)
>> +
>> +#define INGENIC_SFC_TRANSFER_TIMEOUT	1000
>> +
>> +enum ingenic_sfc_version {
>> +	ID_X1000,
>> +	ID_X1600,
>> +	ID_X2000,
>> +};
>> +
>> +struct ingenic_soc_info {
>> +	enum ingenic_sfc_version version;
>> +
> No need for blank line.
>
>> +	unsigned int max_bus_width;
>> +
> Remove as well.
>
>> +	const u32 tran_mode_mask;
>> +};
>> +
>> +struct ingenic_sfc {
>> +	const struct ingenic_soc_info *soc_info;
>> +
>> +	void __iomem *base;
>> +	struct device *dev;
>> +	struct clk *clk;
>> +	int irq;
>> +
>> +	struct completion completion;
>> +};
>> +
>> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
>> +{
>> +	struct ingenic_sfc *sfc = data;
>> +
>> +	writel(0x1f, sfc->base + SFC_REG_INTC);
>> +
>> +	complete(&sfc->completion);
>> +
>> +	return IRQ_HANDLED;
>> +}
>> +
>> +static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
>> +{
>> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
>> +
>> +	if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
>> +		op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
>> +
>> +	return 0;
>> +}
>> +
>> +static bool ingenic_sfc_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
>> +{
>> +	struct spi_device *spi = mem->spi;
>> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
>> +	uintptr_t addr = (uintptr_t)op->data.buf.in;
>> +
>> +	/* The controller only supports Standard SPI mode, Duall mode, Quad mode and Octal mode. */
>> +	if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
>> +		op->addr.buswidth > sfc->soc_info->max_bus_width ||
>> +		op->dummy.buswidth > sfc->soc_info->max_bus_width ||
>> +		op->data.buswidth > sfc->soc_info->max_bus_width)
>> +		return false;
>> +
>> +	/* Max 32 dummy clock cycles supported */
>> +	if (op->dummy.nbytes && op->dummy.nbytes * 8 / op->dummy.buswidth > 32)
>> +		return false;
>> +
>> +	/* Max rx data length, check controller limits and alignment */
>> +	if (op->data.dir == SPI_MEM_DATA_IN &&
>> +		op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 4))
>> +		return false;
>> +
>> +	/* Max 6 bytes address width supported */
>> +	if (op->addr.nbytes > 6)
>> +		return false;
>> +
>> +	return spi_mem_default_supports_op(mem, op);
>> +}
>> +
>> +static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, const struct spi_mem_op *op)
>> +{
>> +	int val;
>> +
>> +	val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>> +			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
> This is no really readable.


Sure, I will change it in the next version.


>> +	val &= ~sfc->soc_info->tran_mode_mask;
>> +	if (op->cmd.buswidth == 8)
>> +		val |= (TRAN_MODE_OCTAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->cmd.buswidth == 4)
>> +		val |= (TRAN_MODE_QUAD_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->cmd.buswidth == 2)
>> +		val |= (TRAN_MODE_DUAL_FULL << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->addr.buswidth == 8)
>> +		val |= (TRAN_MODE_OCTAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->addr.buswidth == 4)
>> +		val |= (TRAN_MODE_QUAD_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->addr.buswidth == 2)
>> +		val |= (TRAN_MODE_DUAL_IO << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->data.buswidth == 8)
>> +		val |= (TRAN_MODE_OCTAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->data.buswidth == 4)
>> +		val |= (TRAN_MODE_QUAD_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else if (op->data.buswidth == 2)
>> +		val |= (TRAN_MODE_DUAL_DATA << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	else
>> +		val |= (TRAN_MODE_STANDARD << (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +				sfc->soc_info->tran_mode_mask;
>> +	writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>> +			SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
> Not readable.


Will change it.


>
>> +}
>> +
>> +/*
>> + * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
>> + * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
>> + */
> (...)
>
>> +	sfc->dev = &pdev->dev;
>> +
>> +	platform_set_drvdata(pdev, sfc);
>> +
>> +	ret = devm_request_irq(&pdev->dev, sfc->irq, ingenic_sfc_irq_handler, 0,
>> +			dev_name(&pdev->dev), sfc);
>> +	if (ret) {
>> +		dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", sfc->irq, ret);
>> +		goto err_put_master;
>> +	}
>> +
>> +	ctlr->bus_num = -1;
>> +	ctlr->num_chipselect = 1;
>> +	ctlr->mem_ops = &ingenic_sfc_mem_ops;
>> +	ctlr->dev.of_node = pdev->dev.of_node;
>> +	ctlr->setup = ingenic_sfc_setup;
>> +	ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
>> +			SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
>> +	if (sfc->soc_info->version >= ID_X2000)
>> +		ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
>> +
>> +	ret = devm_spi_register_controller(&pdev->dev, ctlr);
>> +	if (ret)
>> +		goto err_put_master;
>> +
>> +	return 0;
>> +
>> +err_put_master:
>> +	spi_master_put(ctlr);
> What about unpreparing clocks? Is it part of spi_master_put()?


Will add it in the next version.


Thanks and beset regards!


>> +
>> +	return ret;
>> +}
>> +
>> +static const struct ingenic_soc_info x1000_soc_info = {
>> +	.version = ID_X1000,
>> +
> No need for blank lines after each field.
>
>
> Best regards,
> Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 18:38   ` Mark Brown
@ 2022-07-23 17:06     ` Zhou Yanjie
  2022-07-23 19:32       ` Mark Brown
  0 siblings, 1 reply; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-23 17:06 UTC (permalink / raw)
  To: Mark Brown
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd, linux-spi,
	linux-mips, linux-kernel, devicetree, aidanmacdonald.0x0, tmn505,
	paul, dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu,
	sernia.zhou, reimu

Hi Mark,

On 2022/7/23 上午2:38, Mark Brown wrote:
> On Sat, Jul 23, 2022 at 12:48:30AM +0800, 周琰杰 (Zhou Yanjie) wrote:
>
> This looks mostly good, a few small issues though:
>
>> +++ b/drivers/spi/spi-ingenic-sfc.c
>> @@ -0,0 +1,662 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +/*
>> + * Ingenic SoCs SPI Flash Controller Driver
> Please make the entire comment a C++ one so things look more
> intentional.


I'm sorry, I didn't understand well what you meant :(
Could you please explain a little more detail?


>
>> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
>> +{
>> +	struct ingenic_sfc *sfc = data;
>> +
>> +	writel(0x1f, sfc->base + SFC_REG_INTC);
>> +
>> +	complete(&sfc->completion);
>> +
>> +	return IRQ_HANDLED;
>> +}
> This doesn't pay any attention to any status registers in the chip so
> won't work if the interrupt is shared and won't notice any error reports
> from the device...


This interrupt is exclusively owned by SFC, do we still
need to perform the operation you said? I haven't done
these operations before because I want to minimize the
overhead and avoid affecting performance.


>
>> +static int ingenic_sfc_setup(struct spi_device *spi)
>> +{
>> +	struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
>> +	unsigned long rate;
>> +	int ret, val;
>> +
>> +	if (!spi->max_speed_hz)
>> +		return -EINVAL;
>> +
>> +	ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
>> +	if (ret)
>> +		return -EINVAL;
> The setup() operation should be safe for use on one device while another
> device is active.  It's not going to be a problem until there's a
> version of the IP with more than one chip select, but that could happen
> some time (and someone might decide to make a board using GPIO chip
> selects...) but this should really go into the data path.


Sure, I will change it in the next version.


>> +	ret = clk_prepare_enable(sfc->clk);
>> +	if (ret)
>> +		goto err_put_master;
> Nothing ever disables this clock.  It might also be nice to enable the
> clock only when the controller is in use, that bit is not super
> important though.


Sure, will add it.


>
>> +	ret = devm_request_irq(&pdev->dev, sfc->irq, ingenic_sfc_irq_handler, 0,
>> +			dev_name(&pdev->dev), sfc);
>> +	if (ret) {
>> +		dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", sfc->irq, ret);
>> +		goto err_put_master;
>> +	}
> It's not safe to use devm here...


Sure, will fix it in the next version.


>
>> +	ret = devm_spi_register_controller(&pdev->dev, ctlr);
>> +	if (ret)
>> +		goto err_put_master;
> ...unregistering the controller may free the driver data structure and
> the interrupt handler uses it so we could attempt to use freed data in
> the window between the controller being unregistered and the interrupt
> being freed.


Sure.


Thanks and best regards!



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 20:03   ` Paul Cercueil
@ 2022-07-23 17:26     ` Zhou Yanjie
  2022-07-23 20:24       ` Paul Cercueil
  0 siblings, 1 reply; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-23 17:26 UTC (permalink / raw)
  To: Paul Cercueil
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt, linux-mtd,
	linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, dongsheng.qiu, aric.pzqi, rick.tyliu,
	jinghui.liu, sernia.zhou, reimu

Hi Paul,

On 2022/7/23 上午4:03, Paul Cercueil wrote:
> Hi Zhou,
>
>
> Le sam., juil. 23 2022 at 00:48:30 +0800, 周琰杰 (Zhou Yanjie) 
> <zhouyanjie@wanyeetech.com> a écrit :
>> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
>> from Ingenic.
>>
>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> ---
>>  drivers/spi/Kconfig           |   9 +
>>  drivers/spi/Makefile          |   1 +
>>  drivers/spi/spi-ingenic-sfc.c | 662 
>> ++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 672 insertions(+)
>>  create mode 100644 drivers/spi/spi-ingenic-sfc.c
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 3b1044e..1077bd3 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -437,6 +437,15 @@ config SPI_INGENIC
>>        To compile this driver as a module, choose M here: the module
>>        will be called spi-ingenic.
>>
>> +config SPI_INGENIC_SFC
>> +    tristate "Ingenic SoCs SPI Flash Controller"
>> +    depends on MACH_INGENIC || COMPILE_TEST
>> +    help
>> +      This enables support for the Ingenic SoCs SPI flash controller.
>> +
>> +      To compile this driver as a module, choose M here: the module
>> +      will be called ingenic-sfc.
>> +
>>  config SPI_INTEL
>>      tristate
>>
>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>> index 0f44eb6..f3e42c0 100644
>> --- a/drivers/spi/Makefile
>> +++ b/drivers/spi/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)        += 
>> spi-hisi-sfc-v3xx.o
>>  obj-$(CONFIG_SPI_IMG_SPFI)        += spi-img-spfi.o
>>  obj-$(CONFIG_SPI_IMX)            += spi-imx.o
>>  obj-$(CONFIG_SPI_INGENIC)        += spi-ingenic.o
>> +obj-$(CONFIG_SPI_INGENIC_SFC)    += spi-ingenic-sfc.o
>>  obj-$(CONFIG_SPI_INTEL)            += spi-intel.o
>>  obj-$(CONFIG_SPI_INTEL_PCI)        += spi-intel-pci.o
>>  obj-$(CONFIG_SPI_INTEL_PLATFORM)    += spi-intel-platform.o
>> diff --git a/drivers/spi/spi-ingenic-sfc.c 
>> b/drivers/spi/spi-ingenic-sfc.c
>> new file mode 100644
>> index 00000000..a565546
>> --- /dev/null
>> +++ b/drivers/spi/spi-ingenic-sfc.c
>> @@ -0,0 +1,662 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>
> Dual-license driver? That's not what MODULE_LICENSE() says.
>

My fault, forgot to modify MODULE_LICENSE(), will fix it in the next 
version.


>> +/*
>> + * Ingenic SoCs SPI Flash Controller Driver
>> + * Copyright (c) 2022 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/completion.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/module.h>
>> +#include <linux/mtd/mtd.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/spi/spi.h>
>> +#include <linux/spi/spi-mem.h>
>> +
>> +/* SFC register offsets */
>> +#define SFC_REG_GLB                        0x0000
>> +#define SFC_REG_DEV_CONF                0x0004
>> +#define SFC_REG_DEV_STA_EXP                0x0008
>> +#define SFC_REG_DEV_STA_RT                0x000c
>> +#define SFC_REG_DEV_STA_MSK                0x0010
>> +#define SFC_REG_TRAN_CONF(n)            (0x0014 + n * 4)
>> +#define SFC_REG_TRAN_CFG0(n)            (0x0014 + n * 4)
>
> You should protect the macro parameter. If you do for instance 
> SFC_REG_TRAN_CONF(x + 1) it would resolve to (0x0014 + x + 1 * 4) 
> which is not what you'd want.
>

Sure, will fix it.


> Also - looks like SFC_REG_TRAN_CONF() and SFC_REG_TRAN_CFG0() are the 
> same thing, that's on purpose?
>
>> +#define SFC_REG_TRAN_LEN 0x002c
>> +#define SFC_REG_DEV_ADDR(n)                (0x0030 + n * 4)
>> +#define SFC_REG_DEV_ADDR_PLUS(n)        (0x0048 + n * 4)
>> +#define SFC_REG_MEM_ADDR                0x0060
>> +#define SFC_REG_TRIG                    0x0064
>> +#define SFC_REG_SR                        0x0068
>> +#define SFC_REG_SCR                        0x006c
>> +#define SFC_REG_INTC                    0x0070
>> +#define SFC_REG_FSM                        0x0074
>> +#define SFC_REG_CGE                        0x0078
>> +#define SFC_REG_TRAN_CFG1(n)            (0x009c + n * 4)
>> +#define SFC_REG_DR                        0x1000
>> +
>> +/* bits within the GLB register */
>> +#define GLB_TRAN_DIR_MASK                GENMASK(13, 13)
>> +#define GLB_TRAN_DIR_WRITE                0x1
>> +#define GLB_TRAN_DIR_READ                0x0
>
> When it's a single bit - just use BIT().


Sure.


>
>> +#define GLB_THRESHOLD_MASK GENMASK(12, 7)
>> +#define GLB_OP_MODE_MASK                GENMASK(6, 6)
>
> Same here, and I see it a few times below as well.
>

Sure.


>> +#define GLB_OP_MODE_DMA                    0x1
>> +#define GLB_OP_MODE_SLAVE                0x0
>> +#define GLB_PHASE_NUM_MASK                GENMASK(5, 3)
>> +#define GLB_WP_EN                        BIT(2)
>> +#define GLB_BURST_MD_MASK                GENMASK(1, 0)
>> +#define GLB_BURST_MD_INCR32                0x3
>> +#define GLB_BURST_MD_INCR16                0x2
>> +#define GLB_BURST_MD_INCR8                0x1
>> +#define GLB_BURST_MD_INCR4                0x0
>> +
>> +/* bits within the DEV_CONF register */
>> +#define DEV_CONF_SMP_DELAY_MASK            GENMASK(20, 16)
>> +#define DEV_CONF_SMP_DELAY_180DEG        0x4
>> +#define DEV_CONF_SMP_DELAY_HALF_CYCLE    0x1
>> +#define DEV_CONF_CMD_TYPE_MASK            GENMASK(15, 15)
>> +#define DEV_CONF_CMD_TYPE_16BIT            0x1
>> +#define DEV_CONF_CMD_TYPE_8BIT            0x0
>> +#define DEV_CONF_STA_TYPE_MASK            GENMASK(14, 13)
>> +#define DEV_CONF_THOLD_MASK                GENMASK(12, 11)
>> +#define DEV_CONF_TSETUP_MASK            GENMASK(10, 9)
>> +#define DEV_CONF_TSH_MASK                GENMASK(8, 5)
>> +#define DEV_CONF_CPHA                    BIT(4)
>> +#define DEV_CONF_CPOL                    BIT(3)
>> +#define DEV_CONF_CE_DL                    BIT(2)
>> +#define DEV_CONF_HOLD_DL                BIT(1)
>> +#define DEV_CONF_WP_DL                    BIT(0)
>> +
>> +/* bits within the TRAN_CONF(n) register */
>> +#define TRAN_CONF_TRAN_MODE_MASK        GENMASK(31, 29)
>> +#define TRAN_CONF_ADDR_WIDTH_MASK        GENMASK(28, 26)
>> +#define TRAN_CONF_POLL_EN                BIT(25)
>> +#define TRAN_CONF_CMD_EN                BIT(24)
>> +#define TRAN_CONF_PHASE_FORMAT_MASK        GENMASK(23, 23)
>> +#define TRAN_CONF_DMY_BITS_MASK            GENMASK(22, 17)
>> +#define TRAN_CONF_DATA_EN                BIT(16)
>> +#define TRAN_CONF_CMD_MASK                GENMASK(15, 0)
>> +
>> +/* bits within the TRIG register */
>> +#define TRIG_FLUSH                        BIT(2)
>> +#define TRIG_STOP                        BIT(1)
>> +#define TRIG_START                        BIT(0)
>> +
>> +/* bits within the SR register */
>> +#define SR_FIFO_NUM_MASK                GENMASK(22, 16)
>> +#define SR_END                            BIT(4)
>> +#define SR_TRAN_REQ                        BIT(3)
>> +#define SR_RECE_REQ                        BIT(2)
>> +#define SR_OVER                            BIT(1)
>> +#define SR_UNDER                        BIT(0)
>> +
>> +/* bits within the SCR register */
>> +#define SCR_CLR_END                        BIT(4)
>> +#define SCR_CLR_TREQ                    BIT(3)
>> +#define SCR_CLR_RREQ                    BIT(2)
>> +#define SCR_CLR_OVER                    BIT(1)
>> +#define SCR_CLR_UNDER                    BIT(0)
>> +
>> +/* bits within the INTC register */
>> +#define INTC_MASK_END                    BIT(4)
>> +#define INTC_MASK_TREQ                    BIT(3)
>> +#define INTC_MASK_RREQ                    BIT(2)
>> +#define INTC_MASK_OVER                    BIT(1)
>> +#define INTC_MASK_UNDER                    BIT(0)
>> +
>> +/* bits within the TRAN_CFG1(n) register */
>> +#define TRAN_CFG1_TRAN_MODE_MASK        GENMASK(7, 4)
>> +
>> +#define TRAN_MODE_STANDARD                0
>> +#define TRAN_MODE_DUAL_DATA                1
>> +#define TRAN_MODE_DUAL_IO                2
>> +#define TRAN_MODE_DUAL_FULL                3
>> +#define TRAN_MODE_QUAD_DATA                5
>> +#define TRAN_MODE_QUAD_IO                6
>> +#define TRAN_MODE_QUAD_FULL                7
>> +#define TRAN_MODE_OCTAL_DATA            9
>> +#define TRAN_MODE_OCTAL_IO                10
>> +#define TRAN_MODE_OCTAL_FULL            11
>> +
>> +#define INGENIC_SFC_FIFO_SIZE            (64 * 4)
>> +
>> +#define INGENIC_SFC_TRANSFER_TIMEOUT    1000
>
> Maybe add the unit name in the macro as well - 
> INGENIC_SFC_TRANSFER_TIMEOUT_MS.


Sure.


>
>> +
>> +enum ingenic_sfc_version {
>> +    ID_X1000,
>> +    ID_X1600,
>> +    ID_X2000,
>> +};
>> +
>> +struct ingenic_soc_info {
>> +    enum ingenic_sfc_version version;
>> +
>> +    unsigned int max_bus_width;
>> +
>> +    const u32 tran_mode_mask;
>> +};
>> +
>> +struct ingenic_sfc {
>> +    const struct ingenic_soc_info *soc_info;
>> +
>> +    void __iomem *base;
>> +    struct device *dev;
>> +    struct clk *clk;
>> +    int irq;
>> +
>> +    struct completion completion;
>> +};
>> +
>> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
>> +{
>> +    struct ingenic_sfc *sfc = data;
>> +
>> +    writel(0x1f, sfc->base + SFC_REG_INTC);
>> +
>> +    complete(&sfc->completion);
>> +
>> +    return IRQ_HANDLED;
>> +}
>> +
>> +static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct 
>> spi_mem_op *op)
>> +{
>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>> +
>> +    if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 
>> 4))
>> +        op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
>> +
>> +    return 0;
>> +}
>> +
>> +static bool ingenic_sfc_supports_op(struct spi_mem *mem, const 
>> struct spi_mem_op *op)
>> +{
>> +    struct spi_device *spi = mem->spi;
>> +    struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>> +
>> +    /* The controller only supports Standard SPI mode, Duall mode, 
>> Quad mode and Octal mode. */
>
> Dual*


Oops, will fix it.


>
>> +    if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
>> +        op->addr.buswidth > sfc->soc_info->max_bus_width ||
>> +        op->dummy.buswidth > sfc->soc_info->max_bus_width ||
>> +        op->data.buswidth > sfc->soc_info->max_bus_width)
>> +        return false;
>> +
>> +    /* Max 32 dummy clock cycles supported */
>> +    if (op->dummy.nbytes && op->dummy.nbytes * 8 / 
>> op->dummy.buswidth > 32)
>> +        return false;
>> +
>> +    /* Max rx data length, check controller limits and alignment */
>> +    if (op->data.dir == SPI_MEM_DATA_IN &&
>> +        op->data.nbytes > INGENIC_SFC_FIFO_SIZE && !IS_ALIGNED(addr, 
>> 4))
>
> This does the same check than in ingenic_sfc_adjust_op_size(), maybe 
> move it to a new inline function?
>

Sure.


>> +        return false;
>> +
>> +    /* Max 6 bytes address width supported */
>> +    if (op->addr.nbytes > 6)
>> +        return false;
>> +
>> +    return spi_mem_default_supports_op(mem, op);
>> +}
>> +
>> +static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, 
>> const struct spi_mem_op *op)
>> +{
>> +    int val;
>> +
>> +    val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>> +            SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
>
> As Krzysztof said - ugh.
>

Will fix it.


> Also, instead of having a "version" enum in your soc_info, why not 
> just have a "reg_conf" field that gives you directly the right register?
>

We still need a version to distinguish the SFC before X1600 SoC and
the SFC after X1600 SoC, because in addition to the difference in the
cfg register, another difference is that the SFC before X1600 SoC does
not support address unaligned RX DMA transfer, while SFC in X1600 and
later SoCs can support this feature.


>
>> +    val &= ~sfc->soc_info->tran_mode_mask;
>> +    if (op->cmd.buswidth == 8)
>> +        val |= (TRAN_MODE_OCTAL_FULL << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>
> Looks like you're really trying to reinvent the wheel.
>
> val |= FIELD_PREP(sfc->soc_info->tran_mode_mask, TRAN_MODE_OCTAL_FULL);
>
> using <linux/bitfield.h>.
>
> Also, just define a 'mode' variable and set it in your if/else blocks, 
> that would look much better. Then you can set val |= FIELD_PREP(..., 
> mode) at the end.


Sure, will change this in the next version.


>
>> +    else if (op->cmd.buswidth == 4)
>> +        val |= (TRAN_MODE_QUAD_FULL << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->cmd.buswidth == 2)
>> +        val |= (TRAN_MODE_DUAL_FULL << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->addr.buswidth == 8)
>> +        val |= (TRAN_MODE_OCTAL_IO << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->addr.buswidth == 4)
>> +        val |= (TRAN_MODE_QUAD_IO << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->addr.buswidth == 2)
>> +        val |= (TRAN_MODE_DUAL_IO << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->data.buswidth == 8)
>> +        val |= (TRAN_MODE_OCTAL_DATA << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->data.buswidth == 4)
>> +        val |= (TRAN_MODE_QUAD_DATA << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else if (op->data.buswidth == 2)
>> +        val |= (TRAN_MODE_DUAL_DATA << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    else
>> +        val |= (TRAN_MODE_STANDARD << 
>> (ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>> +                sfc->soc_info->tran_mode_mask;
>> +    writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>> +            SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
>> +}
>> +
>> +/*
>> + * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
>> + * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
>> + */
>> +static void ingenic_sfc_read_rxfifo(struct ingenic_sfc *sfc, u8 *to, 
>> unsigned int len)
>> +{
>> +    void __iomem *from;
>> +
>> +    from = sfc->base + SFC_REG_DR;
>> +
>> +    for (; len >= 4; len -= 4, to += 4) {
>> +        u32 val = __raw_readl(from);
>> +        memcpy(to, &val, 4);
>
> No need to use memcpy for 4 bytes. You can do: put_unaligned(val, (u32 
> *)to);
>

Sure.


>> +    }
>> +
>> +    if (len) {
>> +        u32 val = __raw_readl(from);
>> +        memcpy(to, &val, len);
>
> Hmm, I'm not sure that is endian-safe. I would prefer if you copied 
> byte by byte.
>

Sure.


>> +    }
>> +}
>> +
>> +static int ingenic_sfc_exec_op_pio(struct ingenic_sfc *sfc, const 
>> struct spi_mem_op *op)
>> +{
>> +    int ret, val;
>> +
>> +    val = readl(sfc->base + SFC_REG_GLB);
>> +    u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>> +    writel(val, sfc->base + SFC_REG_GLB);
>
> By the way, have you considered using regmap?
>
> It would give you things like regmap_update_bits() for this kind of 
> things, and regmap_field() to handle your conf register being at a 
> different address across SoCs.
>

It seems that the overhead of using regmap will be greater than using 
readl and writel,
the purpose of using readl and writel is to minimize overhead and 
maximize performance. :)


>> +
>> +    val = TRAN_CONF_CMD_EN | op->cmd.opcode;
>> +
>> +    if (op->addr.nbytes > 0) {
>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
>> +
>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>> SFC_REG_DEV_ADDR(0));
>> +        writel(op->addr.val >> 32, sfc->base + 
>> SFC_REG_DEV_ADDR_PLUS(0));
>> +    }
>> +
>> +    if (op->dummy.nbytes > 0)
>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>> +
>> +    if (op->data.nbytes > 0)
>> +        val |= TRAN_CONF_DATA_EN;
>> +
>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>> +
>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>> +
>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>
> Random 0x1f value here, maybe use a macro?


Sure.


>
>> +    writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + 
>> SFC_REG_INTC);
>> +
>> +    writel(0, sfc->base + SFC_REG_MEM_ADDR);
>> +
>> +    writel(TRIG_FLUSH, sfc->base + SFC_REG_TRIG);
>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>> +
>> +    ret = wait_for_completion_timeout(&sfc->completion,
>> +            msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>> +    if (!ret) {
>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>> device\n", __LINE__);
>> +        return -ETIMEDOUT;
>> +    }
>> +
>> +    ingenic_sfc_read_rxfifo(sfc, op->data.buf.in, op->data.nbytes);
>> +    readl_poll_timeout(sfc->base + SFC_REG_SR, val, val & SR_END, 
>> 10, 0);
>
> Infinite timeout? Is that very wise?


Will fix it in the next version.


>
>> +
>> +    writel(INTC_MASK_END | INTC_MASK_RREQ, sfc->base + SFC_REG_SCR);
>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>> +
>> +    return 0;
>> +}
>> +
>> +static int ingenic_sfc_exec_op_dma(struct ingenic_sfc *sfc, const 
>> struct spi_mem_op *op)
>> +{
>> +    dma_addr_t addr;
>> +    int ret, val;
>> +
>> +    val = readl(sfc->base + SFC_REG_GLB);
>> +    u32p_replace_bits(&val, op->data.dir == SPI_MEM_DATA_IN ?
>> +            GLB_TRAN_DIR_READ : GLB_TRAN_DIR_WRITE, GLB_TRAN_DIR_MASK);
>> +    u32p_replace_bits(&val, GLB_OP_MODE_DMA, GLB_OP_MODE_MASK);
>> +    writel(val, sfc->base + SFC_REG_GLB);
>> +
>> +    val = TRAN_CONF_CMD_EN | op->cmd.opcode;
>> +
>> +    if (op->addr.nbytes > 0) {
>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>> SFC_REG_DEV_ADDR(0));
>> +        writel(op->addr.val >> 32, sfc->base + 
>> SFC_REG_DEV_ADDR_PLUS(0));
>> +    }
>> +
>> +    if (op->dummy.nbytes > 0)
>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>> +
>> +    if (op->data.nbytes > 0)
>> +        val |= TRAN_CONF_DATA_EN;
>
> There's a lot of code duplication here with ingenic_sfc_exec_op_pio(). 
> A lot can be factorized.


Sure, I will try to do it.


>
>> +
>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>> +
>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>> +
>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>> +    writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
>> +
>> +    switch (op->data.dir) {
>> +    case SPI_MEM_DATA_IN:
>> +        addr = dma_map_single(sfc->dev, op->data.buf.in, 
>> op->data.nbytes, DMA_FROM_DEVICE);
>> +        if (dma_mapping_error(sfc->dev, addr)) {
>> +            dev_err(sfc->dev, "RX DMA memory not mapped\n");
>> +            return -ENOMEM;
>> +        }
>> +
>> +        writel(addr, sfc->base + SFC_REG_MEM_ADDR);
>> +        break;
>> +
>> +    case SPI_MEM_DATA_OUT:
>> +        addr = dma_map_single(sfc->dev, (void *)op->data.buf.out,
>> +                op->data.nbytes, DMA_TO_DEVICE);
>> +        if (dma_mapping_error(sfc->dev, addr)) {
>> +            dev_err(sfc->dev, "TX DMA memory not mapped\n");
>> +            return -ENOMEM;
>> +        }
>> +
>> +        writel(addr, sfc->base + SFC_REG_MEM_ADDR);
>> +        break;
>> +
>> +    default:
>> +        return -EINVAL;
>> +    }
>> +
>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>> +
>> +    ret = wait_for_completion_timeout(&sfc->completion,
>> +            msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>> +    if (!ret) {
>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>> device\n", __LINE__);
>> +        return -ETIMEDOUT;
>> +    }
>> +
>> +    dma_unmap_single(sfc->dev, addr, op->data.nbytes,
>> +            op->data.dir == SPI_MEM_DATA_IN ? DMA_FROM_DEVICE : 
>> DMA_TO_DEVICE);
>
> Use a small inline function for that too. My personal rule is that ?: 
> is fine if the line fits in 80 characters, but if you have to break, 
> then you really need to move it somewhere else.
>

Sure.


>> +
>> +    writel(INTC_MASK_END, sfc->base + SFC_REG_SCR);
>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>> +
>> +    return 0;
>> +}
>> +
>> +static int ingenic_sfc_exec_op(struct spi_mem *mem, const struct 
>> spi_mem_op *op)
>> +{
>> +    struct spi_device *spi = mem->spi;
>> +    struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>> +
>> +    init_completion(&sfc->completion);
>> +
>> +    switch (op->data.dir) {
>> +    case SPI_MEM_DATA_IN:
>> +        if (sfc->soc_info->version >= ID_X1600 || IS_ALIGNED(addr, 4))
>> +            break;
>> +
>> +        fallthrough;
>> +
>> +    case SPI_MEM_NO_DATA:
>> +        return ingenic_sfc_exec_op_pio(sfc, op);
>> +
>> +    default:
>> +        break;
>> +    }
>> +
>> +    return ingenic_sfc_exec_op_dma(sfc, op);
>> +}
>> +
>> +static int ingenic_sfc_poll_status(struct spi_mem *mem, const struct 
>> spi_mem_op *op,
>> +            u16 mask, u16 match, unsigned long initial_delay_us,
>> +            unsigned long polling_delay_us, unsigned long timeout_ms)
>> +{
>> +    struct spi_device *spi = mem->spi;
>> +    struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
>> +    int ret, val;
>> +
>> +    init_completion(&sfc->completion);
>> +
>> +    val = readl(sfc->base + SFC_REG_GLB);
>> +    u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>> +    writel(val, sfc->base + SFC_REG_GLB);
>> +
>> +    writel(match, sfc->base + SFC_REG_DEV_STA_EXP);
>> +    writel(mask, sfc->base + SFC_REG_DEV_STA_MSK);
>> +
>> +    val = TRAN_CONF_POLL_EN | TRAN_CONF_CMD_EN | op->cmd.opcode;
>> +
>> +    if (op->addr.nbytes > 0) {
>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
>> +
>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>> SFC_REG_DEV_ADDR(0));
>> +        writel(op->addr.val >> 32, sfc->base + 
>> SFC_REG_DEV_ADDR_PLUS(0));
>> +    }
>> +
>> +    if (op->dummy.nbytes > 0)
>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>> +
>> +    if (op->data.nbytes > 0)
>> +        val |= TRAN_CONF_DATA_EN;
>> +
>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>> +
>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>> +
>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>> +    writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
>> +
>> +    writel(0, sfc->base + SFC_REG_MEM_ADDR);
>> +
>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>> +
>> +    ret = wait_for_completion_timeout(&sfc->completion,
>> +            msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>> +    if (!ret) {
>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>> device\n", __LINE__);
>> +        return -ETIMEDOUT;
>> +    }
>> +
>> +    writel(SCR_CLR_END, sfc->base + SFC_REG_SCR);
>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>> +
>> +    return 0;
>> +}
>> +
>> +static const struct spi_controller_mem_ops ingenic_sfc_mem_ops = {
>> +    .adjust_op_size = ingenic_sfc_adjust_op_size,
>> +    .supports_op = ingenic_sfc_supports_op,
>> +    .exec_op = ingenic_sfc_exec_op,
>> +    .poll_status = ingenic_sfc_poll_status,
>> +};
>> +
>> +static int ingenic_sfc_setup(struct spi_device *spi)
>> +{
>> +    struct ingenic_sfc *sfc = spi_controller_get_devdata(spi->master);
>> +    unsigned long rate;
>> +    int ret, val;
>> +
>> +    if (!spi->max_speed_hz)
>> +        return -EINVAL;
>
> Maybe set a sane default?


Sure.


>
>> +
>> +    ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
>> +    if (ret)
>> +        return -EINVAL;
>> +
>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>> +    writel(0, sfc->base + SFC_REG_DEV_CONF);
>> +    writel(0, sfc->base + SFC_REG_CGE);
>> +
>> +    val = readl(sfc->base + SFC_REG_GLB);
>> +    u32p_replace_bits(&val, 64 - 1, GLB_THRESHOLD_MASK);
>> +    writel(val, sfc->base + SFC_REG_GLB);
>> +
>> +    val = readl(sfc->base + SFC_REG_DEV_CONF);
>> +
>> +    /* cpha bit:0 , cpol bit:0 */
>> +    val &= ~(DEV_CONF_CPHA | DEV_CONF_CPOL);
>> +    val |= spi->mode & SPI_CPHA ? DEV_CONF_CPHA : 0;
>> +    val |= spi->mode & SPI_CPOL ? DEV_CONF_CPOL : 0;
>> +
>> +    /* ce_dl bit:1, hold bit:1, wp bit:1 */
>> +    val |= (DEV_CONF_CE_DL | DEV_CONF_HOLD_DL | DEV_CONF_WP_DL);
>> +
>> +    writel(val, sfc->base + SFC_REG_DEV_CONF);
>> +
>> +    val = readl(sfc->base + SFC_REG_GLB);
>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>> +    writel(val, sfc->base + SFC_REG_GLB);
>> +
>> +    rate = clk_get_rate(sfc->clk);
>
> I'd suggest using clk_round_rate() before clk_set_rate() because then 
> you know what frequency it's going to be, and you don't have to call 
> clk_get_rate() afterwards.
>

Sure, will try.


Thanks and best regards!


> Cheers,
> -Paul
>
>> +    val = readl(sfc->base + SFC_REG_DEV_CONF);
>> +    if (sfc->soc_info->version >= ID_X1600 && rate >= 200000000)
>> +        u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_180DEG, 
>> DEV_CONF_SMP_DELAY_MASK);
>> +    else if (sfc->soc_info->version == ID_X1000 && rate >= 100000000)
>> +        u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_HALF_CYCLE, 
>> DEV_CONF_SMP_DELAY_MASK);
>> +    writel(val, sfc->base + SFC_REG_DEV_CONF);
>> +
>> +    return 0;
>> +}
>> +
>> +static int ingenic_sfc_probe(struct platform_device *pdev)
>> +{
>> +    struct ingenic_sfc *sfc;
>> +    struct spi_controller *ctlr;
>> +    int ret;
>> +
>> +    ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
>> +    if (!ctlr)
>> +        return -ENOMEM;
>> +
>> +    sfc = spi_controller_get_devdata(ctlr);
>> +
>> +    sfc->soc_info = of_device_get_match_data(&pdev->dev);
>> +    if (!sfc->soc_info) {
>> +        dev_err(&pdev->dev, "No of match data provided\n");
>> +        ret = -ENODEV;
>> +        goto err_put_master;
>> +    }
>> +
>> +    sfc->base = devm_platform_ioremap_resource(pdev, 0);
>> +    if (IS_ERR(sfc->base)) {
>> +        ret = PTR_ERR(sfc->base);
>> +        goto err_put_master;
>> +    }
>> +
>> +    sfc->clk = devm_clk_get(&pdev->dev, "sfc");
>> +    if (IS_ERR(sfc->clk)) {
>> +        ret = IS_ERR(sfc->clk);
>> +        goto err_put_master;
>> +    }
>> +
>> +    ret = clk_prepare_enable(sfc->clk);
>> +    if (ret)
>> +        goto err_put_master;
>> +
>> +    sfc->irq = platform_get_irq(pdev, 0);
>> +    if (sfc->irq < 0) {
>> +        ret = sfc->irq;
>> +        goto err_put_master;
>> +    }
>> +
>> +    sfc->dev = &pdev->dev;
>> +
>> +    platform_set_drvdata(pdev, sfc);
>> +
>> +    ret = devm_request_irq(&pdev->dev, sfc->irq, 
>> ingenic_sfc_irq_handler, 0,
>> +            dev_name(&pdev->dev), sfc);
>> +    if (ret) {
>> +        dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", 
>> sfc->irq, ret);
>> +        goto err_put_master;
>> +    }
>> +
>> +    ctlr->bus_num = -1;
>> +    ctlr->num_chipselect = 1;
>> +    ctlr->mem_ops = &ingenic_sfc_mem_ops;
>> +    ctlr->dev.of_node = pdev->dev.of_node;
>> +    ctlr->setup = ingenic_sfc_setup;
>> +    ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
>> +            SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
>> +    if (sfc->soc_info->version >= ID_X2000)
>> +        ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
>> +
>> +    ret = devm_spi_register_controller(&pdev->dev, ctlr);
>> +    if (ret)
>> +        goto err_put_master;
>> +
>> +    return 0;
>> +
>> +err_put_master:
>> +    spi_master_put(ctlr);
>> +
>> +    return ret;
>> +}
>> +
>> +static const struct ingenic_soc_info x1000_soc_info = {
>> +    .version = ID_X1000,
>> +
>> +    .max_bus_width = 4,
>> +
>> +    .tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
>> +};
>> +
>> +static const struct ingenic_soc_info x1600_soc_info = {
>> +    .version = ID_X1600,
>> +
>> +    .max_bus_width = 4,
>> +
>> +    .tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
>> +};
>> +
>> +static const struct ingenic_soc_info x2000_soc_info = {
>> +    .version = ID_X2000,
>> +
>> +    .max_bus_width = 8,
>> +
>> +    .tran_mode_mask = TRAN_CFG1_TRAN_MODE_MASK,
>> +};
>> +
>> +static const struct of_device_id ingenic_sfc_of_matches[] = {
>> +    { .compatible = "ingenic,x1000-sfc", .data = &x1000_soc_info },
>> +    { .compatible = "ingenic,x1600-sfc", .data = &x1600_soc_info },
>> +    { .compatible = "ingenic,x2000-sfc", .data = &x2000_soc_info },
>> +    { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, ingenic_sfc_of_matches);
>> +
>> +static struct platform_driver ingenic_sfc_driver = {
>> +    .driver = {
>> +        .name = "ingenic-sfc",
>> +        .of_match_table = ingenic_sfc_of_matches,
>> +    },
>> +    .probe = ingenic_sfc_probe,
>> +};
>> +module_platform_driver(ingenic_sfc_driver);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>");
>> +MODULE_DESCRIPTION("Ingenic SoCs SPI Flash Controller Driver");
>> -- 
>> 2.7.4
>>
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 16:50     ` Zhou Yanjie
@ 2022-07-23 17:43       ` Krzysztof Kozlowski
  2022-07-23 18:47         ` Mike Yang
  0 siblings, 1 reply; 39+ messages in thread
From: Krzysztof Kozlowski @ 2022-07-23 17:43 UTC (permalink / raw)
  To: Zhou Yanjie, tudor.ambarus, p.yadav, michael, miquel.raynal,
	richard, vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

On 23/07/2022 18:50, Zhou Yanjie wrote:
> Hi Krzysztof,
> 
> On 2022/7/23 上午1:46, Krzysztof Kozlowski wrote:
>> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>>> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
>>> and the X2000 SoC from Ingenic.
>>>
>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>>> ---
>>>   .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>>>   1 file changed, 64 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>> new file mode 100644
>>> index 00000000..b7c4cf4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>> @@ -0,0 +1,64 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
>> File name should be rather based on first compatible, so
>> ingenic,x1000-sfc.yaml
> 
> 
> No offense, does it really need to be named that way?
> I can't seem to find documentation with instructions on this :(
> 
> The use of "ingenic,sfc.yaml" indicates that this is the documentation
> for the SFC module for all Ingenic SoCs, without misleading people into
> thinking it's only for a specific model of SoC. And there seem to be many
> other yaml documents that use similar names (eg. fsl,spi-fsl-qspi.yaml,
> spi-rockchip.yaml, spi-nxp-fspi.yaml, ingenic,spi.yaml, spi-sifive.yaml,
> omap-spi.yaml), maybe these yaml files that are not named with first
> compatible are also for the same consideration. :)

We have many bad examples, many poor patterns and they are never an
argument to add one more bad pattern.

It might never grow to new devices (because they might be different), so
that is not really an argument.

All bindings are to follow this rule, so I don't understand why you
think it is an exception for you?


Best regards,
Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 17:43       ` Krzysztof Kozlowski
@ 2022-07-23 18:47         ` Mike Yang
  2022-07-23 19:27           ` Mark Brown
  2022-07-23 20:05           ` Krzysztof Kozlowski
  0 siblings, 2 replies; 39+ messages in thread
From: Mike Yang @ 2022-07-23 18:47 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Zhou Yanjie, tudor.ambarus, p.yadav,
	michael, miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou

On 7/24/22 01:43, Krzysztof Kozlowski wrote:
> On 23/07/2022 18:50, Zhou Yanjie wrote:
>> Hi Krzysztof,
>>
>> On 2022/7/23 上午1:46, Krzysztof Kozlowski wrote:
>>> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>>>> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
>>>> and the X2000 SoC from Ingenic.
>>>>
>>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>>>> ---
>>>>   .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>>>>   1 file changed, 64 insertions(+)
>>>>   create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>> new file mode 100644
>>>> index 00000000..b7c4cf4
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>> @@ -0,0 +1,64 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
>>> File name should be rather based on first compatible, so
>>> ingenic,x1000-sfc.yaml
>>
>>
>> No offense, does it really need to be named that way?
>> I can't seem to find documentation with instructions on this :(
>>
>> The use of "ingenic,sfc.yaml" indicates that this is the documentation
>> for the SFC module for all Ingenic SoCs, without misleading people into
>> thinking it's only for a specific model of SoC. And there seem to be many
>> other yaml documents that use similar names (eg. fsl,spi-fsl-qspi.yaml,
>> spi-rockchip.yaml, spi-nxp-fspi.yaml, ingenic,spi.yaml, spi-sifive.yaml,
>> omap-spi.yaml), maybe these yaml files that are not named with first
>> compatible are also for the same consideration. :)
> 
> We have many bad examples, many poor patterns and they are never an
> argument to add one more bad pattern.

Zhou already mentioned he was unable find the naming guidelines of these .yaml files.

Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.

> 
> It might never grow to new devices (because they might be different), so
> that is not really an argument.

It is an argument. A very valid one.

"they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.

I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.

> 
> All bindings are to follow this rule, so I don't understand why you
> think it is an exception for you?

Zhou didn't ask you to make an exception. They have a valid point and they're asking why.

You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.

> 
> 
> Best regards,
> Krzysztof

Best regards,
Mike Yang

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 18:47         ` Mike Yang
@ 2022-07-23 19:27           ` Mark Brown
  2022-07-23 20:07             ` Krzysztof Kozlowski
  2022-07-23 20:05           ` Krzysztof Kozlowski
  1 sibling, 1 reply; 39+ messages in thread
From: Mark Brown @ 2022-07-23 19:27 UTC (permalink / raw)
  To: Mike Yang
  Cc: Krzysztof Kozlowski, Zhou Yanjie, tudor.ambarus, p.yadav,
	michael, miquel.raynal, richard, vigneshr, robh+dt,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, tmn505, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou


[-- Attachment #1.1: Type: text/plain, Size: 768 bytes --]

On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote:
> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
> > On 23/07/2022 18:50, Zhou Yanjie wrote:

> >> No offense, does it really need to be named that way?
> >> I can't seem to find documentation with instructions on this :(

...

> > All bindings are to follow this rule, so I don't understand why you
> > think it is an exception for you?

> Zhou didn't ask you to make an exception. They have a valid
> point and they're asking why.

> You may want to avoid further incidents of this kind by stop
> being bossy and actually writing a guideline of naming these
> .yaml files and publish it somewhere online.

Yeah, I do have to say that I was also completely unaware that
there was any enforced convention here.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-23 17:06     ` Zhou Yanjie
@ 2022-07-23 19:32       ` Mark Brown
  2022-07-24  1:24         ` Zhou Yanjie
  0 siblings, 1 reply; 39+ messages in thread
From: Mark Brown @ 2022-07-23 19:32 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd, linux-spi,
	linux-mips, linux-kernel, devicetree, aidanmacdonald.0x0, tmn505,
	paul, dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu,
	sernia.zhou, reimu


[-- Attachment #1.1: Type: text/plain, Size: 1640 bytes --]

On Sun, Jul 24, 2022 at 01:06:16AM +0800, Zhou Yanjie wrote:
> On 2022/7/23 上午2:38, Mark Brown wrote:

> > > +++ b/drivers/spi/spi-ingenic-sfc.c
> > > @@ -0,0 +1,662 @@
> > > +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +/*
> > > + * Ingenic SoCs SPI Flash Controller Driver

> > Please make the entire comment a C++ one so things look more
> > intentional.

> I'm sorry, I didn't understand well what you meant :(
> Could you please explain a little more detail?

The above comment block uses both C /* */ and C++ // style comments,
please make it just use the C++ style.

> > > +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
> > > +{
> > > +	struct ingenic_sfc *sfc = data;
> > > +
> > > +	writel(0x1f, sfc->base + SFC_REG_INTC);
> > > +
> > > +	complete(&sfc->completion);
> > > +
> > > +	return IRQ_HANDLED;
> > > +}

> > This doesn't pay any attention to any status registers in the chip so
> > won't work if the interrupt is shared and won't notice any error reports
> > from the device...

> This interrupt is exclusively owned by SFC, do we still
> need to perform the operation you said? I haven't done
> these operations before because I want to minimize the
> overhead and avoid affecting performance.

Even if the device is not shared is there no possibility that the
device can report an unexpected interrupt status?  It's not just
the sharing case, it's also the fact that it looks like there's a
status being reported but we're not checking it so if anything
goes wrong then we're less likely to notice.  I'd worry about
data corruption.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 18:47         ` Mike Yang
  2022-07-23 19:27           ` Mark Brown
@ 2022-07-23 20:05           ` Krzysztof Kozlowski
  2022-07-24 14:52             ` Zhou Yanjie
  1 sibling, 1 reply; 39+ messages in thread
From: Krzysztof Kozlowski @ 2022-07-23 20:05 UTC (permalink / raw)
  To: Mike Yang, Zhou Yanjie, tudor.ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou

On 23/07/2022 20:47, Mike Yang wrote:
> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
>> On 23/07/2022 18:50, Zhou Yanjie wrote:
>>> Hi Krzysztof,
>>>
>>> On 2022/7/23 上午1:46, Krzysztof Kozlowski wrote:
>>>> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>>>>> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
>>>>> and the X2000 SoC from Ingenic.
>>>>>
>>>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>>>>> ---
>>>>>   .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>>>>>   1 file changed, 64 insertions(+)
>>>>>   create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>> new file mode 100644
>>>>> index 00000000..b7c4cf4
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>> @@ -0,0 +1,64 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
>>>> File name should be rather based on first compatible, so
>>>> ingenic,x1000-sfc.yaml
>>>
>>>
>>> No offense, does it really need to be named that way?
>>> I can't seem to find documentation with instructions on this :(
>>>
>>> The use of "ingenic,sfc.yaml" indicates that this is the documentation
>>> for the SFC module for all Ingenic SoCs, without misleading people into
>>> thinking it's only for a specific model of SoC. And there seem to be many
>>> other yaml documents that use similar names (eg. fsl,spi-fsl-qspi.yaml,
>>> spi-rockchip.yaml, spi-nxp-fspi.yaml, ingenic,spi.yaml, spi-sifive.yaml,
>>> omap-spi.yaml), maybe these yaml files that are not named with first
>>> compatible are also for the same consideration. :)
>>
>> We have many bad examples, many poor patterns and they are never an
>> argument to add one more bad pattern.
> 
> Zhou already mentioned he was unable find the naming guidelines of these .yaml files.
> 
> Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.

It's everywhere in the kernel, what can I say? If you copy existing
code, you might copy poor code...

> 
>>
>> It might never grow to new devices (because they might be different), so
>> that is not really an argument.
> 
> It is an argument. A very valid one.
> 
> "they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.
> 
> I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.
> 
>>
>> All bindings are to follow this rule, so I don't understand why you
>> think it is an exception for you?
> 
> Zhou didn't ask you to make an exception. They have a valid point and they're asking why.

Hm, everyone has the same valid point and such recommendation is to
everyone, although it is nothing serious.

> You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.

I did not see any incident here... Process of review includes comments
and there is nothing bad happening when you receive a comment. No
incident...

Best regards,
Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 19:27           ` Mark Brown
@ 2022-07-23 20:07             ` Krzysztof Kozlowski
  2022-07-23 20:49               ` Mike Yang
  0 siblings, 1 reply; 39+ messages in thread
From: Krzysztof Kozlowski @ 2022-07-23 20:07 UTC (permalink / raw)
  To: Mark Brown, Mike Yang
  Cc: Zhou Yanjie, tudor.ambarus, p.yadav, michael, miquel.raynal,
	richard, vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd,
	linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou

On 23/07/2022 21:27, Mark Brown wrote:
> On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote:
>> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
>>> On 23/07/2022 18:50, Zhou Yanjie wrote:
> 
>>>> No offense, does it really need to be named that way?
>>>> I can't seem to find documentation with instructions on this :(
> 
> ...
> 
>>> All bindings are to follow this rule, so I don't understand why you
>>> think it is an exception for you?
> 
>> Zhou didn't ask you to make an exception. They have a valid
>> point and they're asking why.
> 
>> You may want to avoid further incidents of this kind by stop
>> being bossy and actually writing a guideline of naming these
>> .yaml files and publish it somewhere online.
> 
> Yeah, I do have to say that I was also completely unaware that
> there was any enforced convention here.

Indeed, it's not a enforced pattern. But there are many other
insignificant ones which we also tend to forget during review, like
using words "Device Tree bindings" in title or using unnecessary quotes
around "refs" (also in ID of schema). It's not a big deal, but I ask
when I notice it.


Best regards,
Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-23 17:26     ` Zhou Yanjie
@ 2022-07-23 20:24       ` Paul Cercueil
  2022-07-24 15:29         ` Zhou Yanjie
  0 siblings, 1 reply; 39+ messages in thread
From: Paul Cercueil @ 2022-07-23 20:24 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt, linux-mtd,
	linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, dongsheng.qiu, aric.pzqi, rick.tyliu,
	jinghui.liu, sernia.zhou, reimu

Hi Zhou,

Le dim., juil. 24 2022 at 01:26:56 +0800, Zhou Yanjie 
<zhouyanjie@wanyeetech.com> a écrit :
> Hi Paul,
> 
> On 2022/7/23 上午4:03, Paul Cercueil wrote:
>> Hi Zhou,
>> 
>> 
>> Le sam., juil. 23 2022 at 00:48:30 +0800, 周琰杰 (Zhou Yanjie) 
>> \x7f<zhouyanjie@wanyeetech.com> a écrit :
>>> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
>>> from Ingenic.
>>> 
>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>>> ---
>>>  drivers/spi/Kconfig           |   9 +
>>>  drivers/spi/Makefile          |   1 +
>>>  drivers/spi/spi-ingenic-sfc.c | 662 
>>> \x7f\x7f++++++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 672 insertions(+)
>>>  create mode 100644 drivers/spi/spi-ingenic-sfc.c
>>> 
>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>> index 3b1044e..1077bd3 100644
>>> --- a/drivers/spi/Kconfig
>>> +++ b/drivers/spi/Kconfig
>>> @@ -437,6 +437,15 @@ config SPI_INGENIC
>>>        To compile this driver as a module, choose M here: the module
>>>        will be called spi-ingenic.
>>> 
>>> +config SPI_INGENIC_SFC
>>> +    tristate "Ingenic SoCs SPI Flash Controller"
>>> +    depends on MACH_INGENIC || COMPILE_TEST
>>> +    help
>>> +      This enables support for the Ingenic SoCs SPI flash 
>>> controller.
>>> +
>>> +      To compile this driver as a module, choose M here: the module
>>> +      will be called ingenic-sfc.
>>> +
>>>  config SPI_INTEL
>>>      tristate
>>> 
>>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>>> index 0f44eb6..f3e42c0 100644
>>> --- a/drivers/spi/Makefile
>>> +++ b/drivers/spi/Makefile
>>> @@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)        += 
>>> \x7f\x7fspi-hisi-sfc-v3xx.o
>>>  obj-$(CONFIG_SPI_IMG_SPFI)        += spi-img-spfi.o
>>>  obj-$(CONFIG_SPI_IMX)            += spi-imx.o
>>>  obj-$(CONFIG_SPI_INGENIC)        += spi-ingenic.o
>>> +obj-$(CONFIG_SPI_INGENIC_SFC)    += spi-ingenic-sfc.o
>>>  obj-$(CONFIG_SPI_INTEL)            += spi-intel.o
>>>  obj-$(CONFIG_SPI_INTEL_PCI)        += spi-intel-pci.o
>>>  obj-$(CONFIG_SPI_INTEL_PLATFORM)    += spi-intel-platform.o
>>> diff --git a/drivers/spi/spi-ingenic-sfc.c 
>>> \x7f\x7fb/drivers/spi/spi-ingenic-sfc.c
>>> new file mode 100644
>>> index 00000000..a565546
>>> --- /dev/null
>>> +++ b/drivers/spi/spi-ingenic-sfc.c
>>> @@ -0,0 +1,662 @@
>>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> 
>> Dual-license driver? That's not what MODULE_LICENSE() says.
>> 
> 
> My fault, forgot to modify MODULE_LICENSE(), will fix it in the next 
> version.
> 
> 
>>> +/*
>>> + * Ingenic SoCs SPI Flash Controller Driver
>>> + * Copyright (c) 2022 周琰杰 (Zhou Yanjie) 
>>> <zhouyanjie@wanyeetech.com>
>>> + */
>>> +
>>> +#include <linux/bitfield.h>
>>> +#include <linux/bitops.h>
>>> +#include <linux/clk.h>
>>> +#include <linux/completion.h>
>>> +#include <linux/dma-mapping.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/iopoll.h>
>>> +#include <linux/module.h>
>>> +#include <linux/mtd/mtd.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/spi/spi.h>
>>> +#include <linux/spi/spi-mem.h>
>>> +
>>> +/* SFC register offsets */
>>> +#define SFC_REG_GLB                        0x0000
>>> +#define SFC_REG_DEV_CONF                0x0004
>>> +#define SFC_REG_DEV_STA_EXP                0x0008
>>> +#define SFC_REG_DEV_STA_RT                0x000c
>>> +#define SFC_REG_DEV_STA_MSK                0x0010
>>> +#define SFC_REG_TRAN_CONF(n)            (0x0014 + n * 4)
>>> +#define SFC_REG_TRAN_CFG0(n)            (0x0014 + n * 4)
>> 
>> You should protect the macro parameter. If you do for instance 
>> \x7fSFC_REG_TRAN_CONF(x + 1) it would resolve to (0x0014 + x + 1 * 4) 
>> \x7fwhich is not what you'd want.
>> 
> 
> Sure, will fix it.
> 
> 
>> Also - looks like SFC_REG_TRAN_CONF() and SFC_REG_TRAN_CFG0() are 
>> the \x7fsame thing, that's on purpose?
>> 
>>> +#define SFC_REG_TRAN_LEN 0x002c
>>> +#define SFC_REG_DEV_ADDR(n)                (0x0030 + n * 4)
>>> +#define SFC_REG_DEV_ADDR_PLUS(n)        (0x0048 + n * 4)
>>> +#define SFC_REG_MEM_ADDR                0x0060
>>> +#define SFC_REG_TRIG                    0x0064
>>> +#define SFC_REG_SR                        0x0068
>>> +#define SFC_REG_SCR                        0x006c
>>> +#define SFC_REG_INTC                    0x0070
>>> +#define SFC_REG_FSM                        0x0074
>>> +#define SFC_REG_CGE                        0x0078
>>> +#define SFC_REG_TRAN_CFG1(n)            (0x009c + n * 4)
>>> +#define SFC_REG_DR                        0x1000
>>> +
>>> +/* bits within the GLB register */
>>> +#define GLB_TRAN_DIR_MASK                GENMASK(13, 13)
>>> +#define GLB_TRAN_DIR_WRITE                0x1
>>> +#define GLB_TRAN_DIR_READ                0x0
>> 
>> When it's a single bit - just use BIT().
> 
> 
> Sure.
> 
> 
>> 
>>> +#define GLB_THRESHOLD_MASK GENMASK(12, 7)
>>> +#define GLB_OP_MODE_MASK                GENMASK(6, 6)
>> 
>> Same here, and I see it a few times below as well.
>> 
> 
> Sure.
> 
> 
>>> +#define GLB_OP_MODE_DMA                    0x1
>>> +#define GLB_OP_MODE_SLAVE                0x0
>>> +#define GLB_PHASE_NUM_MASK                GENMASK(5, 3)
>>> +#define GLB_WP_EN                        BIT(2)
>>> +#define GLB_BURST_MD_MASK                GENMASK(1, 0)
>>> +#define GLB_BURST_MD_INCR32                0x3
>>> +#define GLB_BURST_MD_INCR16                0x2
>>> +#define GLB_BURST_MD_INCR8                0x1
>>> +#define GLB_BURST_MD_INCR4                0x0
>>> +
>>> +/* bits within the DEV_CONF register */
>>> +#define DEV_CONF_SMP_DELAY_MASK            GENMASK(20, 16)
>>> +#define DEV_CONF_SMP_DELAY_180DEG        0x4
>>> +#define DEV_CONF_SMP_DELAY_HALF_CYCLE    0x1
>>> +#define DEV_CONF_CMD_TYPE_MASK            GENMASK(15, 15)
>>> +#define DEV_CONF_CMD_TYPE_16BIT            0x1
>>> +#define DEV_CONF_CMD_TYPE_8BIT            0x0
>>> +#define DEV_CONF_STA_TYPE_MASK            GENMASK(14, 13)
>>> +#define DEV_CONF_THOLD_MASK                GENMASK(12, 11)
>>> +#define DEV_CONF_TSETUP_MASK            GENMASK(10, 9)
>>> +#define DEV_CONF_TSH_MASK                GENMASK(8, 5)
>>> +#define DEV_CONF_CPHA                    BIT(4)
>>> +#define DEV_CONF_CPOL                    BIT(3)
>>> +#define DEV_CONF_CE_DL                    BIT(2)
>>> +#define DEV_CONF_HOLD_DL                BIT(1)
>>> +#define DEV_CONF_WP_DL                    BIT(0)
>>> +
>>> +/* bits within the TRAN_CONF(n) register */
>>> +#define TRAN_CONF_TRAN_MODE_MASK        GENMASK(31, 29)
>>> +#define TRAN_CONF_ADDR_WIDTH_MASK        GENMASK(28, 26)
>>> +#define TRAN_CONF_POLL_EN                BIT(25)
>>> +#define TRAN_CONF_CMD_EN                BIT(24)
>>> +#define TRAN_CONF_PHASE_FORMAT_MASK        GENMASK(23, 23)
>>> +#define TRAN_CONF_DMY_BITS_MASK            GENMASK(22, 17)
>>> +#define TRAN_CONF_DATA_EN                BIT(16)
>>> +#define TRAN_CONF_CMD_MASK                GENMASK(15, 0)
>>> +
>>> +/* bits within the TRIG register */
>>> +#define TRIG_FLUSH                        BIT(2)
>>> +#define TRIG_STOP                        BIT(1)
>>> +#define TRIG_START                        BIT(0)
>>> +
>>> +/* bits within the SR register */
>>> +#define SR_FIFO_NUM_MASK                GENMASK(22, 16)
>>> +#define SR_END                            BIT(4)
>>> +#define SR_TRAN_REQ                        BIT(3)
>>> +#define SR_RECE_REQ                        BIT(2)
>>> +#define SR_OVER                            BIT(1)
>>> +#define SR_UNDER                        BIT(0)
>>> +
>>> +/* bits within the SCR register */
>>> +#define SCR_CLR_END                        BIT(4)
>>> +#define SCR_CLR_TREQ                    BIT(3)
>>> +#define SCR_CLR_RREQ                    BIT(2)
>>> +#define SCR_CLR_OVER                    BIT(1)
>>> +#define SCR_CLR_UNDER                    BIT(0)
>>> +
>>> +/* bits within the INTC register */
>>> +#define INTC_MASK_END                    BIT(4)
>>> +#define INTC_MASK_TREQ                    BIT(3)
>>> +#define INTC_MASK_RREQ                    BIT(2)
>>> +#define INTC_MASK_OVER                    BIT(1)
>>> +#define INTC_MASK_UNDER                    BIT(0)
>>> +
>>> +/* bits within the TRAN_CFG1(n) register */
>>> +#define TRAN_CFG1_TRAN_MODE_MASK        GENMASK(7, 4)
>>> +
>>> +#define TRAN_MODE_STANDARD                0
>>> +#define TRAN_MODE_DUAL_DATA                1
>>> +#define TRAN_MODE_DUAL_IO                2
>>> +#define TRAN_MODE_DUAL_FULL                3
>>> +#define TRAN_MODE_QUAD_DATA                5
>>> +#define TRAN_MODE_QUAD_IO                6
>>> +#define TRAN_MODE_QUAD_FULL                7
>>> +#define TRAN_MODE_OCTAL_DATA            9
>>> +#define TRAN_MODE_OCTAL_IO                10
>>> +#define TRAN_MODE_OCTAL_FULL            11
>>> +
>>> +#define INGENIC_SFC_FIFO_SIZE            (64 * 4)
>>> +
>>> +#define INGENIC_SFC_TRANSFER_TIMEOUT    1000
>> 
>> Maybe add the unit name in the macro as well - 
>> \x7fINGENIC_SFC_TRANSFER_TIMEOUT_MS.
> 
> 
> Sure.
> 
> 
>> 
>>> +
>>> +enum ingenic_sfc_version {
>>> +    ID_X1000,
>>> +    ID_X1600,
>>> +    ID_X2000,
>>> +};
>>> +
>>> +struct ingenic_soc_info {
>>> +    enum ingenic_sfc_version version;
>>> +
>>> +    unsigned int max_bus_width;
>>> +
>>> +    const u32 tran_mode_mask;
>>> +};
>>> +
>>> +struct ingenic_sfc {
>>> +    const struct ingenic_soc_info *soc_info;
>>> +
>>> +    void __iomem *base;
>>> +    struct device *dev;
>>> +    struct clk *clk;
>>> +    int irq;
>>> +
>>> +    struct completion completion;
>>> +};
>>> +
>>> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
>>> +{
>>> +    struct ingenic_sfc *sfc = data;
>>> +
>>> +    writel(0x1f, sfc->base + SFC_REG_INTC);
>>> +
>>> +    complete(&sfc->completion);
>>> +
>>> +    return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct 
>>> \x7f\x7fspi_mem_op *op)
>>> +{
>>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>>> +
>>> +    if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && 
>>> !IS_ALIGNED(addr, \x7f\x7f4))
>>> +        op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static bool ingenic_sfc_supports_op(struct spi_mem *mem, const 
>>> \x7f\x7fstruct spi_mem_op *op)
>>> +{
>>> +    struct spi_device *spi = mem->spi;
>>> +    struct ingenic_sfc *sfc = 
>>> spi_controller_get_devdata(spi->master);
>>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>>> +
>>> +    /* The controller only supports Standard SPI mode, Duall mode, 
>>> \x7f\x7fQuad mode and Octal mode. */
>> 
>> Dual*
> 
> 
> Oops, will fix it.
> 
> 
>> 
>>> +    if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
>>> +        op->addr.buswidth > sfc->soc_info->max_bus_width ||
>>> +        op->dummy.buswidth > sfc->soc_info->max_bus_width ||
>>> +        op->data.buswidth > sfc->soc_info->max_bus_width)
>>> +        return false;
>>> +
>>> +    /* Max 32 dummy clock cycles supported */
>>> +    if (op->dummy.nbytes && op->dummy.nbytes * 8 / 
>>> \x7f\x7fop->dummy.buswidth > 32)
>>> +        return false;
>>> +
>>> +    /* Max rx data length, check controller limits and alignment */
>>> +    if (op->data.dir == SPI_MEM_DATA_IN &&
>>> +        op->data.nbytes > INGENIC_SFC_FIFO_SIZE && 
>>> !IS_ALIGNED(addr, \x7f\x7f4))
>> 
>> This does the same check than in ingenic_sfc_adjust_op_size(), maybe 
>> \x7fmove it to a new inline function?
>> 
> 
> Sure.
> 
> 
>>> +        return false;
>>> +
>>> +    /* Max 6 bytes address width supported */
>>> +    if (op->addr.nbytes > 6)
>>> +        return false;
>>> +
>>> +    return spi_mem_default_supports_op(mem, op);
>>> +}
>>> +
>>> +static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, 
>>> \x7f\x7fconst struct spi_mem_op *op)
>>> +{
>>> +    int val;
>>> +
>>> +    val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>>> +            SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
>> 
>> As Krzysztof said - ugh.
>> 
> 
> Will fix it.
> 
> 
>> Also, instead of having a "version" enum in your soc_info, why not 
>> \x7fjust have a "reg_conf" field that gives you directly the right 
>> register?
>> 
> 
> We still need a version to distinguish the SFC before X1600 SoC and
> the SFC after X1600 SoC, because in addition to the difference in the
> cfg register, another difference is that the SFC before X1600 SoC does
> not support address unaligned RX DMA transfer, while SFC in X1600 and
> later SoCs can support this feature.

Then add a .dma_supports_unaligned_address field.

> 
> 
>> 
>>> +    val &= ~sfc->soc_info->tran_mode_mask;
>>> +    if (op->cmd.buswidth == 8)
>>> +        val |= (TRAN_MODE_OCTAL_FULL << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>> 
>> Looks like you're really trying to reinvent the wheel.
>> 
>> val |= FIELD_PREP(sfc->soc_info->tran_mode_mask, 
>> TRAN_MODE_OCTAL_FULL);
>> 
>> using <linux/bitfield.h>.
>> 
>> Also, just define a 'mode' variable and set it in your if/else 
>> blocks, \x7fthat would look much better. Then you can set val |= 
>> FIELD_PREP(..., \x7fmode) at the end.
> 
> 
> Sure, will change this in the next version.
> 
> 
>> 
>>> +    else if (op->cmd.buswidth == 4)
>>> +        val |= (TRAN_MODE_QUAD_FULL << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->cmd.buswidth == 2)
>>> +        val |= (TRAN_MODE_DUAL_FULL << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->addr.buswidth == 8)
>>> +        val |= (TRAN_MODE_OCTAL_IO << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->addr.buswidth == 4)
>>> +        val |= (TRAN_MODE_QUAD_IO << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->addr.buswidth == 2)
>>> +        val |= (TRAN_MODE_DUAL_IO << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->data.buswidth == 8)
>>> +        val |= (TRAN_MODE_OCTAL_DATA << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->data.buswidth == 4)
>>> +        val |= (TRAN_MODE_QUAD_DATA << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else if (op->data.buswidth == 2)
>>> +        val |= (TRAN_MODE_DUAL_DATA << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    else
>>> +        val |= (TRAN_MODE_STANDARD << 
>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>> +                sfc->soc_info->tran_mode_mask;
>>> +    writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>>> +            SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
>>> +}
>>> +
>>> +/*
>>> + * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
>>> + * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
>>> + */
>>> +static void ingenic_sfc_read_rxfifo(struct ingenic_sfc *sfc, u8 
>>> *to, \x7f\x7funsigned int len)
>>> +{
>>> +    void __iomem *from;
>>> +
>>> +    from = sfc->base + SFC_REG_DR;
>>> +
>>> +    for (; len >= 4; len -= 4, to += 4) {
>>> +        u32 val = __raw_readl(from);
>>> +        memcpy(to, &val, 4);
>> 
>> No need to use memcpy for 4 bytes. You can do: put_unaligned(val, 
>> (u32 \x7f*)to);
>> 
> 
> Sure.
> 
> 
>>> +    }
>>> +
>>> +    if (len) {
>>> +        u32 val = __raw_readl(from);
>>> +        memcpy(to, &val, len);
>> 
>> Hmm, I'm not sure that is endian-safe. I would prefer if you copied 
>> \x7fbyte by byte.
>> 
> 
> Sure.
> 
> 
>>> +    }
>>> +}
>>> +
>>> +static int ingenic_sfc_exec_op_pio(struct ingenic_sfc *sfc, const 
>>> \x7f\x7fstruct spi_mem_op *op)
>>> +{
>>> +    int ret, val;
>>> +
>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>> +    u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
>>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>>> +    writel(val, sfc->base + SFC_REG_GLB);
>> 
>> By the way, have you considered using regmap?
>> 
>> It would give you things like regmap_update_bits() for this kind of 
>> \x7fthings, and regmap_field() to handle your conf register being at a 
>> \x7fdifferent address across SoCs.
>> 
> 
> It seems that the overhead of using regmap will be greater than using 
> readl and writel,
> the purpose of using readl and writel is to minimize overhead and 
> maximize performance. :)

If you really think that this is a valid reason not to use regmap, then 
prove it with a benchmark, because I'm *very* doubtful about your claim.

Cheers,
-Paul

>>> +
>>> +    val = TRAN_CONF_CMD_EN | op->cmd.opcode;
>>> +
>>> +    if (op->addr.nbytes > 0) {
>>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, 
>>> op->addr.nbytes);
>>> +
>>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>>> \x7f\x7fSFC_REG_DEV_ADDR(0));
>>> +        writel(op->addr.val >> 32, sfc->base + 
>>> \x7f\x7fSFC_REG_DEV_ADDR_PLUS(0));
>>> +    }
>>> +
>>> +    if (op->dummy.nbytes > 0)
>>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>>> +
>>> +    if (op->data.nbytes > 0)
>>> +        val |= TRAN_CONF_DATA_EN;
>>> +
>>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>>> +
>>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>>> +
>>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>> 
>> Random 0x1f value here, maybe use a macro?
> 
> 
> Sure.
> 
> 
>> 
>>> +    writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + 
>>> \x7f\x7fSFC_REG_INTC);
>>> +
>>> +    writel(0, sfc->base + SFC_REG_MEM_ADDR);
>>> +
>>> +    writel(TRIG_FLUSH, sfc->base + SFC_REG_TRIG);
>>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>>> +
>>> +    ret = wait_for_completion_timeout(&sfc->completion,
>>> +            msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>>> +    if (!ret) {
>>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>>> \x7f\x7fdevice\n", __LINE__);
>>> +        return -ETIMEDOUT;
>>> +    }
>>> +
>>> +    ingenic_sfc_read_rxfifo(sfc, op->data.buf.in, op->data.nbytes);
>>> +    readl_poll_timeout(sfc->base + SFC_REG_SR, val, val & SR_END, 
>>> \x7f\x7f10, 0);
>> 
>> Infinite timeout? Is that very wise?
> 
> 
> Will fix it in the next version.
> 
> 
>> 
>>> +
>>> +    writel(INTC_MASK_END | INTC_MASK_RREQ, sfc->base + 
>>> SFC_REG_SCR);
>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int ingenic_sfc_exec_op_dma(struct ingenic_sfc *sfc, const 
>>> \x7f\x7fstruct spi_mem_op *op)
>>> +{
>>> +    dma_addr_t addr;
>>> +    int ret, val;
>>> +
>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>> +    u32p_replace_bits(&val, op->data.dir == SPI_MEM_DATA_IN ?
>>> +            GLB_TRAN_DIR_READ : GLB_TRAN_DIR_WRITE, 
>>> GLB_TRAN_DIR_MASK);
>>> +    u32p_replace_bits(&val, GLB_OP_MODE_DMA, GLB_OP_MODE_MASK);
>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>> +
>>> +    val = TRAN_CONF_CMD_EN | op->cmd.opcode;
>>> +
>>> +    if (op->addr.nbytes > 0) {
>>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, 
>>> op->addr.nbytes);
>>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>>> \x7f\x7fSFC_REG_DEV_ADDR(0));
>>> +        writel(op->addr.val >> 32, sfc->base + 
>>> \x7f\x7fSFC_REG_DEV_ADDR_PLUS(0));
>>> +    }
>>> +
>>> +    if (op->dummy.nbytes > 0)
>>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>>> +
>>> +    if (op->data.nbytes > 0)
>>> +        val |= TRAN_CONF_DATA_EN;
>> 
>> There's a lot of code duplication here with 
>> ingenic_sfc_exec_op_pio(). \x7fA lot can be factorized.
> 
> 
> Sure, I will try to do it.
> 
> 
>> 
>>> +
>>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>>> +
>>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>>> +
>>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>>> +    writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
>>> +
>>> +    switch (op->data.dir) {
>>> +    case SPI_MEM_DATA_IN:
>>> +        addr = dma_map_single(sfc->dev, op->data.buf.in, 
>>> \x7f\x7fop->data.nbytes, DMA_FROM_DEVICE);
>>> +        if (dma_mapping_error(sfc->dev, addr)) {
>>> +            dev_err(sfc->dev, "RX DMA memory not mapped\n");
>>> +            return -ENOMEM;
>>> +        }
>>> +
>>> +        writel(addr, sfc->base + SFC_REG_MEM_ADDR);
>>> +        break;
>>> +
>>> +    case SPI_MEM_DATA_OUT:
>>> +        addr = dma_map_single(sfc->dev, (void *)op->data.buf.out,
>>> +                op->data.nbytes, DMA_TO_DEVICE);
>>> +        if (dma_mapping_error(sfc->dev, addr)) {
>>> +            dev_err(sfc->dev, "TX DMA memory not mapped\n");
>>> +            return -ENOMEM;
>>> +        }
>>> +
>>> +        writel(addr, sfc->base + SFC_REG_MEM_ADDR);
>>> +        break;
>>> +
>>> +    default:
>>> +        return -EINVAL;
>>> +    }
>>> +
>>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>>> +
>>> +    ret = wait_for_completion_timeout(&sfc->completion,
>>> +            msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>>> +    if (!ret) {
>>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>>> \x7f\x7fdevice\n", __LINE__);
>>> +        return -ETIMEDOUT;
>>> +    }
>>> +
>>> +    dma_unmap_single(sfc->dev, addr, op->data.nbytes,
>>> +            op->data.dir == SPI_MEM_DATA_IN ? DMA_FROM_DEVICE : 
>>> \x7f\x7fDMA_TO_DEVICE);
>> 
>> Use a small inline function for that too. My personal rule is that 
>> ?: \x7fis fine if the line fits in 80 characters, but if you have to 
>> break, \x7fthen you really need to move it somewhere else.
>> 
> 
> Sure.
> 
> 
>>> +
>>> +    writel(INTC_MASK_END, sfc->base + SFC_REG_SCR);
>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int ingenic_sfc_exec_op(struct spi_mem *mem, const struct 
>>> \x7f\x7fspi_mem_op *op)
>>> +{
>>> +    struct spi_device *spi = mem->spi;
>>> +    struct ingenic_sfc *sfc = 
>>> spi_controller_get_devdata(spi->master);
>>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>>> +
>>> +    init_completion(&sfc->completion);
>>> +
>>> +    switch (op->data.dir) {
>>> +    case SPI_MEM_DATA_IN:
>>> +        if (sfc->soc_info->version >= ID_X1600 || IS_ALIGNED(addr, 
>>> 4))
>>> +            break;
>>> +
>>> +        fallthrough;
>>> +
>>> +    case SPI_MEM_NO_DATA:
>>> +        return ingenic_sfc_exec_op_pio(sfc, op);
>>> +
>>> +    default:
>>> +        break;
>>> +    }
>>> +
>>> +    return ingenic_sfc_exec_op_dma(sfc, op);
>>> +}
>>> +
>>> +static int ingenic_sfc_poll_status(struct spi_mem *mem, const 
>>> struct \x7f\x7fspi_mem_op *op,
>>> +            u16 mask, u16 match, unsigned long initial_delay_us,
>>> +            unsigned long polling_delay_us, unsigned long 
>>> timeout_ms)
>>> +{
>>> +    struct spi_device *spi = mem->spi;
>>> +    struct ingenic_sfc *sfc = 
>>> spi_controller_get_devdata(spi->master);
>>> +    int ret, val;
>>> +
>>> +    init_completion(&sfc->completion);
>>> +
>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>> +    u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
>>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>> +
>>> +    writel(match, sfc->base + SFC_REG_DEV_STA_EXP);
>>> +    writel(mask, sfc->base + SFC_REG_DEV_STA_MSK);
>>> +
>>> +    val = TRAN_CONF_POLL_EN | TRAN_CONF_CMD_EN | op->cmd.opcode;
>>> +
>>> +    if (op->addr.nbytes > 0) {
>>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, 
>>> op->addr.nbytes);
>>> +
>>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>>> \x7f\x7fSFC_REG_DEV_ADDR(0));
>>> +        writel(op->addr.val >> 32, sfc->base + 
>>> \x7f\x7fSFC_REG_DEV_ADDR_PLUS(0));
>>> +    }
>>> +
>>> +    if (op->dummy.nbytes > 0)
>>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>>> +
>>> +    if (op->data.nbytes > 0)
>>> +        val |= TRAN_CONF_DATA_EN;
>>> +
>>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>>> +
>>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>>> +
>>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>>> +    writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
>>> +
>>> +    writel(0, sfc->base + SFC_REG_MEM_ADDR);
>>> +
>>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>>> +
>>> +    ret = wait_for_completion_timeout(&sfc->completion,
>>> +            msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>>> +    if (!ret) {
>>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>>> \x7f\x7fdevice\n", __LINE__);
>>> +        return -ETIMEDOUT;
>>> +    }
>>> +
>>> +    writel(SCR_CLR_END, sfc->base + SFC_REG_SCR);
>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static const struct spi_controller_mem_ops ingenic_sfc_mem_ops = {
>>> +    .adjust_op_size = ingenic_sfc_adjust_op_size,
>>> +    .supports_op = ingenic_sfc_supports_op,
>>> +    .exec_op = ingenic_sfc_exec_op,
>>> +    .poll_status = ingenic_sfc_poll_status,
>>> +};
>>> +
>>> +static int ingenic_sfc_setup(struct spi_device *spi)
>>> +{
>>> +    struct ingenic_sfc *sfc = 
>>> spi_controller_get_devdata(spi->master);
>>> +    unsigned long rate;
>>> +    int ret, val;
>>> +
>>> +    if (!spi->max_speed_hz)
>>> +        return -EINVAL;
>> 
>> Maybe set a sane default?
> 
> 
> Sure.
> 
> 
>> 
>>> +
>>> +    ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
>>> +    if (ret)
>>> +        return -EINVAL;
>>> +
>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>> +    writel(0, sfc->base + SFC_REG_DEV_CONF);
>>> +    writel(0, sfc->base + SFC_REG_CGE);
>>> +
>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>> +    u32p_replace_bits(&val, 64 - 1, GLB_THRESHOLD_MASK);
>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>> +
>>> +    val = readl(sfc->base + SFC_REG_DEV_CONF);
>>> +
>>> +    /* cpha bit:0 , cpol bit:0 */
>>> +    val &= ~(DEV_CONF_CPHA | DEV_CONF_CPOL);
>>> +    val |= spi->mode & SPI_CPHA ? DEV_CONF_CPHA : 0;
>>> +    val |= spi->mode & SPI_CPOL ? DEV_CONF_CPOL : 0;
>>> +
>>> +    /* ce_dl bit:1, hold bit:1, wp bit:1 */
>>> +    val |= (DEV_CONF_CE_DL | DEV_CONF_HOLD_DL | DEV_CONF_WP_DL);
>>> +
>>> +    writel(val, sfc->base + SFC_REG_DEV_CONF);
>>> +
>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>> +
>>> +    rate = clk_get_rate(sfc->clk);
>> 
>> I'd suggest using clk_round_rate() before clk_set_rate() because 
>> then \x7fyou know what frequency it's going to be, and you don't have 
>> to call \x7fclk_get_rate() afterwards.
>> 
> 
> Sure, will try.
> 
> 
> Thanks and best regards!
> 
> 
>> Cheers,
>> -Paul
>> 
>>> +    val = readl(sfc->base + SFC_REG_DEV_CONF);
>>> +    if (sfc->soc_info->version >= ID_X1600 && rate >= 200000000)
>>> +        u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_180DEG, 
>>> \x7f\x7fDEV_CONF_SMP_DELAY_MASK);
>>> +    else if (sfc->soc_info->version == ID_X1000 && rate >= 
>>> 100000000)
>>> +        u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_HALF_CYCLE, 
>>> \x7f\x7fDEV_CONF_SMP_DELAY_MASK);
>>> +    writel(val, sfc->base + SFC_REG_DEV_CONF);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int ingenic_sfc_probe(struct platform_device *pdev)
>>> +{
>>> +    struct ingenic_sfc *sfc;
>>> +    struct spi_controller *ctlr;
>>> +    int ret;
>>> +
>>> +    ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
>>> +    if (!ctlr)
>>> +        return -ENOMEM;
>>> +
>>> +    sfc = spi_controller_get_devdata(ctlr);
>>> +
>>> +    sfc->soc_info = of_device_get_match_data(&pdev->dev);
>>> +    if (!sfc->soc_info) {
>>> +        dev_err(&pdev->dev, "No of match data provided\n");
>>> +        ret = -ENODEV;
>>> +        goto err_put_master;
>>> +    }
>>> +
>>> +    sfc->base = devm_platform_ioremap_resource(pdev, 0);
>>> +    if (IS_ERR(sfc->base)) {
>>> +        ret = PTR_ERR(sfc->base);
>>> +        goto err_put_master;
>>> +    }
>>> +
>>> +    sfc->clk = devm_clk_get(&pdev->dev, "sfc");
>>> +    if (IS_ERR(sfc->clk)) {
>>> +        ret = IS_ERR(sfc->clk);
>>> +        goto err_put_master;
>>> +    }
>>> +
>>> +    ret = clk_prepare_enable(sfc->clk);
>>> +    if (ret)
>>> +        goto err_put_master;
>>> +
>>> +    sfc->irq = platform_get_irq(pdev, 0);
>>> +    if (sfc->irq < 0) {
>>> +        ret = sfc->irq;
>>> +        goto err_put_master;
>>> +    }
>>> +
>>> +    sfc->dev = &pdev->dev;
>>> +
>>> +    platform_set_drvdata(pdev, sfc);
>>> +
>>> +    ret = devm_request_irq(&pdev->dev, sfc->irq, 
>>> \x7f\x7fingenic_sfc_irq_handler, 0,
>>> +            dev_name(&pdev->dev), sfc);
>>> +    if (ret) {
>>> +        dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", 
>>> \x7f\x7fsfc->irq, ret);
>>> +        goto err_put_master;
>>> +    }
>>> +
>>> +    ctlr->bus_num = -1;
>>> +    ctlr->num_chipselect = 1;
>>> +    ctlr->mem_ops = &ingenic_sfc_mem_ops;
>>> +    ctlr->dev.of_node = pdev->dev.of_node;
>>> +    ctlr->setup = ingenic_sfc_setup;
>>> +    ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
>>> +            SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
>>> +    if (sfc->soc_info->version >= ID_X2000)
>>> +        ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
>>> +
>>> +    ret = devm_spi_register_controller(&pdev->dev, ctlr);
>>> +    if (ret)
>>> +        goto err_put_master;
>>> +
>>> +    return 0;
>>> +
>>> +err_put_master:
>>> +    spi_master_put(ctlr);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static const struct ingenic_soc_info x1000_soc_info = {
>>> +    .version = ID_X1000,
>>> +
>>> +    .max_bus_width = 4,
>>> +
>>> +    .tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
>>> +};
>>> +
>>> +static const struct ingenic_soc_info x1600_soc_info = {
>>> +    .version = ID_X1600,
>>> +
>>> +    .max_bus_width = 4,
>>> +
>>> +    .tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
>>> +};
>>> +
>>> +static const struct ingenic_soc_info x2000_soc_info = {
>>> +    .version = ID_X2000,
>>> +
>>> +    .max_bus_width = 8,
>>> +
>>> +    .tran_mode_mask = TRAN_CFG1_TRAN_MODE_MASK,
>>> +};
>>> +
>>> +static const struct of_device_id ingenic_sfc_of_matches[] = {
>>> +    { .compatible = "ingenic,x1000-sfc", .data = &x1000_soc_info },
>>> +    { .compatible = "ingenic,x1600-sfc", .data = &x1600_soc_info },
>>> +    { .compatible = "ingenic,x2000-sfc", .data = &x2000_soc_info },
>>> +    { /* sentinel */ }
>>> +};
>>> +MODULE_DEVICE_TABLE(of, ingenic_sfc_of_matches);
>>> +
>>> +static struct platform_driver ingenic_sfc_driver = {
>>> +    .driver = {
>>> +        .name = "ingenic-sfc",
>>> +        .of_match_table = ingenic_sfc_of_matches,
>>> +    },
>>> +    .probe = ingenic_sfc_probe,
>>> +};
>>> +module_platform_driver(ingenic_sfc_driver);
>>> +
>>> +MODULE_LICENSE("GPL");
>>> +MODULE_AUTHOR("周琰杰 (Zhou Yanjie) 
>>> <zhouyanjie@wanyeetech.com>");
>>> +MODULE_DESCRIPTION("Ingenic SoCs SPI Flash Controller Driver");
>>> --
>>> 2.7.4
>>> 
>> 



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 20:07             ` Krzysztof Kozlowski
@ 2022-07-23 20:49               ` Mike Yang
  2022-07-24 15:33                 ` Zhou Yanjie
  2022-07-25 18:30                 ` Rob Herring
  0 siblings, 2 replies; 39+ messages in thread
From: Mike Yang @ 2022-07-23 20:49 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Mark Brown
  Cc: Zhou Yanjie, tudor.ambarus, p.yadav, michael, miquel.raynal,
	richard, vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd,
	linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou

On 7/24/22 04:07, Krzysztof Kozlowski wrote:
> On 23/07/2022 21:27, Mark Brown wrote:
>> On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote:
>>> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
>>>> On 23/07/2022 18:50, Zhou Yanjie wrote:
>>
>>>>> No offense, does it really need to be named that way?
>>>>> I can't seem to find documentation with instructions on this :(
>>
>> ...
>>
>>>> All bindings are to follow this rule, so I don't understand why you
>>>> think it is an exception for you?
>>
>>> Zhou didn't ask you to make an exception. They have a valid
>>> point and they're asking why.
>>
>>> You may want to avoid further incidents of this kind by stop
>>> being bossy and actually writing a guideline of naming these
>>> .yaml files and publish it somewhere online.
>>
>> Yeah, I do have to say that I was also completely unaware that
>> there was any enforced convention here.
> 
> Indeed, it's not a enforced pattern. But there are many other
> insignificant ones which we also tend to forget during review, like
> using words "Device Tree bindings" in title or using unnecessary quotes
> around "refs" (also in ID of schema). It's not a big deal, but I ask
> when I notice it.

Good. Thanks for paying attention to these details.


>> Zhou already mentioned he was unable find the naming guidelines of these .yaml files.
>>
>> Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.
> 
> It's everywhere in the kernel, what can I say? If you copy existing
> code, you might copy poor code...

Still, it shouldn't be a responsibility of new contributors to determine the quality of an existing piece of code, unless there are clear guidelines (i.e. one should use the new "cs-gpios" attribute in SPI controllers).

> 
>>
>>>
>>> It might never grow to new devices (because they might be different), so
>>> that is not really an argument.
>>
>> It is an argument. A very valid one.
>>
>> "they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.
>>
>> I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.
>>
>>>
>>> All bindings are to follow this rule, so I don't understand why you
>>> think it is an exception for you?
>>
>> Zhou didn't ask you to make an exception. They have a valid point and they're asking why.
> 
> Hm, everyone has the same valid point and such recommendation is to
> everyone, although it is nothing serious.
> 
>> You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.
> 
> I did not see any incident here... Process of review includes comments
> and there is nothing bad happening when you receive a comment. No
> incident...


Okay. After careful inspection of the Ingenic datasheets, now I have the conclusion: The Ingenic X1000, X1021, X1500, X1501, X1520, X1600, X1800, X1830, X2000, X2100, X2500 have the same SFC controller.

X1600 has a newer version (let's say v2) of the SFC, and X2000-2500 have v3. Others have the original version (let's say v1). Each new version introduced new features such as arbitrary DMA sizes, and the rest features are the same.


So IMO the name "ingenic,sfc.yaml" is perfectly logical.


Regards,
Mike Yang

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
                     ` (3 preceding siblings ...)
  2022-07-23 15:15   ` Christophe JAILLET
@ 2022-07-24  0:43   ` kernel test robot
  2022-07-24  1:28     ` Vanessa Page
  4 siblings, 1 reply; 39+ messages in thread
From: kernel test robot @ 2022-07-24  0:43 UTC (permalink / raw)
  To: 周琰杰 (Zhou Yanjie),
	tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt
  Cc: kbuild-all, linux-mtd, linux-spi, linux-mips, linux-kernel,
	devicetree, aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu,
	aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou, reimu

Hi "周琰杰,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on broonie-spi/for-next]
[also build test WARNING on mtd/spi-nor/next linus/master v5.19-rc7 next-20220722]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Zhou-Yanjie/Add-SFC-support-for-Ingenic-SoCs/20220723-005011
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220724/202207240839.YeZ8uQ0T-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/0d9d0e60238025a04d428e64e18211c037229284
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Zhou-Yanjie/Add-SFC-support-for-Ingenic-SoCs/20220723-005011
        git checkout 0d9d0e60238025a04d428e64e18211c037229284
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=alpha SHELL=/bin/bash drivers/spi/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

   drivers/spi/spi-ingenic-sfc.c: In function 'ingenic_sfc_exec_op_pio':
>> drivers/spi/spi-ingenic-sfc.c:299:16: warning: conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value from '18446744073709551595' to '4294967275' [-Woverflow]
     299 |         writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + SFC_REG_INTC);
         |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/spi/spi-ingenic-sfc.c: In function 'ingenic_sfc_exec_op_dma':
   drivers/spi/spi-ingenic-sfc.c:356:16: warning: conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value from '18446744073709551599' to '4294967279' [-Woverflow]
     356 |         writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
   drivers/spi/spi-ingenic-sfc.c: In function 'ingenic_sfc_poll_status':
   drivers/spi/spi-ingenic-sfc.c:469:16: warning: conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value from '18446744073709551599' to '4294967279' [-Woverflow]
     469 |         writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);


vim +299 drivers/spi/spi-ingenic-sfc.c

   267	
   268	static int ingenic_sfc_exec_op_pio(struct ingenic_sfc *sfc, const struct spi_mem_op *op)
   269	{
   270		int ret, val;
   271	
   272		val = readl(sfc->base + SFC_REG_GLB);
   273		u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
   274		u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
   275		writel(val, sfc->base + SFC_REG_GLB);
   276	
   277		val = TRAN_CONF_CMD_EN | op->cmd.opcode;
   278	
   279		if (op->addr.nbytes > 0) {
   280			val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, op->addr.nbytes);
   281	
   282			writel(op->addr.val & 0xffffffff, sfc->base + SFC_REG_DEV_ADDR(0));
   283			writel(op->addr.val >> 32, sfc->base + SFC_REG_DEV_ADDR_PLUS(0));
   284		}
   285	
   286		if (op->dummy.nbytes > 0)
   287			val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
   288					op->dummy.nbytes * 8 / op->dummy.buswidth);
   289	
   290		if (op->data.nbytes > 0)
   291			val |= TRAN_CONF_DATA_EN;
   292	
   293		writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
   294		writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
   295	
   296		ingenic_sfc_set_transfer_mode(sfc, op);
   297	
   298		writel(0x1f, sfc->base + SFC_REG_SCR);
 > 299		writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + SFC_REG_INTC);
   300	
   301		writel(0, sfc->base + SFC_REG_MEM_ADDR);
   302	
   303		writel(TRIG_FLUSH, sfc->base + SFC_REG_TRIG);
   304		writel(TRIG_START, sfc->base + SFC_REG_TRIG);
   305	
   306		ret = wait_for_completion_timeout(&sfc->completion,
   307				msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
   308		if (!ret) {
   309			writel(0x1f, sfc->base + SFC_REG_INTC);
   310			writel(0x1f, sfc->base + SFC_REG_SCR);
   311			dev_err(sfc->dev, "line:%d Timeout for ACK from SFC device\n", __LINE__);
   312			return -ETIMEDOUT;
   313		}
   314	
   315		ingenic_sfc_read_rxfifo(sfc, op->data.buf.in, op->data.nbytes);
   316		readl_poll_timeout(sfc->base + SFC_REG_SR, val, val & SR_END, 10, 0);
   317	
   318		writel(INTC_MASK_END | INTC_MASK_RREQ, sfc->base + SFC_REG_SCR);
   319		writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
   320	
   321		return 0;
   322	}
   323	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-23 15:15   ` Christophe JAILLET
  2022-07-23 15:15     ` Christophe JAILLET
@ 2022-07-24  1:22     ` Zhou Yanjie
  1 sibling, 0 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-24  1:22 UTC (permalink / raw)
  To: Christophe JAILLET, tudor.ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

Hi Christophe,

On 2022/7/23 下午11:15, Christophe JAILLET wrote:
> Le 22/07/2022 à 18:48, 周琰杰 (Zhou Yanjie) a écrit :
>> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
>> from Ingenic.
>>
>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>> ---
>>   drivers/spi/Kconfig           |   9 +
>>   drivers/spi/Makefile          |   1 +
>>   drivers/spi/spi-ingenic-sfc.c | 662 
>> ++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 672 insertions(+)
>>   create mode 100644 drivers/spi/spi-ingenic-sfc.c
>>
>
> [...]
>
>> +static int ingenic_sfc_probe(struct platform_device *pdev)
>> +{
>> +    struct ingenic_sfc *sfc;
>> +    struct spi_controller *ctlr;
>> +    int ret;
>> +
>> +    ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
>> +    if (!ctlr)
>> +        return -ENOMEM;
>
> devm_spi_alloc_master()? (+ error handling simplification)
> Or there should be a .remove() function.
>

Sure, will do in the next version.


Thanks and best regards!


> CJ
>
>> +
>> +    sfc = spi_controller_get_devdata(ctlr);
>> +
>> +    sfc->soc_info = of_device_get_match_data(&pdev->dev);
>> +    if (!sfc->soc_info) {
>> +        dev_err(&pdev->dev, "No of match data provided\n");
>> +        ret = -ENODEV;
>> +        goto err_put_master;
>> +    }
>> +
>
> [...]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-23 19:32       ` Mark Brown
@ 2022-07-24  1:24         ` Zhou Yanjie
  0 siblings, 0 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-24  1:24 UTC (permalink / raw)
  To: Mark Brown
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd, linux-spi,
	linux-mips, linux-kernel, devicetree, aidanmacdonald.0x0, tmn505,
	paul, dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu,
	sernia.zhou, reimu

Hi Mark,

On 2022/7/24 上午3:32, Mark Brown wrote:
> On Sun, Jul 24, 2022 at 01:06:16AM +0800, Zhou Yanjie wrote:
>> On 2022/7/23 上午2:38, Mark Brown wrote:
>>>> +++ b/drivers/spi/spi-ingenic-sfc.c
>>>> @@ -0,0 +1,662 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +/*
>>>> + * Ingenic SoCs SPI Flash Controller Driver
>>> Please make the entire comment a C++ one so things look more
>>> intentional.
>> I'm sorry, I didn't understand well what you meant :(
>> Could you please explain a little more detail?
> The above comment block uses both C /* */ and C++ // style comments,
> please make it just use the C++ style.


Sure, will do in the next version.


>>>> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
>>>> +{
>>>> +	struct ingenic_sfc *sfc = data;
>>>> +
>>>> +	writel(0x1f, sfc->base + SFC_REG_INTC);
>>>> +
>>>> +	complete(&sfc->completion);
>>>> +
>>>> +	return IRQ_HANDLED;
>>>> +}
>>> This doesn't pay any attention to any status registers in the chip so
>>> won't work if the interrupt is shared and won't notice any error reports
>>> from the device...
>> This interrupt is exclusively owned by SFC, do we still
>> need to perform the operation you said? I haven't done
>> these operations before because I want to minimize the
>> overhead and avoid affecting performance.
> Even if the device is not shared is there no possibility that the
> device can report an unexpected interrupt status?  It's not just
> the sharing case, it's also the fact that it looks like there's a
> status being reported but we're not checking it so if anything
> goes wrong then we're less likely to notice.  I'd worry about
> data corruption.


Sure, I will change this in the next version.


Thanks and best regards!



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-23 14:47 ` [PATCH 0/3] " Tomasz Maciej Nowak
@ 2022-07-24  1:25   ` Zhou Yanjie
  2022-07-24  1:28     ` Vanessa Page
                       ` (2 more replies)
  0 siblings, 3 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-24  1:25 UTC (permalink / raw)
  To: Tomasz Maciej Nowak, tudor.ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, paul, dongsheng.qiu, aric.pzqi, rick.tyliu,
	jinghui.liu, sernia.zhou, reimu

Hi Tomasz,

On 2022/7/23 下午10:47, Tomasz Maciej Nowak wrote:
> W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
>> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
>> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
>>
>> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
>>
>> 周琰杰 (Zhou Yanjie) (3):
>>    mtd: spi-nor: Use the spi-mem poll status APIs.
>>    dt-bindings: SPI: Add Ingenic SFC bindings.
>>    SPI: Ingenic: Add SFC support for Ingenic SoCs.
>>
>>   .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>>   drivers/mtd/spi-nor/core.c                         |  42 +-
>>   drivers/spi/Kconfig                                |   9 +
>>   drivers/spi/Makefile                               |   1 +
>>   drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>>   5 files changed, 768 insertions(+), 10 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>   create mode 100755 drivers/spi/spi-ingenic-sfc.c
>>
> Even tough it's still early in revision process, I'll add my
> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
>
> The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
> but with 256 MiB RAM. No bugs yet observed on my side.


Thanks for you test!


>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-24  0:43   ` kernel test robot
@ 2022-07-24  1:28     ` Vanessa Page
  0 siblings, 0 replies; 39+ messages in thread
From: Vanessa Page @ 2022-07-24  1:28 UTC (permalink / raw)
  To: kernel test robot
  Cc:  周琰杰 (Zhou Yanjie) ,
	Tudor.Ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt, kbuild-all,
	linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou, reimu

288                    op->dummy.nbytes * 8 / op->dummy.buswidth);
  289    
  290        if (op->data.nbytes > 0)
  291            val |= TRAN_CONF_DATA_EN;
  292    
  293        writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
  294        writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
  295    
  296       

Sent from my iPhone

> On Jul 23, 2022, at 8:47 PM, kernel test robot <lkp@intel.com> wrote:
> 
> 288                    op->dummy.nbytes * 8 / op->dummy.buswidth);
>   289    
>   290        if (op->data.nbytes > 0)
>   291            val |= TRAN_CONF_DATA_EN;
>   292    
>   293        writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>   294        writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>   295    
>   296      
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-24  1:25   ` Zhou Yanjie
@ 2022-07-24  1:28     ` Vanessa Page
  2022-07-24  1:28     ` Vanessa Page
  2022-07-24  1:30     ` Vanessa Page
  2 siblings, 0 replies; 39+ messages in thread
From: Vanessa Page @ 2022-07-24  1:28 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: Tomasz Maciej Nowak, Tudor.Ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou,
	reimu

288                    op->dummy.nbytes * 8 / op->dummy.buswidth);
  289    
  290        if (op->data.nbytes > 0)
  291            val |= TRAN_CONF_DATA_EN;
  292    
  293        writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
  294        writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
  295    
  296       

Sent from my iPhone

> On Jul 23, 2022, at 9:27 PM, Zhou Yanjie <zhouyanjie@wanyeetech.com> wrote:
> 
> Hi Tomasz,
> 
>> On 2022/7/23 下午10:47, Tomasz Maciej Nowak wrote:
>> W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
>>> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
>>> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
>>> 
>>> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
>>> 
>>> 周琰杰 (Zhou Yanjie) (3):
>>>   mtd: spi-nor: Use the spi-mem poll status APIs.
>>>   dt-bindings: SPI: Add Ingenic SFC bindings.
>>>   SPI: Ingenic: Add SFC support for Ingenic SoCs.
>>> 
>>>  .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>>>  drivers/mtd/spi-nor/core.c                         |  42 +-
>>>  drivers/spi/Kconfig                                |   9 +
>>>  drivers/spi/Makefile                               |   1 +
>>>  drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>>>  5 files changed, 768 insertions(+), 10 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>  create mode 100755 drivers/spi/spi-ingenic-sfc.c
>>> 
>> Even tough it's still early in revision process, I'll add my
>> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
>> 
>> The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
>> but with 256 MiB RAM. No bugs yet observed on my side.
> 
> 
> Thanks for you test!
> 
> 
>> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-24  1:25   ` Zhou Yanjie
  2022-07-24  1:28     ` Vanessa Page
@ 2022-07-24  1:28     ` Vanessa Page
  2022-07-24  1:30     ` Vanessa Page
  2 siblings, 0 replies; 39+ messages in thread
From: Vanessa Page @ 2022-07-24  1:28 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: Tomasz Maciej Nowak, Tudor.Ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou,
	reimu

288                    op->dummy.nbytes * 8 / op->dummy.buswidth);
  289    
  290        if (op->data.nbytes > 0)
  291            val |= TRAN_CONF_DATA_EN;
  292    
  293        writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
  294        writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
  295    
  296       

Sent from my iPhone

> On Jul 23, 2022, at 9:27 PM, Zhou Yanjie <zhouyanjie@wanyeetech.com> wrote:
> 
> Hi Tomasz,
> 
>> On 2022/7/23 下午10:47, Tomasz Maciej Nowak wrote:
>> W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
>>> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
>>> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
>>> 
>>> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
>>> 
>>> 周琰杰 (Zhou Yanjie) (3):
>>>   mtd: spi-nor: Use the spi-mem poll status APIs.
>>>   dt-bindings: SPI: Add Ingenic SFC bindings.
>>>   SPI: Ingenic: Add SFC support for Ingenic SoCs.
>>> 
>>>  .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>>>  drivers/mtd/spi-nor/core.c                         |  42 +-
>>>  drivers/spi/Kconfig                                |   9 +
>>>  drivers/spi/Makefile                               |   1 +
>>>  drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>>>  5 files changed, 768 insertions(+), 10 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>  create mode 100755 drivers/spi/spi-ingenic-sfc.c
>>> 
>> Even tough it's still early in revision process, I'll add my
>> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
>> 
>> The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
>> but with 256 MiB RAM. No bugs yet observed on my side.
> 
> 
> Thanks for you test!
> 
> 
>> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-24  1:25   ` Zhou Yanjie
  2022-07-24  1:28     ` Vanessa Page
  2022-07-24  1:28     ` Vanessa Page
@ 2022-07-24  1:30     ` Vanessa Page
  2022-07-24  1:32       ` Vee Page
  2 siblings, 1 reply; 39+ messages in thread
From: Vanessa Page @ 2022-07-24  1:30 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: Tomasz Maciej Nowak, Tudor.Ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou,
	reimu

🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😚😍😚😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍

Omg thank you Janika!

I’m glad to see everything is okay just tell them next time!

Love ya babes!

> On Jul 23, 2022, at 9:27 PM, Zhou Yanjie <zhouyanjie@wanyeetech.com> wrote:
> 
> Hi Tomasz,
> 
>> On 2022/7/23 下午10:47, Tomasz Maciej Nowak wrote:
>> W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
>>> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
>>> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
>>> 
>>> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
>>> 
>>> 周琰杰 (Zhou Yanjie) (3):
>>>   mtd: spi-nor: Use the spi-mem poll status APIs.
>>>   dt-bindings: SPI: Add Ingenic SFC bindings.
>>>   SPI: Ingenic: Add SFC support for Ingenic SoCs.
>>> 
>>>  .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>>>  drivers/mtd/spi-nor/core.c                         |  42 +-
>>>  drivers/spi/Kconfig                                |   9 +
>>>  drivers/spi/Makefile                               |   1 +
>>>  drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>>>  5 files changed, 768 insertions(+), 10 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>  create mode 100755 drivers/spi/spi-ingenic-sfc.c
>>> 
>> Even tough it's still early in revision process, I'll add my
>> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
>> 
>> The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
>> but with 256 MiB RAM. No bugs yet observed on my side.
> 
> 
> Thanks for you test!
> 
> 
>> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-24  1:30     ` Vanessa Page
@ 2022-07-24  1:32       ` Vee Page
  2022-07-26  6:13         ` Vee Page
  0 siblings, 1 reply; 39+ messages in thread
From: Vee Page @ 2022-07-24  1:32 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: Tomasz Maciej Nowak, Tudor.Ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou,
	reimu

No problem!!!
I forget to tell them. It’s okay though! 👌👍
😚😚😚😚😚😚😚😚😚😚😚😚😚😚☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️
I’m blushing! Last night was fun.

> On Jul 23, 2022, at 9:30 PM, Vanessa Page <Vebpe@outlook.com> wrote:
> 
> 🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😚😍😚😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍
> 
> Omg thank you Janika!
> 
> I’m glad to see everything is okay just tell them next time!
> 
> Love ya babes!
> 
>> On Jul 23, 2022, at 9:27 PM, Zhou Yanjie <zhouyanjie@wanyeetech.com> wrote:
>> 
>> Hi Tomasz,
>> 
>>>> On 2022/7/23 下午10:47, Tomasz Maciej Nowak wrote:
>>> W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
>>>> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
>>>> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
>>>> 
>>>> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
>>>> 
>>>> 周琰杰 (Zhou Yanjie) (3):
>>>>  mtd: spi-nor: Use the spi-mem poll status APIs.
>>>>  dt-bindings: SPI: Add Ingenic SFC bindings.
>>>>  SPI: Ingenic: Add SFC support for Ingenic SoCs.
>>>> 
>>>> .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>>>> drivers/mtd/spi-nor/core.c                         |  42 +-
>>>> drivers/spi/Kconfig                                |   9 +
>>>> drivers/spi/Makefile                               |   1 +
>>>> drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>>>> 5 files changed, 768 insertions(+), 10 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>> create mode 100755 drivers/spi/spi-ingenic-sfc.c
>>>> 
>>> Even tough it's still early in revision process, I'll add my
>>> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
>>> 
>>> The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
>>> but with 256 MiB RAM. No bugs yet observed on my side.
>> 
>> 
>> Thanks for you test!
>> 
>> 
>>> 
>> 
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 20:05           ` Krzysztof Kozlowski
@ 2022-07-24 14:52             ` Zhou Yanjie
  0 siblings, 0 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-24 14:52 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Mike Yang, tudor.ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-mtd, linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, paul, dongsheng.qiu, aric.pzqi,
	rick.tyliu, jinghui.liu, sernia.zhou

Hi Krzysztof, Mike & Mark,

On 2022/7/24 上午4:05, Krzysztof Kozlowski wrote:
> On 23/07/2022 20:47, Mike Yang wrote:
>> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
>>> On 23/07/2022 18:50, Zhou Yanjie wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 2022/7/23 上午1:46, Krzysztof Kozlowski wrote:
>>>>> On 22/07/2022 18:48, 周琰杰 (Zhou Yanjie) wrote:
>>>>>> Add the SFC bindings for the X1000 SoC, the X1600 SoC, the X1830 SoC,
>>>>>> and the X2000 SoC from Ingenic.
>>>>>>
>>>>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>>>>>> ---
>>>>>>    .../devicetree/bindings/spi/ingenic,sfc.yaml       | 64 ++++++++++++++++++++++
>>>>>>    1 file changed, 64 insertions(+)
>>>>>>    create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>> new file mode 100644
>>>>>> index 00000000..b7c4cf4
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>>> @@ -0,0 +1,64 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/spi/ingenic,sfc.yaml#
>>>>> File name should be rather based on first compatible, so
>>>>> ingenic,x1000-sfc.yaml
>>>>
>>>> No offense, does it really need to be named that way?
>>>> I can't seem to find documentation with instructions on this :(
>>>>
>>>> The use of "ingenic,sfc.yaml" indicates that this is the documentation
>>>> for the SFC module for all Ingenic SoCs, without misleading people into
>>>> thinking it's only for a specific model of SoC. And there seem to be many
>>>> other yaml documents that use similar names (eg. fsl,spi-fsl-qspi.yaml,
>>>> spi-rockchip.yaml, spi-nxp-fspi.yaml, ingenic,spi.yaml, spi-sifive.yaml,
>>>> omap-spi.yaml), maybe these yaml files that are not named with first
>>>> compatible are also for the same consideration. :)
>>> We have many bad examples, many poor patterns and they are never an
>>> argument to add one more bad pattern.
>> Zhou already mentioned he was unable find the naming guidelines of these .yaml files.
>>
>> Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.
> It's everywhere in the kernel, what can I say? If you copy existing
> code, you might copy poor code...
>
>>> It might never grow to new devices (because they might be different), so
>>> that is not really an argument.
>> It is an argument. A very valid one.
>>
>> "they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.
>>
>> I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.
>>
>>> All bindings are to follow this rule, so I don't understand why you
>>> think it is an exception for you?
>> Zhou didn't ask you to make an exception. They have a valid point and they're asking why.
> Hm, everyone has the same valid point and such recommendation is to
> everyone, although it is nothing serious.
>
>> You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.
> I did not see any incident here... Process of review includes comments
> and there is nothing bad happening when you receive a comment. No
> incident...


I have no intention of provoking arguments, I just did *grep -rn "first 
compatible"* in the
Documentation folder after you mentioned the naming rules about "first 
compatible" before,
but just found a "first compatible" in "Documentation/fb/sstfb.rst", but 
It has absolutely
nothing to do with file naming. As Mike and Mark said, my question in 
the previous email
was just out of curiosity about where to look for a detailed explanation 
of the rule.
Since it would be somewhat strange to have two "Ingenic" yaml files with 
different naming
rules in the SPI subsystem, maybe Rob can guide us here?


Thanks and best regards!


>
> Best regards,
> Krzysztof

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs.
  2022-07-23 20:24       ` Paul Cercueil
@ 2022-07-24 15:29         ` Zhou Yanjie
  0 siblings, 0 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-24 15:29 UTC (permalink / raw)
  To: Paul Cercueil
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, broonie, robh+dt, krzysztof.kozlowski+dt, linux-mtd,
	linux-spi, linux-mips, linux-kernel, devicetree,
	aidanmacdonald.0x0, tmn505, dongsheng.qiu, aric.pzqi, rick.tyliu,
	jinghui.liu, sernia.zhou, reimu

Hi Paul,

On 2022/7/24 上午4:24, Paul Cercueil wrote:
> Hi Zhou,
>
> Le dim., juil. 24 2022 at 01:26:56 +0800, Zhou Yanjie 
> <zhouyanjie@wanyeetech.com> a écrit :
>> Hi Paul,
>>
>> On 2022/7/23 上午4:03, Paul Cercueil wrote:
>>> Hi Zhou,
>>>
>>>
>>> Le sam., juil. 23 2022 at 00:48:30 +0800, 周琰杰 (Zhou Yanjie) 
>>> \x7f<zhouyanjie@wanyeetech.com> a écrit :
>>>> Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC
>>>> from Ingenic.
>>>>
>>>> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
>>>> ---
>>>>  drivers/spi/Kconfig           |   9 +
>>>>  drivers/spi/Makefile          |   1 +
>>>>  drivers/spi/spi-ingenic-sfc.c | 662 
>>>> \x7f\x7f++++++++++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 672 insertions(+)
>>>>  create mode 100644 drivers/spi/spi-ingenic-sfc.c
>>>>
>>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>>> index 3b1044e..1077bd3 100644
>>>> --- a/drivers/spi/Kconfig
>>>> +++ b/drivers/spi/Kconfig
>>>> @@ -437,6 +437,15 @@ config SPI_INGENIC
>>>>        To compile this driver as a module, choose M here: the module
>>>>        will be called spi-ingenic.
>>>>
>>>> +config SPI_INGENIC_SFC
>>>> +    tristate "Ingenic SoCs SPI Flash Controller"
>>>> +    depends on MACH_INGENIC || COMPILE_TEST
>>>> +    help
>>>> +      This enables support for the Ingenic SoCs SPI flash controller.
>>>> +
>>>> +      To compile this driver as a module, choose M here: the module
>>>> +      will be called ingenic-sfc.
>>>> +
>>>>  config SPI_INTEL
>>>>      tristate
>>>>
>>>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>>>> index 0f44eb6..f3e42c0 100644
>>>> --- a/drivers/spi/Makefile
>>>> +++ b/drivers/spi/Makefile
>>>> @@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_HISI_SFC_V3XX)        += 
>>>> \x7f\x7fspi-hisi-sfc-v3xx.o
>>>>  obj-$(CONFIG_SPI_IMG_SPFI)        += spi-img-spfi.o
>>>>  obj-$(CONFIG_SPI_IMX)            += spi-imx.o
>>>>  obj-$(CONFIG_SPI_INGENIC)        += spi-ingenic.o
>>>> +obj-$(CONFIG_SPI_INGENIC_SFC)    += spi-ingenic-sfc.o
>>>>  obj-$(CONFIG_SPI_INTEL)            += spi-intel.o
>>>>  obj-$(CONFIG_SPI_INTEL_PCI)        += spi-intel-pci.o
>>>>  obj-$(CONFIG_SPI_INTEL_PLATFORM)    += spi-intel-platform.o
>>>> diff --git a/drivers/spi/spi-ingenic-sfc.c 
>>>> \x7f\x7fb/drivers/spi/spi-ingenic-sfc.c
>>>> new file mode 100644
>>>> index 00000000..a565546
>>>> --- /dev/null
>>>> +++ b/drivers/spi/spi-ingenic-sfc.c
>>>> @@ -0,0 +1,662 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>
>>> Dual-license driver? That's not what MODULE_LICENSE() says.
>>>
>>
>> My fault, forgot to modify MODULE_LICENSE(), will fix it in the next 
>> version.
>>
>>
>>>> +/*
>>>> + * Ingenic SoCs SPI Flash Controller Driver
>>>> + * Copyright (c) 2022 周琰杰 (Zhou Yanjie) 
>>>> <zhouyanjie@wanyeetech.com>
>>>> + */
>>>> +
>>>> +#include <linux/bitfield.h>
>>>> +#include <linux/bitops.h>
>>>> +#include <linux/clk.h>
>>>> +#include <linux/completion.h>
>>>> +#include <linux/dma-mapping.h>
>>>> +#include <linux/interrupt.h>
>>>> +#include <linux/iopoll.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/mtd/mtd.h>
>>>> +#include <linux/of_device.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/spi/spi.h>
>>>> +#include <linux/spi/spi-mem.h>
>>>> +
>>>> +/* SFC register offsets */
>>>> +#define SFC_REG_GLB                        0x0000
>>>> +#define SFC_REG_DEV_CONF                0x0004
>>>> +#define SFC_REG_DEV_STA_EXP                0x0008
>>>> +#define SFC_REG_DEV_STA_RT                0x000c
>>>> +#define SFC_REG_DEV_STA_MSK                0x0010
>>>> +#define SFC_REG_TRAN_CONF(n)            (0x0014 + n * 4)
>>>> +#define SFC_REG_TRAN_CFG0(n)            (0x0014 + n * 4)
>>>
>>> You should protect the macro parameter. If you do for instance 
>>> \x7fSFC_REG_TRAN_CONF(x + 1) it would resolve to (0x0014 + x + 1 * 4) 
>>> \x7fwhich is not what you'd want.
>>>
>>
>> Sure, will fix it.
>>
>>
>>> Also - looks like SFC_REG_TRAN_CONF() and SFC_REG_TRAN_CFG0() are 
>>> the \x7fsame thing, that's on purpose?
>>>
>>>> +#define SFC_REG_TRAN_LEN 0x002c
>>>> +#define SFC_REG_DEV_ADDR(n)                (0x0030 + n * 4)
>>>> +#define SFC_REG_DEV_ADDR_PLUS(n)        (0x0048 + n * 4)
>>>> +#define SFC_REG_MEM_ADDR                0x0060
>>>> +#define SFC_REG_TRIG                    0x0064
>>>> +#define SFC_REG_SR                        0x0068
>>>> +#define SFC_REG_SCR                        0x006c
>>>> +#define SFC_REG_INTC                    0x0070
>>>> +#define SFC_REG_FSM                        0x0074
>>>> +#define SFC_REG_CGE                        0x0078
>>>> +#define SFC_REG_TRAN_CFG1(n)            (0x009c + n * 4)
>>>> +#define SFC_REG_DR                        0x1000
>>>> +
>>>> +/* bits within the GLB register */
>>>> +#define GLB_TRAN_DIR_MASK                GENMASK(13, 13)
>>>> +#define GLB_TRAN_DIR_WRITE                0x1
>>>> +#define GLB_TRAN_DIR_READ                0x0
>>>
>>> When it's a single bit - just use BIT().
>>
>>
>> Sure.
>>
>>
>>>
>>>> +#define GLB_THRESHOLD_MASK GENMASK(12, 7)
>>>> +#define GLB_OP_MODE_MASK                GENMASK(6, 6)
>>>
>>> Same here, and I see it a few times below as well.
>>>
>>
>> Sure.
>>
>>
>>>> +#define GLB_OP_MODE_DMA                    0x1
>>>> +#define GLB_OP_MODE_SLAVE                0x0
>>>> +#define GLB_PHASE_NUM_MASK                GENMASK(5, 3)
>>>> +#define GLB_WP_EN                        BIT(2)
>>>> +#define GLB_BURST_MD_MASK                GENMASK(1, 0)
>>>> +#define GLB_BURST_MD_INCR32                0x3
>>>> +#define GLB_BURST_MD_INCR16                0x2
>>>> +#define GLB_BURST_MD_INCR8                0x1
>>>> +#define GLB_BURST_MD_INCR4                0x0
>>>> +
>>>> +/* bits within the DEV_CONF register */
>>>> +#define DEV_CONF_SMP_DELAY_MASK            GENMASK(20, 16)
>>>> +#define DEV_CONF_SMP_DELAY_180DEG        0x4
>>>> +#define DEV_CONF_SMP_DELAY_HALF_CYCLE    0x1
>>>> +#define DEV_CONF_CMD_TYPE_MASK            GENMASK(15, 15)
>>>> +#define DEV_CONF_CMD_TYPE_16BIT            0x1
>>>> +#define DEV_CONF_CMD_TYPE_8BIT            0x0
>>>> +#define DEV_CONF_STA_TYPE_MASK            GENMASK(14, 13)
>>>> +#define DEV_CONF_THOLD_MASK                GENMASK(12, 11)
>>>> +#define DEV_CONF_TSETUP_MASK            GENMASK(10, 9)
>>>> +#define DEV_CONF_TSH_MASK                GENMASK(8, 5)
>>>> +#define DEV_CONF_CPHA                    BIT(4)
>>>> +#define DEV_CONF_CPOL                    BIT(3)
>>>> +#define DEV_CONF_CE_DL                    BIT(2)
>>>> +#define DEV_CONF_HOLD_DL                BIT(1)
>>>> +#define DEV_CONF_WP_DL                    BIT(0)
>>>> +
>>>> +/* bits within the TRAN_CONF(n) register */
>>>> +#define TRAN_CONF_TRAN_MODE_MASK        GENMASK(31, 29)
>>>> +#define TRAN_CONF_ADDR_WIDTH_MASK        GENMASK(28, 26)
>>>> +#define TRAN_CONF_POLL_EN                BIT(25)
>>>> +#define TRAN_CONF_CMD_EN                BIT(24)
>>>> +#define TRAN_CONF_PHASE_FORMAT_MASK        GENMASK(23, 23)
>>>> +#define TRAN_CONF_DMY_BITS_MASK            GENMASK(22, 17)
>>>> +#define TRAN_CONF_DATA_EN                BIT(16)
>>>> +#define TRAN_CONF_CMD_MASK                GENMASK(15, 0)
>>>> +
>>>> +/* bits within the TRIG register */
>>>> +#define TRIG_FLUSH                        BIT(2)
>>>> +#define TRIG_STOP                        BIT(1)
>>>> +#define TRIG_START                        BIT(0)
>>>> +
>>>> +/* bits within the SR register */
>>>> +#define SR_FIFO_NUM_MASK                GENMASK(22, 16)
>>>> +#define SR_END                            BIT(4)
>>>> +#define SR_TRAN_REQ                        BIT(3)
>>>> +#define SR_RECE_REQ                        BIT(2)
>>>> +#define SR_OVER                            BIT(1)
>>>> +#define SR_UNDER                        BIT(0)
>>>> +
>>>> +/* bits within the SCR register */
>>>> +#define SCR_CLR_END                        BIT(4)
>>>> +#define SCR_CLR_TREQ                    BIT(3)
>>>> +#define SCR_CLR_RREQ                    BIT(2)
>>>> +#define SCR_CLR_OVER                    BIT(1)
>>>> +#define SCR_CLR_UNDER                    BIT(0)
>>>> +
>>>> +/* bits within the INTC register */
>>>> +#define INTC_MASK_END                    BIT(4)
>>>> +#define INTC_MASK_TREQ                    BIT(3)
>>>> +#define INTC_MASK_RREQ                    BIT(2)
>>>> +#define INTC_MASK_OVER                    BIT(1)
>>>> +#define INTC_MASK_UNDER                    BIT(0)
>>>> +
>>>> +/* bits within the TRAN_CFG1(n) register */
>>>> +#define TRAN_CFG1_TRAN_MODE_MASK        GENMASK(7, 4)
>>>> +
>>>> +#define TRAN_MODE_STANDARD                0
>>>> +#define TRAN_MODE_DUAL_DATA                1
>>>> +#define TRAN_MODE_DUAL_IO                2
>>>> +#define TRAN_MODE_DUAL_FULL                3
>>>> +#define TRAN_MODE_QUAD_DATA                5
>>>> +#define TRAN_MODE_QUAD_IO                6
>>>> +#define TRAN_MODE_QUAD_FULL                7
>>>> +#define TRAN_MODE_OCTAL_DATA            9
>>>> +#define TRAN_MODE_OCTAL_IO                10
>>>> +#define TRAN_MODE_OCTAL_FULL            11
>>>> +
>>>> +#define INGENIC_SFC_FIFO_SIZE            (64 * 4)
>>>> +
>>>> +#define INGENIC_SFC_TRANSFER_TIMEOUT    1000
>>>
>>> Maybe add the unit name in the macro as well - 
>>> \x7fINGENIC_SFC_TRANSFER_TIMEOUT_MS.
>>
>>
>> Sure.
>>
>>
>>>
>>>> +
>>>> +enum ingenic_sfc_version {
>>>> +    ID_X1000,
>>>> +    ID_X1600,
>>>> +    ID_X2000,
>>>> +};
>>>> +
>>>> +struct ingenic_soc_info {
>>>> +    enum ingenic_sfc_version version;
>>>> +
>>>> +    unsigned int max_bus_width;
>>>> +
>>>> +    const u32 tran_mode_mask;
>>>> +};
>>>> +
>>>> +struct ingenic_sfc {
>>>> +    const struct ingenic_soc_info *soc_info;
>>>> +
>>>> +    void __iomem *base;
>>>> +    struct device *dev;
>>>> +    struct clk *clk;
>>>> +    int irq;
>>>> +
>>>> +    struct completion completion;
>>>> +};
>>>> +
>>>> +static irqreturn_t ingenic_sfc_irq_handler(int irq, void *data)
>>>> +{
>>>> +    struct ingenic_sfc *sfc = data;
>>>> +
>>>> +    writel(0x1f, sfc->base + SFC_REG_INTC);
>>>> +
>>>> +    complete(&sfc->completion);
>>>> +
>>>> +    return IRQ_HANDLED;
>>>> +}
>>>> +
>>>> +static int ingenic_sfc_adjust_op_size(struct spi_mem *mem, struct 
>>>> \x7f\x7fspi_mem_op *op)
>>>> +{
>>>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>>>> +
>>>> +    if (op->data.nbytes > INGENIC_SFC_FIFO_SIZE && 
>>>> !IS_ALIGNED(addr, \x7f\x7f4))
>>>> +        op->data.nbytes = INGENIC_SFC_FIFO_SIZE;
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static bool ingenic_sfc_supports_op(struct spi_mem *mem, const 
>>>> \x7f\x7fstruct spi_mem_op *op)
>>>> +{
>>>> +    struct spi_device *spi = mem->spi;
>>>> +    struct ingenic_sfc *sfc = 
>>>> spi_controller_get_devdata(spi->master);
>>>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>>>> +
>>>> +    /* The controller only supports Standard SPI mode, Duall mode, 
>>>> \x7f\x7fQuad mode and Octal mode. */
>>>
>>> Dual*
>>
>>
>> Oops, will fix it.
>>
>>
>>>
>>>> +    if (op->cmd.buswidth > sfc->soc_info->max_bus_width ||
>>>> +        op->addr.buswidth > sfc->soc_info->max_bus_width ||
>>>> +        op->dummy.buswidth > sfc->soc_info->max_bus_width ||
>>>> +        op->data.buswidth > sfc->soc_info->max_bus_width)
>>>> +        return false;
>>>> +
>>>> +    /* Max 32 dummy clock cycles supported */
>>>> +    if (op->dummy.nbytes && op->dummy.nbytes * 8 / 
>>>> \x7f\x7fop->dummy.buswidth > 32)
>>>> +        return false;
>>>> +
>>>> +    /* Max rx data length, check controller limits and alignment */
>>>> +    if (op->data.dir == SPI_MEM_DATA_IN &&
>>>> +        op->data.nbytes > INGENIC_SFC_FIFO_SIZE && 
>>>> !IS_ALIGNED(addr, \x7f\x7f4))
>>>
>>> This does the same check than in ingenic_sfc_adjust_op_size(), maybe 
>>> \x7fmove it to a new inline function?
>>>
>>
>> Sure.
>>
>>
>>>> +        return false;
>>>> +
>>>> +    /* Max 6 bytes address width supported */
>>>> +    if (op->addr.nbytes > 6)
>>>> +        return false;
>>>> +
>>>> +    return spi_mem_default_supports_op(mem, op);
>>>> +}
>>>> +
>>>> +static void ingenic_sfc_set_transfer_mode(struct ingenic_sfc *sfc, 
>>>> \x7f\x7fconst struct spi_mem_op *op)
>>>> +{
>>>> +    int val;
>>>> +
>>>> +    val = readl(sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>>>> +            SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
>>>
>>> As Krzysztof said - ugh.
>>>
>>
>> Will fix it.
>>
>>
>>> Also, instead of having a "version" enum in your soc_info, why not 
>>> \x7fjust have a "reg_conf" field that gives you directly the right 
>>> register?
>>>
>>
>> We still need a version to distinguish the SFC before X1600 SoC and
>> the SFC after X1600 SoC, because in addition to the difference in the
>> cfg register, another difference is that the SFC before X1600 SoC does
>> not support address unaligned RX DMA transfer, while SFC in X1600 and
>> later SoCs can support this feature.
>
> Then add a .dma_supports_unaligned_address field.


Sure, I will try.


>
>>
>>
>>>
>>>> +    val &= ~sfc->soc_info->tran_mode_mask;
>>>> +    if (op->cmd.buswidth == 8)
>>>> +        val |= (TRAN_MODE_OCTAL_FULL << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>
>>> Looks like you're really trying to reinvent the wheel.
>>>
>>> val |= FIELD_PREP(sfc->soc_info->tran_mode_mask, TRAN_MODE_OCTAL_FULL);
>>>
>>> using <linux/bitfield.h>.
>>>
>>> Also, just define a 'mode' variable and set it in your if/else 
>>> blocks, \x7fthat would look much better. Then you can set val |= 
>>> FIELD_PREP(..., \x7fmode) at the end.
>>
>>
>> Sure, will change this in the next version.
>>
>>
>>>
>>>> +    else if (op->cmd.buswidth == 4)
>>>> +        val |= (TRAN_MODE_QUAD_FULL << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->cmd.buswidth == 2)
>>>> +        val |= (TRAN_MODE_DUAL_FULL << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->addr.buswidth == 8)
>>>> +        val |= (TRAN_MODE_OCTAL_IO << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->addr.buswidth == 4)
>>>> +        val |= (TRAN_MODE_QUAD_IO << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->addr.buswidth == 2)
>>>> +        val |= (TRAN_MODE_DUAL_IO << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->data.buswidth == 8)
>>>> +        val |= (TRAN_MODE_OCTAL_DATA << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->data.buswidth == 4)
>>>> +        val |= (TRAN_MODE_QUAD_DATA << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else if (op->data.buswidth == 2)
>>>> +        val |= (TRAN_MODE_DUAL_DATA << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    else
>>>> +        val |= (TRAN_MODE_STANDARD << 
>>>> \x7f\x7f(ffs(sfc->soc_info->tran_mode_mask) - 1)) &
>>>> +                sfc->soc_info->tran_mode_mask;
>>>> +    writel(val, sfc->base + (sfc->soc_info->version >= ID_X1600 ?
>>>> +            SFC_REG_TRAN_CFG1(0) : SFC_REG_TRAN_CONF(0)));
>>>> +}
>>>> +
>>>> +/*
>>>> + * We only need PIO mode to handle the SPI_MEM_NO_DATA transfers,
>>>> + * and the unaligned accesses in SPI_MEM_DATA_IN transfers.
>>>> + */
>>>> +static void ingenic_sfc_read_rxfifo(struct ingenic_sfc *sfc, u8 
>>>> *to, \x7f\x7funsigned int len)
>>>> +{
>>>> +    void __iomem *from;
>>>> +
>>>> +    from = sfc->base + SFC_REG_DR;
>>>> +
>>>> +    for (; len >= 4; len -= 4, to += 4) {
>>>> +        u32 val = __raw_readl(from);
>>>> +        memcpy(to, &val, 4);
>>>
>>> No need to use memcpy for 4 bytes. You can do: put_unaligned(val, 
>>> (u32 \x7f*)to);
>>>
>>
>> Sure.
>>
>>
>>>> +    }
>>>> +
>>>> +    if (len) {
>>>> +        u32 val = __raw_readl(from);
>>>> +        memcpy(to, &val, len);
>>>
>>> Hmm, I'm not sure that is endian-safe. I would prefer if you copied 
>>> \x7fbyte by byte.
>>>
>>
>> Sure.
>>
>>
>>>> +    }
>>>> +}
>>>> +
>>>> +static int ingenic_sfc_exec_op_pio(struct ingenic_sfc *sfc, const 
>>>> \x7f\x7fstruct spi_mem_op *op)
>>>> +{
>>>> +    int ret, val;
>>>> +
>>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>>> +    u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
>>>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>>
>>> By the way, have you considered using regmap?
>>>
>>> It would give you things like regmap_update_bits() for this kind of 
>>> \x7fthings, and regmap_field() to handle your conf register being at a 
>>> \x7fdifferent address across SoCs.
>>>
>>
>> It seems that the overhead of using regmap will be greater than using 
>> readl and writel,
>> the purpose of using readl and writel is to minimize overhead and 
>> maximize performance. :)
>
> If you really think that this is a valid reason not to use regmap, 
> then prove it with a benchmark, because I'm *very* doubtful about your 
> claim.
>

I have tested your writel/readl version of the spi driver and the 
current regmap
version of the spi driver, and indeed the measured performance 
differences are
perceivable. I will do another test for the sfc driver to determine if 
it's the
same case. By the way, I'm trying to use interrupts in the spi driver 
instead of
using regmap_read_poll_timeout(), which can indeed improve some performance.


Thanks and best regards!


> Cheers,
> -Paul
>
>>>> +
>>>> +    val = TRAN_CONF_CMD_EN | op->cmd.opcode;
>>>> +
>>>> +    if (op->addr.nbytes > 0) {
>>>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, 
>>>> op->addr.nbytes);
>>>> +
>>>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>>>> \x7f\x7fSFC_REG_DEV_ADDR(0));
>>>> +        writel(op->addr.val >> 32, sfc->base + 
>>>> \x7f\x7fSFC_REG_DEV_ADDR_PLUS(0));
>>>> +    }
>>>> +
>>>> +    if (op->dummy.nbytes > 0)
>>>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>>>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>>>> +
>>>> +    if (op->data.nbytes > 0)
>>>> +        val |= TRAN_CONF_DATA_EN;
>>>> +
>>>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>>>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>>>> +
>>>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>>>> +
>>>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>>>
>>> Random 0x1f value here, maybe use a macro?
>>
>>
>> Sure.
>>
>>
>>>
>>>> +    writel(~(INTC_MASK_END | INTC_MASK_RREQ), sfc->base + 
>>>> \x7f\x7fSFC_REG_INTC);
>>>> +
>>>> +    writel(0, sfc->base + SFC_REG_MEM_ADDR);
>>>> +
>>>> +    writel(TRIG_FLUSH, sfc->base + SFC_REG_TRIG);
>>>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>>>> +
>>>> +    ret = wait_for_completion_timeout(&sfc->completion,
>>>> + msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>>>> +    if (!ret) {
>>>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>>>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>>>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>>>> \x7f\x7fdevice\n", __LINE__);
>>>> +        return -ETIMEDOUT;
>>>> +    }
>>>> +
>>>> +    ingenic_sfc_read_rxfifo(sfc, op->data.buf.in, op->data.nbytes);
>>>> +    readl_poll_timeout(sfc->base + SFC_REG_SR, val, val & SR_END, 
>>>> \x7f\x7f10, 0);
>>>
>>> Infinite timeout? Is that very wise?
>>
>>
>> Will fix it in the next version.
>>
>>
>>>
>>>> +
>>>> +    writel(INTC_MASK_END | INTC_MASK_RREQ, sfc->base + SFC_REG_SCR);
>>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static int ingenic_sfc_exec_op_dma(struct ingenic_sfc *sfc, const 
>>>> \x7f\x7fstruct spi_mem_op *op)
>>>> +{
>>>> +    dma_addr_t addr;
>>>> +    int ret, val;
>>>> +
>>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>>> +    u32p_replace_bits(&val, op->data.dir == SPI_MEM_DATA_IN ?
>>>> +            GLB_TRAN_DIR_READ : GLB_TRAN_DIR_WRITE, 
>>>> GLB_TRAN_DIR_MASK);
>>>> +    u32p_replace_bits(&val, GLB_OP_MODE_DMA, GLB_OP_MODE_MASK);
>>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>>> +
>>>> +    val = TRAN_CONF_CMD_EN | op->cmd.opcode;
>>>> +
>>>> +    if (op->addr.nbytes > 0) {
>>>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, 
>>>> op->addr.nbytes);
>>>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>>>> \x7f\x7fSFC_REG_DEV_ADDR(0));
>>>> +        writel(op->addr.val >> 32, sfc->base + 
>>>> \x7f\x7fSFC_REG_DEV_ADDR_PLUS(0));
>>>> +    }
>>>> +
>>>> +    if (op->dummy.nbytes > 0)
>>>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>>>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>>>> +
>>>> +    if (op->data.nbytes > 0)
>>>> +        val |= TRAN_CONF_DATA_EN;
>>>
>>> There's a lot of code duplication here with 
>>> ingenic_sfc_exec_op_pio(). \x7fA lot can be factorized.
>>
>>
>> Sure, I will try to do it.
>>
>>
>>>
>>>> +
>>>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>>>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>>>> +
>>>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>>>> +
>>>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>>>> +    writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
>>>> +
>>>> +    switch (op->data.dir) {
>>>> +    case SPI_MEM_DATA_IN:
>>>> +        addr = dma_map_single(sfc->dev, op->data.buf.in, 
>>>> \x7f\x7fop->data.nbytes, DMA_FROM_DEVICE);
>>>> +        if (dma_mapping_error(sfc->dev, addr)) {
>>>> +            dev_err(sfc->dev, "RX DMA memory not mapped\n");
>>>> +            return -ENOMEM;
>>>> +        }
>>>> +
>>>> +        writel(addr, sfc->base + SFC_REG_MEM_ADDR);
>>>> +        break;
>>>> +
>>>> +    case SPI_MEM_DATA_OUT:
>>>> +        addr = dma_map_single(sfc->dev, (void *)op->data.buf.out,
>>>> +                op->data.nbytes, DMA_TO_DEVICE);
>>>> +        if (dma_mapping_error(sfc->dev, addr)) {
>>>> +            dev_err(sfc->dev, "TX DMA memory not mapped\n");
>>>> +            return -ENOMEM;
>>>> +        }
>>>> +
>>>> +        writel(addr, sfc->base + SFC_REG_MEM_ADDR);
>>>> +        break;
>>>> +
>>>> +    default:
>>>> +        return -EINVAL;
>>>> +    }
>>>> +
>>>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>>>> +
>>>> +    ret = wait_for_completion_timeout(&sfc->completion,
>>>> + msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>>>> +    if (!ret) {
>>>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>>>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>>>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>>>> \x7f\x7fdevice\n", __LINE__);
>>>> +        return -ETIMEDOUT;
>>>> +    }
>>>> +
>>>> +    dma_unmap_single(sfc->dev, addr, op->data.nbytes,
>>>> +            op->data.dir == SPI_MEM_DATA_IN ? DMA_FROM_DEVICE : 
>>>> \x7f\x7fDMA_TO_DEVICE);
>>>
>>> Use a small inline function for that too. My personal rule is that 
>>> ?: \x7fis fine if the line fits in 80 characters, but if you have to 
>>> break, \x7fthen you really need to move it somewhere else.
>>>
>>
>> Sure.
>>
>>
>>>> +
>>>> +    writel(INTC_MASK_END, sfc->base + SFC_REG_SCR);
>>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static int ingenic_sfc_exec_op(struct spi_mem *mem, const struct 
>>>> \x7f\x7fspi_mem_op *op)
>>>> +{
>>>> +    struct spi_device *spi = mem->spi;
>>>> +    struct ingenic_sfc *sfc = 
>>>> spi_controller_get_devdata(spi->master);
>>>> +    uintptr_t addr = (uintptr_t)op->data.buf.in;
>>>> +
>>>> +    init_completion(&sfc->completion);
>>>> +
>>>> +    switch (op->data.dir) {
>>>> +    case SPI_MEM_DATA_IN:
>>>> +        if (sfc->soc_info->version >= ID_X1600 || IS_ALIGNED(addr, 
>>>> 4))
>>>> +            break;
>>>> +
>>>> +        fallthrough;
>>>> +
>>>> +    case SPI_MEM_NO_DATA:
>>>> +        return ingenic_sfc_exec_op_pio(sfc, op);
>>>> +
>>>> +    default:
>>>> +        break;
>>>> +    }
>>>> +
>>>> +    return ingenic_sfc_exec_op_dma(sfc, op);
>>>> +}
>>>> +
>>>> +static int ingenic_sfc_poll_status(struct spi_mem *mem, const 
>>>> struct \x7f\x7fspi_mem_op *op,
>>>> +            u16 mask, u16 match, unsigned long initial_delay_us,
>>>> +            unsigned long polling_delay_us, unsigned long timeout_ms)
>>>> +{
>>>> +    struct spi_device *spi = mem->spi;
>>>> +    struct ingenic_sfc *sfc = 
>>>> spi_controller_get_devdata(spi->master);
>>>> +    int ret, val;
>>>> +
>>>> +    init_completion(&sfc->completion);
>>>> +
>>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>>> +    u32p_replace_bits(&val, GLB_TRAN_DIR_READ, GLB_TRAN_DIR_MASK);
>>>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>>> +
>>>> +    writel(match, sfc->base + SFC_REG_DEV_STA_EXP);
>>>> +    writel(mask, sfc->base + SFC_REG_DEV_STA_MSK);
>>>> +
>>>> +    val = TRAN_CONF_POLL_EN | TRAN_CONF_CMD_EN | op->cmd.opcode;
>>>> +
>>>> +    if (op->addr.nbytes > 0) {
>>>> +        val |= FIELD_PREP(TRAN_CONF_ADDR_WIDTH_MASK, 
>>>> op->addr.nbytes);
>>>> +
>>>> +        writel(op->addr.val & 0xffffffff, sfc->base + 
>>>> \x7f\x7fSFC_REG_DEV_ADDR(0));
>>>> +        writel(op->addr.val >> 32, sfc->base + 
>>>> \x7f\x7fSFC_REG_DEV_ADDR_PLUS(0));
>>>> +    }
>>>> +
>>>> +    if (op->dummy.nbytes > 0)
>>>> +        val |= FIELD_PREP(TRAN_CONF_DMY_BITS_MASK,
>>>> +                op->dummy.nbytes * 8 / op->dummy.buswidth);
>>>> +
>>>> +    if (op->data.nbytes > 0)
>>>> +        val |= TRAN_CONF_DATA_EN;
>>>> +
>>>> +    writel(val, sfc->base + SFC_REG_TRAN_CONF(0));
>>>> +    writel(op->data.nbytes, sfc->base + SFC_REG_TRAN_LEN);
>>>> +
>>>> +    ingenic_sfc_set_transfer_mode(sfc, op);
>>>> +
>>>> +    writel(0x1f, sfc->base + SFC_REG_SCR);
>>>> +    writel(~INTC_MASK_END, sfc->base + SFC_REG_INTC);
>>>> +
>>>> +    writel(0, sfc->base + SFC_REG_MEM_ADDR);
>>>> +
>>>> +    writel(TRIG_START, sfc->base + SFC_REG_TRIG);
>>>> +
>>>> +    ret = wait_for_completion_timeout(&sfc->completion,
>>>> + msecs_to_jiffies(INGENIC_SFC_TRANSFER_TIMEOUT));
>>>> +    if (!ret) {
>>>> +        writel(0x1f, sfc->base + SFC_REG_INTC);
>>>> +        writel(0x1f, sfc->base + SFC_REG_SCR);
>>>> +        dev_err(sfc->dev, "line:%d Timeout for ACK from SFC 
>>>> \x7f\x7fdevice\n", __LINE__);
>>>> +        return -ETIMEDOUT;
>>>> +    }
>>>> +
>>>> +    writel(SCR_CLR_END, sfc->base + SFC_REG_SCR);
>>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static const struct spi_controller_mem_ops ingenic_sfc_mem_ops = {
>>>> +    .adjust_op_size = ingenic_sfc_adjust_op_size,
>>>> +    .supports_op = ingenic_sfc_supports_op,
>>>> +    .exec_op = ingenic_sfc_exec_op,
>>>> +    .poll_status = ingenic_sfc_poll_status,
>>>> +};
>>>> +
>>>> +static int ingenic_sfc_setup(struct spi_device *spi)
>>>> +{
>>>> +    struct ingenic_sfc *sfc = 
>>>> spi_controller_get_devdata(spi->master);
>>>> +    unsigned long rate;
>>>> +    int ret, val;
>>>> +
>>>> +    if (!spi->max_speed_hz)
>>>> +        return -EINVAL;
>>>
>>> Maybe set a sane default?
>>
>>
>> Sure.
>>
>>
>>>
>>>> +
>>>> +    ret = clk_set_rate(sfc->clk, spi->max_speed_hz * 2);
>>>> +    if (ret)
>>>> +        return -EINVAL;
>>>> +
>>>> +    writel(TRIG_STOP, sfc->base + SFC_REG_TRIG);
>>>> +    writel(0, sfc->base + SFC_REG_DEV_CONF);
>>>> +    writel(0, sfc->base + SFC_REG_CGE);
>>>> +
>>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>>> +    u32p_replace_bits(&val, 64 - 1, GLB_THRESHOLD_MASK);
>>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>>> +
>>>> +    val = readl(sfc->base + SFC_REG_DEV_CONF);
>>>> +
>>>> +    /* cpha bit:0 , cpol bit:0 */
>>>> +    val &= ~(DEV_CONF_CPHA | DEV_CONF_CPOL);
>>>> +    val |= spi->mode & SPI_CPHA ? DEV_CONF_CPHA : 0;
>>>> +    val |= spi->mode & SPI_CPOL ? DEV_CONF_CPOL : 0;
>>>> +
>>>> +    /* ce_dl bit:1, hold bit:1, wp bit:1 */
>>>> +    val |= (DEV_CONF_CE_DL | DEV_CONF_HOLD_DL | DEV_CONF_WP_DL);
>>>> +
>>>> +    writel(val, sfc->base + SFC_REG_DEV_CONF);
>>>> +
>>>> +    val = readl(sfc->base + SFC_REG_GLB);
>>>> +    u32p_replace_bits(&val, GLB_OP_MODE_SLAVE, GLB_OP_MODE_MASK);
>>>> +    writel(val, sfc->base + SFC_REG_GLB);
>>>> +
>>>> +    rate = clk_get_rate(sfc->clk);
>>>
>>> I'd suggest using clk_round_rate() before clk_set_rate() because 
>>> then \x7fyou know what frequency it's going to be, and you don't have 
>>> to call \x7fclk_get_rate() afterwards.
>>>
>>
>> Sure, will try.
>>
>>
>> Thanks and best regards!
>>
>>
>>> Cheers,
>>> -Paul
>>>
>>>> +    val = readl(sfc->base + SFC_REG_DEV_CONF);
>>>> +    if (sfc->soc_info->version >= ID_X1600 && rate >= 200000000)
>>>> +        u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_180DEG, 
>>>> \x7f\x7fDEV_CONF_SMP_DELAY_MASK);
>>>> +    else if (sfc->soc_info->version == ID_X1000 && rate >= 100000000)
>>>> +        u32p_replace_bits(&val, DEV_CONF_SMP_DELAY_HALF_CYCLE, 
>>>> \x7f\x7fDEV_CONF_SMP_DELAY_MASK);
>>>> +    writel(val, sfc->base + SFC_REG_DEV_CONF);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static int ingenic_sfc_probe(struct platform_device *pdev)
>>>> +{
>>>> +    struct ingenic_sfc *sfc;
>>>> +    struct spi_controller *ctlr;
>>>> +    int ret;
>>>> +
>>>> +    ctlr = spi_alloc_master(&pdev->dev, sizeof(*sfc));
>>>> +    if (!ctlr)
>>>> +        return -ENOMEM;
>>>> +
>>>> +    sfc = spi_controller_get_devdata(ctlr);
>>>> +
>>>> +    sfc->soc_info = of_device_get_match_data(&pdev->dev);
>>>> +    if (!sfc->soc_info) {
>>>> +        dev_err(&pdev->dev, "No of match data provided\n");
>>>> +        ret = -ENODEV;
>>>> +        goto err_put_master;
>>>> +    }
>>>> +
>>>> +    sfc->base = devm_platform_ioremap_resource(pdev, 0);
>>>> +    if (IS_ERR(sfc->base)) {
>>>> +        ret = PTR_ERR(sfc->base);
>>>> +        goto err_put_master;
>>>> +    }
>>>> +
>>>> +    sfc->clk = devm_clk_get(&pdev->dev, "sfc");
>>>> +    if (IS_ERR(sfc->clk)) {
>>>> +        ret = IS_ERR(sfc->clk);
>>>> +        goto err_put_master;
>>>> +    }
>>>> +
>>>> +    ret = clk_prepare_enable(sfc->clk);
>>>> +    if (ret)
>>>> +        goto err_put_master;
>>>> +
>>>> +    sfc->irq = platform_get_irq(pdev, 0);
>>>> +    if (sfc->irq < 0) {
>>>> +        ret = sfc->irq;
>>>> +        goto err_put_master;
>>>> +    }
>>>> +
>>>> +    sfc->dev = &pdev->dev;
>>>> +
>>>> +    platform_set_drvdata(pdev, sfc);
>>>> +
>>>> +    ret = devm_request_irq(&pdev->dev, sfc->irq, 
>>>> \x7f\x7fingenic_sfc_irq_handler, 0,
>>>> +            dev_name(&pdev->dev), sfc);
>>>> +    if (ret) {
>>>> +        dev_err(&pdev->dev, "Failed to request irq%d, ret = %d\n", 
>>>> \x7f\x7fsfc->irq, ret);
>>>> +        goto err_put_master;
>>>> +    }
>>>> +
>>>> +    ctlr->bus_num = -1;
>>>> +    ctlr->num_chipselect = 1;
>>>> +    ctlr->mem_ops = &ingenic_sfc_mem_ops;
>>>> +    ctlr->dev.of_node = pdev->dev.of_node;
>>>> +    ctlr->setup = ingenic_sfc_setup;
>>>> +    ctlr->mode_bits = SPI_CPHA | SPI_CPOL |
>>>> +            SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
>>>> +    if (sfc->soc_info->version >= ID_X2000)
>>>> +        ctlr->mode_bits |= SPI_RX_OCTAL | SPI_TX_OCTAL;
>>>> +
>>>> +    ret = devm_spi_register_controller(&pdev->dev, ctlr);
>>>> +    if (ret)
>>>> +        goto err_put_master;
>>>> +
>>>> +    return 0;
>>>> +
>>>> +err_put_master:
>>>> +    spi_master_put(ctlr);
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static const struct ingenic_soc_info x1000_soc_info = {
>>>> +    .version = ID_X1000,
>>>> +
>>>> +    .max_bus_width = 4,
>>>> +
>>>> +    .tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
>>>> +};
>>>> +
>>>> +static const struct ingenic_soc_info x1600_soc_info = {
>>>> +    .version = ID_X1600,
>>>> +
>>>> +    .max_bus_width = 4,
>>>> +
>>>> +    .tran_mode_mask = TRAN_CONF_TRAN_MODE_MASK,
>>>> +};
>>>> +
>>>> +static const struct ingenic_soc_info x2000_soc_info = {
>>>> +    .version = ID_X2000,
>>>> +
>>>> +    .max_bus_width = 8,
>>>> +
>>>> +    .tran_mode_mask = TRAN_CFG1_TRAN_MODE_MASK,
>>>> +};
>>>> +
>>>> +static const struct of_device_id ingenic_sfc_of_matches[] = {
>>>> +    { .compatible = "ingenic,x1000-sfc", .data = &x1000_soc_info },
>>>> +    { .compatible = "ingenic,x1600-sfc", .data = &x1600_soc_info },
>>>> +    { .compatible = "ingenic,x2000-sfc", .data = &x2000_soc_info },
>>>> +    { /* sentinel */ }
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, ingenic_sfc_of_matches);
>>>> +
>>>> +static struct platform_driver ingenic_sfc_driver = {
>>>> +    .driver = {
>>>> +        .name = "ingenic-sfc",
>>>> +        .of_match_table = ingenic_sfc_of_matches,
>>>> +    },
>>>> +    .probe = ingenic_sfc_probe,
>>>> +};
>>>> +module_platform_driver(ingenic_sfc_driver);
>>>> +
>>>> +MODULE_LICENSE("GPL");
>>>> +MODULE_AUTHOR("周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>");
>>>> +MODULE_DESCRIPTION("Ingenic SoCs SPI Flash Controller Driver");
>>>> -- 
>>>> 2.7.4
>>>>
>>>
>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 20:49               ` Mike Yang
@ 2022-07-24 15:33                 ` Zhou Yanjie
  2022-07-25 18:30                 ` Rob Herring
  1 sibling, 0 replies; 39+ messages in thread
From: Zhou Yanjie @ 2022-07-24 15:33 UTC (permalink / raw)
  To: Mike Yang, Krzysztof Kozlowski, Mark Brown
  Cc: tudor.ambarus, p.yadav, michael, miquel.raynal, richard,
	vigneshr, robh+dt, krzysztof.kozlowski+dt, linux-mtd, linux-spi,
	linux-mips, linux-kernel, devicetree, aidanmacdonald.0x0, tmn505,
	paul, dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu,
	sernia.zhou

Hi Mike,

On 2022/7/24 上午4:49, Mike Yang wrote:
> On 7/24/22 04:07, Krzysztof Kozlowski wrote:
>> On 23/07/2022 21:27, Mark Brown wrote:
>>> On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote:
>>>> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
>>>>> On 23/07/2022 18:50, Zhou Yanjie wrote:
>>>>>> No offense, does it really need to be named that way?
>>>>>> I can't seem to find documentation with instructions on this :(
>>> ...
>>>
>>>>> All bindings are to follow this rule, so I don't understand why you
>>>>> think it is an exception for you?
>>>> Zhou didn't ask you to make an exception. They have a valid
>>>> point and they're asking why.
>>>> You may want to avoid further incidents of this kind by stop
>>>> being bossy and actually writing a guideline of naming these
>>>> .yaml files and publish it somewhere online.
>>> Yeah, I do have to say that I was also completely unaware that
>>> there was any enforced convention here.
>> Indeed, it's not a enforced pattern. But there are many other
>> insignificant ones which we also tend to forget during review, like
>> using words "Device Tree bindings" in title or using unnecessary quotes
>> around "refs" (also in ID of schema). It's not a big deal, but I ask
>> when I notice it.
> Good. Thanks for paying attention to these details.
>
>
>>> Zhou already mentioned he was unable find the naming guidelines of these .yaml files.
>>>
>>> Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.
>> It's everywhere in the kernel, what can I say? If you copy existing
>> code, you might copy poor code...
> Still, it shouldn't be a responsibility of new contributors to determine the quality of an existing piece of code, unless there are clear guidelines (i.e. one should use the new "cs-gpios" attribute in SPI controllers).
>
>>>> It might never grow to new devices (because they might be different), so
>>>> that is not really an argument.
>>> It is an argument. A very valid one.
>>>
>>> "they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.
>>>
>>> I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.
>>>
>>>> All bindings are to follow this rule, so I don't understand why you
>>>> think it is an exception for you?
>>> Zhou didn't ask you to make an exception. They have a valid point and they're asking why.
>> Hm, everyone has the same valid point and such recommendation is to
>> everyone, although it is nothing serious.
>>
>>> You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.
>> I did not see any incident here... Process of review includes comments
>> and there is nothing bad happening when you receive a comment. No
>> incident...
>
> Okay. After careful inspection of the Ingenic datasheets, now I have the conclusion: The Ingenic X1000, X1021, X1500, X1501, X1520, X1600, X1800, X1830, X2000, X2100, X2500 have the same SFC controller.


Actually, you are also missing out the X1630 and X1660, and the upcoming 
X2600.


>
> X1600 has a newer version (let's say v2) of the SFC, and X2000-2500 have v3. Others have the original version (let's say v1). Each new version introduced new features such as arbitrary DMA sizes, and the rest features are the same.
>
>
> So IMO the name "ingenic,sfc.yaml" is perfectly logical.
>
>
> Regards,
> Mike Yang

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings.
  2022-07-23 20:49               ` Mike Yang
  2022-07-24 15:33                 ` Zhou Yanjie
@ 2022-07-25 18:30                 ` Rob Herring
  1 sibling, 0 replies; 39+ messages in thread
From: Rob Herring @ 2022-07-25 18:30 UTC (permalink / raw)
  To: Mike Yang
  Cc: Krzysztof Kozlowski, Mark Brown, Zhou Yanjie, tudor.ambarus,
	p.yadav, michael, miquel.raynal, richard, vigneshr,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, tmn505, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou

On Sun, Jul 24, 2022 at 04:49:25AM +0800, Mike Yang wrote:
> On 7/24/22 04:07, Krzysztof Kozlowski wrote:
> > On 23/07/2022 21:27, Mark Brown wrote:
> >> On Sun, Jul 24, 2022 at 02:47:14AM +0800, Mike Yang wrote:
> >>> On 7/24/22 01:43, Krzysztof Kozlowski wrote:
> >>>> On 23/07/2022 18:50, Zhou Yanjie wrote:
> >>
> >>>>> No offense, does it really need to be named that way?
> >>>>> I can't seem to find documentation with instructions on this :(
> >>
> >> ...
> >>
> >>>> All bindings are to follow this rule, so I don't understand why you
> >>>> think it is an exception for you?
> >>
> >>> Zhou didn't ask you to make an exception. They have a valid
> >>> point and they're asking why.
> >>
> >>> You may want to avoid further incidents of this kind by stop
> >>> being bossy and actually writing a guideline of naming these
> >>> .yaml files and publish it somewhere online.

I don't like your tone. Patches are welcome to fix deficiencies in 
documentation. Out of the hundreds of bindings a year, I see <5 
documentation patches a year.

The documentation clearly says to run 'make dt_binding_check' and that 
was obviously not followed here. 

> >> Yeah, I do have to say that I was also completely unaware that
> >> there was any enforced convention here.
> > 
> > Indeed, it's not a enforced pattern. But there are many other
> > insignificant ones which we also tend to forget during review, like
> > using words "Device Tree bindings" in title or using unnecessary quotes
> > around "refs" (also in ID of schema). It's not a big deal, but I ask
> > when I notice it.
> 
> Good. Thanks for paying attention to these details.
> 
> 
> >> Zhou already mentioned he was unable find the naming guidelines of these .yaml files.
> >>
> >> Apparently you think it's unacceptable for new contributors of a certain subsystem to use existing code as examples, and/or they're responsible for figuring out what's a good example and what's a bad one in the existing codebase.

Please wrap your lines on replies.


> > 
> > It's everywhere in the kernel, what can I say? If you copy existing
> > code, you might copy poor code...
> 
> Still, it shouldn't be a responsibility of new contributors to 
> determine the quality of an existing piece of code, unless there are 
> clear guidelines (i.e. one should use the new "cs-gpios" attribute in SPI controllers).

Generally the guidance is to look at newer drivers for current best 
practices.


> >>> It might never grow to new devices (because they might be different), so
> >>> that is not really an argument.
> >>
> >> It is an argument. A very valid one.
> >>
> >> "they *might* be different". You may want to get your hands on real hardware and try another word. Or at least read the datasheets instead of believing your imagination.
> >>
> >> I would enjoy duplicating the st,stm32-spi.yaml into st,stm32{f,h}{0..7}-spi.yaml if I'm bored at a Sunday afternoon.
> >>
> >>>
> >>> All bindings are to follow this rule, so I don't understand why you
> >>> think it is an exception for you?
> >>
> >> Zhou didn't ask you to make an exception. They have a valid point and they're asking why.
> > 
> > Hm, everyone has the same valid point and such recommendation is to
> > everyone, although it is nothing serious.
> > 
> >> You may want to avoid further incidents of this kind by stop being bossy and actually writing a guideline of naming these .yaml files and publish it somewhere online.
> > 
> > I did not see any incident here... Process of review includes comments
> > and there is nothing bad happening when you receive a comment. No
> > incident...
> 
> 
> Okay. After careful inspection of the Ingenic datasheets, now I have 
> the conclusion: The Ingenic X1000, X1021, X1500, X1501, X1520, X1600, 
> X1800, X1830, X2000, X2100, X2500 have the same SFC controller.

So if they are all 'the same', then I expect they all have a fallback 
compatible with x1000 and using that for the filename makes sense.


> X1600 has a newer version (let's say v2) of the SFC, and X2000-2500 
> have v3. Others have the original version (let's say v1). Each new 
> version introduced new features such as arbitrary DMA sizes, and the 
> rest features are the same.

So backwards compatible? If so, then they should have x1000 for 
fallback.

> 
> So IMO the name "ingenic,sfc.yaml" is perfectly logical.

Covering all 3 versions? If so and not backwards compatible, then I 
would agree.

Rob

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH 0/3] Add SFC support for Ingenic SoCs.
  2022-07-24  1:32       ` Vee Page
@ 2022-07-26  6:13         ` Vee Page
  0 siblings, 0 replies; 39+ messages in thread
From: Vee Page @ 2022-07-26  6:13 UTC (permalink / raw)
  To: Zhou Yanjie
  Cc: Tomasz Maciej Nowak, Tudor.Ambarus, p.yadav, michael,
	miquel.raynal, richard, vigneshr, broonie, robh+dt,
	krzysztof.kozlowski+dt, linux-mtd, linux-spi, linux-mips,
	linux-kernel, devicetree, aidanmacdonald.0x0, paul,
	dongsheng.qiu, aric.pzqi, rick.tyliu, jinghui.liu, sernia.zhou,
	reimu

Y’all stank nasty bitch ass niggas don’t have nothing else to say?

What now mother fucker is it past your bedtimes?

Go society a favor …..go to the nearest bridge…and jump in it.

Y’all can go continue your conversation six feet under. You sick stupid fuck.


> On Jul 23, 2022, at 9:32 PM, Vee Page <takeiteasy27@icloud.com> wrote:
> 
> No problem!!!
> I forget to tell them. It’s okay though! 👌👍
> 😚😚😚😚😚😚😚😚😚😚😚😚😚😚☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️☺️
> I’m blushing! Last night was fun.
> 
>> On Jul 23, 2022, at 9:30 PM, Vanessa Page <Vebpe@outlook.com> wrote:
>> 
>> 🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰🥰😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😚😍😚😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍
>> 
>> Omg thank you Janika!
>> 
>> I’m glad to see everything is okay just tell them next time!
>> 
>> Love ya babes!
>> 
>>>> On Jul 23, 2022, at 9:27 PM, Zhou Yanjie <zhouyanjie@wanyeetech.com> wrote:
>>> 
>>> Hi Tomasz,
>>> 
>>>>> On 2022/7/23 下午10:47, Tomasz Maciej Nowak wrote:
>>>> W dniu 22.07.2022 o 18:48, 周琰杰 (Zhou Yanjie) pisze:
>>>>> 1.Use the spi-mem poll status APIs in SPI-NOR to reduce CPU load.
>>>>> 2.Add SFC support for the X1000 SoC, the X1600 SoC, and the X2000 SoC from Ingenic.
>>>>> 
>>>>> Liu Jinghui and Aidan MacDonald provided a lot of assistance during the development of this driver.
>>>>> 
>>>>> 周琰杰 (Zhou Yanjie) (3):
>>>>> mtd: spi-nor: Use the spi-mem poll status APIs.
>>>>> dt-bindings: SPI: Add Ingenic SFC bindings.
>>>>> SPI: Ingenic: Add SFC support for Ingenic SoCs.
>>>>> 
>>>>> .../devicetree/bindings/spi/ingenic,sfc.yaml       |  64 ++
>>>>> drivers/mtd/spi-nor/core.c                         |  42 +-
>>>>> drivers/spi/Kconfig                                |   9 +
>>>>> drivers/spi/Makefile                               |   1 +
>>>>> drivers/spi/spi-ingenic-sfc.c                      | 662 +++++++++++++++++++++
>>>>> 5 files changed, 768 insertions(+), 10 deletions(-)
>>>>> create mode 100644 Documentation/devicetree/bindings/spi/ingenic,sfc.yaml
>>>>> create mode 100755 drivers/spi/spi-ingenic-sfc.c
>>>>> 
>>>> Even tough it's still early in revision process, I'll add my
>>>> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
>>>> 
>>>> The test was performed with Damai DM6291A SoC which is a Ingenic X1000 IP
>>>> but with 256 MiB RAM. No bugs yet observed on my side.
>>> 
>>> 
>>> Thanks for you test!
>>> 
>>> 
>>>> 
>>> 
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, other threads:[~2022-07-26  6:13 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-22 16:48 [PATCH 0/3] Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
2022-07-22 16:48 ` [PATCH 1/3] mtd: spi-nor: Use the spi-mem poll status APIs 周琰杰 (Zhou Yanjie)
2022-07-23  8:30   ` Sergey Shtylyov
2022-07-22 16:48 ` [PATCH 2/3] dt-bindings: SPI: Add Ingenic SFC bindings 周琰杰 (Zhou Yanjie)
2022-07-22 17:46   ` Krzysztof Kozlowski
2022-07-23 16:50     ` Zhou Yanjie
2022-07-23 17:43       ` Krzysztof Kozlowski
2022-07-23 18:47         ` Mike Yang
2022-07-23 19:27           ` Mark Brown
2022-07-23 20:07             ` Krzysztof Kozlowski
2022-07-23 20:49               ` Mike Yang
2022-07-24 15:33                 ` Zhou Yanjie
2022-07-25 18:30                 ` Rob Herring
2022-07-23 20:05           ` Krzysztof Kozlowski
2022-07-24 14:52             ` Zhou Yanjie
2022-07-22 22:44   ` Rob Herring
2022-07-22 16:48 ` [PATCH 3/3] SPI: Ingenic: Add SFC support for Ingenic SoCs 周琰杰 (Zhou Yanjie)
2022-07-22 18:07   ` Krzysztof Kozlowski
2022-07-23 16:53     ` Zhou Yanjie
2022-07-22 18:38   ` Mark Brown
2022-07-23 17:06     ` Zhou Yanjie
2022-07-23 19:32       ` Mark Brown
2022-07-24  1:24         ` Zhou Yanjie
2022-07-22 20:03   ` Paul Cercueil
2022-07-23 17:26     ` Zhou Yanjie
2022-07-23 20:24       ` Paul Cercueil
2022-07-24 15:29         ` Zhou Yanjie
2022-07-23 15:15   ` Christophe JAILLET
2022-07-23 15:15     ` Christophe JAILLET
2022-07-24  1:22     ` Zhou Yanjie
2022-07-24  0:43   ` kernel test robot
2022-07-24  1:28     ` Vanessa Page
2022-07-23 14:47 ` [PATCH 0/3] " Tomasz Maciej Nowak
2022-07-24  1:25   ` Zhou Yanjie
2022-07-24  1:28     ` Vanessa Page
2022-07-24  1:28     ` Vanessa Page
2022-07-24  1:30     ` Vanessa Page
2022-07-24  1:32       ` Vee Page
2022-07-26  6:13         ` Vee Page

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).