RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Punnaiah Choudary Kalluri 


> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Tuesday, October 25, 2016 4:30 AM
> To: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>; Punnaiah Choudary
> Kalluri <punn...@xilinx.com>; mark.rutl...@arm.com; linux-
> m...@lists.infradead.org; michal.si...@xilinx.com; ezequiel.garcia@free-
> electrons.com; linux-kernel@vger.kernel.org; r...@landley.net;
> ga...@codeaurora.org; Khoronzhuk, Ivan <ivan.khoronz...@ti.com>;
> computersforpe...@gmail.com; dw...@infradead.org
> Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand
> interface
> 
> [cc list trimmed]
> 
> On Sun, Oct 23, 2016 at 05:37:42PM +0530, punnaiah choudary kalluri wrote:
> > Hi Boris and Jason,
> >
> >  I am doing rework on these patches to accommodate recent changes with
> >  respect to ooblayout. Also some of the comments that i have received
> > from Boris as part of the arasan nand controller upstream patches will
> > apply to this driver. So, i will be releasing the next set of patches for 
> > this
> > driver soon and request your time for reviewing those patches.
> 
> I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> more to work on my hardware. The driver appears to be in no better
> shape than the 3.12 out-of-tree Xilinx release I was using previously..


The driver in Xilinx tree works with 4.6 kernel and adopted the required
 Changes (may release in 1-2 weeks). Still it need some rework, now a days
I am seeing many requests from different people for this driver and some of
Them are using different version of IP as you know this IP has four variants and
Xilinx is using the pl353 variant.  Let's wait for the next series of patches 
and 
Get the patches tested with others as well along with the review comments.
 
Regards,
Punnaiah
> I've attached the ugly, ugly patch I made, it may save you some time
> when preparing v8.
> 
> Commentary:
>  1) nand_chip already includes mtd_info, no reason for a second one in
> the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> should be used instead of priv
>  2) I hacked out all the ECC stuff from the driver since I don't use
> it and it was broken.. Obviously some has to come back, but fixing
> other things on this list first will make that much easier and better..
>  3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
> outdated copies of the core routines and should not exist in a
> driver. This needs to be fixed so nand_scan_tail sets them.
> This seems to be a side effect of #9 ?
>  4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> and doesn't work without ONFI (see patch for possible fix). The
> driver should probably use the same scheme the core code uses..
> But this is all a problem because of #10
>  5) The driver assumes alignment of the iomap, needs to use + not |
> when constructing the address. (yes, this blows up on my system)
>  6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> Maybe timing should be common code driven by DT..
>  7) Driver unconditionally selects a BBT format, and an ECC layout
> (neither match what my system uses, but I guess that is a core mtd
> issue these days :/)
>  8) Driver unconditionally forces a chip-delay (wrong for my
> system) maybe this should be common code driven by DT..
>  9) This buisness with pl353_nand_ecc_init and the
> special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> is just horrid. I'd expect that is a big NAK.
> 
> The driver needs to implement read_buf *properly* so the core
> routines can be used instead of trying to 'fix' the call sites
> to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
>  10) pl353_nand_cmd_function is a wonky copy of nand_command_lp,
> maybe
>  this driver should use cmd_ctrl, or the core code should be
>  refactored some more..
> 
> Jason
> 
> diff --git a/drivers/mtd/nand/pl353_nand.c
> b/drivers/mtd/nand/pl353_nand.c
> index 7e3993931f75..63a8d8c008e3 100644
> --- a/drivers/mtd/nand/pl353_nand.c
> +++ b/drivers/mtd/nand/pl353_nand.c
> @@ -26,7 +26,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -56,7 +55,6 @@
>  #define PL353_NAND_ECC_LAST  BIT(ECC_LAST_SHIFT) /* Set
> ECC_Last */
>  #define PL353_NAND_CLEAR_CS  BIT(CLEAR_CS_SHIFT) /* Clear chip
> select */
> 
> -#define ONDIE_ECC_FEATURE_ADDR   0x90
>  #define PL353_NAND_ECC_BUSY_TIMEOUT  (1 * HZ)
>  #define PL353_NAND_DEV_BUSY_TIMEOUT  (1 * HZ)
>  #define P

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Punnaiah Choudary Kalluri 


> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Tuesday, October 25, 2016 4:30 AM
> To: Punnaiah Choudary Kalluri 
> Cc: Boris Brezillon ; Punnaiah Choudary
> Kalluri ; mark.rutl...@arm.com; linux-
> m...@lists.infradead.org; michal.si...@xilinx.com; ezequiel.garcia@free-
> electrons.com; linux-kernel@vger.kernel.org; r...@landley.net;
> ga...@codeaurora.org; Khoronzhuk, Ivan ;
> computersforpe...@gmail.com; dw...@infradead.org
> Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand
> interface
> 
> [cc list trimmed]
> 
> On Sun, Oct 23, 2016 at 05:37:42PM +0530, punnaiah choudary kalluri wrote:
> > Hi Boris and Jason,
> >
> >  I am doing rework on these patches to accommodate recent changes with
> >  respect to ooblayout. Also some of the comments that i have received
> > from Boris as part of the arasan nand controller upstream patches will
> > apply to this driver. So, i will be releasing the next set of patches for 
> > this
> > driver soon and request your time for reviewing those patches.
> 
> I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> more to work on my hardware. The driver appears to be in no better
> shape than the 3.12 out-of-tree Xilinx release I was using previously..


