All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Liang Yang <liang.yang@amlogic.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Yixun Lan <yixun.lan@amlogic.com>,
	Jianxin Pan <jianxin.pan@amlogic.com>, <oxffffaa@gmail.com>,
	<kernel@sberdevices.ru>, <linux-mtd@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-amlogic@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/5] mtd: rawnand: meson: fix command sequence for read/write
Date: Wed, 24 May 2023 12:05:47 +0300	[thread overview]
Message-ID: <abeadc03-a69c-be1c-3c6a-6ce492a5e4f6@sberdevices.ru> (raw)
In-Reply-To: <9013b0e2-c923-43f8-0bd6-979bf0c23ebc@sberdevices.ru>



On 23.05.2023 12:12, Arseniy Krasnov wrote:
> Hello Miquel, Liang
> 
> On 22.05.2023 18:05, Miquel Raynal wrote:
>> Hi Arseniy,
>>
>> AVKrasnov@sberdevices.ru wrote on Mon, 15 May 2023 12:44:35 +0300:
>>
>>> This fixes read/write functionality by:
>>> 1) Changing NFC_CMD_RB_INT bit value.
>>
>> I guess this is a separate fix
>>
> 
> Ok, I'll move it to separate patch
> 
>>> 2) Adding extra NAND_CMD_STATUS command on each r/w request.
>>
>> Is this really needed? Looks like you're delaying the next op only. Is
>> using a delay enough? If yes, then it's probably the wrong approach.

Hi Miquel, small update, I found some details from @Liang's message in v1 talks from the last month:

*
After sending NAND_CMD_READ0, address, NAND_CMD_READSTART and read status(NAND_CMD_STATUS = 0x70) commands, it should send
NAND_CMD_READ0 command for exiting the read status mode from the datasheet from NAND device. but previous meson_nfc_queue_rb()
only checks the Ready/Busy pin and it doesn't send read status(NAND_CMD_STATUS = 0x70) command.
i think there is something wrong with the Ready/Busy pin(please check the hardware whether this
Ready/Busy pin is connected with SOC) or the source code. i have the board without Ready/Busy pin and prefer to use the
nfc command called RB_IO6. it sends NAND_CMD_STATUS command and checks bit6 of the status register of NAND device from the
data bus and generate IRQ if ready.
*

