[v3,0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>

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 and Hauke for the reviews and suggestions.
---
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       | 705 +++++++++++++++++++++
 4 files changed, 775 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
 create mode 100644 drivers/mtd/nand/raw/intel-nand-controller.c

On Fri, 24 Apr 2020 00:21:13 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> +
> +#define EBU_CLC			0x000
> +#define EBU_CLC_RST		0x00000000u
> +
> +#define	EBU_ADDR_SEL(n)		(0x20 + (n) * 4)

	   ^ Please replace those tabs by a single space.

> +#define	EBU_ADDR_MASK		(5 << 4)
> +#define	EBU_ADDR_SEL_REGEN	0x1
> +
> +#define EBU_BUSCON(n)		(0x60 + (n) * 4)
> +#define EBU_BUSCON_CMULT_V4	0x1
> +#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_CS	0x0
> +#define EBU_BUSCON_SETUP_EN	BIT(22)
> +#define EBU_BUSCON_ALEC		0xC000
> +
> +#define EBU_CON			0x0B0
> +#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	0x17400
> +#define	EBU_MEM_BASE_CS_1	0x17C00

If I refer to v2, that's actually 0x17400000 and 0x17C00000.
And I suspect those addresses come from the physical addresses of the
EBU range attached to those CS lines, which can be extracted
from the resource passed to the driver. But maybe I'm wrong.

> +#define	EBU_MEM_OFFSET		0x051

Sorry but that's too vague. What is this mask/offset encoding?

> +
> +#define HSNAND_CTL1		0x110
> +#define HSNAND_CTL1_ADDR_SHIFT	24
> +
> +#define HSNAND_CTL2		0x114
> +#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_C	BIT(4)
> +
> +#define HSNAND_INT_STA		0x128
> +#define HSNAND_INT_STA_WR_C	BIT(4)
> +
> +#define HSNAND_CTL		0x130
> +#define HSNAND_CTL_MODE_ECC	0x1

#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_WRITE	BIT(10)
> +#define HSNAND_CTL_ECC_OFF_V8TH	BIT(11)
> +#define HSNAND_CTL_CKFF_EN	0x0
> +#define HSNAND_CTL_MSG_EN	BIT(17)
> +
> +#define NAND_PARA0		0x13c

Why are some of those registers prefixed NAND and others HSNAND? I
guess HS stands for High-Speed.

> +#define NAND_PARA0_PAGE_V8192	0x3
> +#define NAND_PARA0_PIB_V256	(0x3 << 4)
> +#define NAND_PARA0_BYP_EN_NP	0x0
> +#define NAND_PARA0_BYP_DEC_NP	0x0
> +#define NAND_PARA0_TYPE_ONFI	BIT(18)
> +#define NAND_PARA0_ADEP_EN	BIT(21)
> +
> +#define NAND_CMSG_0		0x150
> +#define NAND_CMSG_1		0x154
> +
> +#define NAND_ALE_OFFS		BIT(2)
> +#define NAND_CLE_OFFS		BIT(3)
> +#define NAND_CS_OFFS		BIT(4)
> +
> +#define NAND_WRITE_CMD		(NAND_CS_OFFS | NAND_CLE_OFFS)
> +#define NAND_WRITE_ADDR		(NAND_CS_OFFS | NAND_ALE_OFFS)

Those macros are no longer used, you can drop them.

> +#define NAND_WRITE_DATA		EBU_CON_CS_P_LOW
> +#define NAND_READ_DATA		EBU_CON_CS_P_LOW

And those should not be used, please use NAND_CS_OFFS instead.

> +
> +#define NAND_ECC_OFFSET		0x008
> +
> +struct ebu_nand_controller {
> +	struct nand_controller	controller;

Can you drop the tabs and use one space between the type and field name?

> +	struct nand_chip	chip;

Can you add a comment explaining that this should be reworked if
someone needs to support more than one chip.

> +	void __iomem		*ebu_addr;
> +	void __iomem		*nand_addr;

Can we get rid of those _addr and rename those fields so they describe
more precisely what the MMIO range is about:

	void __iomem *ebu;
	void __iomem *hsnand;


> +	void __iomem		*chip_addr;

This field should be part of a specialized nand_chip object (see what's
done here [1]). More generally, you should move anything that's
chip-specific to this driver-specific nand_chip object. 

> +	struct clk		*clk;
> +	unsigned long		clk_rate;
> +	u32			cs;
> +	u32			nd_para0;

The cs and nd_para0 fields should be attached to the ebu_nand_chip
object too (see [1]). While you move that, please add a comment saying
that you currently only support single-CE chips.

> +	struct device		*dev;
> +	struct dma_chan		*dma_tx;
> +	struct dma_chan		*dma_rx;
> +	struct completion	dma_access_complete;

Maybe

	struct {
		struct dma_chan *tx;
		struct dma_chan *rx;
		struct completion complete;
	} dma;

> +	const char *cs_name;

You no longer use this field.

> +};
> +
> +static inline struct ebu_nand_controller *nand_to_ebu(struct nand_chip *chip)
> +{
> +	return container_of(chip, struct ebu_nand_controller, chip);
> +}
> +
> +static u8 ebu_nand_readb(struct nand_chip *chip, unsigned int op)
> +{
> +	struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
> +	void __iomem *nand_wait = ebu_host->ebu_addr + EBU_WAIT;
> +	u32 stat;
> +	int ret;
> +	u8 val;
> +
> +	val = readb(ebu_host->chip_addr + op);

No need for op here, just pass NAND_CS_OFFS directly, and you can drop
the op argument.

> +
> +	ret = readl_poll_timeout(nand_wait, stat, stat & EBU_WAIT_WR_C,
> +				 20, 1000);
> +	if (ret)
> +		dev_warn(ebu_host->dev,
> +			 "ebu nand write timeout. nand_wait(0x%p)=0x%x\n",
> +			 nand_wait, readl(nand_wait));

Maybe dev_warn_ratelimited().

> +
> +	return val;
> +}
> +
> +static void ebu_nand_writeb(struct nand_chip *chip, int op, u8 value)

							^u32 offset,

> +{
> +	struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
> +	void __iomem *nand_wait = ebu_host->ebu_addr + EBU_WAIT;
> +	u32 stat;
> +	int ret;
> +
> +	writeb(value, ebu_host->chip_addr + op);
> +
> +	ret = readl_poll_timeout(nand_wait, stat, stat & EBU_WAIT_WR_C,
> +				 20, 1000);
> +	if (ret)
> +		dev_warn(ebu_host->dev,
> +			 "ebu nand write timeout. nand_wait(0x%p)=0x%x\n",
> +			 nand_wait, readl(nand_wait));
> +}
> +
> +static void ebu_read_buf(struct nand_chip *chip, u_char *buf, int len)

						      ^void *	   ^unsigned int

Please update all of those.

> +{
> +	int i;
> +
> +	for (i = 0; i < len; i++)
> +		buf[i] = ebu_nand_readb(chip, NAND_READ_DATA);
> +}
> +
> +static void ebu_write_buf(struct nand_chip *chip, const u_char *buf, int len)
> +{
> +	int i;
> +
> +	for (i = 0; i < len; i++)
> +		ebu_nand_writeb(chip, NAND_WRITE_DATA, buf[i]);

				      ^NAND_CS_OFFS

> +}
> +
> +static void ebu_unselect_chip(struct nand_chip *chip)
> +{
> +	struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
> +	void __iomem *nand_con = ebu_host->ebu_addr + EBU_CON;
> +	int val;

	^u32

> +
> +	val = readl(nand_con);
> +	writel(val & ~EBU_CON_NANDM_EN, nand_con);

And I suspect you could just do:

	writel(0, ebu_host->ebu + EBU_CON);

here.

BTW, maybe we don't have to unselect the chip and can instead do this
'disable NAND module' in a runtime PM hook when the NAND has been
unused for some time, but let's keep that for later.

> +}

...

> +static int ebu_nand_exec_op(struct nand_chip *chip,
> +			    const struct nand_operation *op, bool check_only)
> +{
> +	struct ebu_nand_controller *ctrl = nand_to_ebu(chip);
> +	const struct nand_op_instr *instr = NULL;
> +	unsigned int op_id;
> +	int i, time_out, ret = 0;
> +	u32 stat;
> +
> +	ebu_select_chip(chip);
> +
> +	for (op_id = 0; op_id < op->ninstrs; op_id++) {
> +		instr = &op->instrs[op_id];
> +
> +		switch (instr->type) {
> +		case NAND_OP_CMD_INSTR:
> +			ebu_nand_writeb(chip, NAND_CLE_OFFS,

Hm, are you sure you shouldn't add NAND_CS_OFFS here? I'd expect
the CS to be asserted when the CLE/ALE pin is. Or maybe NAND_CS_OFFS
is not about CS pin assertion/de-assertion, in which case this should
be documented (and the name should be changed accordingly).

> +					instr->ctx.cmd.opcode);
> +			break;
> +
> +		case NAND_OP_ADDR_INSTR:
> +			for (i = 0; i < instr->ctx.addr.naddrs; i++)
> +				ebu_nand_writeb(chip, NAND_ALE_OFFS,
> +						instr->ctx.addr.addrs[i]);
> +			break;
> +
> +		case NAND_OP_DATA_IN_INSTR:
> +			ebu_read_buf(chip, instr->ctx.data.buf.in,
> +				     instr->ctx.data.len);
> +			break;
> +
> +		case NAND_OP_DATA_OUT_INSTR:
> +			ebu_write_buf(chip, instr->ctx.data.buf.out,
> +				      instr->ctx.data.len);
> +			break;
> +
> +		case NAND_OP_WAITRDY_INSTR:
> +			time_out = instr->ctx.waitrdy.timeout_ms * 1000;
> +			ret = readl_poll_timeout(ctrl->ebu_addr + EBU_WAIT,
> +						 stat, stat & EBU_WAIT_RDBY,
> +						 20, time_out);
> +			break;
> +		}
> +	}

Yay! I really like this new version of exec_op().

> +
> +	ebu_unselect_chip(chip);
> +
> +	return ret;
> +}
> +
> +static const struct nand_controller_ops ebu_nand_controller_ops = {
> +	.attach_chip = ebu_nand_attach_chip,
> +	.exec_op = ebu_nand_exec_op,
> +};
> +
> +static void ebu_dma_cleanup(struct ebu_nand_controller *ebu_host)
> +{
> +	if (ebu_host->dma_rx) {
> +		dma_release_channel(ebu_host->dma_rx);
> +		ebu_host->dma_rx = NULL;

You don't need to reset the value here.

> +	}
> +
> +	if (ebu_host->dma_tx) {
> +		dma_release_channel(ebu_host->dma_tx);
> +		ebu_host->dma_tx = NULL;
> +	}
> +}
> +
> +static int ebu_nand_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->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(&ebu_host->controller);
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);