The driver in Xilinx tree works with 4.6 kernel and adopted the required
 Changes (may release in 1-2 weeks). Still it need some rework, now a days
I am seeing many requests from different people for this driver and some of
Them are using different version of IP as you know this IP has four variants and
Xilinx is using the pl353 variant.  Let's wait for the next series of patches 
and 
Get the patches tested with others as well along with the review comments.
 
Regards,
Punnaiah
> I've attached the ugly, ugly patch I made, it may save you some time
> when preparing v8.
> 
> Commentary:
>  1) nand_chip already includes mtd_info, no reason for a second one in
> the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> should be used instead of priv
>  2) I hacked out all the ECC stuff from the driver since I don't use
> it and it was broken.. Obviously some has to come back, but fixing
> other things on this list first will make that much easier and better..
>  3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
> outdated copies of the core routines and should not exist in a
> driver. This needs to be fixed so nand_scan_tail sets them.
> This seems to be a side effect of #9 ?
>  4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> and doesn't work without ONFI (see patch for possible fix). The
> driver should probably use the same scheme the core code uses..
> But this is all a problem because of #10
>  5) The driver assumes alignment of the iomap, needs to use + not |
> when constructing the address. (yes, this blows up on my system)
>  6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> Maybe timing should be common code driven by DT..
>  7) Driver unconditionally selects a BBT format, and an ECC layout
> (neither match what my system uses, but I guess that is a core mtd
> issue these days :/)
>  8) Driver unconditionally forces a chip-delay (wrong for my
> system) maybe this should be common code driven by DT..
>  9) This buisness with pl353_nand_ecc_init and the
> special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> is just horrid. I'd expect that is a big NAK.
> 
> The driver needs to implement read_buf *properly* so the core
> routines can be used instead of trying to 'fix' the call sites
> to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
>  10) pl353_nand_cmd_function is a wonky copy of nand_command_lp,
> maybe
>  this driver should use cmd_ctrl, or the core code should be
>  refactored some more..
> 
> Jason
> 
> diff --git a/drivers/mtd/nand/pl353_nand.c
> b/drivers/mtd/nand/pl353_nand.c
> index 7e3993931f75..63a8d8c008e3 100644
> --- a/drivers/mtd/nand/pl353_nand.c
> +++ b/drivers/mtd/nand/pl353_nand.c
> @@ -26,7 +26,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -56,7 +55,6 @@
>  #define PL353_NAND_ECC_LAST  BIT(ECC_LAST_SHIFT) /* Set
> ECC_Last */
>  #define PL353_NAND_CLEAR_CS  BIT(CLEAR_CS_SHIFT) /* Clear chip
> select */
> 
> -#define ONDIE_ECC_FEATURE_ADDR   0x90
>  #define PL353_NAND_ECC_BUSY_TIMEOUT  (1 * HZ)
>  #define PL353_NAND_DEV_BUSY_TIMEOUT  (1 * HZ)
>  #define PL353_NAND_LAST_TRANSFER_LENGTH  4
> @@ -88,11 +86,9 @@ struct pl353_nand_command_format {
>   */
>  st

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Punnaiah Choudary Kalluri 


> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Tuesday, October 25, 2016 10:16 AM
> To: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> Cc: Boris Brezillon <boris.brezil...@free-electrons.com>;
> mark.rutl...@arm.com; linux-...@lists.infradead.org;
> michal.si...@xilinx.com; ezequiel.gar...@free-electrons.com; linux-
> ker...@vger.kernel.org; r...@landley.net; ga...@codeaurora.org;
> computersforpe...@gmail.com; dw...@infradead.org
> Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand
> interface
>
> On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote:
>
> > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> > > more to work on my hardware. The driver appears to be in no better
> > > shape than the 3.12 out-of-tree Xilinx release I was using previously..
> >
> > The driver in Xilinx tree works with 4.6 kernel and adopted the
> > required
>
> I mean, the driver from the 3.12 Xilinx tree that I last looked
> at years ago. This is at v7 now and is still needs lots of work, I did
> some fixing, including making parts of it work on 4.8.
> You can copy it out of the patch I sent you.
>
> > Changes (may release in 1-2 weeks). Still it need some rework, now a days
> > I am seeing many requests from different people for this driver and some
> of
> > Them are using different version of IP as you know this IP has four variants
> and
> > Xilinx is using the pl353 variant.
>
> Well, I am using Xilinx Zynq hardware and care about making that
> configuration actually work. This is the last driver I require to use
> Zynq with mainline.
>

Sure.

> It clearly needs more work than just forward porting to 4.8, so please
> let me know if you are able to tackle this.

I didn't say that I am forwarding the patch working with 4.8. I said
We made changes to driver compatible for 4.6 and working on driver rework,
Most of your comments also part of that.

>
> > Let's wait for the next series of patches and Get the patches tested
> > with others as well along with the review comments.
>
> You now have 10 review comments from me, please respond to all of them
> in
> your v8 patchset - no sense in continuing to drag this out.
>

See above.

> Please cc me on future series.

Ok.

Regards,
Punnaiah

>
> Jason
>
> > Regards,
> > Punnaiah
> > > I've attached the ugly, ugly patch I made, it may save you some time
> > > when preparing v8.
> > >
> > > Commentary:
> > >  1) nand_chip already includes mtd_info, no reason for a second one in
> > > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> > > should be used instead of priv
> > >  2) I hacked out all the ECC stuff from the driver since I don't use
> > > it and it was broken.. Obviously some has to come back, but fixing
> > > other things on this list first will make that much easier and 
> > > better..
> > >  3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are
> pure
> > > outdated copies of the core routines and should not exist in a
> > > driver. This needs to be fixed so nand_scan_tail sets them.
> > > This seems to be a side effect of #9 ?
> > >  4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> > > and doesn't work without ONFI (see patch for possible fix). The
> > > driver should probably use the same scheme the core code uses..
> > > But this is all a problem because of #10
> > >  5) The driver assumes alignment of the iomap, needs to use + not |
> > > when constructing the address. (yes, this blows up on my system)
> > >  6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> > > Maybe timing should be common code driven by DT..
> > >  7) Driver unconditionally selects a BBT format, and an ECC layout
> > > (neither match what my system uses, but I guess that is a core mtd
> > > issue these days :/)
> > >  8) Driver unconditionally forces a chip-delay (wrong for my
> > > system) maybe this should be common code driven by DT..
> > >  9) This buisness with pl353_nand_ecc_init and the
> > > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> > > is just horrid. I'd expect that is a big NAK.
> > >
> > > The driver needs to implement read_buf *properly* so the core
> > > routines can be used instead of trying to 'fix' the call sites
> > > to do the PL353_NAND_LAST_TRANSFER_LENGTH st

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Punnaiah Choudary Kalluri 


> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Tuesday, October 25, 2016 10:16 AM
> To: Punnaiah Choudary Kalluri 
> Cc: Boris Brezillon ;
> mark.rutl...@arm.com; linux-...@lists.infradead.org;
> michal.si...@xilinx.com; ezequiel.gar...@free-electrons.com; linux-
> ker...@vger.kernel.org; r...@landley.net; ga...@codeaurora.org;
> computersforpe...@gmail.com; dw...@infradead.org
> Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand
> interface
>
> On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote:
>
> > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> > > more to work on my hardware. The driver appears to be in no better
> > > shape than the 3.12 out-of-tree Xilinx release I was using previously..
> >
> > The driver in Xilinx tree works with 4.6 kernel and adopted the
> > required
>
> I mean, the driver from the 3.12 Xilinx tree that I last looked
> at years ago. This is at v7 now and is still needs lots of work, I did
> some fixing, including making parts of it work on 4.8.
> You can copy it out of the patch I sent you.
>
> > Changes (may release in 1-2 weeks). Still it need some rework, now a days
> > I am seeing many requests from different people for this driver and some
> of
> > Them are using different version of IP as you know this IP has four variants
> and
> > Xilinx is using the pl353 variant.
>
> Well, I am using Xilinx Zynq hardware and care about making that
> configuration actually work. This is the last driver I require to use
> Zynq with mainline.
>

Sure.

> It clearly needs more work than just forward porting to 4.8, so please
> let me know if you are able to tackle this.

I didn't say that I am forwarding the patch working with 4.8. I said
We made changes to driver compatible for 4.6 and working on driver rework,
Most of your comments also part of that.

>
> > Let's wait for the next series of patches and Get the patches tested
> > with others as well along with the review comments.
>
> You now have 10 review comments from me, please respond to all of them
> in
> your v8 patchset - no sense in continuing to drag this out.
>

See above.

> Please cc me on future series.

Ok.

Regards,
Punnaiah

>
> Jason
>
> > Regards,
> > Punnaiah
> > > I've attached the ugly, ugly patch I made, it may save you some time
> > > when preparing v8.
> > >
> > > Commentary:
> > >  1) nand_chip already includes mtd_info, no reason for a second one in
> > > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> > > should be used instead of priv
> > >  2) I hacked out all the ECC stuff from the driver since I don't use
> > > it and it was broken.. Obviously some has to come back, but fixing
> > > other things on this list first will make that much easier and 
> > > better..
> > >  3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are
> pure
> > > outdated copies of the core routines and should not exist in a
> > > driver. This needs to be fixed so nand_scan_tail sets them.
> > > This seems to be a side effect of #9 ?
> > >  4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> > > and doesn't work without ONFI (see patch for possible fix). The
> > > driver should probably use the same scheme the core code uses..
> > > But this is all a problem because of #10
> > >  5) The driver assumes alignment of the iomap, needs to use + not |
> > > when constructing the address. (yes, this blows up on my system)
> > >  6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> > > Maybe timing should be common code driven by DT..
> > >  7) Driver unconditionally selects a BBT format, and an ECC layout
> > > (neither match what my system uses, but I guess that is a core mtd
> > > issue these days :/)
> > >  8) Driver unconditionally forces a chip-delay (wrong for my
> > > system) maybe this should be common code driven by DT..
> > >  9) This buisness with pl353_nand_ecc_init and the
> > > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> > > is just horrid. I'd expect that is a big NAK.
> > >
> > > The driver needs to implement read_buf *properly* so the core
> > > routines can be used instead of trying to 'fix' the call sites
> > > to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
> > >  10) pl353_nand_cmd_function is a wonky copy of nand_command_lp,
> > > maybe
> > >  this driver should use cmd_ctrl, or the core code should be
> > >  refactored some more..


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Jason Gunthorpe 
On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote:

> > I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> > more to work on my hardware. The driver appears to be in no better
> > shape than the 3.12 out-of-tree Xilinx release I was using previously..
>
> The driver in Xilinx tree works with 4.6 kernel and adopted the
> required