I guess, that sequence of commands from this patch is described in datasheet (unfortunately I don't have it and relied on the old driver).
Yesterday I tried to remove sending of NAND_CMD_STATUS from this patch, but it broke current driver - i had ECC errors, so it looks like
"shot in the dark" situation, to understand this logic.

Thanks, Arseniy

>>
>>> 3) Adding extra idle commands during r/w request.
>>
>> Question about this below, might also be a patch on its own?
>>
>>> 4) Adding extra NAND_CMD_READ0 on each read request.
>>>
>>> Without this patch driver works unstable, for example there are a lot
>>> of ECC errors.
>>
>> I believe all the fixes should be Cc'ed to stable, please add in your
>> commits:
>>
>> Cc: stable@...
>>
> 
> Ack, after everything will be clear with this patch :)
> 
>>>
>>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
>>> Suggested-by: Liang Yang <liang.yang@amlogic.com>
>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>>> ---
>>>  drivers/mtd/nand/raw/meson_nand.c | 30 +++++++++++++++++++++---------
>>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
>>> index 074e14225c06..2f4d8c84186b 100644
>>> --- a/drivers/mtd/nand/raw/meson_nand.c
>>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>>> @@ -37,7 +37,7 @@
>>>  #define NFC_CMD_SCRAMBLER_ENABLE	BIT(19)
>>>  #define NFC_CMD_SCRAMBLER_DISABLE	0
>>>  #define NFC_CMD_SHORTMODE_DISABLE	0
>>> -#define NFC_CMD_RB_INT		BIT(14)
>>> +#define NFC_CMD_RB_INT ((0xb << 10) | BIT(18) | BIT(16))
>>>  
>>>  #define NFC_CMD_GET_SIZE(x)	(((x) >> 22) & GENMASK(4, 0))
>>>  
>>> @@ -392,7 +392,7 @@ static void meson_nfc_set_data_oob(struct nand_chip *nand,
>>>  	}
>>>  }
>>>  
>>> -static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>> +static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms, int cmd_read0)
>>>  {
>>>  	u32 cmd, cfg;
>>>  	int ret = 0;
>>> @@ -407,17 +407,29 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>>  
>>>  	reinit_completion(&nfc->completion);
>>>  
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS;
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 5);
>>
>> Why 5 and 2 below? They look like magic values. Is this totally
>> experimental?
> 
> @Liang, may be change it to defines ?
> 
>>
>>> +
>>>  	/* use the max erase time as the maximum clock for waiting R/B */
>>> -	cmd = NFC_CMD_RB | NFC_CMD_RB_INT
>>> -		| nfc->param.chip_select | nfc->timing.tbers_max;
>>
>> This is not documented in the commit log, is it?
>>
>>> +	cmd = NFC_CMD_RB | NFC_CMD_RB_INT | nfc->timing.tbers_max;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 2);
>>>  
>>>  	ret = wait_for_completion_timeout(&nfc->completion,
>>>  					  msecs_to_jiffies(timeout_ms));
>>>  	if (ret == 0)
>>> -		ret = -1;
>>> +		return -1;
>>
>> Please use real error codes, such as ETIMEDOUT.
> 
> Ack
> 
>>
>>>  
>>> -	return ret;
>>> +	if (!cmd_read0)
>>> +		return 0;
>>> +
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_READ0;
>>
>> This looks really wrong, I don't get why you would need to send an
>> expensive READ0 command.
> 
> This logic was suggested by @Liang Yang here to fix this driver (suggested as patch):
> https://lore.kernel.org/linux-mtd/8537e736-44a8-d17b-7923-25d5bd406dcc@sberdevices.ru/T/#m0df09d2ab2cac98431fb268a4ce3c00dc5c7a69e
> @Liang, could You please give us more details?
> 
> Thanks, Arseniy
> 
>>
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_drain_cmd(nfc);
>>> +	meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT);
>>> +
>>> +	return 0;
>>>  }
>>>  
>>>  static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf)
>>> @@ -623,7 +635,7 @@ static int meson_nfc_rw_cmd_prepare_and_execute(struct nand_chip *nand,
>>>  	if (in) {
>>>  		nfc->cmdfifo.rw.cmd1 = cs | NFC_CMD_CLE | NAND_CMD_READSTART;
>>>  		writel(nfc->cmdfifo.rw.cmd1, nfc->reg_base + NFC_REG_CMD);
>>> -		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max));
>>> +		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max), 1);
>>>  	} else {
>>>  		meson_nfc_cmd_idle(nfc, nfc->timing.tadl);
>>>  	}
>>> @@ -669,7 +681,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>  
>>>  	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> -	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max));
>>> +	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max), 0);
>>>  
>>>  	meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_TO_DEVICE);
>>>  
>>> @@ -952,7 +964,7 @@ static int meson_nfc_exec_op(struct nand_chip *nand,
>>>  			break;
>>>  
>>>  		case NAND_OP_WAITRDY_INSTR:
>>> -			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
>>> +			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms, 1);
>>>  			if (instr->delay_ns)
>>>  				meson_nfc_cmd_idle(nfc, delay_idle);
>>>  			break;
>>
>>
>> Thanks,
>> Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Liang Yang <liang.yang@amlogic.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Yixun Lan <yixun.lan@amlogic.com>,
	Jianxin Pan <jianxin.pan@amlogic.com>, <oxffffaa@gmail.com>,
	<kernel@sberdevices.ru>, <linux-mtd@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-amlogic@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/5] mtd: rawnand: meson: fix command sequence for read/write
Date: Wed, 24 May 2023 12:05:47 +0300	[thread overview]
Message-ID: <abeadc03-a69c-be1c-3c6a-6ce492a5e4f6@sberdevices.ru> (raw)
In-Reply-To: <9013b0e2-c923-43f8-0bd6-979bf0c23ebc@sberdevices.ru>



On 23.05.2023 12:12, Arseniy Krasnov wrote:
> Hello Miquel, Liang
> 
> On 22.05.2023 18:05, Miquel Raynal wrote:
>> Hi Arseniy,
>>
>> AVKrasnov@sberdevices.ru wrote on Mon, 15 May 2023 12:44:35 +0300:
>>
>>> This fixes read/write functionality by:
>>> 1) Changing NFC_CMD_RB_INT bit value.
>>
>> I guess this is a separate fix
>>
> 
> Ok, I'll move it to separate patch
> 
>>> 2) Adding extra NAND_CMD_STATUS command on each r/w request.
>>
>> Is this really needed? Looks like you're delaying the next op only. Is
>> using a delay enough? If yes, then it's probably the wrong approach.

Hi Miquel, small update, I found some details from @Liang's message in v1 talks from the last month:

