[PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

Current gpmi-nand driver only supports one chips. But we may meet
some embarrassing situation, such as Micron MT29F32G08QAA.
This nand chip has two DIEs internally. Each die has its own chip select pin,
so this chip acts as two nand chips.

If we only scan one chip, we may find that we only get 2G for this chip,
but in actually, this chip's size is 4G.

So scan two chips by default.

In order to support two nand chips, we have to do the following:
   1.) Decouple the chip select from the DMA channel,
       We can use the dma 0 to access all the nand chips.

   2.) fix the wrong method of checking the ready/busy status.
      In the imx6, all the ready/busy pins are binding together, we
      should check ready/busy status of chip 0 for the all the chips. 

Tested this patch set with MT29F32G08QAA.

To Brian:
	My "better" solution was proved to be a bad idea. So i resend this
	patch set again.

v1 --> v2:
	[0] rebase on the latest l2-mtd tree.

Huang Shijie (4):
  mtd: gpmi: decouple the chip select from the DMA channel
  mtd: gpmi: use DMA channel 0 for all the nand chips
  mtd: gpmi: scan two nand chips
  mtd: gpmi: imx6: fix the wrong method for checking ready/busy

 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |   13 +++++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    7 +++----
 drivers/mtd/nand/gpmi-nand/gpmi-regs.h |    3 +++
 3 files changed, 19 insertions(+), 4 deletions(-)

[PATCH V2 1/4] mtd: gpmi: decouple the chip select from the DMA channel

[Huang Shijie]

Decouple the chip select from the DMA channel, we use the DMA channel 0
to accecc all the nand devices.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |    6 ++++++
 drivers/mtd/nand/gpmi-nand/gpmi-regs.h |    3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 4f8857f..7d56d87 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -187,6 +187,12 @@ int gpmi_init(struct gpmi_nand_data *this)
 	/* Select BCH ECC. */
 	writel(BM_GPMI_CTRL1_BCH_MODE, r->gpmi_regs + HW_GPMI_CTRL1_SET);
 
+	/*
+	 * Decouple the chip select from dma channel. We use dma0 for all
+	 * the chips.
+	 */
+	writel(BM_GPMI_CTRL1_DECOUPLE_CS, r->gpmi_regs + HW_GPMI_CTRL1_SET);
+
 	gpmi_disable_clk(this);
 	return 0;
 err_out:
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-regs.h b/drivers/mtd/nand/gpmi-nand/gpmi-regs.h
index 53397cc..82114cd 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-regs.h
@@ -108,6 +108,9 @@
 #define HW_GPMI_CTRL1_CLR				0x00000068
 #define HW_GPMI_CTRL1_TOG				0x0000006c
 
+#define BP_GPMI_CTRL1_DECOUPLE_CS			24
+#define BM_GPMI_CTRL1_DECOUPLE_CS	(1 << BP_GPMI_CTRL1_DECOUPLE_CS)
+
 #define BP_GPMI_CTRL1_WRN_DLY_SEL			22
 #define BM_GPMI_CTRL1_WRN_DLY_SEL	(0x3 << BP_GPMI_CTRL1_WRN_DLY_SEL)
 #define BF_GPMI_CTRL1_WRN_DLY_SEL(v)  \
-- 
1.7.1

[PATCH V2 2/4] mtd: gpmi: use DMA channel 0 for all the nand chips

[Huang Shijie]

We only have one DMA channel : the channel 0.
Use DMA channel 0 to access all the nand chips.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 8d8a814..24ee8d7 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -357,9 +357,8 @@ int common_nfc_set_geometry(struct gpmi_nand_data *this)
 
 struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
 {
-	int chipnr = this->current_chip;
-
-	return this->dma_chans[chipnr];
+	/* We use the DMA channel 0 to access all the nand chips. */
+	return this->dma_chans[0];
 }
 
 /* Can we use the upper's buffer directly for DMA? */
-- 
1.7.1

[PATCH V2 3/4] mtd: gpmi: scan two nand chips