I mean, the driver from the 3.12 Xilinx tree that I last looked
at years ago. This is at v7 now and is still needs lots of work, I did
some fixing, including making parts of it work on 4.8.
You can copy it out of the patch I sent you.

> Changes (may release in 1-2 weeks). Still it need some rework, now a days
> I am seeing many requests from different people for this driver and some of
> Them are using different version of IP as you know this IP has four variants 
> and
> Xilinx is using the pl353 variant.

Well, I am using Xilinx Zynq hardware and care about making that
configuration actually work. This is the last driver I require to use
Zynq with mainline.

It clearly needs more work than just forward porting to 4.8, so please
let me know if you are able to tackle this.

> Let's wait for the next series of patches and Get the patches tested
> with others as well along with the review comments.

You now have 10 review comments from me, please respond to all of them in
your v8 patchset - no sense in continuing to drag this out.

Please cc me on future series.

Jason

> Regards,
> Punnaiah
> > I've attached the ugly, ugly patch I made, it may save you some time
> > when preparing v8.
> > 
> > Commentary:
> >  1) nand_chip already includes mtd_info, no reason for a second one in
> > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> > should be used instead of priv
> >  2) I hacked out all the ECC stuff from the driver since I don't use
> > it and it was broken.. Obviously some has to come back, but fixing
> > other things on this list first will make that much easier and better..
> >  3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
> > outdated copies of the core routines and should not exist in a
> > driver. This needs to be fixed so nand_scan_tail sets them.
> > This seems to be a side effect of #9 ?
> >  4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> > and doesn't work without ONFI (see patch for possible fix). The
> > driver should probably use the same scheme the core code uses..
> > But this is all a problem because of #10
> >  5) The driver assumes alignment of the iomap, needs to use + not |
> > when constructing the address. (yes, this blows up on my system)
> >  6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> > Maybe timing should be common code driven by DT..
> >  7) Driver unconditionally selects a BBT format, and an ECC layout
> > (neither match what my system uses, but I guess that is a core mtd
> > issue these days :/)
> >  8) Driver unconditionally forces a chip-delay (wrong for my
> > system) maybe this should be common code driven by DT..
> >  9) This buisness with pl353_nand_ecc_init and the
> > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> > is just horrid. I'd expect that is a big NAK.
> > 
> > The driver needs to implement read_buf *properly* so the core
> > routines can be used instead of trying to 'fix' the call sites
> > to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
> >  10) pl353_nand_cmd_function is a wonky copy of nand_command_lp,
> > maybe
> >  this driver should use cmd_ctrl, or the core code should be
> >  refactored some more..

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Jason Gunthorpe 
On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote:

> > I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> > more to work on my hardware. The driver appears to be in no better
> > shape than the 3.12 out-of-tree Xilinx release I was using previously..
>
> The driver in Xilinx tree works with 4.6 kernel and adopted the
> required

I mean, the driver from the 3.12 Xilinx tree that I last looked
at years ago. This is at v7 now and is still needs lots of work, I did
some fixing, including making parts of it work on 4.8.
You can copy it out of the patch I sent you.

> Changes (may release in 1-2 weeks). Still it need some rework, now a days
> I am seeing many requests from different people for this driver and some of
> Them are using different version of IP as you know this IP has four variants 
> and
> Xilinx is using the pl353 variant.

Well, I am using Xilinx Zynq hardware and care about making that
configuration actually work. This is the last driver I require to use
Zynq with mainline.

It clearly needs more work than just forward porting to 4.8, so please
let me know if you are able to tackle this.

> Let's wait for the next series of patches and Get the patches tested
> with others as well along with the review comments.

You now have 10 review comments from me, please respond to all of them in
your v8 patchset - no sense in continuing to drag this out.

Please cc me on future series.

Jason

> Regards,
> Punnaiah
> > I've attached the ugly, ugly patch I made, it may save you some time
> > when preparing v8.
> > 
> > Commentary:
> >  1) nand_chip already includes mtd_info, no reason for a second one in
> > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> > should be used instead of priv
> >  2) I hacked out all the ECC stuff from the driver since I don't use
> > it and it was broken.. Obviously some has to come back, but fixing
> > other things on this list first will make that much easier and better..
> >  3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
> > outdated copies of the core routines and should not exist in a
> > driver. This needs to be fixed so nand_scan_tail sets them.
> > This seems to be a side effect of #9 ?
> >  4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> > and doesn't work without ONFI (see patch for possible fix). The
> > driver should probably use the same scheme the core code uses..
> > But this is all a problem because of #10
> >  5) The driver assumes alignment of the iomap, needs to use + not |
> > when constructing the address. (yes, this blows up on my system)
> >  6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> > Maybe timing should be common code driven by DT..
> >  7) Driver unconditionally selects a BBT format, and an ECC layout
> > (neither match what my system uses, but I guess that is a core mtd
> > issue these days :/)
> >  8) Driver unconditionally forces a chip-delay (wrong for my
> > system) maybe this should be common code driven by DT..
> >  9) This buisness with pl353_nand_ecc_init and the
> > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> > is just horrid. I'd expect that is a big NAK.
> > 
> > The driver needs to implement read_buf *properly* so the core
> > routines can be used instead of trying to 'fix' the call sites
> > to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
> >  10) pl353_nand_cmd_function is a wonky copy of nand_command_lp,
> > maybe
> >  this driver should use cmd_ctrl, or the core code should be
> >  refactored some more..

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Jason Gunthorpe 
[cc list trimmed]

