[PATCH v2 0/2] usb : phy: Add USB PHY support on Intel LGM SoC
The USB PHY provides the optimized for low power dissipation while active, idle, or on standby. Requires minimal external components, a single resistor, for best operation. Supports 10/5-Gbps high-speed data transmission rates through 3-m USB 3.x cable --- v2: - Address Phillip's review comments - replace devm_reset_control_get() by devm_reset_control_get_exclusive() - re-design the assert and deassert fucntion calls as per review comments - address kbuild bot warnings - add the comments v1: - initial version --- dt-bindings: usb: Add USB PHY support for Intel LGM SoC v2: - No Change v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: usb: Add USB PHY support for Intel LGM SoC usb: phy: Add USB3 PHY support for Intel LGM SoC .../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-lgm-usb.c | 280 + 4 files changed, 345 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml create mode 100644 drivers/usb/phy/phy-lgm-usb.c -- 2.11.0
Re: [PATCH v1 2/2] usb: phy: Add USB3 PHY support for Intel LGM SoC
Hi Philipp, Thanks for the review comments... On 9/6/2020 8:14 pm, Philipp Zabel wrote: + + for (i = 0; i < ARRAY_SIZE(CTL_RESETS); i++) + reset_control_deassert(resets[i]); + /* Need to wait at least 20us before de-assert the PHY */ + usleep_range(20, 100); This waits 20us after de-asserting the reset, not before. Is this in the correct place? This is correct place , but the above mentioned comments are wrong, need to re-write the comments as below... /* out-of-band reset of the controller after PHY reset * will cause controller malfunctioning, so should use in-bandcontroller * reset only and leave the controller de-asserted here. */ for (i = 0; i < ARRAY_SIZE(CTL_RESETS); i++) reset_control_deassert(resets[i]); /* Need to wait at least 20us after de-assert the PHY */ usleep_range(20, 100); Regards Vadivel
Re: [PATCH v1 2/2] usb: phy: Add USB3 PHY support for Intel LGM SoC
Hi Philipp,
Thank you very much for review comments and your time...
On 9/6/2020 8:14 pm, Philipp Zabel wrote:
+
+ for (i = 0; i < ARRAY_SIZE(CTL_RESETS); i++) {
+ resets[i] = devm_reset_control_get(dev, CTL_RESETS[i]);
Please use devm_reset_control_get_exclusive() instead.
Noted, will use it.
+ if (IS_ERR(resets[i])) {
+ dev_err(dev, "%s reset not found\n", CTL_RESETS[i]);
+ return PTR_ERR(resets[i]);
+ }
+ reset_control_assert(resets[i]);
+ }
You should request all reset controls first, and only then start
asserting / deasserting, otherwise you may end up with partially
asserted resets in case a later reset control is not found.
Agreed!, re-write the assert/de-assert logic as you have suggested.
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++) {
+ ta->resets[i] = devm_reset_control_get(dev, PHY_RESETS[i]);
Same as above.
+ if (IS_ERR(ta->resets[i])) {
+ dev_err(dev, "%s reset not found\n", PHY_RESETS[i]);
+ return PTR_ERR(ta->resets[i]);
+ }
+ reset_control_assert(ta->resets[i]);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(CTL_RESETS); i++)
+ reset_control_deassert(resets[i]);
+ /* Need to wait at least 20us before de-assert the PHY */
+ usleep_range(20, 100);
This waits 20us after de-asserting the reset, not before. Is this in the
correct place?
yes, you are right, it's in wrong place, Thanks!
Regards
Vadivel
[PATCH v1 1/2] dt-bindings: usb: Add USB PHY support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add the dt-schema to support USB PHY on Intel LGM SoC
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
b/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
new file mode 100644
index ..0fc76cd23774
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,lgm-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM USB PHY Device Tree Bindings
+
+maintainers:
+ - Vadivel Murugan Ramuthevar
+
+properties:
+ compatible:
+const: intel,lgm-usb-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ resets:
+items:
+ - description: USB PHY and Host controller reset
+ - description: APB BUS reset
+ - description: General Hardware reset
+
+ reset-names:
+items:
+ - const: phy
+ - const: apb
+ - const: phy31
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+usb_phy: usb_phy@e7e0 {
+compatible = "intel,lgm-usb-phy";
+reg = <0xe7e0 0x1>;
+clocks = < 153>;
+resets = < 0x70 0x24>,
+ < 0x70 0x26>,
+ < 0x70 0x28>;
+reset-names = "phy", "apb", "phy31";
+};
--
2.11.0
[PATCH v1 2/2] usb: phy: Add USB3 PHY support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add support for USB PHY on Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/phy-lgm-usb.c | 269 ++
3 files changed, 281 insertions(+)
create mode 100644 drivers/usb/phy/phy-lgm-usb.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 4b3fa78995cf..95f2e737d663 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -192,4 +192,15 @@ config JZ4770_PHY
This driver provides PHY support for the USB controller found
on the JZ4770 SoC from Ingenic.
+config USB_LGM_PHY
+ tristate "INTEL Lightning Mountain USB PHY Driver"
+ depends on USB_SUPPORT
+ select USB_PHY
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
+ help
+ Enable this to support Intel DWC3 PHY USB phy. This driver provides
+ interface to interact with USB GEN-II and USB 3.x PHY that is part
+ of the Intel network SOC.
+
endmenu
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b352bdbe8712..ef5345164e10 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_USB_ULPI)+= phy-ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= phy-ulpi-viewport.o
obj-$(CONFIG_KEYSTONE_USB_PHY) += phy-keystone.o
obj-$(CONFIG_JZ4770_PHY) += phy-jz4770.o
+obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
diff --git a/drivers/usb/phy/phy-lgm-usb.c b/drivers/usb/phy/phy-lgm-usb.c
new file mode 100644
index ..66cb327b7b71
--- /dev/null
+++ b/drivers/usb/phy/phy-lgm-usb.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel LGM USB PHY driver
+ *
+ * Copyright (C) 2020 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CTRL1_OFFSET 0x14
+#define SRAM_EXT_LD_DONE BIT(25)
+#define SRAM_INIT_DONE BIT(26)
+
+#define TCPC_OFFSET0x1014
+#define TCPC_MUX_CTL GENMASK(1, 0)
+#define MUX_NC 0
+#define MUX_USB1
+#define MUX_DP 2
+#define MUX_USBDP 3
+#define TCPC_FLIPPED BIT(2)
+#define TCPC_LOW_POWER_EN BIT(3)
+#define TCPC_VALID BIT(4)
+#define TCPC_DISCONN \
+ (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_NC) | TCPC_LOW_POWER_EN)
+
+static const char *const PHY_RESETS[] = { "phy31", "phy", };
+static const char *const CTL_RESETS[] = { "apb", "ctrl", };
+
+struct tca_apb {
+ struct reset_control *resets[ARRAY_SIZE(PHY_RESETS)];
+ struct regulator *vbus;
+ struct work_struct wk;
+ struct usb_phy phy;
+
+ bool phy_initialized;
+ bool connected;
+};
+
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+ union extcon_property_value property;
+ int ret;
+
+ ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+ if (ret) {
+ dev_err(ta->phy.dev, "no polarity property from extcon\n");
+ return false;
+ }
+
+ *flipped = property.intval;
+
+ return *flipped;
+}
+
+static int phy_init(struct usb_phy *phy)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ void __iomem *ctrl1 = phy->io_priv + CTRL1_OFFSET;
+ int val, ret, i;
+
+ if (ta->phy_initialized)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+ reset_control_deassert(ta->resets[i]);
+
+ ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE,
+10, 10 * 1000);
+ if (IS_ERR(ret)) {
+ dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
+ return PTR_ERR(ret);
+ }
+
+ writel(readl(ctrl1) | SRAM_EXT_LD_DONE, ctrl1);
+
+ ta->phy_initialized = true;
+ if (!ta->phy.edev)
+ return phy->set_vbus(phy, true);
+
+ schedule_work(>wk);
+
+ return 0;
+}
+
+static void phy_shutdown(struct usb_phy *phy)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ int i;
+
+ if (!ta->phy_initialized)
+ return;
+
+ ta->phy_initialized = false;
+ flush_work(>wk);
+ ta->phy.set_vbus(>phy, false);
+ if (ta->connected) {
+ ta->connected = false;
+ writel(TCPC_DISCONN, ta->phy.io_priv + TCPC_OFFSET);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+ reset_control_assert(ta->resets[i]);
+}
+
+static int phy_set_vbus(struct usb_phy *phy, int on)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ int ret = 0;
+
+ if
[PATCH v1 0/2] usb : phy: Add USB PHY support on Intel LGM SoC
The USB PHY provides the optimized for low power dissipation while active, idle, or on standby. Requires minimal external components, a single resistor, for best operation. Supports 10/5-Gbps high-speed data transmission rates through 3-m USB 3.x cable Ramuthevar Vadivel Murugan (2): dt-bindings: usb: Add USB PHY support for Intel LGM SoC usb: phy: Add USB3 PHY support for Intel LGM SoC .../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-lgm-usb.c | 269 + 4 files changed, 334 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml create mode 100644 drivers/usb/phy/phy-lgm-usb.c -- 2.11.0
Re: FATAL: drivers/phy/intel/phy-intel-emmc: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_of___device_table=512.
Hi, On 8/6/2020 10:23 am, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: af7b4801030c07637840191c69eb666917e4135d commit: 9227942383307f97fa6992416f73af4a23ef972c phy: intel-lgm-emmc: Add support for eMMC PHY date: 5 months ago config: x86_64-randconfig-a011-20200607 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project e429cffd4f228f70c1d9df0e5d77c08590dd9766) 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 # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git checkout 9227942383307f97fa6992416f73af4a23ef972c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/intel/phy-intel-emmc.o see include/linux/module.h for more information FATAL: drivers/phy/intel/phy-intel-emmc: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_of___device_table=512. Fix definition of struct of_device_id in mod_devicetable.h Thanks for the report! Noted, will fix it. Regards Vadivel --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v11 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..564d28978943 --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,747 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
[PATCH v11 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 99 ++
1 file changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..313daec4d783
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand
+
+ reg:
+maxItems: 6
+
+ reg-names:
+items:
+ - const: ebunand
+ - const: hsnand
+ - const: nand_cs0
+ - const: nand_cs1
+ - const: addr_sel0
+ - const: addr_sel1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - dmas
+ - dma-names
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0", "addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+nand-ecc-mode = "hw";
+ };
+};
+
+...
--
2.11.0
[PATCH v11 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Boris, Andy, Arnd and Rob for the review comments and suggestions. --- v11: - No Change v10: - No Change v9: - No change v8: - fix the kbuild bot warnings - correct the typo's v7: - indentation issue is fixed - add error check for retrieve the resource from dt v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - add MIPS maintainers and xway_nand driver author in CC v1: - initial version dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC --- v11: - Fixed the compatible issue with example 10: - fix bot errors v9: - Rob's review comments address - dual licensed - compatible change - add reg-names - drop clock-names and clock-cells - correct typo's v8: No change v7: - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - add the example in YAML file v4: - No change v3: - No change v2: YAML compatible string update to intel, lgm-nand-controller v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 99 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 + 4 files changed, 855 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
Re: [PATCH v10 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob, On 30/5/2020 3:31 am, Rob Herring wrote: On Thu, May 28, 2020 at 11:39:28PM +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 ++ 1 file changed, 93 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml new file mode 100644 index ..afecc9920e04 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id:http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml# +$schema:http://devicetree.org/meta-schemas/core.yaml# + +title: Intel LGM SoC NAND Controller Device Tree Bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Ramuthevar Vadivel Murugan + +properties: + compatible: +const: intel,lgm-nand-controller Doesn't match the example. Thank you for the review comments... if we add the compatible = intel,lgm-nand-controller it throws an error like below.. /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: '#address-cells', '#size-cells' do not match any of the regexes: '^nand@[a-f0-9]+$', 'pinctrl-[0-9]+' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: nand@0: '#address-cells', '#size-cells', 'nand-on-flash-bbt' do not match any of the regexes: 'pinctrl-[0-9]+' referred from this file :Documentation/devicetree/bindings/mtd/nand-controller.yaml fixed the compatible and example doesn't match issue. Regards Vadivel
[PATCH v10 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 ++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..afecc9920e04
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 6
+
+ reg-names:
+items:
+ - const: ebunand
+ - const: hsnand
+ - const: nand_cs0
+ - const: nand_cs1
+ - const: addr_sel0
+ - const: addr_sel1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0", "addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
[PATCH v10 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Boris, Andy, Arnd and Rob for the review comments and suggestions. --- v10: - No Change v9: - No change v8: - fix the kbuild bot warnings - correct the typo's v7: - indentation issue is fixed - add error check for retrieve the resource from dt v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - add MIPS maintainers and xway_nand driver author in CC v1: - initial version dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC --- v10: - fix bot errors v9: - Rob's review comments address - dual licensed - compatible change - add reg-names - drop clock-names and clock-cells - correct typo's v8: No change v7: - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - add the example in YAML file v4: - No change v3: - No change v2: YAML compatible string update to intel, lgm-nand-controller v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 + 4 files changed, 849 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
[PATCH v10 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..564d28978943 --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,747 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
[PATCH v9 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 ++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..afecc9920e04
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 6
+
+ reg-names:
+items:
+ - const: ebunand
+ - const: hsnand
+ - const: nand_cs0
+ - const: nand_cs1
+ - const: addr_sel0
+ - const: addr_sel1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0", "addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
[PATCH v9 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Boris, Andy, Arnd and Rob for the review comments and suggestions. --- v10: - No Change v9: - No change v8: - fix the kbuild bot warnings - correct the typo's v7: - indentation issue is fixed - add error check for retrieve the resource from dt v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - add MIPS maintainers and xway_nand driver author in CC v1: - initial version dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC --- v10: - fix bot errors v9: - Rob's review comments address - dual licensed - compatible change - add reg-names - drop clock-names and clock-cells - correct typo's v8: No change v7: - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - add the example in YAML file v4: - No change v3: - No change v2: YAML compatible string update to intel, lgm-nand-controller v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 + 4 files changed, 849 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
[PATCH v9 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..564d28978943 --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,747 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
Re: [PATCH v9 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob, On 28/5/2020 10:06 pm, Rob Herring wrote: On Thu, 28 May 2020 13:12:10 +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 ++ 1 file changed, 93 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: '#address-cells', '#size-cells' do not match any of the regexes: '^nand@[a-f0-9]+$', 'pinctrl-[0-9]+' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: nand@0: '#address-cells', '#size-cells', 'nand-on-flash-bbt' do not match any of the regexes: 'pinctrl-[0-9]+' See https://patchwork.ozlabs.org/patch/1299399 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. Thank you!!! Oh my bad, used old dtc compiler path and didn't see the error, will fix. Regards Vadivel
[PATCH v9 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..564d28978943 --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,747 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
[PATCH v9 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 ++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..8672d03b4e6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand
+
+ reg:
+maxItems: 6
+
+ reg-names:
+items:
+ - const: ebunand
+ - const: hsnand
+ - const: nand_cs0
+ - const: nand_cs1
+ - const: addr_sel0
+ - const: addr_sel1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0", "addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
[PATCH v9 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Boris, Andy, Arnd and Rob for the review comments and suggestions. --- v9: No change v8: - fix the kbuild bot warnings - correct the typo's v7: - indentation issue is fixed - add error check for retrieve the resource from dt v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - add MIPS maintainers and xway_nand driver author in CC v1: - initial version dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC --- v9: - Rob's review comments address - dual licensed - compatible change - add reg-names - drop clock-names and clock-cells - correct typo's v8: No change v7: - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - add the example in YAML file v4: - No change v3: - No change v2: YAML compatible string update to intel, lgm-nand-controller v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 93 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 + 4 files changed, 849 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
Re: [RESENDPATCH v8 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob,
Thank you very much for the review comments...
On 27/5/2020 4:43 am, Rob Herring wrote:
On Wed, May 20, 2020 at 08:06:20AM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 ++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..cd4e983a449e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
Still not dual licensed.
oh sorry, will update.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
Still doesn't match the example. And the example will fail when it does.
Noted, will change it.
+
+ reg:
+items:
+ - description: ebunand registers
+ - description: hsnand registers
+ - description: nand_cs0 external flash access
+ - description: nand_cs1 external flash access
+ - description: addr_sel0 memory region enable and access
+ - description: addr_sel1 memory region enable and access
reg-names?
should be -const: ebunand instead added description with register
name , will keep "-const: ebunand ..etc"
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
Not documented or should be dropped.
Yes, will drop it.
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0","addr_sel1";
Not documented. And needs a space after the ','.
Good catch, Thanks
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
Should be removed?
sure, will remove it
Regards
Vadivel
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
Re: [PATCH v2 1/1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
Hi Mark, On 21/5/2020 8:37 pm, Mark Brown wrote: On Thu, May 21, 2020 at 08:34:43PM +0800, Ramuthevar, Vadivel MuruganX wrote: On 21/5/2020 8:20 pm, Mark Brown wrote: I mean that any changes to the bindings ought to be split out into separate patches, if there's multiple changes it may make sense for there to be multiple patches. Got it, we do not have multiple changes since it is new YAML file. in case if we feel anything to be added , we add as separate patches. If this is just a conversion to YAML then your changelog is wildly inaccurate and needs to be improved, your changelog says you are adding new things. Yes , You are right, just conversion only, over that adding/modifying few of the properties like compatible and node name in the example..etc Sure I will make a multiple patches , Thanks! Regards Vadivel
Re: [PATCH v2 1/1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
Hi Mark, On 21/5/2020 8:20 pm, Mark Brown wrote: On Thu, May 21, 2020 at 08:14:04PM +0800, Ramuthevar, Vadivel MuruganX wrote: On 21/5/2020 6:56 pm, Mark Brown wrote: That doesn't address either of the issues. The removal of the old bindings and addition of the YAML ones needs to be in a single patch doing that conversion. What I'm suggesting should be done separately is whatever changes to the semantics of the bindings you are (according to your changelog) doing. You mean semantics of the binding as a single patch you are suggesting me, right? , Thanks! I mean that any changes to the bindings ought to be split out into separate patches, if there's multiple changes it may make sense for there to be multiple patches. Got it, we do not have multiple changes since it is new YAML file. in case if we feel anything to be added , we add as separate patches. Thanks! Regards Vadivel
Re: [PATCH v2 1/1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
Hi Mark, On 21/5/2020 6:56 pm, Mark Brown wrote: On Thu, May 21, 2020 at 10:18:26AM +0800, Ramuthevar, Vadivel MuruganX wrote: On 20/5/2020 8:43 pm, Mark Brown wrote: On Wed, May 20, 2020 at 08:36:12PM +0800, Ramuthevar,Vadivel MuruganX wrote: .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 --- .../devicetree/bindings/spi/cdns,qspi-nor.yaml | 133 + The changelog says this is adding a new binding but the actual change is mostly a conversion to YAML. Please split the additions out into a separate change, ideally doing that before the conversion since there is a backlog on review of YAML conversions. Initially was sending the only YAML file alone, then reviewers suggest to me do this way so I did, next by split the patches like below... 1. remove the cadence-quadspi.txt (patch1) 2. convert txt to YAML (patch2) That doesn't address either of the issues. The removal of the old bindings and addition of the YAML ones needs to be in a single patch doing that conversion. What I'm suggesting should be done separately is whatever changes to the semantics of the bindings you are (according to your changelog) doing. You mean semantics of the binding as a single patch you are suggesting me, right? , Thanks! Regards Vadivel
Re: [PATCH v2 1/1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
Hi Mark, Thank you for the review comments... On 20/5/2020 8:43 pm, Mark Brown wrote: On Wed, May 20, 2020 at 08:36:12PM +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add dt-bindings documentation for Cadence-QSPI controller to support spi based flash memories. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 --- .../devicetree/bindings/spi/cdns,qspi-nor.yaml | 133 + The changelog says this is adding a new binding but the actual change is mostly a conversion to YAML. Please split the additions out into a separate change, ideally doing that before the conversion since there is a backlog on review of YAML conversions. Initially was sending the only YAML file alone, then reviewers suggest to me do this way so I did, next by split the patches like below... 1. remove the cadence-quadspi.txt (patch1) 2. convert txt to YAML (patch2) Regards Vadivel
[PATCH v2 1/1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
From: Ramuthevar Vadivel Murugan
Add dt-bindings documentation for Cadence-QSPI controller to support
spi based flash memories.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 67 ---
.../devicetree/bindings/spi/cdns,qspi-nor.yaml | 133 +
2 files changed, 133 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = < QSPI_RESET>, < QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
new file mode 100644
index ..1c15acc184b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Cadence QSPI Flash Controller support
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ Binding Documentation for Cadence QSPI controller,This controller is
+ present in the Intel LGM, Altera SoCFPGA and TI SoCs and this driver
+ has been tested On Intel's LGM SoC.
+
+properties:
+ compatible:
+ enum:
+ - cdns,qspi-nor
+ - ti,k2g-qspi
+ - ti,am654-ospi
+ - intel,lgm-qspi
+
+ reg:
+items:
+ - description:
+ The first entry is the address and length of
+ the controller register set.
+ - description:
+ The second entry is
Re: [PATCH v1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
Hi Rob,
Thank you very much for the review comments...
On 20/5/2020 2:44 am, Rob Herring wrote:
On Tue, May 12, 2020 at 08:49:19AM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add dt-bindings documentation for Cadence-QSPI controller to support
spi based flash memories.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 67 ---
.../devicetree/bindings/spi/cdns,qspi-nor.yaml | 127 +
2 files changed, 127 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = < QSPI_RESET>, < QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
new file mode 100644
index ..28112b38e6a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Cadence QSPI Flash Controller support
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ Binding Documentation for Cadence QSPI controller,This controller is
+ present in the Intel LGM, Al
[RESENDPATCH v8 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..564d28978943 --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,747 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
[RESENDPATCH v8 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Boris, Andy and Arnd for the review comments and suggestions. --- v8: - fix the kbuild bot warnings - correct the typo's v7: - indentation issue is fixed - add error check for retrieve the resource from dt - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written - add the example in YAML file v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - YAML compatible string update to intel, lgm-nand-controller - add MIPS maintainers and xway_nand driver author in CC v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 + 4 files changed, 847 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
[RESENDPATCH v8 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 ++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..cd4e983a449e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+items:
+ - description: ebunand registers
+ - description: hsnand registers
+ - description: nand_cs0 external flash access
+ - description: nand_cs1 external flash access
+ - description: addr_sel0 memory region enable and access
+ - description: addr_sel1 memory region enable and access
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0","addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
Re: [PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob, On 19/5/2020 2:27 am, Rob Herring wrote: On Thu, May 14, 2020 at 8:08 PM Ramuthevar, Vadivel MuruganX wrote: Hi Rob, On 14/5/2020 8:57 pm, Rob Herring wrote: On Wed, 13 May 2020 18:46:14 +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 83 ++ 1 file changed, 83 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: 'dmas' is a dependency of 'dma-names' See https://patchwork.ozlabs.org/patch/1289160 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. Thank you very much for review comments... I didn't find build errors, successfully built. You need to build without DT_SCHEMA_FILES set or be on 5.7-rc (you should be on a current -rcX at least for any patch submission). This comes from the core schema. Yes, reproduced the issue as above mentioned and fixed it. Thanks! Regards Vadivel Rob
[PATCH v8 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 743 +++ 3 files changed, 752 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..0e1079a4fbb5 --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,743 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
[PATCH v8 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 ++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..cd4e983a449e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+items:
+ - description: ebunand registers
+ - description: hsnand registers
+ - description: nand_cs0 external flash access
+ - description: nand_cs1 external flash access
+ - description: addr_sel0 memory region enable and access
+ - description: addr_sel1 memory region enable and access
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0","addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
[PATCH v8 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Boris, Andy and Arnd for the review comments and suggestions. --- v8: - fix the kbuild bot warnings - correct the typo's v7: - indentation issue is fixed - add error check for retrieve the resource from dt - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written - add the example in YAML file v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - YAML compatible string update to intel, lgm-nand-controller - add MIPS maintainers and xway_nand driver author in CC v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 743 + 4 files changed, 843 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Arnd, Andy, On 15/5/2020 10:30 pm, Arnd Bergmann wrote: On Fri, May 15, 2020 at 4:25 PM Andy Shevchenko wrote: On Fri, May 15, 2020 at 4:48 PM kbuild test robot wrote: sparse warnings: (new ones prefixed by >>) drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: sparse: incorrect type in argument 1 (different base types) @@expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@ drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse:expected unsigned int val drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse:got restricted __be32 [assigned] [usertype] reg drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: sparse: incorrect type in argument 1 (different base types) @@expected unsigned int val @@got restricted __be32 [assignedunsigned int val @@ drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse:expected unsigned int val drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse:got restricted __be32 [assigned] [usertype] reg 440 reg = cpu_to_be32(*pdata++); > 441 writel(reg, ebu_host->hsnand + HSNAND_CMSG_0); 442 443 reg = cpu_to_be32(*pdata); 444 writel(reg, ebu_host->hsnand + HSNAND_CMSG_1); On BE: cpu_to_be32 -> no-op writel() -> converts reg to LE On LE: cpu_to_be32 -> converts to BE writel() -> no-op (in terms of conversion) Seems to me that the proper API (if above is intended) should be swab32(). But something tells me that above is broken (or my understanding is wrong). iowrite_be32() is the correct way to store word into a big-endian mmio register, if that is the intention here. Thank you for suggestions to use iowrite32be(), it suits exactly. Regards Vadivel Arnd
[PATCH v7 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 ++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..cd4e983a449e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+items:
+ - description: ebunand registers
+ - description: hsnand registers
+ - description: nand_cs0 external flash access
+ - description: nand_cs1 external flash access
+ - description: addr_sel0 memory region enable and access
+ - description: addr_sel1 memory region enable and access
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>,
+<0x1740 0x4>,
+<0x17c0 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0","addr_sel1";
+ clocks = < 125>;
+ dmas = < 8>, < 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
[PATCH v7 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. --- v7: - indentation issue is fixed - add error check for retrieve the resource from dt - Rob's review comments addressed - dt-schema build issue fixed with upgraded dt-schema v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written - add the example in YAML file v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - YAML compatible string update to intel, lgm-nand-controller - add MIPS maintainers and xway_nand driver author in CC v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 91 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 748 + 4 files changed, 848 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
[PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 748 +++ 3 files changed, 757 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..d2d53c32ca9c --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,748 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
Re: [PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob, On 15/5/2020 10:08 am, Ramuthevar, Vadivel MuruganX wrote: Hi Rob, On 14/5/2020 8:57 pm, Rob Herring wrote: On Wed, 13 May 2020 18:46:14 +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml | 83 ++ 1 file changed, 83 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: 'dmas' is a dependency of 'dma-names' See https://patchwork.ozlabs.org/patch/1289160 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.Sure, will check and re-submit, Thanks! Regards Vadivel
Re: [PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob, On 14/5/2020 8:57 pm, Rob Herring wrote: On Wed, 13 May 2020 18:46:14 +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 83 ++ 1 file changed, 83 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f0: 'dmas' is a dependency of 'dma-names' See https://patchwork.ozlabs.org/patch/1289160 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. Thank you very much for review comments... I didn't find build errors, successfully built. Regards Vadivel
Re: [PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
Hi Rob,
Thank you for the review comments...
On 14/5/2020 9:03 pm, Rob Herring wrote:
On Wed, May 13, 2020 at 06:46:14PM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 83 ++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..d9e0df8553fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: GPL-2.0
Dual license new bindings please:
(GPL-2.0-only OR BSD-2-Clause)
Noted.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 1
Looks like you have 4 or 6 entries, not 1. Need to define what each one
is.
Sure, will define it.
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+enum:
+ - rx
+ - tx
This defines a single entry. I believe you want:
items:
- const: tx
- const: rx
Yes, Thanks!
+
+ pinctrl-names: true
No need for this. Tools add pinctrl properties.
will drop it.
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,nand-controller";
Doesn't match the schema.
Noted, will update the schema name.
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>;
Is it 4 or 6 entries?
yes, will update.
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0","addr_sel1";
Not documented.
Noted, will document it.
+ clocks = < 125>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
This is a clock provider too?
Yes, it is getting clock from CGU for nand-controller.
Regards
Vadivel
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
Re: [PATCH v6 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Andy,
On 13/5/2020 11:35 pm, Andy Shevchenko wrote:
On Wed, May 13, 2020 at 06:34:05PM +0300, Andy Shevchenko wrote:
On Wed, May 13, 2020 at 06:46:15PM +0800, Ramuthevar,Vadivel MuruganX wrote:
...
+static int ebu_nand_remove(struct platform_device *pdev)
+{
+ struct ebu_nand_controller *ebu_host = platform_get_drvdata(pdev);
+
+ if (ebu_host) {
How it can be NULL here?
+ mtd_device_unregister(nand_to_mtd(_host->chip));
+ nand_cleanup(_host->chip);
+ ebu_nand_disable(_host->chip);
+
+ if (ebu_host->dma_rx || ebu_host->dma_tx)
This is duplicate and thus redundant.
Let me check and update, Thanks!
Regards
Vadivel
+ ebu_dma_cleanup(ebu_host);
+
+ clk_disable_unprepare(ebu_host->clk);
+ }
+
+ return 0;
+}
Re: [PATCH v6 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Andy,
On 13/5/2020 11:34 pm, Andy Shevchenko wrote:
On Wed, May 13, 2020 at 06:46:15PM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
This patch adds the new IP of Nand Flash Controller(NFC) support
on Intel's Lightning Mountain(LGM) SoC.
DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported. Data register used to support the read/write
operation from/to device.
NAND controller driver implements ->exec_op() to replace legacy hooks,
these specific call-back method to execute NAND operations.
...
+static int ebu_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct ebu_nand_controller *ebu_host;
+ struct nand_chip *nand;
+ struct mtd_info *mtd;
+ struct resource *res;
+ char *resname;
+ int ret, i;
+ u32 reg;
+
+ ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
+ if (!ebu_host)
+ return -ENOMEM;
+
+ ebu_host->dev = dev;
+ nand_controller_init(_host->controller);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
+ ebu_host->ebu = devm_ioremap_resource(>dev, res);
devm_platform_ioremap_resource_byname
+ if (IS_ERR(ebu_host->ebu))
+ return PTR_ERR(ebu_host->ebu);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
+ ebu_host->hsnand = devm_ioremap_resource(>dev, res);
devm_platform_ioremap_resource_byname
Thanks for the review comments
As Boris suggested , split into 2 API's.
+ if (IS_ERR(ebu_host->hsnand))
+ return PTR_ERR(ebu_host->hsnand);
+
+ ret = device_property_read_u32(dev, "nand,cs", );
+ if (ret) {
+ dev_err(dev, "failed to get chip select: %d\n", ret);
+ return ret;
+ }
+ ebu_host->cs_num = reg;
+
+ for (i = 0; i < MAX_CS; i++) {
+ resname = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", i);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ resname);
if res is NULL?
Noted.
+ ebu_host->cs[i].chipaddr = devm_ioremap_resource(dev, res);
+ ebu_host->cs[i].nand_pa = res->start;
+ if (IS_ERR(ebu_host->cs[i].chipaddr))
+ return PTR_ERR(ebu_host->cs[i].chipaddr);
Something happened with ordering / indentation along these lines...
Noted.
+ }
+
+ for (i = 0; i < MAX_CS; i++) {
+ resname = devm_kasprintf(dev, GFP_KERNEL, "addr_sel%d", i);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ resname);
if res is NULL?
Noted.
Regards
Vadivel
+ ebu_host->cs[i].addr_sel = res->start;
+ writel(ebu_host->cs[i].addr_sel | EBU_ADDR_MASK(5) |
+ EBU_ADDR_SEL_REGEN, ebu_host->ebu + EBU_ADDR_SEL(i));
+ }
+ return ret;
+}
...
+static int ebu_nand_remove(struct platform_device *pdev)
+{
+ struct ebu_nand_controller *ebu_host = platform_get_drvdata(pdev);
+
+ if (ebu_host) {
How it can be NULL here?
+ mtd_device_unregister(nand_to_mtd(_host->chip));
+ nand_cleanup(_host->chip);
+ ebu_nand_disable(_host->chip);
+
+ if (ebu_host->dma_rx || ebu_host->dma_tx)
+ ebu_dma_cleanup(ebu_host);
+
+ clk_disable_unprepare(ebu_host->clk);
+ }
+
+ return 0;
+}
[PATCH v6 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thank you very much Boris for the reviews, suggestions and valuable inputs. --- v6: - update EBU_ADDR_SELx register base value build it from DT - Add tabs in in Kconfig - Rob's review comments addressed in YAML file - add addr_sel0 and addr_sel1 reg-names in YAML example v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written - add the example in YAML file v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - YAML compatible string update to intel, lgm-nand-controller - add MIPS maintainers and xway_nand driver author in CC v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 83 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 + 4 files changed, 839 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
[PATCH v6 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 747 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..75ab2afb78cf 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash controller interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..a66a0861420d --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,747 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18)
[PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 83 ++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..d9e0df8553fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+enum:
+ - rx
+ - tx
+
+ pinctrl-names: true
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+
+additionalProperties: false
+
+examples:
+ - |
+nand-controller@e0f0 {
+ compatible = "intel,nand-controller";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+"addr_sel0","addr_sel1";
+ clocks = < 125>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
Re: [PATCH v5 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support
Hi Rob,
Thank you for the review comments and your time...
On 11/5/2020 11:37 pm, Rob Herring wrote:
On Thu, May 07, 2020 at 08:15:36AM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
The $subject should some how reflect this is for this SoC.
Noted, will update.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 85 ++
1 file changed, 85 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..69b592ae62f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+enum:
+ - rx
+ - tx
+
+ pinctrl-names: true
+
+patternProperties:
+ "^pinctrl-[0-9]+$": true
Don't need the pinctrl properties. The tooling adds them.
ok, will drop.
+
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+
+additionalProperties: false
+
+examples:
+ - |
+#include
Is this applied somewhere? It's missing in my check and will break the
build.
You have already reviewed the below patch which has the file
https://lkml.org/lkml/2020/4/17/31
Regards
Vadivel
+nand-controller@e0f0 {
+ compatible = "intel,nand-controller";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1";
+ clocks = < LGM_GCLK_EBU>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
[PATCH v1] dt-bindings: spi: Add schema for Cadence QSPI Controller driver
From: Ramuthevar Vadivel Murugan
Add dt-bindings documentation for Cadence-QSPI controller to support
spi based flash memories.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/cadence-quadspi.txt| 67 ---
.../devicetree/bindings/spi/cdns,qspi-nor.yaml | 127 +
2 files changed, 127 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = < QSPI_RESET>, < QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
new file mode 100644
index ..28112b38e6a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Cadence QSPI Flash Controller support
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ Binding Documentation for Cadence QSPI controller,This controller is
+ present in the Intel LGM, Altera SoCFPGA and TI SoCs and this driver
+ has been tested On Intel's LGM SoC.
+
+properties:
+ compatible:
+ enum:
+ - cdns,qspi-nor
+ - ti,k2g-qspi
+ - ti,am654-ospi
+ - intel,lgm-qspi
+
+ reg:
+maxItems: 2
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ cdns,fifo-depth:
+description:
+ Depth of hardware FIFOs.
+allOf:
+ - $ref:
Re: [PATCH 0/6] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
Hi Vignesh, On 9/5/2020 2:54 am, Vignesh Raghavendra wrote: Vadivel, I have maintained the additional changes needed on top of this series for Intel platform that were part of your v12 series here (needs cleanup): https://github.com/r-vignesh/linux.git branch: cqspi-mig Please use above branch to test the same. Thank you for the sending the patches on behalf of, will do the cleanup. also I have already prepared YAML file , will send as separate patch. Regards Vadivel
Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, Thank you very much for the review comments and your time... On 7/5/2020 2:48 pm, Boris Brezillon wrote: > On Thu, 7 May 2020 14:38:52 +0800 > "Ramuthevar, Vadivel MuruganX" > wrote: > >> Hi Boris, >> >>Thank you very much for the review comments and your time... >> >> On 7/5/2020 2:27 pm, Boris Brezillon wrote: >>> On Thu, 7 May 2020 14:13:42 +0800 >>> "Ramuthevar, Vadivel MuruganX" >>> wrote: >>> >>>> Hi Boris, >>>> >>>> Thank you very much for the review comments and your time... >>>> >>>> On 7/5/2020 1:28 pm, Boris Brezillon wrote: >>>>> On Thu, 7 May 2020 08:15:37 +0800 >>>>> "Ramuthevar,Vadivel MuruganX" >>>>> wrote: >>>>> >>>>>> + reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); >>>>>> + writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN, >>>>>> + ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); >>>>> Seriously, did you really think I would not notice what you're doing >>>>> here? >>>> Yes , I know that you have very good understanding about this. >>>>You're reading the previous value which either contains a default >>>>> mapping or has the mapping set by the bootloader, and write it back to >>>>> the register along with a new mask and the REGEN bit set (which >>>>> BTW is wrong since you don't mask out other fields before updating >>>>> them). >>>> There is no other field get overwritten >>>>This confirms that this Core -> FPI address translation exists >>>>> and has to be set properly, so please stop lying about that. >>>> Sorry, there is no SW translation, as I have mentioned that it's >>>> optional only, for safer side , reading and writing the default values. >>> Then write EBU_ADDR_SEL_REGEN and we'll if see that works. I suspect it >>> won't. >> You mean, without reading just writing EBU_ADDR_SEL_REGEN bit alone in >> EBU_ADDR_SELx , as you said it won't work because it overwrites 0x174 >> with 0x0 values so BASE is lost. > Which confirms that this mapping has to be defined. Sure, Noted. >> either we can leave it or read & write with ORed | EBU_ADDR_SEL_REGEN > None of this is acceptable IMO. You have to build the value based on the > address translation described in the DT. Why are you so reluctant to > this approach? Agreed!, will derive the values(0x174/0x17C) to be written into these registers based on the chip select (CS0/CS1) Address_sel0_register: 0xE0F0_0020 Address_sel1_register: 0xE0F0_0024 Bits : 31...12|11...8| 7..4 |3..2| 1 | 0 flags: BASE |--| MASK | -- | MRME | REGEN BASE : 0x17400 /0x17C00 to be written into 31:12 based on the chip selection MASK: 5: bits 26:22 to included address comparison MRME: Memory Region Memory Enable REGEN: Memory Region Access Enable As you have suggested to get the above base values from DT and update in driver, will do that. Thanks! Regards Vadivel >> Please correct me if anything is wrong, Thanks! >>> >>>> The memory region to enabled that's my concern so written the same >>>> register values. >>> I don't buy that, sorry. >>> >>>> This will not be impact other fields, so please see below for reference >>>> >>>> The EBU Address Select Registers EBU_ADDR_SEL_0 to EBU_ADDSEL3 establish >>>> and control memory regions for external accesses. >>>> >>>> Reset Value: 1741H >>> See, as suspected the reset value is exactly what you expect. >> Yes , that's the reason said being optional. > Then it's not optional. It just works because you use the default > va
Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, Thank you very much for the review comments and your time... On 7/5/2020 2:27 pm, Boris Brezillon wrote: On Thu, 7 May 2020 14:13:42 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, Thank you very much for the review comments and your time... On 7/5/2020 1:28 pm, Boris Brezillon wrote: On Thu, 7 May 2020 08:15:37 +0800 "Ramuthevar,Vadivel MuruganX" wrote: + reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); + writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); Seriously, did you really think I would not notice what you're doing here? Yes , I know that you have very good understanding about this. You're reading the previous value which either contains a default mapping or has the mapping set by the bootloader, and write it back to the register along with a new mask and the REGEN bit set (which BTW is wrong since you don't mask out other fields before updating them). There is no other field get overwritten This confirms that this Core -> FPI address translation exists and has to be set properly, so please stop lying about that. Sorry, there is no SW translation, as I have mentioned that it's optional only, for safer side , reading and writing the default values. Then write EBU_ADDR_SEL_REGEN and we'll if see that works. I suspect it won't. You mean, without reading just writing EBU_ADDR_SEL_REGEN bit alone in EBU_ADDR_SELx , as you said it won't work because it overwrites 0x174 with 0x0 values so BASE is lost. either we can leave it or read & write with ORed | EBU_ADDR_SEL_REGEN Please correct me if anything is wrong, Thanks! The memory region to enabled that's my concern so written the same register values. I don't buy that, sorry. This will not be impact other fields, so please see below for reference The EBU Address Select Registers EBU_ADDR_SEL_0 to EBU_ADDSEL3 establish and control memory regions for external accesses. Reset Value: 1741H See, as suspected the reset value is exactly what you expect. Yes , that's the reason said being optional. Regards Vadivel
Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, Thank you very much for the review comments and your time... On 7/5/2020 1:28 pm, Boris Brezillon wrote: On Thu, 7 May 2020 08:15:37 +0800 "Ramuthevar,Vadivel MuruganX" wrote: + reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); + writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); Seriously, did you really think I would not notice what you're doing here? Yes , I know that you have very good understanding about this. You're reading the previous value which either contains a default mapping or has the mapping set by the bootloader, and write it back to the register along with a new mask and the REGEN bit set (which BTW is wrong since you don't mask out other fields before updating them). There is no other field get overwritten This confirms that this Core -> FPI address translation exists and has to be set properly, so please stop lying about that. Sorry, there is no SW translation, as I have mentioned that it's optional only, for safer side , reading and writing the default values. The memory region to enabled that's my concern so written the same register values. This will not be impact other fields, so please see below for reference The EBU Address Select Registers EBU_ADDR_SEL_0 to EBU_ADDSEL3 establish and control memory regions for external accesses. Reset Value: 1741H Regards Vadivel
Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi, On 7/5/2020 8:22 am, Randy Dunlap wrote: On 5/6/20 5:15 PM, Ramuthevar,Vadivel MuruganX wrote: diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..a026bec28f39 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash interfaced through the External Bus Unit. Please use one tab + 2 spaces for indentation in the line above. Thank you for the review comments, will update in the next patch-set. Regards Vadivel + comment "Misc" config MTD_SM_COMMON
[PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 741 +++ 3 files changed, 750 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..a026bec28f39 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..e9720271ce2a --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,741 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +/* 5 bits 26:22 included for comparison in the ADDR_SELx */ +#define EBU_ADDR_MASK(x) ((x) << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define HSNAND_PARA0_TYPE_ONFI BIT(18) +#define
[PATCH v5 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thank you very much Boris for the reviews, suggestions and valuable inputs. --- v5: - replace by 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' to NAND_WRITE_CMD and NAND_WRITE_ADDR - remove the unused macros - update EBU_ADDR_MASK(x) macro - update the EBU_ADDR_SELx register values to be written - add the example in YAML file v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - YAML compatible string update to intel, lgm-nand-controller - add MIPS maintainers and xway_nand driver author in CC v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add YAML for Nand Flash Controller support mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 85 +++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 741 + 4 files changed, 835 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
[PATCH v5 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 85 ++
1 file changed, 85 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index ..69b592ae62f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+properties:
+ compatible:
+const: intel,lgm-nand-controller
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ dmas:
+maxItems: 2
+
+ dma-names:
+enum:
+ - rx
+ - tx
+
+ pinctrl-names: true
+
+patternProperties:
+ "^pinctrl-[0-9]+$": true
+
+ "^nand@[a-f0-9]+$":
+type: object
+properties:
+ reg:
+minimum: 0
+maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+const: hw
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+nand-controller@e0f0 {
+ compatible = "intel,nand-controller";
+ reg = <0xe0f0 0x100>,
+<0xe100 0x300>,
+<0xe140 0x8000>,
+<0xe1c0 0x1000>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1";
+ clocks = < LGM_GCLK_EBU>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ nand@0 {
+reg = <0>;
+nand-on-flash-bbt;
+#address-cells = <1>;
+#size-cells = <1>;
+ };
+};
+
+...
--
2.11.0
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 5/5/2020 3:00 pm, Boris Brezillon wrote:
Hello Vadivel,
On Tue, 5 May 2020 13:28:58 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Ok. If I understand the SoC topology correctly it should actually be
something like that:
{
...
fpi@x {
compatible = "intel,lgm-fpi", "simple-bus";
/* You might have other ranges to define here */
ranges = <0x1600 0xe000 0x100>;
...
Sorry, we do not have fpi tree node in our dts/dtsi file instead we have
the below one.. , that also not included the major peripherals
controllers node.
/* Special part from CPU core */
core: core {
compatible = "intel,core", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ioapic1: interrupt-controller@fec0 {
#interrupt-cells = <2>;
#address-cells = <0>;
compatible = "intel,ce4100-ioapic";
interrupt-controller;
reg = <0xfec0 0x1000>;
nr_entries = <256>;
};
hpet: timer@fed0 {
compatible = "intel,ce4100-hpet";
reg = <0xfed0 0x400>;
};
lapic0: interrupt-controller@fee0 {
compatible = "intel,ce4100-lapic";
reg = <0xfee0 0x1000>;
no_pic_mode;
};
};
other than this, rest all in independent node .
But you do have an FPI bus, right? If this is the case it should be
represented.
Yes, FPI bus is slave to core which connects all the peripherals.
Or is the "intel,core" bus actually the FPI bus that you
named differently?
FPI slave bus connects to core bus by OCP bridge, so here it is named
FPI bus, but SW perspective didn't have root tree which has all
sub-nodes, as of now each peripheral has its own node.
Duh, not sure that's a good idea to hide that, especially since you
have to describe the address translation that happens when crossing the
FPI bus (the ranges thing I mentioned previously).
Thanks! for the keep reviewing.
SW Address translation is not required, after discussion with HW team ,
came to know that 0x17400 and 0x17C00 internal to the SoC.
NOC will translate 0xE1XX... to FPI address 0x17X... internally.
There is an address translation in the NOC.
0x17X... is not visible to user.
so far added hard-coded values to CS0 and CS1 is not at required.
I will change the code accordingly and sent to you.
Hm, you told me last week that writing wrong values to this register
caused the NAND controller to not work properly (you even had code that
was overwriting the dynamically calculated values by hardcoded ones, so
I suspect it indeed didn't work) and now you say this write to
EBU_ADDR_SEL() is optional?! Sorry but it's hard to believe, and I've
received so many contradictory information from you on that matter that
I can't really tell which one is correct. Not sure I want to keep
reviewing new versions of this driver in this context.
oh my bad really sorry , since last week based on the input given from
person who has worked on legacy IP, but now I have discussed with
low-level HW team and confirmed. also we don't have proper document
reference manual since it's new SoC.
Please forgive me , this shouldn't be happen once again, Thanks a lot!!
Regards
Vadivel
Regards,
Boris
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 4/5/2020 4:58 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 16:50:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 4/5/2020 3:17 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 15:15:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
Thank you very much for the prompt review and suggestions...
On 4/5/2020 3:08 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 10:02:35 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Ok. If I understand the SoC topology correctly it should actually be
something like that:
{
...
fpi@x {
compatible = "intel,lgm-fpi", "simple-bus";
/* You might have other ranges to define here */
ranges = <0x1600 0xe000 0x100>;
...
Sorry, we do not have fpi tree node in our dts/dtsi file instead we have
the below one.. , that also not included the major peripherals
controllers node.
/* Special part from CPU core */
core: core {
compatible = "intel,core", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ioapic1: interrupt-controller@fec0 {
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 4/5/2020 4:58 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 16:50:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 4/5/2020 3:17 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 15:15:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
Thank you very much for the prompt review and suggestions...
On 4/5/2020 3:08 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 10:02:35 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Ok. If I understand the SoC topology correctly it should actually be
something like that:
{
...
fpi@x {
compatible = "intel,lgm-fpi", "simple-bus";
/* You might have other ranges to define here */
ranges = <0x1600 0xe000 0x100>;
...
Sorry, we do not have fpi tree node in our dts/dtsi file instead we have
the below one.. , that also not included the major peripherals
controllers node.
/* Special part from CPU core */
core: core {
compatible = "intel,core", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ioapic1: interrupt-controller@fec0 {
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 4/5/2020 3:17 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 15:15:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
Thank you very much for the prompt review and suggestions...
On 4/5/2020 3:08 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 10:02:35 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Ok. If I understand the SoC topology correctly it should actually be
something like that:
{
...
fpi@x {
compatible = "intel,lgm-fpi", "simple-bus";
/* You might have other ranges to define here */
ranges = <0x1600 0xe000 0x100>;
...
Sorry, we do not have fpi tree node in our dts/dtsi file instead we have
the below one.. , that also not included the major peripherals
controllers node.
/* Special part from CPU core */
core: core {
compatible = "intel,core", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ioapic1: interrupt-controller@fec0 {
#interrupt-cells = <2>;
#address-cells = <0>;
compatible = "intel,ce4100-ioapic";
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
Thank you very much for the prompt review and suggestions...
On 4/5/2020 3:08 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 10:02:35 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Ok. If I understand the SoC topology correctly it should actually be
something like that:
{
...
fpi@x {
compatible = "intel,lgm-fpi", "simple-bus";
/* You might have other ranges to define here */
ranges = <0x1600 0xe000 0x100>;
...
Sorry, we do not have fpi tree node in our dts/dtsi file instead we have
the below one.. , that also not included the major peripherals
controllers node.
/* Special part from CPU core */
core: core {
compatible = "intel,core", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ioapic1: interrupt-controller@fec0 {
#interrupt-cells = <2>;
#address-cells = <0>;
compatible = "intel,ce4100-ioapic";
interrupt-controller;
reg = <0xfec0 0x1000>;
nr_entries = <256>;
};
hpet: timer@fed0 {
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
Thank you very much for the review comments and your time...
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
for the ebu-nand node in the dts file.
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100 //EBU_NAND controller
0xe100 0x300 //NAND ECC Extension access
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
This is not comes under fpi in our devicetree.
Regards
Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
Thank you very much for the review comments and giving inputs...
On 30/4/2020 8:36 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Thanks! , for the optimized and made it generic way, will update in the
next patch-set.
Regards
Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, On 30/4/2020 4:36 pm, Boris Brezillon wrote: On Thu, 30 Apr 2020 16:30:15 +0800 "Ramuthevar, Vadivel MuruganX" wrote: And now I'd like you to explain why 5 is the right value for that field (I guess that has to do with the position of the CS/ALE/CLE pins). 5 : bit 26, 25, 24, 23, 22 to be included for comparison in the That's 6 bits to me, not 5. No , 5 bits only the above case. Oops, right, sorry for the brain fart. The question is, is it the same value we have in nand_pa or it is different? Different address which is 0xE140 NAND_BASE_PHY address. Then why didn't you tell me they didn't match when I suggested to pass sorry, because you keep asking nand_pa after that only I realized that. nand_pa? So now the question is, what does this address represent? EBU-MODULE _ ___ | | ||NAND CTRL | | FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE |_| |_CS1(0x17C)_|__ | EBU_CONRTROLLER_BASE : 0xE0F0_ HSNAND_BASE: 0xE100_ NAND_CS0: 0xE140_ NAND_CS1: 0xE1C0_ MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller ) MEM_REGION_BASE_CS1: 0x17C00 Do you have a reference manual I can look at to understand what this is? We dont have reference manual since it is new SoC, we keep get information from HW team and we have only register map Thanks a lot !!! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
H Boris, On 30/4/2020 4:21 pm, Boris Brezillon wrote: On Thu, 30 Apr 2020 15:50:30 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, Thank you very much for keep reviewing the patches and more queries... On 29/4/2020 11:31 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 23:18:31 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, On 29/4/2020 10:48 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 22:33:37 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, On 29/4/2020 10:22 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:05 +0800 "Ramuthevar, Vadivel MuruganX" wrote: + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +#define EBU_ADDR_MASK (5 << 4) It's still unclear what ADDR_MASK is for. Can you add a comment explaining what it does? Thank you Boris, keep review and giving inputs, will update. Can you please explain it here before sending a new version? Memory Region Address Mask: Specifies the number of right-most bits in the base address that should be included in the address comparison. bits positions(7:4). Okay, then the macro should be #define EBU_ADDR_MASK(x)((x) << 4) And now I'd like you to explain why 5 is the right value for that field (I guess that has to do with the position of the CS/ALE/CLE pins). 5 : bit 26, 25, 24, 23, 22 to be included for comparison in the That's 6 bits to me, not 5. No , 5 bits only the above case. ADDR_SELx , it compares only 5 bits. Definitely not what I would qualify as right-most bits. So, you say the comparison always starts at bit 22, and ends at 22+? Correct Yes , we are setting both CS0 and CS1 memory access region, if you have any concern to optimize, please suggest me, Thanks! If you want to setup both CS, and the address written in EBU_ADDR_SEL(x) is really related to the nand_pa address, then retrieve resources for all CS ranges. If it's not related, please explain what those EBU_MEM_BASE_CS_X values encode. Memory Region Base Address FPI Bus addresses are compared to this base address in conjunction with the mask control(EBU_ADDR_MASK). Driver need to program this field! That's not explaining what the base address should be. Is 'nand_pa' the value we should have there? The one prorgrammed in the addr_sel register is used by the HW controller, it remaps to 0x174XX-> CS0 and 0x17CXX->CS1. The hardware itself, decodes only for 1740xx/17c0xx, other random values cannot be programmed The question is, is it the same value we have in nand_pa or it is different? Different address which is 0xE140 NAND_BASE_PHY address. Thanks! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, Thank you very much for keep reviewing the patches and more queries... On 29/4/2020 11:31 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 23:18:31 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, On 29/4/2020 10:48 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 22:33:37 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, On 29/4/2020 10:22 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:05 +0800 "Ramuthevar, Vadivel MuruganX" wrote: + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +#define EBU_ADDR_MASK (5 << 4) It's still unclear what ADDR_MASK is for. Can you add a comment explaining what it does? Thank you Boris, keep review and giving inputs, will update. Can you please explain it here before sending a new version? Memory Region Address Mask: Specifies the number of right-most bits in the base address that should be included in the address comparison. bits positions(7:4). Okay, then the macro should be #define EBU_ADDR_MASK(x)((x) << 4) And now I'd like you to explain why 5 is the right value for that field (I guess that has to do with the position of the CS/ALE/CLE pins). 5 : bit 26, 25, 24, 23, 22 to be included for comparison in the ADDR_SELx , it compares only 5 bits. +#define EBU_ADDR_SEL_REGEN 0x1 + + writel(lower_32_bits(ebu_host->cs[ebu_host->cs_num].nand_pa) | + EBU_ADDR_SEL_REGEN | EBU_ADDR_MASK, + ebu_host->ebu + EBU_ADDR_SEL(reg)); You set EBU_ADDR_SEL(reg) once here... + + writel(EBU_MEM_BASE_CS_0 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(0)); + writel(EBU_MEM_BASE_CS_1 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(reg)); ... and a second time here. That sounds like overwriting the EBU_ADDR_SEL(reg) register to me. That's super weird. You seem to set EBU_ADDR_SEL(reg) twice. Are you sure that's needed, and are we setting EBU_ADDR_SEL(0) here? You are right, its weird only, but we need it, since different chip select has different memory region access address. Well, that doesn't make any sense, the second write to EBU_ADDR_SEL(reg) overrides the first one, meaning that nand_pa is actually never written to ADDR_SEL(reg). it will not overwrite the first one, since two different registers EBU_ADDR_SEL_0 EBU_ADDR_SEL 20H EBU_ADDR_SEL_1 EBU_ADDR_SEL 24H See my above. it is an internal address selection w.r.t chip select for nand physical address update. Yes , we are setting both CS0 and CS1 memory access region, if you have any concern to optimize, please suggest me, Thanks! If you want to setup both CS, and the address written in EBU_ADDR_SEL(x) is really related to the nand_pa address, then retrieve resources for all CS ranges. If it's not related, please explain what those EBU_MEM_BASE_CS_X values encode. Memory Region Base Address FPI Bus addresses are compared to this base address in conjunction with the mask control(EBU_ADDR_MASK). Driver need to program this field! That's not explaining what the base address should be. Is 'nand_pa' the value we should have there? The one prorgrammed in the addr_sel register is used by the HW controller, it remaps to 0x174XX-> CS0 and 0x17CXX->CS1. The hardware itself, decodes only for 1740xx/17c0xx, other random values cannot be programmed Regards Vadivel
Re: [PATCH v4 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support
Hi Boris, Thank you very much for the review comments and your time... On 29/4/2020 11:34 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:04 +0800 "Ramuthevar,Vadivel MuruganX" wrote: From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 61 ++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml new file mode 100644 index ..6dd899d367b4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel LGM SoC NAND Controller Device Tree Bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Ramuthevar Vadivel Murugan + +properties: + compatible: +const: intel,lgm-nand-controller + + reg: +maxItems: 1 + + clocks: +maxItems: 1 + + dmas: +maxItems: 2 + + dma-names: +enum: + - rx + - tx + + pinctrl-names: true + +patternProperties: + "^pinctrl-[0-9]+$": true + + "^nand@[a-f0-9]+$": +type: object +properties: + reg: +minimum: 0 +maximum: 7 + + nand-ecc-mode: true + + nand-ecc-algo: +const: hw + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - dmas + +additionalProperties: false + +... Can you provide an example? I'd like to make sure the binding looks good. Noted, will update with example. Thanks! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, On 29/4/2020 11:18 pm, Ramuthevar, Vadivel MuruganX wrote: + writel(lower_32_bits(ebu_host->cs[ebu_host->cs_num].nand_pa) | + EBU_ADDR_SEL_REGEN | EBU_ADDR_MASK, + ebu_host->ebu + EBU_ADDR_SEL(reg)); + + writel(EBU_MEM_BASE_CS_0 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(0)); Good catch!, one will be removed , Thanks ! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, On 29/4/2020 10:48 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 22:33:37 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, On 29/4/2020 10:22 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:05 +0800 "Ramuthevar, Vadivel MuruganX" wrote: + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +#define EBU_ADDR_MASK (5 << 4) It's still unclear what ADDR_MASK is for. Can you add a comment explaining what it does? Thank you Boris, keep review and giving inputs, will update. Can you please explain it here before sending a new version? Memory Region Address Mask: Specifies the number of right-most bits in the base address that should be included in the address comparison. bits positions(7:4). +#define EBU_ADDR_SEL_REGEN 0x1 + + writel(lower_32_bits(ebu_host->cs[ebu_host->cs_num].nand_pa) | + EBU_ADDR_SEL_REGEN | EBU_ADDR_MASK, + ebu_host->ebu + EBU_ADDR_SEL(reg)); + + writel(EBU_MEM_BASE_CS_0 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(0)); + writel(EBU_MEM_BASE_CS_1 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(reg)); That's super weird. You seem to set EBU_ADDR_SEL(reg) twice. Are you sure that's needed, and are we setting EBU_ADDR_SEL(0) here? You are right, its weird only, but we need it, since different chip select has different memory region access address. Well, that doesn't make any sense, the second write to EBU_ADDR_SEL(reg) overrides the first one, meaning that nand_pa is actually never written to ADDR_SEL(reg). it will not overwrite the first one, since two different registers EBU_ADDR_SEL_0 EBU_ADDR_SEL 20H EBU_ADDR_SEL_1 EBU_ADDR_SEL 24H it is an internal address selection w.r.t chip select for nand physical address update. Yes , we are setting both CS0 and CS1 memory access region, if you have any concern to optimize, please suggest me, Thanks! If you want to setup both CS, and the address written in EBU_ADDR_SEL(x) is really related to the nand_pa address, then retrieve resources for all CS ranges. If it's not related, please explain what those EBU_MEM_BASE_CS_X values encode. Memory Region Base Address FPI Bus addresses are compared to this base address in conjunction with the mask control(EBU_ADDR_MASK). Driver need to program this field! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, On 29/4/2020 10:22 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:05 +0800 "Ramuthevar, Vadivel MuruganX" wrote: + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +#define EBU_ADDR_MASK (5 << 4) It's still unclear what ADDR_MASK is for. Can you add a comment explaining what it does? Thank you Boris, keep review and giving inputs, will update. +#define EBU_ADDR_SEL_REGEN 0x1 + + writel(lower_32_bits(ebu_host->cs[ebu_host->cs_num].nand_pa) | + EBU_ADDR_SEL_REGEN | EBU_ADDR_MASK, + ebu_host->ebu + EBU_ADDR_SEL(reg)); + + writel(EBU_MEM_BASE_CS_0 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(0)); + writel(EBU_MEM_BASE_CS_1 | EBU_ADDR_MASK | EBU_ADDR_SEL_REGEN, + ebu_host->ebu + EBU_ADDR_SEL(reg)); That's super weird. You seem to set EBU_ADDR_SEL(reg) twice. Are you sure that's needed, and are we setting EBU_ADDR_SEL(0) here? You are right, its weird only, but we need it, since different chip select has different memory region access address. Yes , we are setting both CS0 and CS1 memory access region, if you have any concern to optimize, please suggest me, Thanks! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, Thank you very much for the review comments and your time... On 29/4/2020 9:32 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 21:29:40 +0800 "Ramuthevar, Vadivel MuruganX" wrote: Hi Boris, Thank you very much for the review comments and your time.. On 29/4/2020 7:33 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:05 +0800 "Ramuthevar,Vadivel MuruganX" wrote: +#define NAND_WRITE_CMD (EBU_CON_CS_P_LOW | HSNAND_CLE_OFFS) +#define NAND_WRITE_ADDR(EBU_CON_CS_P_LOW | HSNAND_ALE_OFFS) + I thought we agreed on dropping those definitions. Yes , we agreed upon it, due to assertion/de-assertion of CS kept it. And I keep thinking we don't need that, just pass 'HSNAND_CLE_OFFS | HSNAND_CS_OFFS' directly. Agreed!, will update in the next-patch version, Thanks! Regards Vadivel
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris, Thank you very much for the review comments and your time.. On 29/4/2020 7:33 pm, Boris Brezillon wrote: On Wed, 29 Apr 2020 18:42:05 +0800 "Ramuthevar,Vadivel MuruganX" wrote: +#define NAND_WRITE_CMD (EBU_CON_CS_P_LOW | HSNAND_CLE_OFFS) +#define NAND_WRITE_ADDR(EBU_CON_CS_P_LOW | HSNAND_ALE_OFFS) + I thought we agreed on dropping those definitions. Yes , we agreed upon it, due to assertion/de-assertion of CS kept it. Thanks! Regards Vadivel
[PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Signed-off-by: Ramuthevar Vadivel Murugan --- drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 750 +++ 3 files changed, 759 insertions(+) create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..a026bec28f39 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash interfaced through the External Bus Unit. + comment "Misc" config MTD_SM_COMMON diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 2d136b158fb7..bfc8fe4d2cb0 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o +obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c b/drivers/mtd/nand/raw/intel-nand-controller.c new file mode 100644 index ..fc69c7a9280c --- /dev/null +++ b/drivers/mtd/nand/raw/intel-nand-controller.c @@ -0,0 +1,750 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* Copyright (c) 2020 Intel Corporation. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define EBU_CLC0x000 +#define EBU_CLC_RST0xu + +#define EBU_ADDR_SEL(n)(0x20 + (n) * 4) +#define EBU_ADDR_MASK (5 << 4) +#define EBU_ADDR_SEL_REGEN 0x1 + +#define EBU_BUSCON(n) (0x60 + (n) * 4) +#define EBU_BUSCON_CMULT_V40x1 +#define EBU_BUSCON_RECOVC(n) ((n) << 2) +#define EBU_BUSCON_HOLDC(n)((n) << 4) +#define EBU_BUSCON_WAITRDC(n) ((n) << 6) +#define EBU_BUSCON_WAITWRC(n) ((n) << 8) +#define EBU_BUSCON_BCGEN_CS0x0 +#define EBU_BUSCON_SETUP_ENBIT(22) +#define EBU_BUSCON_ALEC0xC000 + +#define EBU_CON0x0B0 +#define EBU_CON_NANDM_EN BIT(0) +#define EBU_CON_NANDM_DIS 0x0 +#define EBU_CON_CSMUX_E_EN BIT(1) +#define EBU_CON_ALE_P_LOW BIT(2) +#define EBU_CON_CLE_P_LOW BIT(3) +#define EBU_CON_CS_P_LOW BIT(4) +#define EBU_CON_SE_P_LOW BIT(5) +#define EBU_CON_WP_P_LOW BIT(6) +#define EBU_CON_PRE_P_LOW BIT(7) +#define EBU_CON_IN_CS_S(n) ((n) << 8) +#define EBU_CON_OUT_CS_S(n)((n) << 10) +#define EBU_CON_LAT_EN_CS_P((0x3D) << 18) + +#define EBU_WAIT 0x0B4 +#define EBU_WAIT_RDBY BIT(0) +#define EBU_WAIT_WR_C BIT(3) + +#define EBU_MEM_BASE_CS_0 0x1740 +#define EBU_MEM_BASE_CS_1 0x17C0 + +#define HSNAND_CTL10x110 +#define HSNAND_CTL1_ADDR_SHIFT 24 + +#define HSNAND_CTL20x114 +#define HSNAND_CTL2_ADDR_SHIFT 8 +#define HSNAND_CTL2_CYC_N_V5 (0x2 << 16) + +#define HSNAND_INT_MSK_CTL 0x124 +#define HSNAND_INT_MSK_CTL_WR_CBIT(4) + +#define HSNAND_INT_STA 0x128 +#define HSNAND_INT_STA_WR_CBIT(4) + +#define HSNAND_CTL 0x130 +#define HSNAND_CTL_ENABLE_ECC BIT(0) +#define HSNAND_CTL_GO BIT(2) +#define HSNAND_CTL_CE_SEL_CS(n)BIT(3 + (n)) +#define HSNAND_CTL_RW_READ 0x0 +#define HSNAND_CTL_RW_WRITEBIT(10) +#define HSNAND_CTL_ECC_OFF_V8THBIT(11) +#define HSNAND_CTL_CKFF_EN 0x0 +#define HSNAND_CTL_MSG_EN BIT(17) + +#define HSNAND_PARA0 0x13c +#define HSNAND_PARA0_PAGE_V81920x3 +#define HSNAND_PARA0_PIB_V256 (0x3 << 4) +#define HSNAND_PARA0_BYP_EN_NP 0x0 +#define HSNAND_PARA0_BYP_DEC_NP0x0 +#define
[PATCH v4 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support
From: Ramuthevar Vadivel Murugan Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 61 ++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml new file mode 100644 index ..6dd899d367b4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel LGM SoC NAND Controller Device Tree Bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Ramuthevar Vadivel Murugan + +properties: + compatible: +const: intel,lgm-nand-controller + + reg: +maxItems: 1 + + clocks: +maxItems: 1 + + dmas: +maxItems: 2 + + dma-names: +enum: + - rx + - tx + + pinctrl-names: true + +patternProperties: + "^pinctrl-[0-9]+$": true + + "^nand@[a-f0-9]+$": +type: object +properties: + reg: +minimum: 0 +maximum: 7 + + nand-ecc-mode: true + + nand-ecc-algo: +const: hw + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - dmas + +additionalProperties: false + +... -- 2.11.0
[PATCH v4 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar Vadivel Murugan This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thank you very much Boris, Miquel and Hauke for the reviews and suggestions. --- v4: - add ebu_nand_cs structure for multiple-CS support - mask/offset encoding for 0x51 value - update macro HSNAND_CTL_ENABLE_ECC - drop the op argument and un-used macros. - updated the datatype and macros - add function disable nand module - remove ebu_host->dma_rx = NULL; - rename MMIO address range variables to ebu and hsnand - implement ->setup_data_interface() - update label err_cleanup_nand and err_cleanup_dma - add return value check in the nand_remove function - add/remove tabs and spaces as per coding standard - encoded CS ids by reg property v3: - Add depends on MACRO in Kconfig - file name update in Makefile - file name update to intel-nand-controller - modification of MACRO divided like EBU, HSNAND and NAND - add NAND_ALE_OFFS, NAND_CLE_OFFS and NAND_CS_OFFS - rename lgm_ to ebu_ and _va suffix is removed in the whole file - rename structure and varaibles as per review comments. - remove lgm_read_byte(), lgm_dev_ready() and cmd_ctrl() un-used function - update in exec_op() as per review comments - rename function lgm_dma_exit() by lgm_dma_cleanup() - hardcoded magic value for base and offset replaced by MACRO defined - mtd_device_unregister() + nand_cleanup() instead of nand_release() v2: - implement the ->exec_op() to replaces the legacy hook-up. - update the commit message - YAML compatible string update to intel, lgm-nand-controller - add MIPS maintainers and xway_nand driver author in CC v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: mtd: Add YAML for Nand Flash Controller support mtd: rawnand: Add NAND controller support on Intel LGM SoC .../devicetree/bindings/mtd/intel,lgm-nand.yaml| 61 ++ drivers/mtd/nand/raw/Kconfig | 8 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/intel-nand-controller.c | 750 + 4 files changed, 820 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c -- 2.11.0
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Miquel, On 28/4/2020 3:54 pm, Miquel Raynal wrote: Do we have access to the spec or a register map? We could tell you very quickly if it is worth the trouble. But I am pretty sure as well that the controller supports more than 1 CS. Got it, will update the changes to support multiple CS as generic-way. Thank you! Regards Vadivel
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Miquel,
On 28/4/2020 3:54 pm, Miquel Raynal wrote:
Hello,
"Ramuthevar, Vadivel MuruganX"
wrote on Tue, 28 Apr 2020
15:50:06 +0800:
Hi Miquel,
On 28/4/2020 3:40 pm, Miquel Raynal wrote:
Hi Vadivel MuruganX,
"Ramuthevar, Vadivel MuruganX"
wrote on Tue, 28 Apr 2020
14:50:35 +0800:
Hi Boris,
On 28/4/2020 2:47 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:40:58 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
>>>> Hi Boris,
On 28/4/2020 2:27 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:17:30 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
>>>> Hi Miquel,
Thank you very much for the review comments and your time...
On 27/4/2020 11:51 pm, Miquel Raynal wrote:
Hi Ramuthevar,
>>>>>>> +static int ebu_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct ebu_nand_controller *ebu_host;
+ struct nand_chip *nand;
+ phys_addr_t nandaddr_pa;
+ struct mtd_info *mtd;
+ struct resource *res;
+ int ret;
+ u32 cs;
+
+ ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
+ if (!ebu_host)
+ return -ENOMEM;
+
+ ebu_host->dev = dev;
+ nand_controller_init(_host->controller);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
+ ebu_host->ebu_addr = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(ebu_host->ebu_addr))
+ return PTR_ERR(ebu_host->ebu_addr);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
+ ebu_host->nand_addr = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(ebu_host->nand_addr))
+ return PTR_ERR(ebu_host->nand_addr);
+
+ ret = device_property_read_u32(dev, "nand,cs", );
CS ids should be encoded in the reg property (see [1]).
Is it your choice to only support a single CS or is it actually a
controller limitation?
Yes , its controller limitation to support only one CS
I'm pretty sure that's not true, otherwise you wouldn't have to select
the CS you want to use :P.
At a time it supports only one chip select.
Yes, like 99% of the NAND controllers, but that doesn't mean you can't
support multi-CS chips. All you have to do is attach an array of
ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I
pointed to). nand_operation.cs tells you which CS (index in your
ebu_nand_cs array) a specific operation is targeting, and you can pick
the right MMIO range/reg value based on that.
Agreed, sure I will add that and update next series of patches .
There are also many other places where you assume blindly that there
is only one CS. You can check the Atmel NAND controller driver as Boris
said and we will probably propose more little changes to be more
generic.
since LGM EBU_NAND controller supports only one chip select at a time, so
assumed like that, will change as generic way if consider like more chip select
supports, Thanks!
What do you mean "at a time"?
I mean it supports multi-CS, during the run time it selects one.
Thanks!
Regards
Vadivel
Do we have access to the spec or a register map? We could tell you very
quickly if it is worth the trouble. But I am pretty sure as well that
the controller supports more than 1 CS.
Sure , I will do the changes as per your review comments.
Thanks,
Miquèl
Thanks,
Miquèl
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Miquel,
On 28/4/2020 3:40 pm, Miquel Raynal wrote:
Hi Vadivel MuruganX,
"Ramuthevar, Vadivel MuruganX"
wrote on Tue, 28 Apr 2020
14:50:35 +0800:
Hi Boris,
On 28/4/2020 2:47 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:40:58 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 28/4/2020 2:27 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:17:30 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
>>>> Hi Miquel,
Thank you very much for the review comments and your time...
On 27/4/2020 11:51 pm, Miquel Raynal wrote:
Hi Ramuthevar,
>>>>>>> +static int ebu_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct ebu_nand_controller *ebu_host;
+ struct nand_chip *nand;
+ phys_addr_t nandaddr_pa;
+ struct mtd_info *mtd;
+ struct resource *res;
+ int ret;
+ u32 cs;
+
+ ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
+ if (!ebu_host)
+ return -ENOMEM;
+
+ ebu_host->dev = dev;
+ nand_controller_init(_host->controller);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
+ ebu_host->ebu_addr = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(ebu_host->ebu_addr))
+ return PTR_ERR(ebu_host->ebu_addr);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
+ ebu_host->nand_addr = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(ebu_host->nand_addr))
+ return PTR_ERR(ebu_host->nand_addr);
+
+ ret = device_property_read_u32(dev, "nand,cs", );
CS ids should be encoded in the reg property (see [1]).
Is it your choice to only support a single CS or is it actually a
controller limitation?
Yes , its controller limitation to support only one CS
I'm pretty sure that's not true, otherwise you wouldn't have to select
the CS you want to use :P.
At a time it supports only one chip select.
Yes, like 99% of the NAND controllers, but that doesn't mean you can't
support multi-CS chips. All you have to do is attach an array of
ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I
pointed to). nand_operation.cs tells you which CS (index in your
ebu_nand_cs array) a specific operation is targeting, and you can pick
the right MMIO range/reg value based on that.
Agreed, sure I will add that and update next series of patches .
There are also many other places where you assume blindly that there
is only one CS. You can check the Atmel NAND controller driver as Boris
said and we will probably propose more little changes to be more
generic.
since LGM EBU_NAND controller supports only one chip select at a time,
so assumed like that, will change as generic way if consider like more
chip select supports, Thanks!
Sure , I will do the changes as per your review comments.
Thanks,
Miquèl
Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 28/4/2020 2:47 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:40:58 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 28/4/2020 2:27 pm, Boris Brezillon wrote:
On Tue, 28 Apr 2020 14:17:30 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Miquel,
Thank you very much for the review comments and your time...
On 27/4/2020 11:51 pm, Miquel Raynal wrote:
Hi Ramuthevar,
+static int ebu_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct ebu_nand_controller *ebu_host;
+ struct nand_chip *nand;
+ phys_addr_t nandaddr_pa;
+ struct mtd_info *mtd;
+ struct resource *res;
+ int ret;
+ u32 cs;
+
+ ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
+ if (!ebu_host)
+ return -ENOMEM;
+
+ ebu_host->dev = dev;
+ nand_controller_init(_host->controller);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
+ ebu_host->ebu_addr = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(ebu_host->ebu_addr))
+ return PTR_ERR(ebu_host->ebu_addr);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
+ ebu_host->nand_addr = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(ebu_host->nand_addr))
+ return PTR_ERR(ebu_host->nand_addr);
+
+ ret = device_property_read_u32(dev, "nand,cs", );
CS ids should be encoded in the reg property (see [1]).
Is it your choice to only support a single CS or is it actually a
controller limitation?
Yes , its controller limitation to support only one CS
I'm pretty sure that's not true, otherwise you wouldn't have to select
the CS you want to use :P.
At a time it supports only one chip select.
Yes, like 99% of the NAND controllers, but that doesn't mean you can't
support multi-CS chips. All you have to do is attach an array of
ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I
pointed to). nand_operation.cs tells you which CS (index in your
ebu_nand_cs array) a specific operation is targeting, and you can pick
the right MMIO range/reg value based on that.
Agreed, sure I will add that and update next series of patches .
Thanks! a lot Boris
Regards
Vadivel
[PATCH v6 2/2] phy: intel-lgm-emmc: Add support for eMMC PHY
From: Ramuthevar Vadivel Murugan
Add support for eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
Reviewed-by: Andy Shevchenko
---
drivers/phy/Kconfig| 1 +
drivers/phy/Makefile | 1 +
drivers/phy/intel/Kconfig | 9 ++
drivers/phy/intel/Makefile | 2 +
drivers/phy/intel/phy-intel-emmc.c | 283 +
5 files changed, 296 insertions(+)
create mode 100644 drivers/phy/intel/Kconfig
create mode 100644 drivers/phy/intel/Makefile
create mode 100644 drivers/phy/intel/phy-intel-emmc.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0263db2ac874..b3ed94b98d9b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -69,5 +69,6 @@ source "drivers/phy/socionext/Kconfig"
source "drivers/phy/st/Kconfig"
source "drivers/phy/tegra/Kconfig"
source "drivers/phy/ti/Kconfig"
+source "drivers/phy/intel/Kconfig"
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c96a1afc95bd..310c149a9df5 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,6 +18,7 @@ obj-y += broadcom/\
cadence/ \
freescale/ \
hisilicon/ \
+ intel/ \
lantiq/ \
marvell/ \
motorola/\
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
new file mode 100644
index ..4ea6a8897cd7
--- /dev/null
+++ b/drivers/phy/intel/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Phy drivers for Intel Lightning Mountain(LGM) platform
+#
+config PHY_INTEL_EMMC
+ tristate "Intel EMMC PHY driver"
+ select GENERIC_PHY
+ help
+ Enable this to support the Intel EMMC PHY
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
new file mode 100644
index ..6b876a75599d
--- /dev/null
+++ b/drivers/phy/intel/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
diff --git a/drivers/phy/intel/phy-intel-emmc.c
b/drivers/phy/intel/phy-intel-emmc.c
new file mode 100644
index ..1a358e7fd236
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-emmc.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel eMMC PHY driver
+ * Copyright (C) 2019 Intel, Corp.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* eMMC phy register definitions */
+#define EMMC_PHYCTRL0_REG 0xa8
+#define DR_TY_MASK GENMASK(30, 28)
+#define DR_TY_SHIFT(x) (((x) << 28) & DR_TY_MASK)
+#define OTAPDLYENA BIT(14)
+#define OTAPDLYSEL_MASKGENMASK(13, 10)
+#define OTAPDLYSEL_SHIFT(x)(((x) << 10) & OTAPDLYSEL_MASK)
+
+#define EMMC_PHYCTRL1_REG 0xac
+#define PDB_MASK BIT(0)
+#define PDB_SHIFT(x) (((x) << 0) & PDB_MASK)
+#define ENDLL_MASK BIT(7)
+#define ENDLL_SHIFT(x) (((x) << 7) & ENDLL_MASK)
+
+#define EMMC_PHYCTRL2_REG 0xb0
+#define FRQSEL_25M 0
+#define FRQSEL_50M 1
+#define FRQSEL_100M2
+#define FRQSEL_150M3
+#define FRQSEL_MASKGENMASK(24, 22)
+#define FRQSEL_SHIFT(x)(((x) << 22) & FRQSEL_MASK)
+
+#define EMMC_PHYSTAT_REG 0xbc
+#define CALDONE_MASK BIT(9)
+#define DLLRDY_MASKBIT(8)
+#define IS_CALDONE(x) ((x) & CALDONE_MASK)
+#define IS_DLLRDY(x) ((x) & DLLRDY_MASK)
+
+struct intel_emmc_phy {
+ struct regmap *syscfg;
+ struct clk *emmcclk;
+};
+
+static int intel_emmc_phy_power(struct phy *phy, bool on_off)
+{
+ struct intel_emmc_phy *priv = phy_get_drvdata(phy);
+ unsigned int caldone;
+ unsigned int dllrdy;
+ unsigned int freqsel;
+ unsigned long rate;
+ int ret, quot;
+
+ /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+ ret = regmap_update_bits(priv->syscfg, EMMC_PHYCTRL1_REG, PDB_MASK,
+PDB_SHIFT(0));
+ if (ret) {
+ dev_err(>dev, "CALIO power down bar failed: %d\n", ret);
+ return ret;
+ }
+
+ /* Already finish power_off above */
+ if (!on_off)
+ return 0;
+
+ rate = clk_get_rate(priv->emmcclk);
+ quot = DIV_ROUND_CLOSEST(rate, 5000);
+ if (quot > FRQSEL_150M)
+ dev_warn(>dev, "Unsupported rate: %lu\n", rate);
+ freqsel = clamp_t(int, quot, FRQSEL_25M, FRQSEL_150M);
+
+ /*
+* According to the user manual, calpad calibration
+
[PATCH v6 1/2] dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY
From: Ramuthevar Vadivel Murugan
Add a YAML schema to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
---
.../bindings/phy/intel,lgm-emmc-phy.yaml | 63 ++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
new file mode 100644
index ..bc1285be31f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) eMMC PHY Device Tree Bindings
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+description: Bindings for eMMC PHY on Intel's Lightning Mountain SoC, syscon
+ node is used to reference the base address of eMMC phy registers.
+
+select:
+ properties:
+compatible:
+ items:
+ - const: intel,lgm-syscon
+ - const: intel,lgm-emmc-phy
+
+reg:
+ maxItems: 1
+
+ required:
+- compatible
+- reg
+
+properties:
+ "#phy-cells":
+const: 0
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+maxItems: 1
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+examples:
+ - |
+sysconf: chiptop@e020 {
+ compatible = "intel,lgm-syscon";
+ reg = <0xe020 0x100>;
+
+ emmc-phy: emmc-phy {
+compatible = "intel,lgm-emmc-phy";
+reg = <0x00a8 0x10>;
+clocks = <>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+ };
+};
+...
--
2.11.0
[PATCH v6 0/2] phy: intel,lgm-emmc-phy: Add support for eMMC PHY on Intel LGM SoC
Rebased to kernel verson 5.4 dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY changes in v6: - cobined comaptible strings - added as contiguous and can be a single entry for reg properties changes in v5: - earlier Review-by tag given by Rob - rework done with syscon parent node. changes in v4: - As per Rob's review: validate 5.2 and 5.3 - drop unrelated items. changes in v3: - resolve 'make dt_binding_check' warnings changes in v2: As per Rob Herring review comments, the following updates - change GPL-2.0 -> (GPL-2.0-only OR BSD-2-Clause) - filename is the compatible string plus .yaml - LGM: Lightning Mountain - update maintainer - add intel,syscon under property list - keep one example instead of two phy: intel-lgm-emmc: Add support for eMMC PHY No changes from patchV5 Ramuthevar Vadivel Murugan (2): dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY phy: intel-lgm-emmc: Add support for eMMC PHY .../bindings/phy/intel,lgm-emmc-phy.yaml | 63 + drivers/phy/Kconfig| 1 + drivers/phy/Makefile | 1 + drivers/phy/intel/Kconfig | 9 + drivers/phy/intel/Makefile | 2 + drivers/phy/intel/phy-intel-emmc.c | 283 + 6 files changed, 359 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml create mode 100644 drivers/phy/intel/Kconfig create mode 100644 drivers/phy/intel/Makefile create mode 100644 drivers/phy/intel/phy-intel-emmc.c -- 2.11.0
[PATCH v4 2/2] mtd: spi-nor: cadence-quadspi: Disable the auto-poll for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
On Intel Lightning Mountain SoCs QSPI controller do not use auto-poll.
This patch disables auto polling when direct access mode is disabled
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/mtd/spi-nor/cadence-quadspi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 0ad076eaa81b..c2333f0473e3 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -88,6 +88,7 @@ struct cqspi_st {
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
+ boolauto_poll;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
@@ -136,6 +137,8 @@ struct cqspi_driver_platdata {
#define CQSPI_REG_RD_INSTR_TYPE_DATA_MASK 0x3
#define CQSPI_REG_RD_INSTR_DUMMY_MASK 0x1F
+#define CQSPI_REG_WR_COMPLETION_CTRL 0x38
+#define CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL BIT(14)
#define CQSPI_REG_WR_INSTR 0x08
#define CQSPI_REG_WR_INSTR_OPCODE_LSB 0
#define CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB 12
@@ -1175,6 +1178,18 @@ static int cqspi_of_get_pdata(struct platform_device
*pdev)
return 0;
}
+static int cqspi_disable_auto_poll(struct cqspi_st *cqspi)
+{
+ void __iomem *reg_base = cqspi->iobase;
+ unsigned int reg;
+
+ reg = readl(reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+ reg |= CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL;
+ writel(reg, reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+
+ return 0;
+}
+
static void cqspi_controller_init(struct cqspi_st *cqspi)
{
u32 reg;
@@ -1206,6 +1221,10 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable auto-polling */
+ if (!cqspi->auto_poll)
+ cqspi_disable_auto_poll(cqspi);
+
cqspi_controller_enable(cqspi, 1);
}
@@ -1421,6 +1440,9 @@ static int cqspi_probe(struct platform_device *pdev)
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
+ if (ddata && (ddata->quirks & CQSPI_DISABLE_DAC_MODE))
+ cqspi->auto_poll = false;
+
ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
pdev->name, cqspi);
if (ret) {
--
2.11.0
[PATCH v4 1/2] mtd: spi-nor: cadence-quadspi: Disable the DAC for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).
This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/mtd/spi-nor/Kconfig | 2 +-
drivers/mtd/spi-nor/cadence-quadspi.c | 33 +++--
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index f237fcdf7f86..ef1aa369c2e3 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -36,7 +36,7 @@ config SPI_ASPEED_SMC
config SPI_CADENCE_QUADSPI
tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ depends on OF && (ARM || ARM64 || COMPILE_TEST || X86)
help
Enable support for the Cadence Quad SPI Flash controller.
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 7bef63947b29..0ad076eaa81b 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -34,6 +34,7 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
/* Capabilities mask */
#define CQSPI_BASE_HWCAPS_MASK \
@@ -600,6 +601,13 @@ static int cqspi_write_setup(struct spi_nor *nor)
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ /* Disable direct access controller */
+ if (!f_pdata->use_direct_mode) {
+ reg = readl(reg_base + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, reg_base + CQSPI_REG_CONFIG);
+ }
+
/* Set opcode. */
reg = nor->program_opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
writel(reg, reg_base + CQSPI_REG_WR_INSTR);
@@ -1292,12 +1300,16 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
f_pdata->registered = true;
if (mtd->size <= cqspi->ahb_size) {
- f_pdata->use_direct_mode = true;
- dev_dbg(nor->dev, "using direct mode for %s\n",
- mtd->name);
-
- if (!cqspi->rx_chan)
- cqspi_request_mmap_dma(cqspi);
+ if (ddata && (ddata->quirks & CQSPI_DISABLE_DAC_MODE)) {
+ f_pdata->use_direct_mode = false;
+ } else {
+ f_pdata->use_direct_mode = true;
+ dev_dbg(nor->dev, "using direct mode for %s\n",
+ mtd->name);
+
+ if (!cqspi->rx_chan)
+ cqspi_request_mmap_dma(cqspi);
+ }
}
}
@@ -1501,6 +1513,11 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
};
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1514,6 +1531,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
.compatible = "ti,am654-ospi",
.data = _ospi,
},
+ {
+ .compatible = "intel,lgm-qspi",
+ .data = _lgm_qspi,
+ },
{ /* end of table */ }
};
--
2.11.0
[PATCH v4 0/2] mtd: spi-nor: cadence-quadspi: Disable the DAC and Autopoll for Intel LGM SoC
On Intel Lightning Mountain SoCs QSPI controller do not use auto-poll and Direct Access Controller (DAC). Thanks vignesh for your time to review the patch. The following comments are addressed.. changes from v3: - commit messages are updated in both the patches - moved cqspi_disable_auto_poll() in cqspi_controller_init() - moved the check quirks & CQSPI_DISABLE_DAC_MODE))> in cqspi_setup_flash() - introduced cqspi->auto_poll variable instead of f_pdata->use_direct_mode for auto_poll patch Ramuthevar Vadivel Murugan (2): mtd: spi-nor: cadence-quadspi: Disable the DAC for Intel LGM SoC - This patch adds a quirk to disable the Direct Access Controller for data transfer instead it uses indirect data transfer. mtd: spi-nor: cadence-quadspi: Disable the auto-poll for Intel LGM SoC - This patch disables auto polling when direct access mode is disabled drivers/mtd/spi-nor/Kconfig | 2 +- drivers/mtd/spi-nor/cadence-quadspi.c | 55 +++ 2 files changed, 50 insertions(+), 7 deletions(-) -- 2.11.0
Re: [PATCH v3 3/3] mtd: spi-nor: cadence-quadspi: disable the auto-poll for Intel LGM
Hi Vignesh,
Thank you for the review comments.
On 16/10/2019 4:40 PM, Vignesh Raghavendra wrote:
On 09/09/19 4:17 PM, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
On Intel's Lightning Mountain(LGM) SoC QSPI controller do not auto-poll.
This patch introduces to properly disable the auto-polling feature to
This patch disables auto polling when direct access mode is disabled
which should be noted in the commit message.
will add it.
improve the performance of cadence-quadspi.
How does this improve performance of cadence-quadspi? I would expect HW
auto-polling to be faster than SW polling.
During the bring-up time observed this, once again verify it on my setup.
Agreed, you are correct HW auto-polling is faster than SW polling.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/mtd/spi-nor/cadence-quadspi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 73b9fbd1508a..60998eaad1cc 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -135,6 +135,8 @@ struct cqspi_driver_platdata {
#define CQSPI_REG_RD_INSTR_TYPE_DATA_MASK 0x3
#define CQSPI_REG_RD_INSTR_DUMMY_MASK 0x1F
+#define CQSPI_REG_WR_COMPLETION_CTRL 0x38
+#define CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL BIT(14)
#define CQSPI_REG_WR_INSTR0x08
#define CQSPI_REG_WR_INSTR_OPCODE_LSB 0
#define CQSPI_REG_WR_INSTR_TYPE_ADDR_LSB 12
@@ -471,6 +473,18 @@ static int cqspi_command_write_addr(struct spi_nor *nor,
return cqspi_exec_flash_cmd(cqspi, reg);
}
+static int cqspi_disable_auto_poll(struct cqspi_st *cqspi)
+{
+ void __iomem *reg_base = cqspi->iobase;
+ unsigned int reg;
+
+ reg = readl(reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+ reg |= CQSPI_REG_WR_COMPLETION_DISABLE_AUTO_POLL;
+ writel(reg, reg_base + CQSPI_REG_WR_COMPLETION_CTRL);
+
+ return 0;
+}
+
static int cqspi_read_setup(struct spi_nor *nor)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -508,6 +522,11 @@ static int cqspi_read_setup(struct spi_nor *nor)
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
writel(reg, reg_base + CQSPI_REG_SIZE);
+
+ /* Disable auto-polling */
+ if (!f_pdata->use_direct_mode)
+ cqspi_disable_auto_poll(cqspi);
+
return 0;
}
Hmmm.. There is no need to disable polling for every read/write
operation. It should be enough to do it once in cqspi_controller_init()
sure, move to cqspi_controller_init() .
---
Regards
Vadivel
@@ -627,6 +646,11 @@ static int cqspi_write_setup(struct spi_nor *nor)
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
writel(reg, reg_base + CQSPI_REG_SIZE);
+
+ /* Disable auto-polling */
+ if (!f_pdata->use_direct_mode)
+ cqspi_disable_auto_poll(cqspi);
+
return 0;
}
Re: [PATCH v3 2/3] mtd: spi-nor: cadence-quadspi: Disable the DAC for Intel LGM SoC
Hi Vignesh,
Thank you for the review comments.
On 16/10/2019 4:32 PM, Vignesh Raghavendra wrote:
On 09/09/19 4:17 PM, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
on Intel's Lightning Mountain(LGM) SoCs QSPI controller do not use
s/on/On
Agreed, will update.
Direct Access Controller(DAC).
This patch introduces to properly disable the Direct Access Controller
"This patch adds a quirk to disable..." or something something similar
okay, will update.
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/mtd/spi-nor/Kconfig | 2 +-
drivers/mtd/spi-nor/cadence-quadspi.c | 21 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 6de83277ce8b..ba2e372ae514 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -34,7 +34,7 @@ config SPI_ASPEED_SMC
config SPI_CADENCE_QUADSPI
tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ depends on OF && (ARM || ARM64 || COMPILE_TEST || X86)
help
Enable support for the Cadence Quad SPI Flash controller.
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
index 67f15a1f16fd..73b9fbd1508a 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -33,6 +33,7 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
/* Capabilities mask */
#define CQSPI_BASE_HWCAPS_MASK\
@@ -609,6 +610,13 @@ static int cqspi_write_setup(struct spi_nor *nor)
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ /* Disable direct access controller */
+ if (!f_pdata->use_direct_mode) {
+ reg = readl(reg_base + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, reg_base + CQSPI_REG_CONFIG);
+ }
+
/* Set opcode. */
reg = nor->program_opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
writel(reg, reg_base + CQSPI_REG_WR_INSTR);
@@ -1328,6 +1336,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct resource *res_ahb;
struct reset_control *rstc, *rstc_ocp;
const struct cqspi_driver_platdata *ddata;
+ struct cqspi_flash_pdata *f_pdata;
int ret;
int irq;
@@ -1436,6 +1445,9 @@ static int cqspi_probe(struct platform_device *pdev)
goto probe_setup_failed;
}
+ if (ddata && (ddata->quirks & CQSPI_DISABLE_DAC_MODE))
+ f_pdata->use_direct_mode = false;
+
If you do this here, you will still end up acquiring a DMA channel in
cqspi_request_mmap_dma() (called from cqspi_setup_flash()). So, please
move the check to cqspi_setup_flash().
will fix it.
---
Regards
Vadivel
return ret;
probe_setup_failed:
cqspi_controller_enable(cqspi, 0);
@@ -1510,6 +1522,11 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
};
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1523,6 +1540,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
.compatible = "ti,am654-ospi",
.data = _ospi,
},
+ {
+ .compatible = "intel,lgm-qspi",
+ .data = _lgm_qspi,
+ },
{ /* end of table */ }
};
Re: [PATCH v1 0/2] spi: cadence-qspi: Add cadence-qspi support for Intel LGM SoC
Hi Vignesh, On 10/10/2019 12:18 PM, Vignesh Raghavendra wrote: On 10/10/19 7:04 AM, Ramuthevar, Vadivel MuruganX wrote: HI Vignesh, On 17/9/2019 12:50 AM, Vignesh Raghavendra wrote: Hi, On 16/09/19 1:08 PM, Ramuthevar,Vadivel MuruganX wrote: patch 1: Add YAML for cadence-qspi devicetree cdocumentation. patch 2: cadence-qspi controller driver to support QSPI-NAND flash using existing spi-nand framework with legacy spi protocol. Nope, you cannot have two drivers for the same IP (i.e Cadence QSPI) just to support to different types of SPI memories. This is the reason why spi_mem_ops was introduced. Please rewrite this driver over to use spi_mem_ops (instead of using generic SPI xfers) so that same driver supports both SPI-NOR and SPI-NAND flashes. Once that's done drivers/mtd/spi-nor/cadence-quadspi.c can be deleted. There are few existing examples of spi_mem_ops users in drivers/spi/ (git grep spi_mem_ops) and materials here on how to write such a driver: [1] https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ [2] https://www.youtube.com/watch?v=PkWbuLM_gmU As per Mark Brown and your suggestion, I have started adapting cadence-qaudspi driver with spi_mem_ops framework to work QSPI-NAND/NOR as a generic driver(completely removed the legacy SPI-XFERS), is in progress on Intel LGM SoC. QSPI-IP on Intel LGM do not have DMA support and also not part of QSPI IP, so couldn't able to validate DMA related. will adapt the DMA things which are existing in cadence-quadspi.c as it is. Great, appreciate the effort! currently TI and Altera SoC's use this Cadence-qspi IP , both are not using DMA as per my understanding (correct me if it is wrong). confirmed through device tree entry. TI platforms use DMA to read data from flash in memory mapped mode (direct access controller) using mem-to-mem DMA channels. Mem-to-mem DMA channels are requested as and when needed and are not part of DT description (as they are not bound to a device) yes, understood now, Thanks! what is your opinion on DMA related stuff? Not having DMA support would be a regression. Please keep the DAC + DMA part as is. I can help you will all the DMA related testing... Sure, will keep DAC + DMA, as we discussed earlier use QUIRKS to differentiate and follow the same. --- With Regards Vadivel Regards Vignesh also using macronix(QSPI-NOR) flash/Micron(QSPI-NAND). --- With Regards Vadivel Ramuthevar Vadivel Murugan (2): dt-bindings: spi: Add support for cadence-qspi IP Intel LGM SoC spi: cadence-qspi: Add QSPI support for Intel LGM SoC .../devicetree/bindings/spi/cadence,qspi-nand.yaml | 84 +++ drivers/spi/Kconfig | 9 + drivers/spi/Makefile | 1 + drivers/spi/spi-cadence-qspi-apb.c | 644 + drivers/spi/spi-cadence-qspi-apb.h | 174 ++ drivers/spi/spi-cadence-qspi.c | 461 +++ drivers/spi/spi-cadence-qspi.h | 73 +++ 7 files changed, 1446 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml create mode 100644 drivers/spi/spi-cadence-qspi-apb.c create mode 100644 drivers/spi/spi-cadence-qspi-apb.h create mode 100644 drivers/spi/spi-cadence-qspi.c create mode 100644 drivers/spi/spi-cadence-qspi.h
Re: [PATCH v1 0/2] spi: cadence-qspi: Add cadence-qspi support for Intel LGM SoC
HI Vignesh, On 17/9/2019 12:50 AM, Vignesh Raghavendra wrote: Hi, On 16/09/19 1:08 PM, Ramuthevar,Vadivel MuruganX wrote: patch 1: Add YAML for cadence-qspi devicetree cdocumentation. patch 2: cadence-qspi controller driver to support QSPI-NAND flash using existing spi-nand framework with legacy spi protocol. Nope, you cannot have two drivers for the same IP (i.e Cadence QSPI) just to support to different types of SPI memories. This is the reason why spi_mem_ops was introduced. Please rewrite this driver over to use spi_mem_ops (instead of using generic SPI xfers) so that same driver supports both SPI-NOR and SPI-NAND flashes. Once that's done drivers/mtd/spi-nor/cadence-quadspi.c can be deleted. There are few existing examples of spi_mem_ops users in drivers/spi/ (git grep spi_mem_ops) and materials here on how to write such a driver: [1] https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ [2] https://www.youtube.com/watch?v=PkWbuLM_gmU As per Mark Brown and your suggestion, I have started adapting cadence-qaudspi driver with spi_mem_ops framework to work QSPI-NAND/NOR as a generic driver(completely removed the legacy SPI-XFERS), is in progress on Intel LGM SoC. QSPI-IP on Intel LGM do not have DMA support and also not part of QSPI IP, so couldn't able to validate DMA related. will adapt the DMA things which are existing in cadence-quadspi.c as it is. currently TI and Altera SoC's use this Cadence-qspi IP , both are not using DMA as per my understanding (correct me if it is wrong). confirmed through device tree entry. what is your opinion on DMA related stuff? also using macronix(QSPI-NOR) flash/Micron(QSPI-NAND). --- With Regards Vadivel Ramuthevar Vadivel Murugan (2): dt-bindings: spi: Add support for cadence-qspi IP Intel LGM SoC spi: cadence-qspi: Add QSPI support for Intel LGM SoC .../devicetree/bindings/spi/cadence,qspi-nand.yaml | 84 +++ drivers/spi/Kconfig| 9 + drivers/spi/Makefile | 1 + drivers/spi/spi-cadence-qspi-apb.c | 644 + drivers/spi/spi-cadence-qspi-apb.h | 174 ++ drivers/spi/spi-cadence-qspi.c | 461 +++ drivers/spi/spi-cadence-qspi.h | 73 +++ 7 files changed, 1446 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml create mode 100644 drivers/spi/spi-cadence-qspi-apb.c create mode 100644 drivers/spi/spi-cadence-qspi-apb.h create mode 100644 drivers/spi/spi-cadence-qspi.c create mode 100644 drivers/spi/spi-cadence-qspi.h
Re: [PATCH v1 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
Hi Andy, On 9/10/2019 5:40 PM, Andy Shevchenko wrote: On Wed, Oct 09, 2019 at 09:06:16AM +0800, Ramuthevar, Vadivel MuruganX wrote: Hi Adrian, Thank you for the Acked-by, will add *Acked-by* in the next-patch. Please, stop top-posting. Besides that, there is no need for next version if the only comments you got are ACKs. Rb:s, etc. Sure, Thanks! --- Regards Vadivel
[PATCH v2 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
From: Ramuthevar Vadivel Murugan
The current arasan sdhci PHY configuration isn't compatible
with the PHY on Intel's LGM(Lightning Mountain) SoC devices.
Therefore, add a new compatible, to adapt the Intel's LGM
SDXC PHY with arasan-sdhc controller to configure the PHY.
Signed-off-by: Ramuthevar Vadivel Murugan
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci-of-arasan.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 7023cbec4017..55de839a8a5e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -120,6 +120,12 @@ static const struct sdhci_arasan_soc_ctl_map
intel_lgm_emmc_soc_ctl_map = {
.hiword_update = false,
};
+static const struct sdhci_arasan_soc_ctl_map intel_lgm_sdxc_soc_ctl_map = {
+ .baseclkfreq = { .reg = 0x80, .width = 8, .shift = 2 },
+ .clockmultiplier = { .reg = 0, .width = -1, .shift = -1 },
+ .hiword_update = false,
+};
+
/**
* sdhci_arasan_syscon_write - Write to a field in soc_ctl registers
*
@@ -384,6 +390,11 @@ static struct sdhci_arasan_of_data intel_lgm_emmc_data = {
.pdata = _arasan_cqe_pdata,
};
+static struct sdhci_arasan_of_data intel_lgm_sdxc_data = {
+ .soc_ctl_map = _lgm_sdxc_soc_ctl_map,
+ .pdata = _arasan_cqe_pdata,
+};
+
#ifdef CONFIG_PM_SLEEP
/**
* sdhci_arasan_suspend - Suspend method for the driver
@@ -489,6 +500,10 @@ static const struct of_device_id sdhci_arasan_of_match[] =
{
.compatible = "intel,lgm-sdhci-5.1-emmc",
.data = _lgm_emmc_data,
},
+ {
+ .compatible = "intel,lgm-sdhci-5.1-sdxc",
+ .data = _lgm_sdxc_data,
+ },
/* Generic compatible below here */
{
.compatible = "arasan,sdhci-8.9a",
--
2.11.0
[PATCH v2 1/2] dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM SDXC
From: Ramuthevar Vadivel Murugan
Add a new compatible to use the sdhc-arasan host controller driver
with the SDXC PHY to support on Intel's Lightning Mountain(LGM) SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 7ca0aa7ccc0b..eb78d9a28c8b 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -19,6 +19,8 @@ Required Properties:
Note: This binding has been deprecated and moved to [5].
- "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY
For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
+- "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1": Intel LGM SDXC PHY
+ For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
[5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt
@@ -97,3 +99,18 @@ Example:
phy-names = "phy_arasan";
arasan,soc-ctl-syscon = <>;
};
+
+ sdxc: sdhci@ec60 {
+ compatible = "arasan,sdhci-5.1", "intel,lgm-sdhci-5.1-sdxc";
+ reg = <0xec60 0x300>;
+ interrupt-parent = <>;
+ interrupts = <43 1>;
+ clocks = < LGM_CLK_SDIO>, < LGM_CLK_NGI>,
+< LGM_GCLK_SDXC>;
+ clock-names = "clk_xin", "clk_ahb", "gate";
+ clock-output-names = "sdxc_cardclock";
+ #clock-cells = <0>;
+ phys = <_phy>;
+ phy-names = "phy_arasan";
+ arasan,soc-ctl-syscon = <>;
+ };
--
2.11.0
[PATCH v2 0/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
The current arasan sdhci PHY configuration isn't compatible with the PHY on Intel's LGM(Lightning Mountain) SoC devices. Therefore, add a new compatible, to adapt the Intel's LGM SDXC PHY with arasan-sdhc controller to configure the PHY. Linux code base : V5.4-rc1 Ramuthevar Vadivel Murugan (2): dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM SDXC mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC changes from v1: - commit message updated - Acked-by tag added Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 + drivers/mmc/host/sdhci-of-arasan.c | 15 +++ 2 files changed, 32 insertions(+) -- 2.11.0
Re: [PATCH v5 1/2] dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY
Hi Rob,
On 18/9/2019 10:23 AM, Ramuthevar, Vadivel MuruganX wrote:
Hi Rob,
Thank you for the review comments.
On 17/9/2019 10:23 PM, Rob Herring wrote:
On Wed, Sep 04, 2019 at 01:53:43PM +0800, Ramuthevar,Vadivel MuruganX
wrote:
From: Ramuthevar Vadivel Murugan
Add a YAML schema to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
changes in v5:
- earlier Review-by tag given by Rob
- rework done with syscon parent node.
changes in v4:
- As per Rob's review: validate 5.2 and 5.3
- drop unrelated items.
changes in v3:
- resolve 'make dt_binding_check' warnings
changes in v2:
As per Rob Herring review comments, the following updates
- change GPL-2.0 -> (GPL-2.0-only OR BSD-2-Clause)
- filename is the compatible string plus .yaml
- LGM: Lightning Mountain
- update maintainer
- add intel,syscon under property list
- keep one example instead of two
---
.../bindings/phy/intel,lgm-emmc-phy.yaml | 69
++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
diff --git
a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
new file mode 100644
index ..8f6ac8b3da42
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) eMMC PHY Device Tree Bindings
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+description: Bindings for eMMC PHY on Intel's Lightning Mountain
SoC, syscon
+ node is used to reference the base address of eMMC phy registers.
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: intel,lgm-syscon
This, plus...
you mean, need to add two compatible here-itself look like below
const: intel,lgm-syscon
const: intel,lgm-emmc-phy
Is it right?
Shall I proceed with above compatibles if you agree upon. Thanks!
With Best Regards
Vadivel Murugan
+
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+properties:
+ "#phy-cells":
+ const: 0
+
+ compatible:
+ contains:
+ const: intel,lgm-emmc-phy
...this should not pass validation as they contradict each other.
when I do "make dt_binding_check" didn't throw an error, let me
double confirm once clarified first comment.
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ sysconf: chiptop@e020 {
+ compatible = "intel,lgm-syscon";
+ reg = <0xe020 0x100>;
I'm still waiting for a complete description of what all is in this
block.
Agree!, I will add it.
+
+ emmc-phy: emmc-phy {
+ compatible = "intel,lgm-emmc-phy";
+ reg = <0x00a8 0x4>,
+ <0x00ac 0x4>,
+ <0x00b0 0x4>,
+ <0x00b4 0x4>;
Looks contiguous and can be a single entry:
<0xa8 0x10>
Agreed, will fix it.
Best Regards
Vadivel
+ clocks = <>;
+ clock-names = "emmcclk";
+ #phy-cells = <0>;
+ };
+ };
+...
--
2.11.0
Re: [PATCH v1 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
Hi Adrian, On 3/10/2019 3:46 PM, Ramuthevar, Vadivel MuruganX wrote: Hi Adrian, Thank you for the comments. On 3/10/2019 3:02 PM, Adrian Hunter wrote: On 3/10/19 7:00 AM, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan The current arasan sdhci PHY configuration isn't compatible with the PHY on Intel's LGM(Lightning Mountain) SoC devices. Therefore, add a new compatible, to adapt the Intel's LGM SDXC PHY with arasan-sdhc controller to configure the PHY. Signed-off-by: Ramuthevar Vadivel Murugan Aren't these patches already in v5.4-rc1 No, these patches are not there in v5.4-rc1. The one which is in v5.4-rc1 supports only eMMC, does not SD/SDIO, so these patches are required. can you please provide your suggestions and opinions further on the above reply, to proceed, Thanks! --- With Best Regards Vadivel Murugan
Re: [PATCH v1 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
Hi Adrian, Thank you for the comments. On 3/10/2019 3:02 PM, Adrian Hunter wrote: On 3/10/19 7:00 AM, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan The current arasan sdhci PHY configuration isn't compatible with the PHY on Intel's LGM(Lightning Mountain) SoC devices. Therefore, add a new compatible, to adapt the Intel's LGM SDXC PHY with arasan-sdhc controller to configure the PHY. Signed-off-by: Ramuthevar Vadivel Murugan Aren't these patches already in v5.4-rc1 No, these patches are not there in v5.4-rc1. The one which is in v5.4-rc1 supports only eMMC, does not SD/SDIO, so these patches are required. --- With Best Regards Vadivel Murugan
[PATCH v1 0/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
The current arasan sdhci PHY configuration isn't compatible with the PHY on Intel's LGM(Lightning Mountain) SoC devices. Therefore, add a new compatible, to adapt the Intel's LGM SDXC PHY with arasan-sdhc controller to configure the PHY. Linux code base : V5.4-rc1 Ramuthevar Vadivel Murugan (2): dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM SDXC mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 + drivers/mmc/host/sdhci-of-arasan.c | 15 +++ 2 files changed, 32 insertions(+) -- 2.11.0
[PATCH v1 1/2] dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM SDXC
From: Ramuthevar Vadivel Murugan
Add a new compatible to use the sdhc-arasan host controller driver
with the eMMC PHY on Intel's Lightning Mountain(LGM) SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 7ca0aa7ccc0b..eb78d9a28c8b 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -19,6 +19,8 @@ Required Properties:
Note: This binding has been deprecated and moved to [5].
- "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY
For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
+- "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1": Intel LGM SDXC PHY
+ For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
[5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt
@@ -97,3 +99,18 @@ Example:
phy-names = "phy_arasan";
arasan,soc-ctl-syscon = <>;
};
+
+ sdxc: sdhci@ec60 {
+ compatible = "arasan,sdhci-5.1", "intel,lgm-sdhci-5.1-sdxc";
+ reg = <0xec60 0x300>;
+ interrupt-parent = <>;
+ interrupts = <43 1>;
+ clocks = < LGM_CLK_SDIO>, < LGM_CLK_NGI>,
+< LGM_GCLK_SDXC>;
+ clock-names = "clk_xin", "clk_ahb", "gate";
+ clock-output-names = "sdxc_cardclock";
+ #clock-cells = <0>;
+ phys = <_phy>;
+ phy-names = "phy_arasan";
+ arasan,soc-ctl-syscon = <>;
+ };
--
2.11.0