[Huang Shijie]

Some nand chip has two DIEs in a single chip, such as Micron MT29F32G08QAA.
Each die has its own chip select pin, so this chip acts as two nand
chips.

If we only scan one chip, we may find that we only get 2G for this chip,
but in actually, this chip's size is 4G.

So scan two chips by default.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 24ee8d7..eba7b79 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1676,7 +1676,7 @@ static int gpmi_nfc_init(struct gpmi_nand_data *this)
 	if (ret)
 		goto err_out;
 
-	ret = nand_scan_ident(mtd, 1, NULL);
+	ret = nand_scan_ident(mtd, 2, NULL);
 	if (ret)
 		goto err_out;
 
-- 
1.7.1

[PATCH V2 4/4] mtd: gpmi: imx6: fix the wrong method for checking ready/busy

[Huang Shijie]

In the imx6, all the ready/busy pins are binding togeter.
So we should always check the ready/busy pin of the chip 0.

In the other word, when the CS1 is enabled, we should also check the
ready/busy of chip 0; if we check the ready/busy of chip 1,
we will get the wrong result.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 7d56d87..5edd25b 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -1079,6 +1079,13 @@ int gpmi_is_ready(struct gpmi_nand_data *this, unsigned chip)
 		mask = MX23_BM_GPMI_DEBUG_READY0 << chip;
 		reg = readl(r->gpmi_regs + HW_GPMI_DEBUG);
 	} else if (GPMI_IS_MX28(this) || GPMI_IS_MX6Q(this)) {
+		/*
+		 * In the imx6, all the ready/busy pins are binding
+		 * togeter. So we only need to check the chip 0.
+		 */
+		if (GPMI_IS_MX6Q(this))
+			chip = 0;
+
 		/* MX28 shares the same R/B register as MX6Q. */
 		mask = MX28_BF_GPMI_STAT_READY_BUSY(1 << chip);
 		reg = readl(r->gpmi_regs + HW_GPMI_STAT);
-- 
1.7.1

Re: [PATCH V2 2/4] mtd: gpmi: use DMA channel 0 for all the nand chips

[Vikram Narayanan]

On 27/Aug/2013 2:59 PM, Huang Shijie wrote:
> We only have one DMA channel : the channel 0.
> Use DMA channel 0 to access all the nand chips.

IIRC, We have 4 DMA channels. Don't we?

> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>   drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    5 ++---
>   1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 8d8a814..24ee8d7 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -357,9 +357,8 @@ int common_nfc_set_geometry(struct gpmi_nand_data *this)
>
>   struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
>   {
> -	int chipnr = this->current_chip;
> -
> -	return this->dma_chans[chipnr];
> +	/* We use the DMA channel 0 to access all the nand chips. */
> +	return this->dma_chans[0];
>   }
>
>   /* Can we use the upper's buffer directly for DMA? */
>

Re: [PATCH V2 2/4] mtd: gpmi: use DMA channel 0 for all the nand chips

[Huang Shijie]

于 2013年08月28日 01:05, Vikram Narayanan 写道:
> IIRC, We have 4 DMA channels. Don't we? 
yes, we have. But we only have one gpmi.

I ever tried to use different dma channels for different chip selects.
But after discussed with our IC guy, it is proved to be meaningless.
We only have one gpmi, and so we only have one data bus. Even we have 4 
dma channels
, we have to do the DMA operations one by one.



thanks
Huang Shijie

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

于 2013年08月27日 17:29, Huang Shijie 写道:
> Current gpmi-nand driver only supports one chips. But we may meet
> some embarrassing situation, such as Micron MT29F32G08QAA.
> This nand chip has two DIEs internally. Each die has its own chip select pin,
> so this chip acts as two nand chips.
>
> If we only scan one chip, we may find that we only get 2G for this chip,
> but in actually, this chip's size is 4G.
>
> So scan two chips by default.
>
> In order to support two nand chips, we have to do the following:
>    1.) Decouple the chip select from the DMA channel,
>        We can use the dma 0 to access all the nand chips.
>
>    2.) fix the wrong method of checking the ready/busy status.
>       In the imx6, all the ready/busy pins are binding together, we
>       should check ready/busy status of chip 0 for the all the chips. 
>
> Tested this patch set with MT29F32G08QAA.
>
> To Brian:
> 	My "better" solution was proved to be a bad idea. So i resend this
> 	patch set again.
>
> v1 --> v2:
> 	[0] rebase on the latest l2-mtd tree.
>
> Huang Shijie (4):
>   mtd: gpmi: decouple the chip select from the DMA channel
>   mtd: gpmi: use DMA channel 0 for all the nand chips
>   mtd: gpmi: scan two nand chips
>   mtd: gpmi: imx6: fix the wrong method for checking ready/busy
>
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |   13 +++++++++++++
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    7 +++----
>  drivers/mtd/nand/gpmi-nand/gpmi-regs.h |    3 +++
>  3 files changed, 19 insertions(+), 4 deletions(-)
>
just a ping

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