On Sun, Oct 23, 2016 at 05:37:42PM +0530, punnaiah choudary kalluri wrote:
> Hi Boris and Jason,
> 
>  I am doing rework on these patches to accommodate recent changes with
>  respect to ooblayout. Also some of the comments that i have received
> from Boris as part of the arasan nand controller upstream patches will
> apply to this driver. So, i will be releasing the next set of patches for this
> driver soon and request your time for reviewing those patches.

I have hacked the v7 patchset enough to work on 4.8 and hacked it some
more to work on my hardware. The driver appears to be in no better
shape than the 3.12 out-of-tree Xilinx release I was using previously..

I've attached the ugly, ugly patch I made, it may save you some time
when preparing v8.

Commentary:
 1) nand_chip already includes mtd_info, no reason for a second one in
the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
should be used instead of priv
 2) I hacked out all the ECC stuff from the driver since I don't use
it and it was broken.. Obviously some has to come back, but fixing
other things on this list first will make that much easier and better..
 3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
outdated copies of the core routines and should not exist in a
driver. This needs to be fixed so nand_scan_tail sets them.
This seems to be a side effect of #9 ?
 4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
and doesn't work without ONFI (see patch for possible fix). The
driver should probably use the same scheme the core code uses..
But this is all a problem because of #10
 5) The driver assumes alignment of the iomap, needs to use + not |
when constructing the address. (yes, this blows up on my system)
 6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
Maybe timing should be common code driven by DT..
 7) Driver unconditionally selects a BBT format, and an ECC layout
(neither match what my system uses, but I guess that is a core mtd
issue these days :/)
 8) Driver unconditionally forces a chip-delay (wrong for my
system) maybe this should be common code driven by DT..
 9) This buisness with pl353_nand_ecc_init and the
special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
is just horrid. I'd expect that is a big NAK.

The driver needs to implement read_buf *properly* so the core
routines can be used instead of trying to 'fix' the call sites
to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
 10) pl353_nand_cmd_function is a wonky copy of nand_command_lp, maybe
 this driver should use cmd_ctrl, or the core code should be
 refactored some more..

Jason

diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index 7e3993931f75..63a8d8c008e3 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -56,7 +55,6 @@
 #define PL353_NAND_ECC_LASTBIT(ECC_LAST_SHIFT) /* Set ECC_Last */
 #define PL353_NAND_CLEAR_CSBIT(CLEAR_CS_SHIFT) /* Clear chip select */
 
-#define ONDIE_ECC_FEATURE_ADDR 0x90
 #define PL353_NAND_ECC_BUSY_TIMEOUT(1 * HZ)
 #define PL353_NAND_DEV_BUSY_TIMEOUT(1 * HZ)
 #define PL353_NAND_LAST_TRANSFER_LENGTH4
@@ -88,11 +86,9 @@ struct pl353_nand_command_format {
  */
 struct pl353_nand_info {
struct nand_chip chip;
-   struct mtd_info mtd;
void __iomem *nand_base;
unsigned long end_cmd_pending;
unsigned long end_cmd;
-   int ecc_mode;
u8 raddr_cycles;
u8 caddr_cycles;
 };
@@ -101,13 +97,13 @@ struct pl353_nand_info {
  * The NAND flash operations command format
  */
 static const struct pl353_nand_command_format pl353_nand_commands[] = {
-   {NAND_CMD_READ0, NAND_CMD_READSTART, 5, PL353_NAND_CMD_PHASE},
+   {NAND_CMD_READ0, NAND_CMD_READSTART, -1, PL353_NAND_CMD_PHASE},
{NAND_CMD_RNDOUT, NAND_CMD_RNDOUTSTART, 2, PL353_NAND_CMD_PHASE},
{NAND_CMD_READID, NAND_CMD_NONE, 1, NAND_CMD_NONE},
{NAND_CMD_STATUS, NAND_CMD_NONE, 0, NAND_CMD_NONE},
-   {NAND_CMD_SEQIN, NAND_CMD_PAGEPROG, 5, PL353_NAND_DATA_PHASE},
+   {NAND_CMD_SEQIN, NAND_CMD_PAGEPROG, -1, PL353_NAND_DATA_PHASE},
{NAND_CMD_RNDIN, NAND_CMD_NONE, 2, NAND_CMD_NONE},
-   {NAND_CMD_ERASE1, NAND_CMD_ERASE2, 3, PL353_NAND_CMD_PHASE},
+   {NAND_CMD_ERASE1, NAND_CMD_ERASE2, -1, PL353_NAND_CMD_PHASE},
{NAND_CMD_RESET, NAND_CMD_NONE, 0, NAND_CMD_NONE},
{NAND_CMD_PARAM, NAND_CMD_NONE, 1, NAND_CMD_NONE},
{NAND_CMD_GET_FEATURES, NAND_CMD_NONE, 1, NAND_CMD_NONE},
@@ -126,22 +122,58 @@ static const struct pl353_nand_command_format 
pl353_nand_commands[] = {
 };
 
 /* Define default oob placement schemes for large and small page devices */
-static struct nand_ecclayout nand_oob_16 = {
-   .eccbytes = 3,
-

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Jason Gunthorpe 
[cc list trimmed]

On Sun, Oct 23, 2016 at 05:37:42PM +0530, punnaiah choudary kalluri wrote:
> Hi Boris and Jason,
> 
>  I am doing rework on these patches to accommodate recent changes with
>  respect to ooblayout. Also some of the comments that i have received
> from Boris as part of the arasan nand controller upstream patches will
> apply to this driver. So, i will be releasing the next set of patches for this
> driver soon and request your time for reviewing those patches.

I have hacked the v7 patchset enough to work on 4.8 and hacked it some
more to work on my hardware. The driver appears to be in no better
shape than the 3.12 out-of-tree Xilinx release I was using previously..

I've attached the ugly, ugly patch I made, it may save you some time
when preparing v8.

Commentary:
 1) nand_chip already includes mtd_info, no reason for a second one in
the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
should be used instead of priv
 2) I hacked out all the ECC stuff from the driver since I don't use
it and it was broken.. Obviously some has to come back, but fixing
other things on this list first will make that much easier and better..
 3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
outdated copies of the core routines and should not exist in a
driver. This needs to be fixed so nand_scan_tail sets them.
This seems to be a side effect of #9 ?
 4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
and doesn't work without ONFI (see patch for possible fix). The
driver should probably use the same scheme the core code uses..
But this is all a problem because of #10
 5) The driver assumes alignment of the iomap, needs to use + not |
when constructing the address. (yes, this blows up on my system)
 6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
Maybe timing should be common code driven by DT..
 7) Driver unconditionally selects a BBT format, and an ECC layout