*
After sending NAND_CMD_READ0, address, NAND_CMD_READSTART and read status(NAND_CMD_STATUS = 0x70) commands, it should send
NAND_CMD_READ0 command for exiting the read status mode from the datasheet from NAND device. but previous meson_nfc_queue_rb()
only checks the Ready/Busy pin and it doesn't send read status(NAND_CMD_STATUS = 0x70) command.
i think there is something wrong with the Ready/Busy pin(please check the hardware whether this
Ready/Busy pin is connected with SOC) or the source code. i have the board without Ready/Busy pin and prefer to use the
nfc command called RB_IO6. it sends NAND_CMD_STATUS command and checks bit6 of the status register of NAND device from the
data bus and generate IRQ if ready.
*

I guess, that sequence of commands from this patch is described in datasheet (unfortunately I don't have it and relied on the old driver).
Yesterday I tried to remove sending of NAND_CMD_STATUS from this patch, but it broke current driver - i had ECC errors, so it looks like
"shot in the dark" situation, to understand this logic.

Thanks, Arseniy

>>
>>> 3) Adding extra idle commands during r/w request.
>>
>> Question about this below, might also be a patch on its own?
>>
>>> 4) Adding extra NAND_CMD_READ0 on each read request.
>>>
>>> Without this patch driver works unstable, for example there are a lot
>>> of ECC errors.
>>
>> I believe all the fixes should be Cc'ed to stable, please add in your
>> commits:
>>
>> Cc: stable@...
>>
> 
> Ack, after everything will be clear with this patch :)
> 
>>>
>>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
>>> Suggested-by: Liang Yang <liang.yang@amlogic.com>
>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>>> ---
>>>  drivers/mtd/nand/raw/meson_nand.c | 30 +++++++++++++++++++++---------
>>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
>>> index 074e14225c06..2f4d8c84186b 100644
>>> --- a/drivers/mtd/nand/raw/meson_nand.c
>>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>>> @@ -37,7 +37,7 @@
>>>  #define NFC_CMD_SCRAMBLER_ENABLE	BIT(19)
>>>  #define NFC_CMD_SCRAMBLER_DISABLE	0
>>>  #define NFC_CMD_SHORTMODE_DISABLE	0
>>> -#define NFC_CMD_RB_INT		BIT(14)
>>> +#define NFC_CMD_RB_INT ((0xb << 10) | BIT(18) | BIT(16))
>>>  
>>>  #define NFC_CMD_GET_SIZE(x)	(((x) >> 22) & GENMASK(4, 0))
>>>  
>>> @@ -392,7 +392,7 @@ static void meson_nfc_set_data_oob(struct nand_chip *nand,
>>>  	}
>>>  }
>>>  
>>> -static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>> +static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms, int cmd_read0)
>>>  {
>>>  	u32 cmd, cfg;
>>>  	int ret = 0;
>>> @@ -407,17 +407,29 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>>  
>>>  	reinit_completion(&nfc->completion);
>>>  
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS;
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 5);
>>
>> Why 5 and 2 below? They look like magic values. Is this totally
>> experimental?
> 
> @Liang, may be change it to defines ?
> 
>>
>>> +
>>>  	/* use the max erase time as the maximum clock for waiting R/B */
>>> -	cmd = NFC_CMD_RB | NFC_CMD_RB_INT
>>> -		| nfc->param.chip_select | nfc->timing.tbers_max;
>>
>> This is not documented in the commit log, is it?
>>
>>> +	cmd = NFC_CMD_RB | NFC_CMD_RB_INT | nfc->timing.tbers_max;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 2);
>>>  
>>>  	ret = wait_for_completion_timeout(&nfc->completion,
>>>  					  msecs_to_jiffies(timeout_ms));
>>>  	if (ret == 0)
>>> -		ret = -1;
>>> +		return -1;
>>
>> Please use real error codes, such as ETIMEDOUT.
> 
> Ack
> 
>>
>>>  
>>> -	return ret;
>>> +	if (!cmd_read0)
>>> +		return 0;
>>> +
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_READ0;
>>
>> This looks really wrong, I don't get why you would need to send an
>> expensive READ0 command.
> 
> This logic was suggested by @Liang Yang here to fix this driver (suggested as patch):
> https://lore.kernel.org/linux-mtd/8537e736-44a8-d17b-7923-25d5bd406dcc@sberdevices.ru/T/#m0df09d2ab2cac98431fb268a4ce3c00dc5c7a69e
> @Liang, could You please give us more details?
> 
> Thanks, Arseniy
> 
>>
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_drain_cmd(nfc);
>>> +	meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT);
>>> +
>>> +	return 0;
>>>  }
>>>  
>>>  static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf)
>>> @@ -623,7 +635,7 @@ static int meson_nfc_rw_cmd_prepare_and_execute(struct nand_chip *nand,
>>>  	if (in) {
>>>  		nfc->cmdfifo.rw.cmd1 = cs | NFC_CMD_CLE | NAND_CMD_READSTART;
>>>  		writel(nfc->cmdfifo.rw.cmd1, nfc->reg_base + NFC_REG_CMD);
>>> -		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max));
>>> +		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max), 1);
>>>  	} else {
>>>  		meson_nfc_cmd_idle(nfc, nfc->timing.tadl);
>>>  	}
>>> @@ -669,7 +681,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>  
>>>  	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> -	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max));
>>> +	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max), 0);
>>>  
>>>  	meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_TO_DEVICE);
>>>  
>>> @@ -952,7 +964,7 @@ static int meson_nfc_exec_op(struct nand_chip *nand,
>>>  			break;
>>>  
>>>  		case NAND_OP_WAITRDY_INSTR:
>>> -			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
>>> +			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms, 1);
>>>  			if (instr->delay_ns)
>>>  				meson_nfc_cmd_idle(nfc, delay_idle);
>>>  			break;
>>
>>
>> Thanks,
>> Miquèl

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