CS ids should be encoded in the reg property (see [1]).

> +	if (ret) {
> +		dev_err(dev, "failed to get chip select: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ebu_host->cs = cs;
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_cs0");

	resname = devm_kasprintf("nand-cs%d", cs);
	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resname);

> +	ebu_host->chip_addr = devm_ioremap_resource(&pdev->dev, res);
> +	nandaddr_pa = res->start;
> +	if (IS_ERR(ebu_host->chip_addr))
> +		return PTR_ERR(ebu_host->chip_addr);
> +
> +	ebu_host->clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(ebu_host->clk)) {
> +		ret = PTR_ERR(ebu_host->clk);
> +		dev_err(dev, "failed to get clock: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_prepare_enable(ebu_host->clk);
> +	if (ret) {
> +		dev_err(dev, "failed to enable clock: %d\n", ret);
> +		return ret;
> +	}
> +	ebu_host->clk_rate = clk_get_rate(ebu_host->clk);
> +
> +	ebu_host->dma_tx = dma_request_chan(dev, "tx");
> +	if (IS_ERR(ebu_host->dma_tx)) {
> +		ret = PTR_ERR(ebu_host->dma_tx);
> +		dev_err(dev, "DMA tx channel request fail!.\n");
> +		goto exit_dma;
> +	}
> +
> +	ebu_host->dma_rx = dma_request_chan(dev, "rx");
> +	if (IS_ERR(ebu_host->dma_rx)) {
> +		ret = PTR_ERR(ebu_host->dma_rx);
> +		dev_err(dev, "DMA tx channel request fail!.\n");
> +		goto exit_dma;
> +	}
> +
> +	writel(lower_32_bits(nandaddr_pa) | EBU_ADDR_SEL_REGEN | EBU_ADDR_MASK,
> +	       ebu_host->ebu_addr + EBU_ADDR_SEL(cs));
> +
> +	writel(EBU_BUSCON_CMULT_V4 | EBU_BUSCON_RECOVC(1) |
> +	       EBU_BUSCON_HOLDC(1) | EBU_BUSCON_WAITRDC(2) |
> +	       EBU_BUSCON_WAITWRC(2) | EBU_BUSCON_BCGEN_CS | EBU_BUSCON_ALEC |
> +	       EBU_BUSCON_SETUP_EN, ebu_host->ebu_addr + EBU_BUSCON(cs));

Again, can you try to implement ->setup_data_interface()?

> +
> +	/*
> +	 * NAND physical address selection is based on the chip select
> +	 * and written to ADDR_SEL register to get Memory Region Base address.
> +	 * FPI Bus addresses are compared to this base address in conjunction
> +	 * with the mask control. Driver need to program this field!
> +	 * Address: 0x17400 if chip select is CS_0
> +	 * Address: 0x17C00 if chip select is CS_1
> +	 */
> +	writel(EBU_MEM_BASE_CS_0 + EBU_MEM_OFFSET,
> +	       ebu_host->ebu_addr + EBU_ADDR_SEL(0));
> +	writel(EBU_MEM_BASE_CS_1 + EBU_MEM_OFFSET,
> +	       ebu_host->ebu_addr + EBU_ADDR_SEL(cs));

See my comments on those values. I feel like the mapping should be
created based on information we gather from somewhere else.

> +	nand_set_flash_node(&ebu_host->chip, dev->of_node);
> +	mtd = nand_to_mtd(&ebu_host->chip);
> +	mtd->dev.parent = dev;
> +	ebu_host->dev = dev;
> +
> +	platform_set_drvdata(pdev, ebu_host);
> +	nand_set_controller_data(&ebu_host->chip, ebu_host);
> +
> +	nand = &ebu_host->chip;
> +	nand->controller = &ebu_host->controller;
> +	nand->controller->ops = &ebu_nand_controller_ops;
> +
> +	/* Scan to find existence of the device */
> +	ret = nand_scan(&ebu_host->chip, 1);
> +	if (ret)
> +		goto exit_dma;
> +
> +	ret = mtd_device_register(mtd, NULL, 0);
> +	if (ret)
> +		goto clean_nand;
> +
> +	return 0;
> +
> +clean_nand:

err_cleanup_nand:

> +	nand_cleanup(&ebu_host->chip);
> +exit_dma:

err_cleanup_dma:

> +	ebu_dma_cleanup(ebu_host);
> +	clk_disable_unprepare(ebu_host->clk);
> +
> +	return ret;
> +}
> +
> +static int ebu_nand_remove(struct platform_device *pdev)
> +{
> +	struct ebu_nand_controller *ebu_host = platform_get_drvdata(pdev);
> +
> +	mtd_device_unregister(nand_to_mtd(&ebu_host->chip));

Check the return value of this function please.


[1]https://elixir.bootlin.com/linux/v5.6/source/drivers/mtd/nand/raw/atmel/nand-controller.c#L148

Hi Boris,

     Thank you  very much for review comments and your time...
On 25/4/2020 12:36 am, Boris Brezillon wrote:
 > On Fri, 24 Apr 2020 00:21:13 +0800
 > "Ramuthevar, Vadivel MuruganX"
 > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
 >
 >> +
 >> +#define EBU_CLC			0x000
 >> +#define EBU_CLC_RST		0x00000000u
 >> +
 >> +#define	EBU_ADDR_SEL(n)		(0x20 + (n) * 4)
 > 	   ^ Please replace those tabs by a single space.
Noted.
 >> +#define	EBU_ADDR_MASK		(5 << 4)
 >> +#define	EBU_ADDR_SEL_REGEN	0x1
 >> +
 >> +#define EBU_BUSCON(n)		(0x60 + (n) * 4)
 >> +#define EBU_BUSCON_CMULT_V4	0x1
 >> +#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_CS	0x0
 >> +#define EBU_BUSCON_SETUP_EN	BIT(22)
 >> +#define EBU_BUSCON_ALEC		0xC000
 >> +
 >> +#define EBU_CON			0x0B0
 >> +#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	0x17400
 >> +#define	EBU_MEM_BASE_CS_1	0x17C00
 > If I refer to v2, that's actually 0x17400000 and 0x17C00000.
 > And I suspect those addresses come from the physical addresses of the
 > EBU range attached to those CS lines, which can be extracted
 > from the resource passed to the driver. But maybe I'm wrong.
Agreed!, will update.
 >> +#define	EBU_MEM_OFFSET		0x051
 > Sorry but that's too vague. What is this mask/offset encoding?
it's not offset, wrongly mentioned name as offset, bit field values.
will correct it.
 >> +
 >> +#define HSNAND_CTL1		0x110
 >> +#define HSNAND_CTL1_ADDR_SHIFT	24
 >> +
 >> +#define HSNAND_CTL2		0x114
 >> +#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_C	BIT(4)
 >> +
 >> +#define HSNAND_INT_STA		0x128
 >> +#define HSNAND_INT_STA_WR_C	BIT(4)
 >> +
 >> +#define HSNAND_CTL		0x130
 >> +#define HSNAND_CTL_MODE_ECC	0x1
 > #define HSNAND_CTL_ENABLE_ECC	BIT(0)
Noted, will update
 >> +#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_WRITE	BIT(10)
 >> +#define HSNAND_CTL_ECC_OFF_V8TH	BIT(11)
 >> +#define HSNAND_CTL_CKFF_EN	0x0
 >> +#define HSNAND_CTL_MSG_EN	BIT(17)
 >> +
 >> +#define NAND_PARA0		0x13c
 > Why are some of those registers prefixed NAND and others HSNAND? I
 > guess HS stands for High-Speed.
To differentiate the common HSNAND registers between MIPS and X86 based 
SoC's
 >> +#define NAND_PARA0_PAGE_V8192	0x3
 >> +#define NAND_PARA0_PIB_V256	(0x3 << 4)
 >> +#define NAND_PARA0_BYP_EN_NP	0x0
 >> +#define NAND_PARA0_BYP_DEC_NP	0x0
 >> +#define NAND_PARA0_TYPE_ONFI	BIT(18)
 >> +#define NAND_PARA0_ADEP_EN	BIT(21)
 >> +
 >> +#define NAND_CMSG_0		0x150
 >> +#define NAND_CMSG_1		0x154
 >> +
 >> +#define NAND_ALE_OFFS		BIT(2)
 >> +#define NAND_CLE_OFFS		BIT(3)
 >> +#define NAND_CS_OFFS		BIT(4)
 >> +
 >> +#define NAND_WRITE_CMD		(NAND_CS_OFFS | NAND_CLE_OFFS)
 >> +#define NAND_WRITE_ADDR		(NAND_CS_OFFS | NAND_ALE_OFFS)
 > Those macros are no longer used, you can drop them.
Noted, will drop them
 >> +#define NAND_WRITE_DATA		EBU_CON_CS_P_LOW
 >> +#define NAND_READ_DATA		EBU_CON_CS_P_LOW
 > And those should not be used, please use NAND_CS_OFFS instead.
Sure, Noted
 >> +
 >> +#define NAND_ECC_OFFSET		0x008
 >> +
 >> +struct ebu_nand_controller {
 >> +	struct nand_controller	controller;
 > Can you drop the tabs and use one space between the type and field name?
Noted
 >> +	struct nand_chip	chip;
 > Can you add a comment explaining that this should be reworked if
 > someone needs to support more than one chip.
Sure, will add comments
 >> +	void __iomem		*ebu_addr;
 >> +	void __iomem		*nand_addr;
 > Can we get rid of those _addr and rename those fields so they describe
 > more precisely what the MMIO range is about:
 >
 > 	void __iomem *ebu;
 > 	void __iomem *hsnand;
 >
Noted
 >> +	void __iomem		*chip_addr;
 > This field should be part of a specialized nand_chip object (see what's
 > done here [1]). More generally, you should move anything that's
 > chip-specific to this driver-specific nand_chip object.
I supposed to add like nand_cs, will change it.
 >> +	struct clk		*clk;
 >> +	unsigned long		clk_rate;
 >> +	u32			cs;
 >> +	u32			nd_para0;
 > The cs and nd_para0 fields should be attached to the ebu_nand_chip
 > object too (see [1]). While you move that, please add a comment saying
 > that you currently only support single-CE chips.
Yes, you are correct, will do that
 >> +	struct device		*dev;
 >> +	struct dma_chan		*dma_tx;
 >> +	struct dma_chan		*dma_rx;
 >> +	struct completion	dma_access_complete;
 > Maybe
 >
 > 	struct {
 > 		struct dma_chan *tx;
 > 		struct dma_chan *rx;
 > 		struct completion complete;
 > 	} dma;
Ok, Noted
 >> +	const char *cs_name;
 > You no longer use this field.
Noted, will drop it.
 >> +};
 >> +
 >> +static inline struct ebu_nand_controller *nand_to_ebu(struct 
nand_chip *chip)
 >> +{
 >> +	return container_of(chip, struct ebu_nand_controller, chip);
 >> +}
 >> +
 >> +static u8 ebu_nand_readb(struct nand_chip *chip, unsigned int op)
 >> +{
 >> +	struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
 >> +	void __iomem *nand_wait = ebu_host->ebu_addr + EBU_WAIT;
 >> +	u32 stat;
 >> +	int ret;
 >> +	u8 val;
 >> +
 >> +	val = readb(ebu_host->chip_addr + op);
 > No need for op here, just pass NAND_CS_OFFS directly, and you can drop
 > the op argument.
Noted, will update.
 >> +
 >> +	ret = readl_poll_timeout(nand_wait, stat, stat & EBU_WAIT_WR_C,
 >> +				 20, 1000);
 >> +	if (ret)
 >> +		dev_warn(ebu_host->dev,
 >> +			 "ebu nand write timeout. nand_wait(0x%p)=0x%x\n",
 >> +			 nand_wait, readl(nand_wait));
 > Maybe dev_warn_ratelimited().
Not required, might be used for network drivers.
 >> +
 >> +	return val;
 >> +}
 >> +
 >> +static void ebu_nand_writeb(struct nand_chip *chip, int op, u8 value)
 > 							^u32 offset,
 >
 >> +{
 >> +	struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
 >> +	void __iomem *nand_wait = ebu_host->ebu_addr + EBU_WAIT;
 >> +	u32 stat;
 >> +	int ret;
 >> +
 >> +	writeb(value, ebu_host->chip_addr + op);
 >> +
 >> +	ret = readl_poll_timeout(nand_wait, stat, stat & EBU_WAIT_WR_C,
 >> +				 20, 1000);
 >> +	if (ret)
 >> +		dev_warn(ebu_host->dev,
 >> +			 "ebu nand write timeout. nand_wait(0x%p)=0x%x\n",
 >> +			 nand_wait, readl(nand_wait));
 >> +}
 >> +
 >> +static void ebu_read_buf(struct nand_chip *chip, u_char *buf, int len)
 > 						      ^void *	   ^unsigned int
 >
 > Please update all of those.
Sure, will update all.
 >> +{
 >> +	int i;
 >> +
 >> +	for (i = 0; i < len; i++)
 >> +		buf[i] = ebu_nand_readb(chip, NAND_READ_DATA);
 >> +}
 >> +
 >> +static void ebu_write_buf(struct nand_chip *chip, const u_char 
*buf, int len)
 >> +{
 >> +	int i;
 >> +
 >> +	for (i = 0; i < len; i++)
 >> +		ebu_nand_writeb(chip, NAND_WRITE_DATA, buf[i]);
 > 				      ^NAND_CS_OFFS
Noted.
 >> +}
 >> +
 >> +static void ebu_unselect_chip(struct nand_chip *chip)
 >> +{
 >> +	struct ebu_nand_controller *ebu_host = nand_get_controller_data(chip);
 >> +	void __iomem *nand_con = ebu_host->ebu_addr + EBU_CON;
 >> +	int val;
 > 	^u32
 >
 >> +
 >> +	val = readl(nand_con);
 >> +	writel(val & ~EBU_CON_NANDM_EN, nand_con);
 > And I suspect you could just do:
 >
 > 	writel(0, ebu_host->ebu + EBU_CON);
 >
 > here.
 >
 > BTW, maybe we don't have to unselect the chip and can instead do this
 > 'disable NAND module' in a runtime PM hook when the NAND has been
 > unused for some time, but let's keep that for later.
Sure, Noted.
 >> +}
 > ...
 >
 >> +static int ebu_nand_exec_op(struct nand_chip *chip,
 >> +			    const struct nand_operation *op, bool check_only)
 >> +{
 >> +	struct ebu_nand_controller *ctrl = nand_to_ebu(chip);
 >> +	const struct nand_op_instr *instr = NULL;
 >> +	unsigned int op_id;
 >> +	int i, time_out, ret = 0;
 >> +	u32 stat;
 >> +
 >> +	ebu_select_chip(chip);
 >> +
 >> +	for (op_id = 0; op_id < op->ninstrs; op_id++) {
 >> +		instr = &op->instrs[op_id];
 >> +
 >> +		switch (instr->type) {
 >> +		case NAND_OP_CMD_INSTR:
 >> +			ebu_nand_writeb(chip, NAND_CLE_OFFS,
 > Hm, are you sure you shouldn't add NAND_CS_OFFS here? I'd expect
 > the CS to be asserted when the CLE/ALE pin is. Or maybe NAND_CS_OFFS
 > is not about CS pin assertion/de-assertion, in which case this should
 > be documented (and the name should be changed accordingly).
before doing the read/write asserting the chip by chip_select function, 
let me double check
as you said, will update accordingly
 >> +					instr->ctx.cmd.opcode);
 >> +			break;
 >> +
 >> +		case NAND_OP_ADDR_INSTR:
 >> +			for (i = 0; i < instr->ctx.addr.naddrs; i++)
 >> +				ebu_nand_writeb(chip, NAND_ALE_OFFS,
 >> +						instr->ctx.addr.addrs[i]);
 >> +			break;
 >> +
 >> +		case NAND_OP_DATA_IN_INSTR:
 >> +			ebu_read_buf(chip, instr->ctx.data.buf.in,
 >> +				     instr->ctx.data.len);
 >> +			break;
 >> +
 >> +		case NAND_OP_DATA_OUT_INSTR:
 >> +			ebu_write_buf(chip, instr->ctx.data.buf.out,
 >> +				      instr->ctx.data.len);
 >> +			break;
 >> +
 >> +		case NAND_OP_WAITRDY_INSTR:
 >> +			time_out = instr->ctx.waitrdy.timeout_ms * 1000;
 >> +			ret = readl_poll_timeout(ctrl->ebu_addr + EBU_WAIT,
 >> +						 stat, stat & EBU_WAIT_RDBY,
 >> +						 20, time_out);
 >> +			break;
 >> +		}
 >> +	}
 > Yay! I really like this new version of exec_op().
Thank you Boris!
 >> +
 >> +	ebu_unselect_chip(chip);
 >> +
 >> +	return ret;
 >> +}
 >> +
 >> +static const struct nand_controller_ops ebu_nand_controller_ops = {
 >> +	.attach_chip = ebu_nand_attach_chip,
 >> +	.exec_op = ebu_nand_exec_op,
 >> +};
 >> +
 >> +static void ebu_dma_cleanup(struct ebu_nand_controller *ebu_host)
 >> +{
 >> +	if (ebu_host->dma_rx) {
 >> +		dma_release_channel(ebu_host->dma_rx);
 >> +		ebu_host->dma_rx = NULL;
 > You don't need to reset the value here.
Noted.
 >> +	}
 >> +
 >> +	if (ebu_host->dma_tx) {
 >> +		dma_release_channel(ebu_host->dma_tx);
 >> +		ebu_host->dma_tx = NULL;
 >> +	}
 >> +}
 >> +
 >> +static int ebu_nand_probe(struct platform_device *pdev)
 >> +{
 >> +	struct device *dev = &pdev->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(&ebu_host->controller);
 >> +
 >> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
 >> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);
 > CS ids should be encoded in the reg property (see [1]).
Ok, will check.
 >> +	if (ret) {
 >> +		dev_err(dev, "failed to get chip select: %d\n", ret);
 >> +		return ret;
 >> +	}
 >> +
 >> +	ebu_host->cs = cs;
 >> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_cs0");
 > 	resname = devm_kasprintf("nand-cs%d", cs);
 > 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resname);
I have kept same-way in my earlier patches , will update.
 >> +	ebu_host->chip_addr = devm_ioremap_resource(&pdev->dev, res);
 >> +	nandaddr_pa = res->start;
 >> +	if (IS_ERR(ebu_host->chip_addr))
 >> +		return PTR_ERR(ebu_host->chip_addr);
 >> +
 >> +	ebu_host->clk = devm_clk_get(dev, NULL);
 >> +	if (IS_ERR(ebu_host->clk)) {
 >> +		ret = PTR_ERR(ebu_host->clk);
 >> +		dev_err(dev, "failed to get clock: %d\n", ret);
 >> +		return ret;
 >> +	}
 >> +
 >> +	ret = clk_prepare_enable(ebu_host->clk);
 >> +	if (ret) {
 >> +		dev_err(dev, "failed to enable clock: %d\n", ret);
 >> +		return ret;
 >> +	}
 >> +	ebu_host->clk_rate = clk_get_rate(ebu_host->clk);
 >> +
 >> +	ebu_host->dma_tx = dma_request_chan(dev, "tx");
 >> +	if (IS_ERR(ebu_host->dma_tx)) {
 >> +		ret = PTR_ERR(ebu_host->dma_tx);
 >> +		dev_err(dev, "DMA tx channel request fail!.\n");
 >> +		goto exit_dma;
 >> +	}
 >> +
 >> +	ebu_host->dma_rx = dma_request_chan(dev, "rx");
 >> +	if (IS_ERR(ebu_host->dma_rx)) {
 >> +		ret = PTR_ERR(ebu_host->dma_rx);
 >> +		dev_err(dev, "DMA tx channel request fail!.\n");
 >> +		goto exit_dma;
 >> +	}
 >> +
 >> +	writel(lower_32_bits(nandaddr_pa) | EBU_ADDR_SEL_REGEN | 
EBU_ADDR_MASK,
 >> +	       ebu_host->ebu_addr + EBU_ADDR_SEL(cs));
 >> +
 >> +	writel(EBU_BUSCON_CMULT_V4 | EBU_BUSCON_RECOVC(1) |
 >> +	       EBU_BUSCON_HOLDC(1) | EBU_BUSCON_WAITRDC(2) |
 >> +	       EBU_BUSCON_WAITWRC(2) | EBU_BUSCON_BCGEN_CS | EBU_BUSCON_ALEC |
 >> +	       EBU_BUSCON_SETUP_EN, ebu_host->ebu_addr + EBU_BUSCON(cs));
 > Again, can you try to implement ->setup_data_interface()?
Sure, will implement .
 >> +
 >> +	/*
 >> +	 * NAND physical address selection is based on the chip select
 >> +	 * and written to ADDR_SEL register to get Memory Region Base address.
 >> +	 * FPI Bus addresses are compared to this base address in conjunction
 >> +	 * with the mask control. Driver need to program this field!
 >> +	 * Address: 0x17400 if chip select is CS_0
 >> +	 * Address: 0x17C00 if chip select is CS_1
 >> +	 */
 >> +	writel(EBU_MEM_BASE_CS_0 + EBU_MEM_OFFSET,
 >> +	       ebu_host->ebu_addr + EBU_ADDR_SEL(0));
 >> +	writel(EBU_MEM_BASE_CS_1 + EBU_MEM_OFFSET,
 >> +	       ebu_host->ebu_addr + EBU_ADDR_SEL(cs));
 > See my comments on those values. I feel like the mapping should be
 > created based on information we gather from somewhere else.
Yes, of-course will update the proper way.
 >> +	nand_set_flash_node(&ebu_host->chip, dev->of_node);
 >> +	mtd = nand_to_mtd(&ebu_host->chip);
 >> +	mtd->dev.parent = dev;
 >> +	ebu_host->dev = dev;
 >> +
 >> +	platform_set_drvdata(pdev, ebu_host);
 >> +	nand_set_controller_data(&ebu_host->chip, ebu_host);
 >> +
 >> +	nand = &ebu_host->chip;
 >> +	nand->controller = &ebu_host->controller;
 >> +	nand->controller->ops = &ebu_nand_controller_ops;
 >> +
 >> +	/* Scan to find existence of the device */
 >> +	ret = nand_scan(&ebu_host->chip, 1);
 >> +	if (ret)
 >> +		goto exit_dma;
 >> +
 >> +	ret = mtd_device_register(mtd, NULL, 0);
 >> +	if (ret)
 >> +		goto clean_nand;
 >> +
 >> +	return 0;
 >> +
 >> +clean_nand:
 > err_cleanup_nand:
Noted.
 >> +	nand_cleanup(&ebu_host->chip);
 >> +exit_dma:
 > err_cleanup_dma:
Noted.
 >> +	ebu_dma_cleanup(ebu_host);
 >> +	clk_disable_unprepare(ebu_host->clk);
 >> +
 >> +	return ret;
 >> +}
 >> +
 >> +static int ebu_nand_remove(struct platform_device *pdev)
 >> +{
 >> +	struct ebu_nand_controller *ebu_host = platform_get_drvdata(pdev);
 >> +
 >> +	mtd_device_unregister(nand_to_mtd(&ebu_host->chip));
 > Check the return value of this function please.

sure, will check and update.
Regards
Vadivel

Hi Ramuthevar,

> > +static int ebu_nand_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->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(&ebu_host->controller);
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> > +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);  
> 
> 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? If the latter, it would be much better I think
to anticipate the addition of the support for another CS. And in
this case there are many places in this driver that should be
more generic.