于 2013年08月27日 17:29, Huang Shijie 写道:
> Current gpmi-nand driver only supports one chips. But we may meet
> some embarrassing situation, such as Micron MT29F32G08QAA.
> This nand chip has two DIEs internally. Each die has its own chip select pin,
> so this chip acts as two nand chips.
>
> If we only scan one chip, we may find that we only get 2G for this chip,
> but in actually, this chip's size is 4G.
>
> So scan two chips by default.
>
> In order to support two nand chips, we have to do the following:
>    1.) Decouple the chip select from the DMA channel,
>        We can use the dma 0 to access all the nand chips.
>
>    2.) fix the wrong method of checking the ready/busy status.
>       In the imx6, all the ready/busy pins are binding together, we
>       should check ready/busy status of chip 0 for the all the chips. 
>
> Tested this patch set with MT29F32G08QAA.
>
> To Brian:
> 	My "better" solution was proved to be a bad idea. So i resend this
> 	patch set again.
>
> v1 --> v2:
> 	[0] rebase on the latest l2-mtd tree.
>
> Huang Shijie (4):
>   mtd: gpmi: decouple the chip select from the DMA channel
>   mtd: gpmi: use DMA channel 0 for all the nand chips
>   mtd: gpmi: scan two nand chips
>   mtd: gpmi: imx6: fix the wrong method for checking ready/busy
>
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |   13 +++++++++++++
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    7 +++----
>  drivers/mtd/nand/gpmi-nand/gpmi-regs.h |    3 +++
>  3 files changed, 19 insertions(+), 4 deletions(-)
>
Hi Artem & Brian:
Could you please merge this patch set?
it seems you have missed this patch set.


thanks
Huang Shijie

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Brian Norris]

On Thu, Oct 17, 2013 at 11:50 PM, Huang Shijie <b32955@freescale.com> wrote:
> 于 2013年08月27日 17:29, Huang Shijie 写道:
>> Current gpmi-nand driver only supports one chips. But we may meet
>> some embarrassing situation, such as Micron MT29F32G08QAA.
>> This nand chip has two DIEs internally. Each die has its own chip select pin,
>> so this chip acts as two nand chips.
>>
>> If we only scan one chip, we may find that we only get 2G for this chip,
>> but in actually, this chip's size is 4G.
>>
>> So scan two chips by default.
>>
>> In order to support two nand chips, we have to do the following:
>>    1.) Decouple the chip select from the DMA channel,
>>        We can use the dma 0 to access all the nand chips.
>>
>>    2.) fix the wrong method of checking the ready/busy status.
>>       In the imx6, all the ready/busy pins are binding together, we
>>       should check ready/busy status of chip 0 for the all the chips.
>>
>> Tested this patch set with MT29F32G08QAA.
>>
>> To Brian:
>>       My "better" solution was proved to be a bad idea. So i resend this
>>       patch set again.
>>
>> v1 --> v2:
>>       [0] rebase on the latest l2-mtd tree.
>>
>> Huang Shijie (4):
>>   mtd: gpmi: decouple the chip select from the DMA channel
>>   mtd: gpmi: use DMA channel 0 for all the nand chips
>>   mtd: gpmi: scan two nand chips
>>   mtd: gpmi: imx6: fix the wrong method for checking ready/busy
>>
>>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |   13 +++++++++++++
>>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    7 +++----
>>  drivers/mtd/nand/gpmi-nand/gpmi-regs.h |    3 +++
>>  3 files changed, 19 insertions(+), 4 deletions(-)
>>
> Hi Artem & Brian:
> Could you please merge this patch set?
> it seems you have missed this patch set.