WARNING: multiple messages have this Message-ID (diff)
From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Liang Yang <liang.yang@amlogic.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Yixun Lan <yixun.lan@amlogic.com>,
	Jianxin Pan <jianxin.pan@amlogic.com>, <oxffffaa@gmail.com>,
	<kernel@sberdevices.ru>, <linux-mtd@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-amlogic@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/5] mtd: rawnand: meson: fix command sequence for read/write
Date: Wed, 24 May 2023 12:05:47 +0300	[thread overview]
Message-ID: <abeadc03-a69c-be1c-3c6a-6ce492a5e4f6@sberdevices.ru> (raw)
In-Reply-To: <9013b0e2-c923-43f8-0bd6-979bf0c23ebc@sberdevices.ru>



On 23.05.2023 12:12, Arseniy Krasnov wrote:
> Hello Miquel, Liang
> 
> On 22.05.2023 18:05, Miquel Raynal wrote:
>> Hi Arseniy,
>>
>> AVKrasnov@sberdevices.ru wrote on Mon, 15 May 2023 12:44:35 +0300:
>>
>>> This fixes read/write functionality by:
>>> 1) Changing NFC_CMD_RB_INT bit value.
>>
>> I guess this is a separate fix
>>
> 
> Ok, I'll move it to separate patch
> 
>>> 2) Adding extra NAND_CMD_STATUS command on each r/w request.
>>
>> Is this really needed? Looks like you're delaying the next op only. Is
>> using a delay enough? If yes, then it's probably the wrong approach.

Hi Miquel, small update, I found some details from @Liang's message in v1 talks from the last month:

*
After sending NAND_CMD_READ0, address, NAND_CMD_READSTART and read status(NAND_CMD_STATUS = 0x70) commands, it should send
NAND_CMD_READ0 command for exiting the read status mode from the datasheet from NAND device. but previous meson_nfc_queue_rb()
only checks the Ready/Busy pin and it doesn't send read status(NAND_CMD_STATUS = 0x70) command.
i think there is something wrong with the Ready/Busy pin(please check the hardware whether this
Ready/Busy pin is connected with SOC) or the source code. i have the board without Ready/Busy pin and prefer to use the
nfc command called RB_IO6. it sends NAND_CMD_STATUS command and checks bit6 of the status register of NAND device from the
data bus and generate IRQ if ready.
*