(neither match what my system uses, but I guess that is a core mtd
issue these days :/)
 8) Driver unconditionally forces a chip-delay (wrong for my
system) maybe this should be common code driven by DT..
 9) This buisness with pl353_nand_ecc_init and the
special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
is just horrid. I'd expect that is a big NAK.

The driver needs to implement read_buf *properly* so the core
routines can be used instead of trying to 'fix' the call sites
to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
 10) pl353_nand_cmd_function is a wonky copy of nand_command_lp, maybe
 this driver should use cmd_ctrl, or the core code should be
 refactored some more..

Jason

diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index 7e3993931f75..63a8d8c008e3 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -56,7 +55,6 @@
 #define PL353_NAND_ECC_LASTBIT(ECC_LAST_SHIFT) /* Set ECC_Last */
 #define PL353_NAND_CLEAR_CSBIT(CLEAR_CS_SHIFT) /* Clear chip select */
 
-#define ONDIE_ECC_FEATURE_ADDR 0x90
 #define PL353_NAND_ECC_BUSY_TIMEOUT(1 * HZ)
 #define PL353_NAND_DEV_BUSY_TIMEOUT(1 * HZ)
 #define PL353_NAND_LAST_TRANSFER_LENGTH4
@@ -88,11 +86,9 @@ struct pl353_nand_command_format {
  */
 struct pl353_nand_info {
struct nand_chip chip;
-   struct mtd_info mtd;
void __iomem *nand_base;
unsigned long end_cmd_pending;
unsigned long end_cmd;
-   int ecc_mode;
u8 raddr_cycles;
u8 caddr_cycles;
 };
@@ -101,13 +97,13 @@ struct pl353_nand_info {
  * The NAND flash operations command format
  */
 static const struct pl353_nand_command_format pl353_nand_commands[] = {
-   {NAND_CMD_READ0, NAND_CMD_READSTART, 5, PL353_NAND_CMD_PHASE},
+   {NAND_CMD_READ0, NAND_CMD_READSTART, -1, PL353_NAND_CMD_PHASE},
{NAND_CMD_RNDOUT, NAND_CMD_RNDOUTSTART, 2, PL353_NAND_CMD_PHASE},
{NAND_CMD_READID, NAND_CMD_NONE, 1, NAND_CMD_NONE},
{NAND_CMD_STATUS, NAND_CMD_NONE, 0, NAND_CMD_NONE},
-   {NAND_CMD_SEQIN, NAND_CMD_PAGEPROG, 5, PL353_NAND_DATA_PHASE},
+   {NAND_CMD_SEQIN, NAND_CMD_PAGEPROG, -1, PL353_NAND_DATA_PHASE},
{NAND_CMD_RNDIN, NAND_CMD_NONE, 2, NAND_CMD_NONE},
-   {NAND_CMD_ERASE1, NAND_CMD_ERASE2, 3, PL353_NAND_CMD_PHASE},
+   {NAND_CMD_ERASE1, NAND_CMD_ERASE2, -1, PL353_NAND_CMD_PHASE},
{NAND_CMD_RESET, NAND_CMD_NONE, 0, NAND_CMD_NONE},
{NAND_CMD_PARAM, NAND_CMD_NONE, 1, NAND_CMD_NONE},
{NAND_CMD_GET_FEATURES, NAND_CMD_NONE, 1, NAND_CMD_NONE},
@@ -126,22 +122,58 @@ static const struct pl353_nand_command_format 
pl353_nand_commands[] = {
 };
 
 /* Define default oob placement schemes for large and small page devices */
-static struct nand_ecclayout nand_oob_16 = {
-   .eccbytes = 3,
-

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Boris Brezillon 
Hi Punnaih,

On Sun, 23 Oct 2016 17:37:42 +0530
punnaiah choudary kalluri  wrote:

> Hi Boris and Jason,
> 
>  I am doing rework on these patches to accommodate recent changes with
>  respect to ooblayout. Also some of the comments that i have received
> from Boris as part of the arasan nand controller upstream patches will
> apply to this driver. So, i will be releasing the next set of patches for this
> driver soon and request your time for reviewing those patches.
> 
> for now, please ignore these patches.

OK. Thanks for the heads up. I'll wait for your new version.

Regards,

Boris

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-24 Thread Boris Brezillon 
Hi Punnaih,

On Sun, 23 Oct 2016 17:37:42 +0530
punnaiah choudary kalluri  wrote:

> Hi Boris and Jason,
> 
>  I am doing rework on these patches to accommodate recent changes with
>  respect to ooblayout. Also some of the comments that i have received
> from Boris as part of the arasan nand controller upstream patches will
> apply to this driver. So, i will be releasing the next set of patches for this
> driver soon and request your time for reviewing those patches.
> 
> for now, please ignore these patches.

OK. Thanks for the heads up. I'll wait for your new version.

Regards,

Boris

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-23 Thread punnaiah choudary kalluri 
Hi Boris and Jason,

 I am doing rework on these patches to accommodate recent changes with
 respect to ooblayout. Also some of the comments that i have received
from Boris as part of the arasan nand controller upstream patches will
apply to this driver. So, i will be releasing the next set of patches for this
driver soon and request your time for reviewing those patches.

for now, please ignore these patches.

Regards,
Punnaiah

On Sat, Oct 22, 2016 at 3:16 AM, Boris Brezillon
 wrote:
> On Fri, 21 Oct 2016 14:33:22 -0600
> Jason Gunthorpe  wrote:
>
>> On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
>> > Add driver for arm pl353 static memory controller nand interface with
>> > HW ECC support. This controller is used in xilinx zynq soc for interfacing
>> > the nand flash memory.
>> >
>> > Signed-off-by: Punnaiah Choudary Kalluri 
>> > Changes in v7:
>> >  - Currently not implemented the memclk rate adjustments. I will
>> >look into this later and once the basic driver is accepted.
>> >  - Fixed GPL licence ident
>> > Changes in v6:
>> >  - Fixed the checkpatch.pl reported warnings
>> >  - Using the address cycles information from the onfi param page
>> >earlier it is hardcoded to 5 in driver
>> > Changes in v5:
>> >  - Configure the nand timing parameters as per the onfi spec
>> > Changes in v4:
>> >  - Updated the driver to sync with pl353_smc driver APIs
>> > Changes in v3:
>> >  - implemented the proper error codes
>> >  - further breakdown this patch to multiple sets
>> >  - added the controller and driver details to Documentation section
>> >  - updated the licenece to GPLv2
>> >  - reorganized the pl353_nand_ecc_init function
>> > Changes in v2:
>> >  - use "depends on" rather than "select" option in kconfig
>> >  - remove unused variable parts
>> >  - remove dummy helper and use writel_relaxed directly
>>
>> What is the status of getting this driver merged? I am interested in
>> this driver and can provide some help if there are still TODO items.
>
> I'll try to review it next week.
>
>>
>> At the very least I will test it, is there something newer than v7 out
>> there?
>>
>> Regards,
>> Jason
>>
>> __
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-23 Thread punnaiah choudary kalluri 
Hi Boris and Jason,

 I am doing rework on these patches to accommodate recent changes with
 respect to ooblayout. Also some of the comments that i have received
from Boris as part of the arasan nand controller upstream patches will
apply to this driver. So, i will be releasing the next set of patches for this
driver soon and request your time for reviewing those patches.

for now, please ignore these patches.

Regards,
Punnaiah

On Sat, Oct 22, 2016 at 3:16 AM, Boris Brezillon
 wrote:
> On Fri, 21 Oct 2016 14:33:22 -0600
> Jason Gunthorpe  wrote:
>
>> On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
>> > Add driver for arm pl353 static memory controller nand interface with
>> > HW ECC support. This controller is used in xilinx zynq soc for interfacing
>> > the nand flash memory.
>> >
>> > Signed-off-by: Punnaiah Choudary Kalluri 
>> > Changes in v7:
>> >  - Currently not implemented the memclk rate adjustments. I will
>> >look into this later and once the basic driver is accepted.
>> >  - Fixed GPL licence ident
>> > Changes in v6:
>> >  - Fixed the checkpatch.pl reported warnings
>> >  - Using the address cycles information from the onfi param page
>> >earlier it is hardcoded to 5 in driver
>> > Changes in v5:
>> >  - Configure the nand timing parameters as per the onfi spec
>> > Changes in v4:
>> >  - Updated the driver to sync with pl353_smc driver APIs
>> > Changes in v3:
>> >  - implemented the proper error codes
>> >  - further breakdown this patch to multiple sets
>> >  - added the controller and driver details to Documentation section
>> >  - updated the licenece to GPLv2
>> >  - reorganized the pl353_nand_ecc_init function
>> > Changes in v2:
>> >  - use "depends on" rather than "select" option in kconfig
>> >  - remove unused variable parts
>> >  - remove dummy helper and use writel_relaxed directly
>>
>> What is the status of getting this driver merged? I am interested in
>> this driver and can provide some help if there are still TODO items.
>
> I'll try to review it next week.
>
>>
>> At the very least I will test it, is there something newer than v7 out
>> there?
>>
>> Regards,
>> Jason
>>
>> __
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-21 Thread Boris Brezillon 
On Fri, 21 Oct 2016 14:33:22 -0600
Jason Gunthorpe  wrote:

> On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
> > Add driver for arm pl353 static memory controller nand interface with
> > HW ECC support. This controller is used in xilinx zynq soc for interfacing
> > the nand flash memory.
> > 
> > Signed-off-by: Punnaiah Choudary Kalluri 
> > Changes in v7:
> >  - Currently not implemented the memclk rate adjustments. I will
> >look into this later and once the basic driver is accepted.
> >  - Fixed GPL licence ident
> > Changes in v6:
> >  - Fixed the checkpatch.pl reported warnings
> >  - Using the address cycles information from the onfi param page
> >earlier it is hardcoded to 5 in driver
> > Changes in v5:
> >  - Configure the nand timing parameters as per the onfi spec
> > Changes in v4:
> >  - Updated the driver to sync with pl353_smc driver APIs
> > Changes in v3:
> >  - implemented the proper error codes
> >  - further breakdown this patch to multiple sets
> >  - added the controller and driver details to Documentation section
> >  - updated the licenece to GPLv2
> >  - reorganized the pl353_nand_ecc_init function
> > Changes in v2:
> >  - use "depends on" rather than "select" option in kconfig
> >  - remove unused variable parts
> >  - remove dummy helper and use writel_relaxed directly  
> 
> What is the status of getting this driver merged? I am interested in
> this driver and can provide some help if there are still TODO items.

I'll try to review it next week.

> 
> At the very least I will test it, is there something newer than v7 out
> there?
> 
> Regards,
> Jason
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-21 Thread Boris Brezillon 
On Fri, 21 Oct 2016 14:33:22 -0600
Jason Gunthorpe  wrote:

> On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
> > Add driver for arm pl353 static memory controller nand interface with
> > HW ECC support. This controller is used in xilinx zynq soc for interfacing
> > the nand flash memory.
> > 
> > Signed-off-by: Punnaiah Choudary Kalluri 
> > Changes in v7:
> >  - Currently not implemented the memclk rate adjustments. I will
> >look into this later and once the basic driver is accepted.
> >  - Fixed GPL licence ident
> > Changes in v6:
> >  - Fixed the checkpatch.pl reported warnings
> >  - Using the address cycles information from the onfi param page
> >earlier it is hardcoded to 5 in driver
> > Changes in v5:
> >  - Configure the nand timing parameters as per the onfi spec
> > Changes in v4:
> >  - Updated the driver to sync with pl353_smc driver APIs
> > Changes in v3:
> >  - implemented the proper error codes
> >  - further breakdown this patch to multiple sets
> >  - added the controller and driver details to Documentation section
> >  - updated the licenece to GPLv2
> >  - reorganized the pl353_nand_ecc_init function
> > Changes in v2:
> >  - use "depends on" rather than "select" option in kconfig
> >  - remove unused variable parts
> >  - remove dummy helper and use writel_relaxed directly  
> 
> What is the status of getting this driver merged? I am interested in
> this driver and can provide some help if there are still TODO items.

I'll try to review it next week.

> 
> At the very least I will test it, is there something newer than v7 out
> there?
> 
> Regards,
> Jason
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-21 Thread Jason Gunthorpe 
On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
> Add driver for arm pl353 static memory controller nand interface with
> HW ECC support. This controller is used in xilinx zynq soc for interfacing
> the nand flash memory.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> Changes in v7:
>  - Currently not implemented the memclk rate adjustments. I will
>look into this later and once the basic driver is accepted.
>  - Fixed GPL licence ident
> Changes in v6:
>  - Fixed the checkpatch.pl reported warnings
>  - Using the address cycles information from the onfi param page
>earlier it is hardcoded to 5 in driver
> Changes in v5:
>  - Configure the nand timing parameters as per the onfi spec
> Changes in v4:
>  - Updated the driver to sync with pl353_smc driver APIs
> Changes in v3:
>  - implemented the proper error codes
>  - further breakdown this patch to multiple sets
>  - added the controller and driver details to Documentation section
>  - updated the licenece to GPLv2
>  - reorganized the pl353_nand_ecc_init function
> Changes in v2:
>  - use "depends on" rather than "select" option in kconfig
>  - remove unused variable parts
>  - remove dummy helper and use writel_relaxed directly

What is the status of getting this driver merged? I am interested in
this driver and can provide some help if there are still TODO items.

At the very least I will test it, is there something newer than v7 out
there?

Regards,
Jason

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

2016-10-21 Thread Jason Gunthorpe 
On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
> Add driver for arm pl353 static memory controller nand interface with
> HW ECC support. This controller is used in xilinx zynq soc for interfacing
> the nand flash memory.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> Changes in v7:
>  - Currently not implemented the memclk rate adjustments. I will
>look into this later and once the basic driver is accepted.
>  - Fixed GPL licence ident
> Changes in v6:
>  - Fixed the checkpatch.pl reported warnings
>  - Using the address cycles information from the onfi param page
>earlier it is hardcoded to 5 in driver
> Changes in v5:
>  - Configure the nand timing parameters as per the onfi spec
> Changes in v4:
>  - Updated the driver to sync with pl353_smc driver APIs
> Changes in v3:
>  - implemented the proper error codes
>  - further breakdown this patch to multiple sets
>  - added the controller and driver details to Documentation section
>  - updated the licenece to GPLv2
>  - reorganized the pl353_nand_ecc_init function
> Changes in v2:
>  - use "depends on" rather than "select" option in kconfig
>  - remove unused variable parts
>  - remove dummy helper and use writel_relaxed directly

What is the status of getting this driver merged? I am interested in
this driver and can provide some help if there are still TODO items.

At the very least I will test it, is there something newer than v7 out
there?

Regards,
Jason