Yes, I seem to have overlooked this set. I think it must have come in
parallel with your MLC patch set, so I delayed it until the MLC patch
set settled down?

Anyway, I'll revisit this soon. But I probably need to take care of
your mtd-utils updates first, since they should go along with the MLC
patch set.

And on top of that (to update the world on daily status), I seem to be
tripping over some UBIFS bugs that are inhibiting the validation I'm
trying to do for some new hardware. So, I'm all-around pretty busy!
I'll get myself together next week, hopefully.

In the meantime, other people's code could use some extra eyes. I know
Ezequiel just sent out a 27 (!) patch series today. There's also the
pending cmdline.c patch from months ago, where Cai Zhiyong wanted to
migrate our command line partition parser to a common
block/cmdline-parser.c. Part of her work (for block devices) is
upstream already, and part has just sat on our mailing list without
eyes to test it...

See: http://lists.infradead.org/pipermail/linux-mtd/2013-August/048101.html

And finally, I believe Tim Harvey has just reported ECC regressions
for GPMI NAND on some of your code that made it into 3.12 so far. That
issue is probably more urgent than new features.

Brian

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

于 2013年10月19日 10:01, Brian Norris 写道:
> Yes, I seem to have overlooked this set. I think it must have come in
> parallel with your MLC patch set, so I delayed it until the MLC patch
> set settled down?
>
this patch set has no relationship with MLC patch.

> Anyway, I'll revisit this soon. But I probably need to take care of
> your mtd-utils updates first, since they should go along with the MLC
> patch set.
>
> And on top of that (to update the world on daily status), I seem to be
> tripping over some UBIFS bugs that are inhibiting the validation I'm
> trying to do for some new hardware. So, I'm all-around pretty busy!
> I'll get myself together next week, hopefully.
understood.


I am too busy too, i am starting to code the Qspi driver now.
I was blocked by a bluetooth/uart/dma issue last month.
> In the meantime, other people's code could use some extra eyes. I know
> Ezequiel just sent out a 27 (!) patch series today. There's also the
> pending cmdline.c patch from months ago, where Cai Zhiyong wanted to
> migrate our command line partition parser to a common
> block/cmdline-parser.c. Part of her work (for block devices) is
I like Cai zhiyong's patch. But I do not have time to test his patch.


thanks
Huang Shijie

RE: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Gupta, Pekon]

Hi Shijie,

> From: Huang Shijie
> 
> I am too busy too, i am starting to code the Qspi driver now.
> 
(1)
Your controller uses LUT based approach, So in case, you are planning to
follow DT based approach of populating flash information in your QSPI
controller then I can help you to put that as part of generic framework
so that both ti-qspi and fsl-qspi can re-use it.

(2) 
Also, would you be interested in deriving generic framework for serial
NOR something like mtd/spinor/.. where m25p80 can plug-in ?

Based on the following cleaned up version of mtd/spinand/...
https://lkml.org/lkml/2013/6/26/88
by Mona Anonuevo <manonuevo@micron.com>


with regards, pekon

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