I guess, that sequence of commands from this patch is described in datasheet (unfortunately I don't have it and relied on the old driver).
Yesterday I tried to remove sending of NAND_CMD_STATUS from this patch, but it broke current driver - i had ECC errors, so it looks like
"shot in the dark" situation, to understand this logic.

Thanks, Arseniy

>>
>>> 3) Adding extra idle commands during r/w request.
>>
>> Question about this below, might also be a patch on its own?
>>
>>> 4) Adding extra NAND_CMD_READ0 on each read request.
>>>
>>> Without this patch driver works unstable, for example there are a lot
>>> of ECC errors.
>>
>> I believe all the fixes should be Cc'ed to stable, please add in your
>> commits:
>>
>> Cc: stable@...
>>
> 
> Ack, after everything will be clear with this patch :)
> 
>>>
>>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
>>> Suggested-by: Liang Yang <liang.yang@amlogic.com>
>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>>> ---
>>>  drivers/mtd/nand/raw/meson_nand.c | 30 +++++++++++++++++++++---------
>>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
>>> index 074e14225c06..2f4d8c84186b 100644
>>> --- a/drivers/mtd/nand/raw/meson_nand.c
>>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>>> @@ -37,7 +37,7 @@
>>>  #define NFC_CMD_SCRAMBLER_ENABLE	BIT(19)
>>>  #define NFC_CMD_SCRAMBLER_DISABLE	0
>>>  #define NFC_CMD_SHORTMODE_DISABLE	0
>>> -#define NFC_CMD_RB_INT		BIT(14)
>>> +#define NFC_CMD_RB_INT ((0xb << 10) | BIT(18) | BIT(16))
>>>  
>>>  #define NFC_CMD_GET_SIZE(x)	(((x) >> 22) & GENMASK(4, 0))
>>>  
>>> @@ -392,7 +392,7 @@ static void meson_nfc_set_data_oob(struct nand_chip *nand,
>>>  	}
>>>  }
>>>  
>>> -static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>> +static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms, int cmd_read0)
>>>  {
>>>  	u32 cmd, cfg;
>>>  	int ret = 0;
>>> @@ -407,17 +407,29 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>>  
>>>  	reinit_completion(&nfc->completion);
>>>  
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS;
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 5);
>>
>> Why 5 and 2 below? They look like magic values. Is this totally
>> experimental?
> 
> @Liang, may be change it to defines ?
> 
>>
>>> +
>>>  	/* use the max erase time as the maximum clock for waiting R/B */
>>> -	cmd = NFC_CMD_RB | NFC_CMD_RB_INT
>>> -		| nfc->param.chip_select | nfc->timing.tbers_max;
>>
>> This is not documented in the commit log, is it?
>>
>>> +	cmd = NFC_CMD_RB | NFC_CMD_RB_INT | nfc->timing.tbers_max;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 2);
>>>  
>>>  	ret = wait_for_completion_timeout(&nfc->completion,
>>>  					  msecs_to_jiffies(timeout_ms));
>>>  	if (ret == 0)
>>> -		ret = -1;
>>> +		return -1;
>>
>> Please use real error codes, such as ETIMEDOUT.
> 
> Ack
> 
>>
>>>  
>>> -	return ret;
>>> +	if (!cmd_read0)
>>> +		return 0;
>>> +
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_READ0;
>>
>> This looks really wrong, I don't get why you would need to send an
>> expensive READ0 command.
> 
> This logic was suggested by @Liang Yang here to fix this driver (suggested as patch):
> https://lore.kernel.org/linux-mtd/8537e736-44a8-d17b-7923-25d5bd406dcc@sberdevices.ru/T/#m0df09d2ab2cac98431fb268a4ce3c00dc5c7a69e
> @Liang, could You please give us more details?
> 
> Thanks, Arseniy
> 
>>
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_drain_cmd(nfc);
>>> +	meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT);
>>> +
>>> +	return 0;
>>>  }
>>>  
>>>  static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf)
>>> @@ -623,7 +635,7 @@ static int meson_nfc_rw_cmd_prepare_and_execute(struct nand_chip *nand,
>>>  	if (in) {
>>>  		nfc->cmdfifo.rw.cmd1 = cs | NFC_CMD_CLE | NAND_CMD_READSTART;
>>>  		writel(nfc->cmdfifo.rw.cmd1, nfc->reg_base + NFC_REG_CMD);
>>> -		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max));
>>> +		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max), 1);
>>>  	} else {
>>>  		meson_nfc_cmd_idle(nfc, nfc->timing.tadl);
>>>  	}
>>> @@ -669,7 +681,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>  
>>>  	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> -	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max));
>>> +	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max), 0);
>>>  
>>>  	meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_TO_DEVICE);
>>>  
>>> @@ -952,7 +964,7 @@ static int meson_nfc_exec_op(struct nand_chip *nand,
>>>  			break;
>>>  
>>>  		case NAND_OP_WAITRDY_INSTR:
>>> -			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
>>> +			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms, 1);
>>>  			if (instr->delay_ns)
>>>  				meson_nfc_cmd_idle(nfc, delay_idle);
>>>  			break;
>>
>>
>> Thanks,
>> Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Liang Yang <liang.yang@amlogic.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Yixun Lan <yixun.lan@amlogic.com>,
	Jianxin Pan <jianxin.pan@amlogic.com>, <oxffffaa@gmail.com>,
	<kernel@sberdevices.ru>, <linux-mtd@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-amlogic@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/5] mtd: rawnand: meson: fix command sequence for read/write