> > +	if (ret) {
> > +		dev_err(dev, "failed to get chip select: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	ebu_host->cs = cs;
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_cs0");  

Thanks,
Miquèl

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 = &pdev->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(&ebu_host->controller);
>>> +
>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);
>>
>> 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

Regards
Vadivel
  If the latter, it would be much better I think
> to anticipate the addition of the support for another CS. And in
> this case there are many places in this driver that should be
> more generic.
> 
>>> +	if (ret) {
>>> +		dev_err(dev, "failed to get chip select: %d\n", ret);
>>> +		return ret;
>>> +	}
>>> +
>>> +	ebu_host->cs = cs;
>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_cs0");
> 
> Thanks,
> Miquèl
>

On Tue, 28 Apr 2020 14:17:30 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
> >>> +
> >>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> >>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);  
> >>
> >> 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.

Hi Boris,

On 28/4/2020 2:27 pm, Boris Brezillon wrote:
> On Tue, 28 Apr 2020 14:17:30 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
>>>>> +
>>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
>>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);
>>>>
>>>> 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.
Thanks!

Regards
Vadivel
>

On Tue, 28 Apr 2020 14:40:58 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> 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"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
> >>>>> +
> >>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> >>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);  
> >>>>
> >>>> 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.

Hi Boris,