于 2013年10月21日 14:01, Gupta, Pekon 写道:
> Hi Shijie,
>
>> From: Huang Shijie
>>
>> I am too busy too, i am starting to code the Qspi driver now.
>>
> (1)
> Your controller uses LUT based approach, So in case, you are planning to
> follow DT based approach of populating flash information in your QSPI
> controller then I can help you to put that as part of generic framework
> so that both ti-qspi and fsl-qspi can re-use it.
it's very good.
> (2)
> Also, would you be interested in deriving generic framework for serial
> NOR something like mtd/spinor/.. where m25p80 can plug-in ?

yes.

Do you have any solution about the generic framework for spi nor?

i want to chage the m25p80.c, and make it not only work for SPI drivers, 
but also can work for SPI-NOR(QSPI) driver.

thanks
Huang Shijie


> Based on the following cleaned up version of mtd/spinand/...
> https://lkml.org/lkml/2013/6/26/88
> by Mona Anonuevo<manonuevo@micron.com>
>
>
> with regards, pekon
>

RE: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Gupta, Pekon]

Hi,

> From: Huang Shijie [mailto:b32955@freescale.com]
> 于 2013年10月21日 14:01, Gupta, Pekon 写道:
> > Hi Shijie,
> >
> >> From: Huang Shijie
> >>
> >> I am too busy too, i am starting to code the Qspi driver now.
> >>
> > (1)
> > Your controller uses LUT based approach, So in case, you are planning to
> > follow DT based approach of populating flash information in your QSPI
> > controller then I can help you to put that as part of generic framework
> > so that both ti-qspi and fsl-qspi can re-use it.
> it's very good.
> > (2)
> > Also, would you be interested in deriving generic framework for serial
> > NOR something like mtd/spinor/.. where m25p80 can plug-in ?
> 
> yes.
> 
> Do you have any solution about the generic framework for spi nor?
> 
> i want to chage the m25p80.c, and make it not only work for SPI drivers,
> but also can work for SPI-NOR(QSPI) driver.
> 
Thanks, but in that case, please do not add generic code in m25p80.c.
Let it live as driver for NOR devices, because it supports too many other
devices. Rather I was thinking on following ways:

* Step-1: define an interface between SPI-NOR and MTD *
+ create include/linux/mtd/spinor.h
struct spinor {
	/* modes */
	enum modes { MM_MODE, SPI_MODE };
	/* erase operation */	
	uint32 erase_opcode;
	uint32 erase_dummy_cycles;
	int (* erase_done) (...);
	/* read operation */
	uint32 read_opcode;
	uint32 read_dummy_cycles;
	int (*read_done) (...);
	/* write operation */
	[...]
}
This is similar to struct nand_chip in include/linux/mtd/nand.h
But specific to SPI NOR device attributes.


* Step-2:  spawn out generic code from m25p80 into generic framework *
_(maintaining original authorship)_
+ create /driver/mtd/spinor/spinor.c
m25p80_erase() -> spinor_erase(mtd, ...)
m25p80_read() -> spinor_read( mtd, from, len, *buf, ... )
m25p80_write() -> spinor_write (mtd, to, len, *buf, ... )

If you already have done some work on m25p80.c then please see if
you can convert on above thoughts and post it. I'll review them and
add more stuff and cleanups. 
Else, I plan to do that from scratch but need sometime, as I'm bit stuck
in some omap2-nand driver clean-up activities.
Let me know what suits you, as per your QSPI-FSL driver timelines..


with regards, pekon

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

于 2013年10月21日 17:02, Gupta, Pekon 写道:
> If you already have done some work on m25p80.c then please see if
> you can convert on above thoughts and post it. I'll review them and
> add more stuff and cleanups.
I will convert my code, and send out as soon as possible.

thanks
Huang Shijie

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Sourav Poddar]

Hi Huang,
On Tuesday 22 October 2013 01:46 PM, Huang Shijie wrote:
> 于 2013年10月21日 17:02, Gupta, Pekon 写道:
>> If you already have done some work on m25p80.c then please see if
>> you can convert on above thoughts and post it. I'll review them and
>> add more stuff and cleanups.
> I will convert my code, and send out as soon as possible.
>
> thanks
> Huang Shijie
>
>
Did you get the chance to follow the three patch series which I had sent?
One of the patch modifies m25p80 to add support for spnasion and 
macronix quad read
support. If that looks cool also to you[1], we can push for that patch. 
So that, our further works
on m25p80 will be reduced.