Date: Wed, 24 May 2023 12:05:47 +0300	[thread overview]
Message-ID: <abeadc03-a69c-be1c-3c6a-6ce492a5e4f6@sberdevices.ru> (raw)
In-Reply-To: <9013b0e2-c923-43f8-0bd6-979bf0c23ebc@sberdevices.ru>



On 23.05.2023 12:12, Arseniy Krasnov wrote:
> Hello Miquel, Liang
> 
> On 22.05.2023 18:05, Miquel Raynal wrote:
>> Hi Arseniy,
>>
>> AVKrasnov@sberdevices.ru wrote on Mon, 15 May 2023 12:44:35 +0300:
>>
>>> This fixes read/write functionality by:
>>> 1) Changing NFC_CMD_RB_INT bit value.
>>
>> I guess this is a separate fix
>>
> 
> Ok, I'll move it to separate patch
> 
>>> 2) Adding extra NAND_CMD_STATUS command on each r/w request.
>>
>> Is this really needed? Looks like you're delaying the next op only. Is
>> using a delay enough? If yes, then it's probably the wrong approach.

Hi Miquel, small update, I found some details from @Liang's message in v1 talks from the last month:

*
After sending NAND_CMD_READ0, address, NAND_CMD_READSTART and read status(NAND_CMD_STATUS = 0x70) commands, it should send
NAND_CMD_READ0 command for exiting the read status mode from the datasheet from NAND device. but previous meson_nfc_queue_rb()
only checks the Ready/Busy pin and it doesn't send read status(NAND_CMD_STATUS = 0x70) command.
i think there is something wrong with the Ready/Busy pin(please check the hardware whether this
Ready/Busy pin is connected with SOC) or the source code. i have the board without Ready/Busy pin and prefer to use the
nfc command called RB_IO6. it sends NAND_CMD_STATUS command and checks bit6 of the status register of NAND device from the
data bus and generate IRQ if ready.
*