On 28/4/2020 2:47 pm, Boris Brezillon wrote:
> On Tue, 28 Apr 2020 14:40:58 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
>>>>>>> +
>>>>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
>>>>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);
>>>>>>
>>>>>> 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
>

Hi Vadivel MuruganX,

"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> 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"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
> >>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
> >>>>>>> +
> >>>>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> >>>>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);  
> >>>>>>
> >>>>>> 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.

Thanks,
Miquèl

Hi Miquel,

On 28/4/2020 3:40 pm, Miquel Raynal wrote:
> Hi Vadivel MuruganX,
> 
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
>>>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
>>>>>>>>> +
>>>>>>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
>>>>>>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);
>>>>>>>>
>>>>>>>> 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
>

Hello,

"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> 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"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
> >>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
> >>>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
> >>>>>>>>> +
> >>>>>>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> >>>>>>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);  
> >>>>>>>>
> >>>>>>>> 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"?

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

Hi Miquel,

On 28/4/2020 3:54 pm, Miquel Raynal wrote:
> Hello,
> 
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
>>>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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"
>>>>>>> <vadivel.muruganx.ramuthevar@linux.intel.com> 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 = &pdev->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(&ebu_host->controller);
>>>>>>>>>>> +
>>>>>>>>>>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
>>>>>>>>>>> +	ebu_host->ebu_addr = devm_ioremap_resource(&pdev->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(&pdev->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);
>>>>>>>>>>
>>>>>>>>>> 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
>

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