[1]:  http://permalink.gmane.org/gmane.linux.drivers.mtd/48755
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Huang Shijie]

于 2013年10月22日 16:34, Sourav Poddar 写道:
> Hi Huang,
> Did you get the chance to follow the three patch series which I had sent?
> One of the patch modifies m25p80 to add support for spnasion and 
> macronix quad read
> support. If that looks cool also to you[1], we can push for that 
> patch. So that, our further works
> on m25p80 will be reduced.
>
> [1]:  http://permalink.gmane.org/gmane.linux.drivers.mtd/48755
to Brian:
   could you please check Sourav's patch?

If you think his patch is ok, please merge it, and i can do my work base 
on his patch.

thanks
Huang Shijie

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Brian Norris]

On Mon, Oct 21, 2013 at 11:40:16AM +0800, Huang Shijie wrote:
> 于 2013年10月19日 10:01, Brian Norris 写道:
> > Yes, I seem to have overlooked this set. I think it must have come in
> > parallel with your MLC patch set, so I delayed it until the MLC patch
> > set settled down?
> >
> this patch set has no relationship with MLC patch.

Well, it did touch the same driver, and your patch set kept evolving so
I chose to focus on just one of your patch sets at a time there...

I'll take a look now.

> > Anyway, I'll revisit this soon. But I probably need to take care of
> > your mtd-utils updates first, since they should go along with the MLC
> > patch set.
> >
> > And on top of that (to update the world on daily status), I seem to be
> > tripping over some UBIFS bugs that are inhibiting the validation I'm
> > trying to do for some new hardware. So, I'm all-around pretty busy!
> > I'll get myself together next week, hopefully.
> understood.
> 
> 
> I am too busy too, i am starting to code the Qspi driver now.
> I was blocked by a bluetooth/uart/dma issue last month.
> > In the meantime, other people's code could use some extra eyes. I know
> > Ezequiel just sent out a 27 (!) patch series today. There's also the
> > pending cmdline.c patch from months ago, where Cai Zhiyong wanted to
> > migrate our command line partition parser to a common
> > block/cmdline-parser.c. Part of her work (for block devices) is
> I like Cai zhiyong's patch. But I do not have time to test his patch.

Well, this represents a bad community mentality, where people have time
to submit plenty of code for their own drivers, and ask a lot from
maintainers to review and merge their code, yet they do not have any
time to review others' work. I believe that bearing the sole
responsibility of code review is a major contributing factor in both
Artem's and my long latency to merging patches.

That said, I understand that people get very busy sometimes, and I don't
mean to particularly focus on you, Huang. This is a general pattern that
I've seen, and I have done the same thing previously, where I simply did
not have (and did not make) time to review others' work much.

Brian

Re: [PATCH V2 0/4] mtd: gpmi: support two nand chips at most

[Brian Norris]

On Tue, Aug 27, 2013 at 05:29:03PM +0800, Huang Shijie wrote:
> Current gpmi-nand driver only supports one chips. But we may meet
> some embarrassing situation, such as Micron MT29F32G08QAA.
> This nand chip has two DIEs internally. Each die has its own chip select pin,
> so this chip acts as two nand chips.
> 
> If we only scan one chip, we may find that we only get 2G for this chip,
> but in actually, this chip's size is 4G.
> 
> So scan two chips by default.
> 
> In order to support two nand chips, we have to do the following:
>    1.) Decouple the chip select from the DMA channel,
>        We can use the dma 0 to access all the nand chips.
> 
>    2.) fix the wrong method of checking the ready/busy status.
>       In the imx6, all the ready/busy pins are binding together, we
>       should check ready/busy status of chip 0 for the all the chips. 
> 
> Tested this patch set with MT29F32G08QAA.

I fixed up some typos in patch 4 and pushed the series. Thanks!

Brian