I guess, that sequence of commands from this patch is described in datasheet (unfortunately I don't have it and relied on the old driver).
Yesterday I tried to remove sending of NAND_CMD_STATUS from this patch, but it broke current driver - i had ECC errors, so it looks like
"shot in the dark" situation, to understand this logic.

Thanks, Arseniy

>>
>>> 3) Adding extra idle commands during r/w request.
>>
>> Question about this below, might also be a patch on its own?
>>
>>> 4) Adding extra NAND_CMD_READ0 on each read request.
>>>
>>> Without this patch driver works unstable, for example there are a lot
>>> of ECC errors.
>>
>> I believe all the fixes should be Cc'ed to stable, please add in your
>> commits:
>>
>> Cc: stable@...
>>
> 
> Ack, after everything will be clear with this patch :)
> 
>>>
>>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
>>> Suggested-by: Liang Yang <liang.yang@amlogic.com>
>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>>> ---
>>>  drivers/mtd/nand/raw/meson_nand.c | 30 +++++++++++++++++++++---------
>>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
>>> index 074e14225c06..2f4d8c84186b 100644
>>> --- a/drivers/mtd/nand/raw/meson_nand.c
>>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>>> @@ -37,7 +37,7 @@
>>>  #define NFC_CMD_SCRAMBLER_ENABLE	BIT(19)
>>>  #define NFC_CMD_SCRAMBLER_DISABLE	0
>>>  #define NFC_CMD_SHORTMODE_DISABLE	0
>>> -#define NFC_CMD_RB_INT		BIT(14)
>>> +#define NFC_CMD_RB_INT ((0xb << 10) | BIT(18) | BIT(16))
>>>  
>>>  #define NFC_CMD_GET_SIZE(x)	(((x) >> 22) & GENMASK(4, 0))
>>>  
>>> @@ -392,7 +392,7 @@ static void meson_nfc_set_data_oob(struct nand_chip *nand,
>>>  	}
>>>  }
>>>  
>>> -static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>> +static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms, int cmd_read0)
>>>  {
>>>  	u32 cmd, cfg;
>>>  	int ret = 0;
>>> @@ -407,17 +407,29 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>>  
>>>  	reinit_completion(&nfc->completion);
>>>  
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS;
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 5);
>>
>> Why 5 and 2 below? They look like magic values. Is this totally
>> experimental?
> 
> @Liang, may be change it to defines ?
> 
>>
>>> +
>>>  	/* use the max erase time as the maximum clock for waiting R/B */
>>> -	cmd = NFC_CMD_RB | NFC_CMD_RB_INT
>>> -		| nfc->param.chip_select | nfc->timing.tbers_max;
>>
>> This is not documented in the commit log, is it?
>>
>>> +	cmd = NFC_CMD_RB | NFC_CMD_RB_INT | nfc->timing.tbers_max;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_cmd_idle(nfc, 2);
>>>  
>>>  	ret = wait_for_completion_timeout(&nfc->completion,
>>>  					  msecs_to_jiffies(timeout_ms));
>>>  	if (ret == 0)
>>> -		ret = -1;
>>> +		return -1;
>>
>> Please use real error codes, such as ETIMEDOUT.
> 
> Ack
> 
>>
>>>  
>>> -	return ret;
>>> +	if (!cmd_read0)
>>> +		return 0;
>>> +
>>> +	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_READ0;
>>
>> This looks really wrong, I don't get why you would need to send an
>> expensive READ0 command.
> 
> This logic was suggested by @Liang Yang here to fix this driver (suggested as patch):
> https://lore.kernel.org/linux-mtd/8537e736-44a8-d17b-7923-25d5bd406dcc@sberdevices.ru/T/#m0df09d2ab2cac98431fb268a4ce3c00dc5c7a69e
> @Liang, could You please give us more details?
> 
> Thanks, Arseniy
> 
>>
>>> +	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> +	meson_nfc_drain_cmd(nfc);
>>> +	meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT);
>>> +
>>> +	return 0;
>>>  }
>>>  
>>>  static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf)
>>> @@ -623,7 +635,7 @@ static int meson_nfc_rw_cmd_prepare_and_execute(struct nand_chip *nand,
>>>  	if (in) {
>>>  		nfc->cmdfifo.rw.cmd1 = cs | NFC_CMD_CLE | NAND_CMD_READSTART;
>>>  		writel(nfc->cmdfifo.rw.cmd1, nfc->reg_base + NFC_REG_CMD);
>>> -		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max));
>>> +		meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max), 1);
>>>  	} else {
>>>  		meson_nfc_cmd_idle(nfc, nfc->timing.tadl);
>>>  	}
>>> @@ -669,7 +681,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>  
>>>  	cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
>>>  	writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>> -	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max));
>>> +	meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max), 0);
>>>  
>>>  	meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_TO_DEVICE);
>>>  
>>> @@ -952,7 +964,7 @@ static int meson_nfc_exec_op(struct nand_chip *nand,
>>>  			break;
>>>  
>>>  		case NAND_OP_WAITRDY_INSTR:
>>> -			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
>>> +			meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms, 1);
>>>  			if (instr->delay_ns)
>>>  				meson_nfc_cmd_idle(nfc, delay_idle);
>>>  			break;
>>
>>
>> Thanks,
>> Miquèl

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2023-05-24  9:10 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15  9:44 [PATCH v4 0/5] refactoring and fix for Meson NAND Arseniy Krasnov
2023-05-15  9:44 ` Arseniy Krasnov
2023-05-15  9:44 ` Arseniy Krasnov
2023-05-15  9:44 ` Arseniy Krasnov
2023-05-15  9:44 ` [PATCH v4 1/5] mtd: rawnand: meson: fix command sequence for read/write Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-22 15:05   ` Miquel Raynal
2023-05-22 15:05     ` Miquel Raynal
2023-05-22 15:05     ` Miquel Raynal
2023-05-22 15:05     ` Miquel Raynal
2023-05-23  9:12     ` Arseniy Krasnov
2023-05-23  9:12       ` Arseniy Krasnov
2023-05-23  9:12       ` Arseniy Krasnov
2023-05-23  9:12       ` Arseniy Krasnov
2023-05-24  9:05       ` Arseniy Krasnov [this message]
2023-05-24  9:05         ` Arseniy Krasnov
2023-05-24  9:05         ` Arseniy Krasnov
2023-05-24  9:05         ` Arseniy Krasnov
2023-05-26 17:22         ` Miquel Raynal
2023-05-26 17:22           ` Miquel Raynal
2023-05-26 17:22           ` Miquel Raynal
2023-05-26 17:22           ` Miquel Raynal
2023-05-30 11:19           ` Arseniy Krasnov
2023-05-30 11:19             ` Arseniy Krasnov
2023-05-30 11:19             ` Arseniy Krasnov
2023-05-30 11:19             ` Arseniy Krasnov
2023-05-30 13:05             ` Miquel Raynal
2023-05-30 13:05               ` Miquel Raynal
2023-05-30 13:05               ` Miquel Raynal
2023-05-30 13:05               ` Miquel Raynal
2023-05-30 13:35               ` Arseniy Krasnov
2023-05-30 13:35                 ` Arseniy Krasnov
2023-05-30 13:35                 ` Arseniy Krasnov
2023-05-30 13:35                 ` Arseniy Krasnov
2023-05-30 13:58                 ` Miquel Raynal
2023-05-30 13:58                   ` Miquel Raynal
2023-05-30 13:58                   ` Miquel Raynal
2023-05-30 13:58                   ` Miquel Raynal
2023-05-15  9:44 ` [PATCH v4 2/5] mtd: rawnand: meson: move OOB to non-protected ECC area Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-22 15:33   ` Miquel Raynal
2023-05-22 15:33     ` Miquel Raynal
2023-05-22 15:33     ` Miquel Raynal
2023-05-22 15:33     ` Miquel Raynal
2023-05-23 17:17     ` Arseniy Krasnov
2023-05-23 17:17       ` Arseniy Krasnov
2023-05-23 17:17       ` Arseniy Krasnov
2023-05-23 17:17       ` Arseniy Krasnov
2023-05-26 17:03       ` Miquel Raynal
2023-05-26 17:03         ` Miquel Raynal
2023-05-26 17:03         ` Miquel Raynal
2023-05-26 17:03         ` Miquel Raynal
2023-05-29 19:43         ` Arseniy Krasnov
2023-05-29 19:43           ` Arseniy Krasnov
2023-05-29 19:43           ` Arseniy Krasnov
2023-05-29 19:43           ` Arseniy Krasnov
2023-05-30  7:44           ` Miquel Raynal
2023-05-30  7:44             ` Miquel Raynal
2023-05-30  7:44             ` Miquel Raynal
2023-05-30  7:44             ` Miquel Raynal
2023-05-30  8:09             ` Arseniy Krasnov
2023-05-30  8:09               ` Arseniy Krasnov
2023-05-30  8:09               ` Arseniy Krasnov
2023-05-30  8:09               ` Arseniy Krasnov
2023-05-30  8:21               ` Miquel Raynal
2023-05-30  8:21                 ` Miquel Raynal
2023-05-30  8:21                 ` Miquel Raynal
2023-05-30  8:21                 ` Miquel Raynal
2023-05-30  8:28                 ` Arseniy Krasnov
2023-05-30  8:28                   ` Arseniy Krasnov
2023-05-30  8:28                   ` Arseniy Krasnov
2023-05-30  8:28                   ` Arseniy Krasnov
2023-05-15  9:44 ` [PATCH v4 3/5] mtd: rawnand: meson: always read whole OOB bytes Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-22 15:38   ` Miquel Raynal
2023-05-22 15:38     ` Miquel Raynal
2023-05-22 15:38     ` Miquel Raynal
2023-05-22 15:38     ` Miquel Raynal
2023-05-23 17:27     ` Arseniy Krasnov
2023-05-23 17:27       ` Arseniy Krasnov
2023-05-23 17:27       ` Arseniy Krasnov
2023-05-23 17:27       ` Arseniy Krasnov
2023-05-26 17:09       ` Miquel Raynal
2023-05-26 17:09         ` Miquel Raynal
2023-05-26 17:09         ` Miquel Raynal
2023-05-26 17:09         ` Miquel Raynal
2023-05-29 19:46         ` Arseniy Krasnov
2023-05-29 19:46           ` Arseniy Krasnov
2023-05-29 19:46           ` Arseniy Krasnov
2023-05-29 19:46           ` Arseniy Krasnov
2023-05-15  9:44 ` [PATCH v4 4/5] mtd: rawnand: meson: check buffer length Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-22 15:43   ` Miquel Raynal
2023-05-22 15:43     ` Miquel Raynal
2023-05-22 15:43     ` Miquel Raynal
2023-05-22 15:43     ` Miquel Raynal
2023-05-15  9:44 ` [PATCH v4 5/5] mtd: rawnand: meson: remove unneeded bitwise OR with zeroes Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov
2023-05-15  9:44   ` Arseniy Krasnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abeadc03-a69c-be1c-3c6a-6ce492a5e4f6@sberdevices.ru \
    --to=avkrasnov@sberdevices.ru \
    --cc=jbrunet@baylibre.com \
    --cc=jianxin.pan@amlogic.com \
    --cc=kernel@sberdevices.ru \
    --cc=khilman@baylibre.com \
    --cc=liang.yang@amlogic.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=neil.armstrong@linaro.org \
    --cc=oxffffaa@gmail.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    --cc=yixun.lan@amlogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.