RE: [PATCH] serial: fsl_lpuart: Remove the alias node dependence

[Yao Yuan]

On Wed, Jan 11, 2016 at 04:33:32PM +0800, Greg KH wrote:
> On Wed, Dec 14, 2016 at 04:33:32PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Numbering the ttyLPn space should not depend on the generic name
> > "serial".
> >
> > If don't add the alias node like:"serial0 = ", then lpuart
> > will probe failed:
> > [0.773410] fsl-lpuart 295.serial: failed to get alias id, errno -19
> >
> > So remove the alias node dependence, and add the support for allocate
> > the line port automatically.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  drivers/tty/serial/fsl_lpuart.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/fsl_lpuart.c
> > b/drivers/tty/serial/fsl_lpuart.c index a1c6519..c6d639f 100644
> > --- a/drivers/tty/serial/fsl_lpuart.c
> > +++ b/drivers/tty/serial/fsl_lpuart.c
> > @@ -231,6 +231,8 @@
> >  #define DEV_NAME   "ttyLP"
> >  #define UART_NR6
> >
> > +static DECLARE_BITMAP(linemap, UART_NR);
> 
> Why a bitmap?

Because I think the bitmap is enough to meet the need.
Are there any shortcomings for bitmap used here?

> 
> > +
> >  struct lpuart_port {
> > struct uart_portport;
> > struct clk  *clk;
> > @@ -1963,9 +1965,13 @@ static int lpuart_probe(struct platform_device
> > *pdev)
> >
> > ret = of_alias_get_id(np, "serial");
> > if (ret < 0) {
> > -   dev_err(>dev, "failed to get alias id, errno %d\n", ret);
> > -   return ret;
> > +   ret = find_first_zero_bit(linemap, UART_NR);
> > +   if (ret >= UART_NR) {
> > +   dev_err(>dev, "port line is full, add device
> failed\n");
> > +   return ret;
> > +   }
> 
> Does this really remove the alias dependancy?
> 
> Please use an idr or ida for this instead of a bitmap.
> 

Hi Greg,

Thanks for your review.

Is there any advantage for use an idr or ida instead of bitmap?
I will hope to get your guidance.

Thanks.

RE: [PATCH] serial: fsl_lpuart: Remove the alias node dependence

[Yao Yuan]

On Wed, Jan 11, 2016 at 04:33:32PM +0800, Greg KH wrote:
> On Wed, Dec 14, 2016 at 04:33:32PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Numbering the ttyLPn space should not depend on the generic name
> > "serial".
> >
> > If don't add the alias node like:"serial0 = ", then lpuart
> > will probe failed:
> > [0.773410] fsl-lpuart 295.serial: failed to get alias id, errno -19
> >
> > So remove the alias node dependence, and add the support for allocate
> > the line port automatically.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  drivers/tty/serial/fsl_lpuart.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/fsl_lpuart.c
> > b/drivers/tty/serial/fsl_lpuart.c index a1c6519..c6d639f 100644
> > --- a/drivers/tty/serial/fsl_lpuart.c
> > +++ b/drivers/tty/serial/fsl_lpuart.c
> > @@ -231,6 +231,8 @@
> >  #define DEV_NAME   "ttyLP"
> >  #define UART_NR6
> >
> > +static DECLARE_BITMAP(linemap, UART_NR);
> 
> Why a bitmap?

Because I think the bitmap is enough to meet the need.
Are there any shortcomings for bitmap used here?

> 
> > +
> >  struct lpuart_port {
> > struct uart_portport;
> > struct clk  *clk;
> > @@ -1963,9 +1965,13 @@ static int lpuart_probe(struct platform_device
> > *pdev)
> >
> > ret = of_alias_get_id(np, "serial");
> > if (ret < 0) {
> > -   dev_err(>dev, "failed to get alias id, errno %d\n", ret);
> > -   return ret;
> > +   ret = find_first_zero_bit(linemap, UART_NR);
> > +   if (ret >= UART_NR) {
> > +   dev_err(>dev, "port line is full, add device
> failed\n");
> > +   return ret;
> > +   }
> 
> Does this really remove the alias dependancy?
> 
> Please use an idr or ida for this instead of a bitmap.
> 

Hi Greg,

Thanks for your review.

Is there any advantage for use an idr or ida instead of bitmap?
I will hope to get your guidance.

Thanks.

RE: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string

[Yao Yuan]

On Thu, Dec 14, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 8:47 PM, Yao Yuan <yao.y...@nxp.com> wrote:
> > On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> >> On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote:
> >> > From: Yuan Yao <yao.y...@nxp.com>
> >>
> >> Same problem in this subject too.
> >>
> >> >
> >> > new compatible string: "fsl,ls1012a-qspi".
> >> >
> >> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> >> > ---
> >> >  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
> >> >  1 file changed, 1 insertion(+)
> >>
> >> Acked-by: Rob Herring <r...@kernel.org>
> >
> > Thanks for your review.
> > And do you have any suggestion for this subject?
> 
> The problem is you have a space in the compatible string: "fsl, ls1012a-qspi"
> rather than "fsl,ls1012a-qspi"
> 
> Also, I prefer "dt/bindings: " as the beginning of binding patch subjects.
> 

Ok, Get it.

Thanks for your comments.
I will send v2 soon.

RE: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string

[Yao Yuan]

On Thu, Dec 14, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 8:47 PM, Yao Yuan  wrote:
> > On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> >> On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote:
> >> > From: Yuan Yao 
> >>
> >> Same problem in this subject too.
> >>
> >> >
> >> > new compatible string: "fsl,ls1012a-qspi".
> >> >
> >> > Signed-off-by: Yuan Yao 
> >> > ---
> >> >  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
> >> >  1 file changed, 1 insertion(+)
> >>
> >> Acked-by: Rob Herring 
> >
> > Thanks for your review.
> > And do you have any suggestion for this subject?
> 
> The problem is you have a space in the compatible string: "fsl, ls1012a-qspi"
> rather than "fsl,ls1012a-qspi"
> 
> Also, I prefer "dt/bindings: " as the beginning of binding patch subjects.
> 

Ok, Get it.

Thanks for your comments.
I will send v2 soon.

RE: [PATCH 3/5] Documentation: dt: mtd: add chip support for "jedec, spi-nor"

[Yao Yuan]

On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> On Thu, Dec 08, 2016 at 05:23:02PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> 
> The compatible string is wrong in the subject.
> 
> >
> > "sst25wf040b" and "en25s64" are also chip compatible with SPI NOR flash.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> Otherwise,
> 
> Acked-by: Rob Herring 

Thanks for your review.
I will update the subject and send v2 soon.
 

RE: [PATCH 3/5] Documentation: dt: mtd: add chip support for "jedec, spi-nor"

[Yao Yuan]

On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> On Thu, Dec 08, 2016 at 05:23:02PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> 
> The compatible string is wrong in the subject.
> 
> >
> > "sst25wf040b" and "en25s64" are also chip compatible with SPI NOR flash.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> Otherwise,
> 
> Acked-by: Rob Herring 

Thanks for your review.
I will update the subject and send v2 soon.
 

RE: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string

[Yao Yuan]

On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> 
> Same problem in this subject too.
> 
> >
> > new compatible string: "fsl,ls1012a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Rob Herring 

Thanks for your review.
And do you have any suggestion for this subject?

I will update the subject and send v2 soon.

RE: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string

[Yao Yuan]

On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
> On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> 
> Same problem in this subject too.
> 
> >
> > new compatible string: "fsl,ls1012a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Rob Herring 

Thanks for your review.
And do you have any suggestion for this subject?

I will update the subject and send v2 soon.

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 18, 2016 at 12:31 PM, Han Xu wrote:
> On Thu, Nov 17, 2016 at 3:14 AM, Yao Yuan <yao.y...@nxp.com> wrote:
> > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin (Nokia -
> PL/Wroclaw) wrote:
> >> > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> >> > > > <b56...@freescale.com>
> >> > > > wrote:
> >> > > > > From: Yunhui Cui <yunhui@nxp.com>
> >> > > > >
> >> > > > > With the physical sectors combination, S25FS-S family flash
> >> > > > > requires some special operations for read/write functions.
> >> > > > >
> >> > > > > Signed-off-by: Yunhui Cui <yunhui@nxp.com>
> >> > > > > ---
> >> > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> >> > > > > +++
> >> > > > >  1 file changed, 56 insertions(+)
> >> > > > >
> >> > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> >> > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> >> > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> >> > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> >> > > > > @@ -39,6 +39,10 @@
> >> > > > >
> >> > > > >  #define SPI_NOR_MAX_ID_LEN 6
> >> > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> >> > > > > +/* Added for S25FS-S family flash */
> >> > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> >> > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> >> > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> >> > > > >
> >> > > > >  struct flash_info {
> >> > > > > char*name;
> >> > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> >> > > > >
> >> > > > >  #define JEDEC_MFR(info)((info)->id[0])
> >> > > > > +#define EXT_JEDEC(info)((info)->id[5])
> >> > > > >
> >> > > > >  static const struct flash_info *spi_nor_match_id(const char
> >> > > > > *name);
> >> > > > >
> >> > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = 
> >> > > > > {
> >> > > > >  */
> >> > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,
> >> > > > > 64,
> >> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >> > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024,
> >> > > > > 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >> > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> >> > > > > + 512, 0)},
> >> > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) 
> >> > > > > },
> >> > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024,
> >> > > > > 512,
> >> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >> > > > > { "s25fl512s",  INFO(0x010220, 0x4d00, 256 * 1024,
> >> > > > > 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> >> > +1042,50
> >> > > > @@ static const struct flash_info *spi_nor_read_id(struct
> >> > > > spi_nor
> >> > > > *nor)
> >> > > > > return ERR_PTR(-ENODEV);  }
> >> > > > >
> >> > > > > +/*
> >> > > > > + * The S25FS-S family physical sectors may be configured as
> >> > > > > +a
> >> > > > > + * hybrid combination of eight 4-kB parameter sectors
> >> > > > > + * at the top or bottom of the address space with all
> >> > > > > + * but one of the remaining sectors being uniform size.
> >> > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> >> > > > > + * be used to erase the 4-kB parameter sectors individually.
> >> > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> >> > > > > + * must be used to erase any of the re

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 18, 2016 at 12:31 PM, Han Xu wrote:
> On Thu, Nov 17, 2016 at 3:14 AM, Yao Yuan  wrote:
> > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin (Nokia -
> PL/Wroclaw) wrote:
> >> > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> >> > > > 
> >> > > > wrote:
> >> > > > > From: Yunhui Cui 
> >> > > > >
> >> > > > > With the physical sectors combination, S25FS-S family flash
> >> > > > > requires some special operations for read/write functions.
> >> > > > >
> >> > > > > Signed-off-by: Yunhui Cui 
> >> > > > > ---
> >> > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> >> > > > > +++
> >> > > > >  1 file changed, 56 insertions(+)
> >> > > > >
> >> > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> >> > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> >> > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> >> > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> >> > > > > @@ -39,6 +39,10 @@
> >> > > > >
> >> > > > >  #define SPI_NOR_MAX_ID_LEN 6
> >> > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> >> > > > > +/* Added for S25FS-S family flash */
> >> > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> >> > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> >> > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> >> > > > >
> >> > > > >  struct flash_info {
> >> > > > > char*name;
> >> > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> >> > > > >
> >> > > > >  #define JEDEC_MFR(info)((info)->id[0])
> >> > > > > +#define EXT_JEDEC(info)((info)->id[5])
> >> > > > >
> >> > > > >  static const struct flash_info *spi_nor_match_id(const char
> >> > > > > *name);
> >> > > > >
> >> > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = 
> >> > > > > {
> >> > > > >  */
> >> > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,
> >> > > > > 64,
> >> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >> > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024,
> >> > > > > 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >> > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> >> > > > > + 512, 0)},
> >> > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) 
> >> > > > > },
> >> > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024,
> >> > > > > 512,
> >> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> >> > > > > { "s25fl512s",  INFO(0x010220, 0x4d00, 256 * 1024,
> >> > > > > 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> >> > +1042,50
> >> > > > @@ static const struct flash_info *spi_nor_read_id(struct
> >> > > > spi_nor
> >> > > > *nor)
> >> > > > > return ERR_PTR(-ENODEV);  }
> >> > > > >
> >> > > > > +/*
> >> > > > > + * The S25FS-S family physical sectors may be configured as
> >> > > > > +a
> >> > > > > + * hybrid combination of eight 4-kB parameter sectors
> >> > > > > + * at the top or bottom of the address space with all
> >> > > > > + * but one of the remaining sectors being uniform size.
> >> > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> >> > > > > + * be used to erase the 4-kB parameter sectors individually.
> >> > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> >> > > > > + * must be used to erase any of the remaining
> >> > > > > + * sectors, including the portion of highest or lowest
> >> > > > > +address

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 21, 2016 at 03:15 PM +0800, Krzeminski, Marcin (Nokia - PL/Wroclaw) 
wrote:
> > -Original Message-
> > From: Yao Yuan [mailto:yao.y...@nxp.com]
> > Sent: Monday, November 21, 2016 7:28 AM
> > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > <marcin.krzemin...@nokia.com>; Han Xu <xhnj...@gmail.com>
> > Cc: David Woodhouse <dw...@infradead.org>; linux-
> > ker...@vger.kernel.org; linux-...@lists.infradead.org;
> > han...@freescale.com; Brian Norris <computersforpe...@gmail.com>;
> > jagannadh.t...@gmail.com; linux-arm-ker...@lists.infradead.org;
> > Cyrille Pitchen <cyrille.pitc...@atmel.com>
> > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > family flash
> >
> > On Thu, Nov 18, 2016 at 07:00 PM +, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > -Original Message-
> > > > From: Yao Yuan [mailto:yao.y...@nxp.com]
> > > > Sent: Friday, November 18, 2016 5:20 AM
> > > > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > > > <marcin.krzemin...@nokia.com>; Han Xu <xhnj...@gmail.com>
> > > > Cc: David Woodhouse <dw...@infradead.org>; linux-
> > > > ker...@vger.kernel.org; linux-...@lists.infradead.org;
> > > > han...@freescale.com; Brian Norris <computersforpe...@gmail.com>;
> > > > jagannadh.t...@gmail.com; linux-arm-ker...@lists.infradead.org
> > > > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > > > family flash
> > > >
> > > > On Thu, Nov 17, 2016 at 10:14:55AM +, Krzeminski, Marcin
> > > > (Nokia
> > > > -
> > > > PL/Wroclaw) wrote:
> > > > > > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin
> > > > > > (Nokia
> > > > > > -
> > > > > > PL/Wroclaw) wrote:
> > > > > > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > > > > > <b56...@freescale.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > From: Yunhui Cui <yunhui@nxp.com>
> > > > > > > > > > >
> > > > > > > > > > > With the physical sectors combination, S25FS-S
> > > > > > > > > > > family flash requires some special operations for
> > > > > > > > > > > read/write
> > functions.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Yunhui Cui <yunhui@nxp.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > > > > > +++
> > > > > > > > > > >  1 file changed, 56 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index
> > > > > > > > > > > d0fc165..495d0bb
> > > > > > > > > > > 100644
> > > > > > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > @@ -39,6 +39,10 @@
> > > > > > > > > > >
> > > > > > > > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > > > > > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > > > > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > > > > > > > >
> > > > > > > > > > >  struct flash_info {
> > > > > > > > > > > char*name;
> > > > > > > > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > > > > > > > >
> > > > >

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 21, 2016 at 03:15 PM +0800, Krzeminski, Marcin (Nokia - PL/Wroclaw) 
wrote:
> > -Original Message-
> > From: Yao Yuan [mailto:yao.y...@nxp.com]
> > Sent: Monday, November 21, 2016 7:28 AM
> > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > ; Han Xu 
> > Cc: David Woodhouse ; linux-
> > ker...@vger.kernel.org; linux-...@lists.infradead.org;
> > han...@freescale.com; Brian Norris ;
> > jagannadh.t...@gmail.com; linux-arm-ker...@lists.infradead.org;
> > Cyrille Pitchen 
> > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > family flash
> >
> > On Thu, Nov 18, 2016 at 07:00 PM +, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > -Original Message-
> > > > From: Yao Yuan [mailto:yao.y...@nxp.com]
> > > > Sent: Friday, November 18, 2016 5:20 AM
> > > > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > > > ; Han Xu 
> > > > Cc: David Woodhouse ; linux-
> > > > ker...@vger.kernel.org; linux-...@lists.infradead.org;
> > > > han...@freescale.com; Brian Norris ;
> > > > jagannadh.t...@gmail.com; linux-arm-ker...@lists.infradead.org
> > > > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > > > family flash
> > > >
> > > > On Thu, Nov 17, 2016 at 10:14:55AM +, Krzeminski, Marcin
> > > > (Nokia
> > > > -
> > > > PL/Wroclaw) wrote:
> > > > > > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin
> > > > > > (Nokia
> > > > > > -
> > > > > > PL/Wroclaw) wrote:
> > > > > > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > From: Yunhui Cui 
> > > > > > > > > > >
> > > > > > > > > > > With the physical sectors combination, S25FS-S
> > > > > > > > > > > family flash requires some special operations for
> > > > > > > > > > > read/write
> > functions.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Yunhui Cui 
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > > > > > +++
> > > > > > > > > > >  1 file changed, 56 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index
> > > > > > > > > > > d0fc165..495d0bb
> > > > > > > > > > > 100644
> > > > > > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > @@ -39,6 +39,10 @@
> > > > > > > > > > >
> > > > > > > > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > > > > > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > > > > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > > > > > > > >
> > > > > > > > > > >  struct flash_info {
> > > > > > > > > > > char*name;
> > > > > > > > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > > > > > > > >
> > > > > > > > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > > > > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > > > > > > > >
> > > > > > > > > > >  static const struct flash_info
> > > > > > > > > > > *spi_nor_match_id(const char *name);
> > &

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 18, 2016 at 07:00 PM +, Krzeminski, Marcin (Nokia - PL/Wroclaw) 
wrote:
> > -Original Message-
> > From: Yao Yuan [mailto:yao.y...@nxp.com]
> > Sent: Friday, November 18, 2016 5:20 AM
> > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > <marcin.krzemin...@nokia.com>; Han Xu <xhnj...@gmail.com>
> > Cc: David Woodhouse <dw...@infradead.org>; linux-
> > ker...@vger.kernel.org; linux-...@lists.infradead.org;
> > han...@freescale.com; Brian Norris <computersforpe...@gmail.com>;
> > jagannadh.t...@gmail.com; linux-arm-ker...@lists.infradead.org
> > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > family flash
> >
> > On Thu, Nov 17, 2016 at 10:14:55AM +, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin
> > > > (Nokia
> > > > -
> > > > PL/Wroclaw) wrote:
> > > > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > > > <b56...@freescale.com>
> > > > > > > > wrote:
> > > > > > > > > From: Yunhui Cui <yunhui@nxp.com>
> > > > > > > > >
> > > > > > > > > With the physical sectors combination, S25FS-S family
> > > > > > > > > flash requires some special operations for read/write 
> > > > > > > > > functions.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yunhui Cui <yunhui@nxp.com>
> > > > > > > > > ---
> > > > > > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > > > +++
> > > > > > > > >  1 file changed, 56 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb
> > > > > > > > > 100644
> > > > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > @@ -39,6 +39,10 @@
> > > > > > > > >
> > > > > > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > > > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > > > > > >
> > > > > > > > >  struct flash_info {
> > > > > > > > > char*name;
> > > > > > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > > > > > >
> > > > > > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > > > > > >
> > > > > > > > >  static const struct flash_info *spi_nor_match_id(const
> > > > > > > > > char *name);
> > > > > > > > >
> > > > > > > > > @@ -899,6 +904,7 @@ static const struct flash_info
> > spi_nor_ids[] = {
> > > > > > > > >  */
> > > > > > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 *
> > > > > > > > > 1024, 64,
> > > > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 *
> > > > > > > > > 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 *
> > > > > > > > > + 1024, 512, 0)},
> > > > > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 
> > > > > > > > > 128, 0) },
> > > > > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 *
> > > > &

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 18, 2016 at 07:00 PM +, Krzeminski, Marcin (Nokia - PL/Wroclaw) 
wrote:
> > -Original Message-
> > From: Yao Yuan [mailto:yao.y...@nxp.com]
> > Sent: Friday, November 18, 2016 5:20 AM
> > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > ; Han Xu 
> > Cc: David Woodhouse ; linux-
> > ker...@vger.kernel.org; linux-...@lists.infradead.org;
> > han...@freescale.com; Brian Norris ;
> > jagannadh.t...@gmail.com; linux-arm-ker...@lists.infradead.org
> > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > family flash
> >
> > On Thu, Nov 17, 2016 at 10:14:55AM +, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin
> > > > (Nokia
> > > > -
> > > > PL/Wroclaw) wrote:
> > > > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > From: Yunhui Cui 
> > > > > > > > >
> > > > > > > > > With the physical sectors combination, S25FS-S family
> > > > > > > > > flash requires some special operations for read/write 
> > > > > > > > > functions.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yunhui Cui 
> > > > > > > > > ---
> > > > > > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > > > +++
> > > > > > > > >  1 file changed, 56 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb
> > > > > > > > > 100644
> > > > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > @@ -39,6 +39,10 @@
> > > > > > > > >
> > > > > > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > > > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > > > > > >
> > > > > > > > >  struct flash_info {
> > > > > > > > > char*name;
> > > > > > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > > > > > >
> > > > > > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > > > > > >
> > > > > > > > >  static const struct flash_info *spi_nor_match_id(const
> > > > > > > > > char *name);
> > > > > > > > >
> > > > > > > > > @@ -899,6 +904,7 @@ static const struct flash_info
> > spi_nor_ids[] = {
> > > > > > > > >  */
> > > > > > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 *
> > > > > > > > > 1024, 64,
> > > > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 *
> > > > > > > > > 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 *
> > > > > > > > > + 1024, 512, 0)},
> > > > > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 
> > > > > > > > > 128, 0) },
> > > > > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 *
> > > > > > > > > 1024, 512,
> > > > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > >  

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 17, 2016 at 10:14:55AM +, Krzeminski, Marcin (Nokia - 
PL/Wroclaw) wrote:
> > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > 
> > > > > > wrote:
> > > > > > > From: Yunhui Cui 
> > > > > > >
> > > > > > > With the physical sectors combination, S25FS-S family flash
> > > > > > > requires some special operations for read/write functions.
> > > > > > >
> > > > > > > Signed-off-by: Yunhui Cui 
> > > > > > > ---
> > > > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > +++
> > > > > > >  1 file changed, 56 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb
> > > > > > > 100644
> > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > @@ -39,6 +39,10 @@
> > > > > > >
> > > > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > > > >
> > > > > > >  struct flash_info {
> > > > > > > char*name;
> > > > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > > > >
> > > > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > > > >
> > > > > > >  static const struct flash_info *spi_nor_match_id(const char
> > > > > > > *name);
> > > > > > >
> > > > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] 
> > > > > > > = {
> > > > > > >  */
> > > > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,
> > > > > > > 64,
> > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024,
> > > > > > > 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > > > + 512, 0)},
> > > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 
> > > > > > > 0) },
> > > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024,
> > > > > > > 512,
> > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > { "s25fl512s",  INFO(0x010220, 0x4d00, 256 * 1024,
> > > > > > > 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > > > +1042,50
> > > > > > @@ static const struct flash_info *spi_nor_read_id(struct
> > > > > > spi_nor
> > > > > > *nor)
> > > > > > > return ERR_PTR(-ENODEV);  }
> > > > > > >
> > > > > > > +/*
> > > > > > > + * The S25FS-S family physical sectors may be configured as
> > > > > > > +a
> > > > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > > > + * at the top or bottom of the address space with all
> > > > > > > + * but one of the remaining sectors being uniform size.
> > > > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > > > + * must be used to erase any of the remaining
> > > > > > > + * sectors, including the portion of highest or lowest
> > > > > > > +address
> > > > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > > > + * The uniform sector erase command has no effect on
> > > > > > > +parameter
> > > > > > sectors.
> > > > > > > + */
> > > > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) 
> > > > > > > {
> > > > > > > +   u32 cr3v_addr  = SPINOR_CONFIG_REG3_OFFSET;
> > > > > > > +   u8 cr3v = 0x0;
> > > > > > > +   int ret = 0x0;
> > > > > > > +
> > > > > > > +   nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > > > +   nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > > > +   nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > > > +
> > > > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> > , 1);
> > > > > > > +   if (ret)
> > > > > > > +   return ret;
> > > > > > > +   if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > > > +   return 0;
> > > > > > > +   ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > > > +   if (ret)
> > > > > > > +   return ret;
> > > > > > > +   cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > > > +   nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > > > +   nor->write(nor, cr3v_addr, 1, );
> > > > > > > +
> > > > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> > , 1);
> > > > > > > +   if (ret)
> > > > > > > +   return ret;
> > > > > > > +   if (!(cr3v 

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 17, 2016 at 10:14:55AM +, Krzeminski, Marcin (Nokia - 
PL/Wroclaw) wrote:
> > On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > 
> > > > > > wrote:
> > > > > > > From: Yunhui Cui 
> > > > > > >
> > > > > > > With the physical sectors combination, S25FS-S family flash
> > > > > > > requires some special operations for read/write functions.
> > > > > > >
> > > > > > > Signed-off-by: Yunhui Cui 
> > > > > > > ---
> > > > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > +++
> > > > > > >  1 file changed, 56 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb
> > > > > > > 100644
> > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > @@ -39,6 +39,10 @@
> > > > > > >
> > > > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > > > >
> > > > > > >  struct flash_info {
> > > > > > > char*name;
> > > > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > > > >
> > > > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > > > >
> > > > > > >  static const struct flash_info *spi_nor_match_id(const char
> > > > > > > *name);
> > > > > > >
> > > > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] 
> > > > > > > = {
> > > > > > >  */
> > > > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,
> > > > > > > 64,
> > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024,
> > > > > > > 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > > > + 512, 0)},
> > > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 
> > > > > > > 0) },
> > > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024,
> > > > > > > 512,
> > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > { "s25fl512s",  INFO(0x010220, 0x4d00, 256 * 1024,
> > > > > > > 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > > > +1042,50
> > > > > > @@ static const struct flash_info *spi_nor_read_id(struct
> > > > > > spi_nor
> > > > > > *nor)
> > > > > > > return ERR_PTR(-ENODEV);  }
> > > > > > >
> > > > > > > +/*
> > > > > > > + * The S25FS-S family physical sectors may be configured as
> > > > > > > +a
> > > > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > > > + * at the top or bottom of the address space with all
> > > > > > > + * but one of the remaining sectors being uniform size.
> > > > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > > > + * must be used to erase any of the remaining
> > > > > > > + * sectors, including the portion of highest or lowest
> > > > > > > +address
> > > > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > > > + * The uniform sector erase command has no effect on
> > > > > > > +parameter
> > > > > > sectors.
> > > > > > > + */
> > > > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) 
> > > > > > > {
> > > > > > > +   u32 cr3v_addr  = SPINOR_CONFIG_REG3_OFFSET;
> > > > > > > +   u8 cr3v = 0x0;
> > > > > > > +   int ret = 0x0;
> > > > > > > +
> > > > > > > +   nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > > > +   nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > > > +   nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > > > +
> > > > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> > , 1);
> > > > > > > +   if (ret)
> > > > > > > +   return ret;
> > > > > > > +   if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > > > +   return 0;
> > > > > > > +   ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > > > +   if (ret)
> > > > > > > +   return ret;
> > > > > > > +   cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > > > +   nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > > > +   nor->write(nor, cr3v_addr, 1, );
> > > > > > > +
> > > > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR,
> > , 1);
> > > > > > > +   if (ret)
> > > > > > > +   return ret;
> > > > > > > +   if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > > > +   

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin (Nokia - 
PL/Wroclaw) wrote:
> > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui 
> > > > wrote:
> > > > > From: Yunhui Cui 
> > > > >
> > > > > With the physical sectors combination, S25FS-S family flash
> > > > > requires some special operations for read/write functions.
> > > > >
> > > > > Signed-off-by: Yunhui Cui 
> > > > > ---
> > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > +++
> > > > >  1 file changed, 56 insertions(+)
> > > > >
> > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > @@ -39,6 +39,10 @@
> > > > >
> > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > +/* Added for S25FS-S family flash */
> > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > >
> > > > >  struct flash_info {
> > > > > char*name;
> > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > >
> > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > >
> > > > >  static const struct flash_info *spi_nor_match_id(const char
> > > > > *name);
> > > > >
> > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > > >  */
> > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,  64,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024, 128,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > + 512, 0)},
> > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024, 512,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > { "s25fl512s",  INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > +1042,50
> > > > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor
> > > > *nor)
> > > > > return ERR_PTR(-ENODEV);  }
> > > > >
> > > > > +/*
> > > > > + * The S25FS-S family physical sectors may be configured as a
> > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > + * at the top or bottom of the address space with all
> > > > > + * but one of the remaining sectors being uniform size.
> > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > + * must be used to erase any of the remaining
> > > > > + * sectors, including the portion of highest or lowest address
> > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > + * The uniform sector erase command has no effect on parameter
> > > > sectors.
> > > > > + */
> > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > > > +   u32 cr3v_addr  = SPINOR_CONFIG_REG3_OFFSET;
> > > > > +   u8 cr3v = 0x0;
> > > > > +   int ret = 0x0;
> > > > > +
> > > > > +   nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > +   nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > +   nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > +
> > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, , 1);
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +   if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > +   return 0;
> > > > > +   ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +   cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > +   nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > +   nor->write(nor, cr3v_addr, 1, );
> > > > > +
> > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, , 1);
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +   if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > +   return -EPERM;
> > > > > +
> > > > > +   return 0;
> > > > > +}
> > > > > +
> > > > >  static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t 
> > > > > len,
> > > > > size_t *retlen, u_char *buf)  { @@
> > > > > -1361,6
> > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > > > > +*name,
> > > > enum read_mode mode)
> > > > > spi_nor_wait_till_ready(nor);
> > > > > }
> > > > >
> > > > > +   if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > > > +   ret = 

RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash

[Yao Yuan]

On Thu, Nov 17, 2016 at 06:50:55AM +, Krzeminski, Marcin (Nokia - 
PL/Wroclaw) wrote:
> > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui 
> > > > wrote:
> > > > > From: Yunhui Cui 
> > > > >
> > > > > With the physical sectors combination, S25FS-S family flash
> > > > > requires some special operations for read/write functions.
> > > > >
> > > > > Signed-off-by: Yunhui Cui 
> > > > > ---
> > > > >  drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > +++
> > > > >  1 file changed, 56 insertions(+)
> > > > >
> > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > @@ -39,6 +39,10 @@
> > > > >
> > > > >  #define SPI_NOR_MAX_ID_LEN 6
> > > > >  #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > +/* Added for S25FS-S family flash */
> > > > > +#define SPINOR_CONFIG_REG3_OFFSET  0x84
> > > > > +#define CR3V_4KB_ERASE_UNABLE  0x8 #define
> > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC  0x81
> > > > >
> > > > >  struct flash_info {
> > > > > char*name;
> > > > > @@ -78,6 +82,7 @@ struct flash_info {  };
> > > > >
> > > > >  #define JEDEC_MFR(info)((info)->id[0])
> > > > > +#define EXT_JEDEC(info)((info)->id[5])
> > > > >
> > > > >  static const struct flash_info *spi_nor_match_id(const char
> > > > > *name);
> > > > >
> > > > > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > > > >  */
> > > > > { "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,  64,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > { "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024, 128,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > +   { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024,
> > > > > + 512, 0)},
> > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > > > > { "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024, 512,
> > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > { "s25fl512s",  INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6
> > +1042,50
> > > > @@ static const struct flash_info *spi_nor_read_id(struct spi_nor
> > > > *nor)
> > > > > return ERR_PTR(-ENODEV);  }
> > > > >
> > > > > +/*
> > > > > + * The S25FS-S family physical sectors may be configured as a
> > > > > + * hybrid combination of eight 4-kB parameter sectors
> > > > > + * at the top or bottom of the address space with all
> > > > > + * but one of the remaining sectors being uniform size.
> > > > > + * The Parameter Sector Erase commands (20h or 21h) must
> > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > > > > + * must be used to erase any of the remaining
> > > > > + * sectors, including the portion of highest or lowest address
> > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > + * The uniform sector erase command has no effect on parameter
> > > > sectors.
> > > > > + */
> > > > > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > > > > +   u32 cr3v_addr  = SPINOR_CONFIG_REG3_OFFSET;
> > > > > +   u8 cr3v = 0x0;
> > > > > +   int ret = 0x0;
> > > > > +
> > > > > +   nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > +   nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > +   nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > +
> > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, , 1);
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +   if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > +   return 0;
> > > > > +   ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +   cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > +   nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > > > > +   nor->write(nor, cr3v_addr, 1, );
> > > > > +
> > > > > +   ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, , 1);
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +   if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > +   return -EPERM;
> > > > > +
> > > > > +   return 0;
> > > > > +}
> > > > > +
> > > > >  static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t 
> > > > > len,
> > > > > size_t *retlen, u_char *buf)  { @@
> > > > > -1361,6
> > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > > > > +*name,
> > > > enum read_mode mode)
> > > > > spi_nor_wait_till_ready(nor);
> > > > > }
> > > > >
> > > > > +   if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > > > > +   ret = spansion_s25fs_disable_4kb_erase(nor);
> > > > > +   if 

RE: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

[Yao Yuan]

On Mon 29 August 2016 03:34:47, : Alexander Stein  wrote:
> On Thursday 18 August 2016 14:38:47, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Add the QDMA node for ls1043a platform to support QDMA driver.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index
> > e8e4c3e..e463074
> > 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -467,6 +467,16 @@
> >  < 4 0>;
> > };
> >
> > +   qdma: qdma@839 {
> > +   compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
> 
> This doesn't match the order of your binding in Patch 2/5:
> > +- compatible :
> > +   - "fsl,ls1021a-qdma",
> > +   Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
> 
> It should be the other way around.

Thanks for your review.
It should be compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
 I will update it in the next version.
Thanks.

RE: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

[Yao Yuan]

On Mon 29 August 2016 03:34:47, : Alexander Stein  wrote:
> On Thursday 18 August 2016 14:38:47, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Add the QDMA node for ls1043a platform to support QDMA driver.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index
> > e8e4c3e..e463074
> > 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -467,6 +467,16 @@
> >  < 4 0>;
> > };
> >
> > +   qdma: qdma@839 {
> > +   compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
> 
> This doesn't match the order of your binding in Patch 2/5:
> > +- compatible :
> > +   - "fsl,ls1021a-qdma",
> > +   Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
> 
> It should be the other way around.

Thanks for your review.
It should be compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
 I will update it in the next version.
Thanks.

RE: [PATCH v1 1/5] dma: Add QorIQ qDMA engine driver support

[Yao Yuan]

On Thu, Aug 18, 2016 at 05:16 PM +0800, Russell King wrote:
> On Thu, Aug 18, 2016 at 02:38:44PM +0800, Yuan Yao wrote:
> > +   spin_lock(_comp->qchan->vchan.lock);
> > +   if (status == DMA_COMPLETE)
> > +   vchan_cookie_complete(_comp->vdesc);
> > +   fsl_comp->qchan->status = status;
> 
> This is buggy - if the DMA has finished processing it, even if it finished in 
> error, it
> must _complete_ the transaction.  Completion is not the same as being
> successful - it means that the DMA is no longer processing the cookie.
> 
> The issue here is that when the _following_ transaction completes 
> successfully,
> _this_ transaction will effectively be marked as complete due to the way the
> cookie system works.
> 
> So... to get this straight - "completion" means "I have finished processing 
> this
> transaction".  It does not mean "I successfully processed this transaction
> without any errors."
> 

Thanks for your review.
So you mean that I should call vchan_cookie_complete no matter whether the 
error issue in QDMA?
I have some random DMA error test case, it seems work will.

RE: [PATCH v1 1/5] dma: Add QorIQ qDMA engine driver support

[Yao Yuan]

On Thu, Aug 18, 2016 at 05:16 PM +0800, Russell King wrote:
> On Thu, Aug 18, 2016 at 02:38:44PM +0800, Yuan Yao wrote:
> > +   spin_lock(_comp->qchan->vchan.lock);
> > +   if (status == DMA_COMPLETE)
> > +   vchan_cookie_complete(_comp->vdesc);
> > +   fsl_comp->qchan->status = status;
> 
> This is buggy - if the DMA has finished processing it, even if it finished in 
> error, it
> must _complete_ the transaction.  Completion is not the same as being
> successful - it means that the DMA is no longer processing the cookie.
> 
> The issue here is that when the _following_ transaction completes 
> successfully,
> _this_ transaction will effectively be marked as complete due to the way the
> cookie system works.
> 
> So... to get this straight - "completion" means "I have finished processing 
> this
> transaction".  It does not mean "I successfully processed this transaction
> without any errors."
> 

Thanks for your review.
So you mean that I should call vchan_cookie_complete no matter whether the 
error issue in QDMA?
I have some random DMA error test case, it seems work will.

RE: [PATCH v6 2/2] dts/ls2080a: update the DTS for QSPI and DSPI support

[Yao Yuan]

Thanks for your review and work.

Best Regards,
Yuan Yao


> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Wednesday, April 13, 2016 10:30 AM
> To: Yuan Yao <yao.y...@freescale.com>
> Cc: robh...@kernel.org; mark.rutl...@arm.com; pawel.m...@arm.com; Han
> Xu <han...@nxp.com>; Yang-Leo Li <leoyang...@nxp.com>;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Yao Yuan <yao.y...@nxp.com>
> Subject: Re: [PATCH v6 2/2] dts/ls2080a: update the DTS for QSPI and DSPI
> support
> 
> On Wed, Mar 09, 2016 at 06:22:06PM +0800, Yuan Yao wrote:
> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> > Acked-by: Han xu <han...@nxp.com>
> 
> Changed subject prefix to 'arm64: dts: ls2080a: ', and then applied the patch.
> 
> Shawn
> 
> > ---
> > Changed in v6:
> > No changes.
> >
> > Changed in v5:
> > Resend base on arm-soc.
> >
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > No changes.
> >
> > Changed in v2:
> > Update my email to <yao.y...@nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 -
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi| 4 ++--
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > index 4cb996d..e8801fa 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > @@ -178,7 +178,14 @@
> >
> >   {
> > status = "okay";
> > -   qflash0: s25fl008k {
> > +   flash0: s25fl256s1@0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "st,m25p80";
> > +   spi-max-frequency = <2000>;
> > +   reg = <0>;
> > +   };
> > +   flash2: s25fl256s1@2 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > compatible = "st,m25p80";
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > index 2b23d03..65e612a 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > @@ -318,7 +318,7 @@
> >
> > dspi: dspi@210 {
> > status = "disabled";
> > -   compatible = "fsl,vf610-dspi";
> > +   compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0x0 0x210 0x0 0x1>; @@ -444,7 +444,7
> @@
> >
> > qspi: quadspi@20c {
> > status = "disabled";
> > -   compatible = "fsl,vf610-qspi";
> > +   compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0x0 0x20c 0x0 0x1>,
> > --
> > 2.1.0.27.g96db324
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >

RE: [PATCH v6 2/2] dts/ls2080a: update the DTS for QSPI and DSPI support

[Yao Yuan]

Thanks for your review and work.

Best Regards,
Yuan Yao


> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Wednesday, April 13, 2016 10:30 AM
> To: Yuan Yao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; pawel.m...@arm.com; Han
> Xu ; Yang-Leo Li ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Yao Yuan 
> Subject: Re: [PATCH v6 2/2] dts/ls2080a: update the DTS for QSPI and DSPI
> support
> 
> On Wed, Mar 09, 2016 at 06:22:06PM +0800, Yuan Yao wrote:
> > Signed-off-by: Yuan Yao 
> > Acked-by: Han xu 
> 
> Changed subject prefix to 'arm64: dts: ls2080a: ', and then applied the patch.
> 
> Shawn
> 
> > ---
> > Changed in v6:
> > No changes.
> >
> > Changed in v5:
> > Resend base on arm-soc.
> >
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > No changes.
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 -
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi| 4 ++--
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > index 4cb996d..e8801fa 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> > @@ -178,7 +178,14 @@
> >
> >   {
> > status = "okay";
> > -   qflash0: s25fl008k {
> > +   flash0: s25fl256s1@0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "st,m25p80";
> > +   spi-max-frequency = <2000>;
> > +   reg = <0>;
> > +   };
> > +   flash2: s25fl256s1@2 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > compatible = "st,m25p80";
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > index 2b23d03..65e612a 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > @@ -318,7 +318,7 @@
> >
> > dspi: dspi@210 {
> > status = "disabled";
> > -   compatible = "fsl,vf610-dspi";
> > +   compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0x0 0x210 0x0 0x1>; @@ -444,7 +444,7
> @@
> >
> > qspi: quadspi@20c {
> > status = "disabled";
> > -   compatible = "fsl,vf610-qspi";
> > +   compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0x0 0x20c 0x0 0x1>,
> > --
> > 2.1.0.27.g96db324
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >

RE: [PATCH 2/2] dts/ls1043a: add the DTS node for QSPI support

[Yao Yuan]

On Thu, Apr 12, 2016 at 10:50:01AM +0800, Shawn Guo wrote:
> On Thu, Mar 31, 2016 at 02:45:01PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> 
> Please style of 'arm64: dts: ls1043a: ' for subject prefix.
> 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 16 
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 14 ++
> >  2 files changed, 30 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > index 97e9906..c8303a3 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > @@ -100,6 +100,22 @@
> > };
> >  };
> >
> > + {
> 
> Please sort such labeled node alphabetically in label name.  That said, it 
> should
> go after 

Ok, Thanks.

> > +   num-cs = <2>;
> 
> I do not see this property in bindings doc.

We can find this property in ./Documentation/devicetree/bindings/spi/spi-bus.txt
 
> 
> > +   bus-num = <0>;
> > +   status = "okay";
> 
> Please let 'status' line be the last of property list.


Ok, Thanks.

> > +   fsl,ddr-sampling-point = <4>;
> 
> I do not see this one in bindings definition either.

It's used for DDR mode; The DDR mode will send to upstream late.
So I will remove this, once the DDR mode patch is merged, I will send patch to 
add the property.

> 
> > +
> > +   qflash0: s25fl128s@0 {
> > +   compatible = "spansion,m25p80";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   spi-max-frequency = <2000>;
> > +   ddr-quad-read;
> 
> Ditto

Ditto, Thanks.

> 
> > +   reg = <0>;
> > +   };
> > +};
> > +
> >   {
> > status = "okay";
> > pca9547@77 {
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > index be72bf5..49b1aeb 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -208,6 +208,20 @@
> > status = "disabled";
> > };
> >
> > +   qspi: quadspi@155 {
> 
> Please sort the node in .dtsi in order of unit-address.  That said, the 
> node
> should be added between ifc@153 and esdhc@156.

Thanks. I will update it and resend it soon.

> Shawn
> 
> > +   compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0x0 0x155 0x0 0x1>,
> > +   <0x0 0x4000 0x0 0x400>;
> > +   reg-names = "QuadSPI", "QuadSPI-memory";
> > +   interrupts = <0 99 0x4>;
> > +   clock-names = "qspi_en", "qspi";
> > +   clocks = < 4 0>, < 4 0>;
> > +   big-endian;
> > +   status = "disabled";
> > +   };
> > +
> > i2c0: i2c@218 {
> > compatible = "fsl,vf610-i2c";
> > #address-cells = <1>;
> > --
> > 2.1.0.27.g96db324
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >

RE: [PATCH 2/2] dts/ls1043a: add the DTS node for QSPI support

[Yao Yuan]

On Thu, Apr 12, 2016 at 10:50:01AM +0800, Shawn Guo wrote:
> On Thu, Mar 31, 2016 at 02:45:01PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> 
> Please style of 'arm64: dts: ls1043a: ' for subject prefix.
> 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 16 
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 14 ++
> >  2 files changed, 30 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > index 97e9906..c8303a3 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > @@ -100,6 +100,22 @@
> > };
> >  };
> >
> > + {
> 
> Please sort such labeled node alphabetically in label name.  That said, it 
> should
> go after 

Ok, Thanks.

> > +   num-cs = <2>;
> 
> I do not see this property in bindings doc.

We can find this property in ./Documentation/devicetree/bindings/spi/spi-bus.txt
 
> 
> > +   bus-num = <0>;
> > +   status = "okay";
> 
> Please let 'status' line be the last of property list.


Ok, Thanks.

> > +   fsl,ddr-sampling-point = <4>;
> 
> I do not see this one in bindings definition either.

It's used for DDR mode; The DDR mode will send to upstream late.
So I will remove this, once the DDR mode patch is merged, I will send patch to 
add the property.

> 
> > +
> > +   qflash0: s25fl128s@0 {
> > +   compatible = "spansion,m25p80";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   spi-max-frequency = <2000>;
> > +   ddr-quad-read;
> 
> Ditto

Ditto, Thanks.

> 
> > +   reg = <0>;
> > +   };
> > +};
> > +
> >   {
> > status = "okay";
> > pca9547@77 {
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > index be72bf5..49b1aeb 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -208,6 +208,20 @@
> > status = "disabled";
> > };
> >
> > +   qspi: quadspi@155 {
> 
> Please sort the node in .dtsi in order of unit-address.  That said, the 
> node
> should be added between ifc@153 and esdhc@156.

Thanks. I will update it and resend it soon.

> Shawn
> 
> > +   compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0x0 0x155 0x0 0x1>,
> > +   <0x0 0x4000 0x0 0x400>;
> > +   reg-names = "QuadSPI", "QuadSPI-memory";
> > +   interrupts = <0 99 0x4>;
> > +   clock-names = "qspi_en", "qspi";
> > +   clocks = < 4 0>, < 4 0>;
> > +   big-endian;
> > +   status = "disabled";
> > +   };
> > +
> > i2c0: i2c@218 {
> > compatible = "fsl,vf610-i2c";
> > #address-cells = <1>;
> > --
> > 2.1.0.27.g96db324
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >

RE: [PATCH v6 1/2] Documentation: fsl: dspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi Brian Norris,

Could you please help to review and merge this patch?

Thanks.

> On 03/09/2016 08:59 PM, Yao Yuan wrote:
> >
> > new compatible string: "fsl,ls2080a-dspi".
> >
> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> > Acked-by: Rob Herring <r...@kernel.org>
> > ---
> > Changed in v6:
> > No changes.
> >
> > Changed in v5:
> > Fix the subject and commit message.
> >
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to <yao.y...@nxp.com>
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..1ad0fe3 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,10 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi"
> > +   or
> > +   "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >  - reg : Offset and length of the register set for the device
> >  - interrupts : Should contain SPI controller interrupt
> >  - clocks: from common clock binding: handle to dspi clock.
> > --

RE: [PATCH v6 1/2] Documentation: fsl: dspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi Brian Norris,

Could you please help to review and merge this patch?

Thanks.

> On 03/09/2016 08:59 PM, Yao Yuan wrote:
> >
> > new compatible string: "fsl,ls2080a-dspi".
> >
> > Signed-off-by: Yuan Yao 
> > Acked-by: Rob Herring 
> > ---
> > Changed in v6:
> > No changes.
> >
> > Changed in v5:
> > Fix the subject and commit message.
> >
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..1ad0fe3 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,10 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi"
> > +   or
> > +   "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >  - reg : Offset and length of the register set for the device
> >  - interrupts : Should contain SPI controller interrupt
> >  - clocks: from common clock binding: handle to dspi clock.
> > --

RE: [PATCH v6 2/2] dts/ls2080a: update the DTS for QSPI and DSPI support

[Yao Yuan]

Hi All,

Could you please help to review and merge this patch?

Thanks.

Best Regards,
Yuan Yao


On 03/09/2016 08:59 PM, Yao Yuan wrote:
> 
> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> Acked-by: Han xu <han...@nxp.com>
> ---
> Changed in v6:
> No changes.
> 
> Changed in v5:
> Resend base on arm-soc.
> 
> Changed in v4:
> No changes.
> 
> Changed in v3:
> No changes.
> 
> Changed in v2:
> Update my email to <yao.y...@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 -
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi| 4 ++--
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> index 4cb996d..e8801fa 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> @@ -178,7 +178,14 @@
> 
>   {
>   status = "okay";
> - qflash0: s25fl008k {
> + flash0: s25fl256s1@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <2000>;
> + reg = <0>;
> + };
> + flash2: s25fl256s1@2 {
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "st,m25p80";
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 2b23d03..65e612a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -318,7 +318,7 @@
> 
>   dspi: dspi@210 {
>   status = "disabled";
> - compatible = "fsl,vf610-dspi";
> + compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x0 0x210 0x0 0x1>;
> @@ -444,7 +444,7 @@
> 
>   qspi: quadspi@20c {
>   status = "disabled";
> - compatible = "fsl,vf610-qspi";
> + compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x0 0x20c 0x0 0x1>,
> --
> 2.1.0.27.g96db324

RE: [PATCH v6 2/2] dts/ls2080a: update the DTS for QSPI and DSPI support

[Yao Yuan]

Hi All,

Could you please help to review and merge this patch?

Thanks.

Best Regards,
Yuan Yao


On 03/09/2016 08:59 PM, Yao Yuan wrote:
> 
> Signed-off-by: Yuan Yao 
> Acked-by: Han xu 
> ---
> Changed in v6:
> No changes.
> 
> Changed in v5:
> Resend base on arm-soc.
> 
> Changed in v4:
> No changes.
> 
> Changed in v3:
> No changes.
> 
> Changed in v2:
> Update my email to 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 -
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi| 4 ++--
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> index 4cb996d..e8801fa 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> @@ -178,7 +178,14 @@
> 
>   {
>   status = "okay";
> - qflash0: s25fl008k {
> + flash0: s25fl256s1@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <2000>;
> + reg = <0>;
> + };
> + flash2: s25fl256s1@2 {
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "st,m25p80";
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 2b23d03..65e612a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -318,7 +318,7 @@
> 
>   dspi: dspi@210 {
>   status = "disabled";
> - compatible = "fsl,vf610-dspi";
> + compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x0 0x210 0x0 0x1>;
> @@ -444,7 +444,7 @@
> 
>   qspi: quadspi@20c {
>   status = "disabled";
> - compatible = "fsl,vf610-qspi";
> + compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x0 0x20c 0x0 0x1>,
> --
> 2.1.0.27.g96db324

RE: [PATCH v6 1/2] Documentation: fsl: dspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi All,

Could you please help to review and merge this patch?

Thanks.

On 03/09/2016 08:59 PM, Yao Yuan wrote:
> 
> new compatible string: "fsl,ls2080a-dspi".
> 
> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> Acked-by: Rob Herring <r...@kernel.org>
> ---
> Changed in v6:
> No changes.
> 
> Changed in v5:
> Fix the subject and commit message.
> 
> Changed in v4:
> No changes.
> 
> Changed in v3:
> Add the modifier for new compatible string like:
> "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> 
> Changed in v2:
> Update my email to <yao.y...@nxp.com>
> ---
>  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> index fa77f87..1ad0fe3 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> @@ -1,7 +1,10 @@
>  ARM Freescale DSPI controller
> 
>  Required properties:
> -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi"
> +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> + "fsl,ls2085a-dspi"
> + or
> + "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
>  - reg : Offset and length of the register set for the device
>  - interrupts : Should contain SPI controller interrupt
>  - clocks: from common clock binding: handle to dspi clock.
> --

RE: [PATCH v6 1/2] Documentation: fsl: dspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi All,

Could you please help to review and merge this patch?

Thanks.

On 03/09/2016 08:59 PM, Yao Yuan wrote:
> 
> new compatible string: "fsl,ls2080a-dspi".
> 
> Signed-off-by: Yuan Yao 
> Acked-by: Rob Herring 
> ---
> Changed in v6:
> No changes.
> 
> Changed in v5:
> Fix the subject and commit message.
> 
> Changed in v4:
> No changes.
> 
> Changed in v3:
> Add the modifier for new compatible string like:
> "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> 
> Changed in v2:
> Update my email to 
> ---
>  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> index fa77f87..1ad0fe3 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> @@ -1,7 +1,10 @@
>  ARM Freescale DSPI controller
> 
>  Required properties:
> -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi"
> +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> + "fsl,ls2085a-dspi"
> + or
> + "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
>  - reg : Offset and length of the register set for the device
>  - interrupts : Should contain SPI controller interrupt
>  - clocks: from common clock binding: handle to dspi clock.
> --

RE: [PATCH 2/2] dts/ls2080a: Update DSPI compatible

[Yao Yuan]

Hi All,

Sorry for the patch:
dts/ls2080a: Update DSPI compatible

I was just trying to resend this patch:
dts/ls2080a: update the DTS for QSPI and DSPI support
https://patchwork.ozlabs.org/patch/573108/

But I have a big mistake to sending a wrong patch.
Please ignore it.

And I will resend the right patch.

Sorry for make you confused.

Best Regards,
Yuan Yao


> -Original Message-
> From: Yuan Yao [mailto:yao.y...@freescale.com]
> Sent: Tuesday, March 08, 2016 4:23 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; pawel.m...@arm.com
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Yao Yuan <yao.y...@nxp.com>
> Subject: [PATCH 2/2] dts/ls2080a: Update DSPI compatible
> 
> From: Yuan Yao <yao.y...@nxp.com>
> 
> The patch adds LS2085a to DSPI compatible.
> The DSPI driver on LS2080A should use TCFQ mode.
> It's different from on vf610.
> 
> Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 9d746c6..122c517 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -318,7 +318,7 @@
> 
>   dspi: dspi@210 {
>   status = "disabled";
> - compatible = "fsl,vf610-dspi";
> + compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x0 0x210 0x0 0x1>;
> --
> 2.1.0.27.g96db324

RE: [PATCH 2/2] dts/ls2080a: Update DSPI compatible

[Yao Yuan]

Hi All,

Sorry for the patch:
dts/ls2080a: Update DSPI compatible

I was just trying to resend this patch:
dts/ls2080a: update the DTS for QSPI and DSPI support
https://patchwork.ozlabs.org/patch/573108/

But I have a big mistake to sending a wrong patch.
Please ignore it.

And I will resend the right patch.

Sorry for make you confused.

Best Regards,
Yuan Yao


> -Original Message-
> From: Yuan Yao [mailto:yao.y...@freescale.com]
> Sent: Tuesday, March 08, 2016 4:23 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; pawel.m...@arm.com
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Yao Yuan 
> Subject: [PATCH 2/2] dts/ls2080a: Update DSPI compatible
> 
> From: Yuan Yao 
> 
> The patch adds LS2085a to DSPI compatible.
> The DSPI driver on LS2080A should use TCFQ mode.
> It's different from on vf610.
> 
> Signed-off-by: Yuan Yao 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 9d746c6..122c517 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -318,7 +318,7 @@
> 
>   dspi: dspi@210 {
>   status = "disabled";
> - compatible = "fsl,vf610-dspi";
> + compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x0 0x210 0x0 0x1>;
> --
> 2.1.0.27.g96db324

RE: [PATCH v4 4/7] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Tue, Mar 08, 2016 at 4:32AM, Brian Norris wrote:
> On Tue, Jan 26, 2016 at 03:23:58PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> 
> ^^ This line doesn't match the subject or the content of the patch.
> 
> > Signed-off-by: Yuan Yao 
> > Acked-by: Rob Herring 
> > ---
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> 
> ^^ What is this change doing in this series anyway? You're touching MTD stuff,
> not SPI stuff, and this string doesn't get used in any driver. Is this 
> controller
> somehow related, or is it a separate IP block that happens to be on some of 
> the
> same SoCs?
> 

Sorry for the wrong subject, this patch is used for add the SPI(DSPI) binging 
document.
It should be some mistake that I make the wrong subject and the commit message.

> Anyway, you should send this kind of stuff to the SPI list, not the MTD one.

I will resend it to SPI list, thanks for your review.

> Regards,
> Brian
> 
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..1ad0fe3 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,10 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi"
> > +   or
> > +   "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >  - reg : Offset and length of the register set for the device
> >  - interrupts : Should contain SPI controller interrupt
> >  - clocks: from common clock binding: handle to dspi clock.
> > --
> > 2.1.0.27.g96db324
> >

RE: [PATCH v4 4/7] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Tue, Mar 08, 2016 at 4:32AM, Brian Norris wrote:
> On Tue, Jan 26, 2016 at 03:23:58PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> 
> ^^ This line doesn't match the subject or the content of the patch.
> 
> > Signed-off-by: Yuan Yao 
> > Acked-by: Rob Herring 
> > ---
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> 
> ^^ What is this change doing in this series anyway? You're touching MTD stuff,
> not SPI stuff, and this string doesn't get used in any driver. Is this 
> controller
> somehow related, or is it a separate IP block that happens to be on some of 
> the
> same SoCs?
> 

Sorry for the wrong subject, this patch is used for add the SPI(DSPI) binging 
document.
It should be some mistake that I make the wrong subject and the commit message.

> Anyway, you should send this kind of stuff to the SPI list, not the MTD one.

I will resend it to SPI list, thanks for your review.

> Regards,
> Brian
> 
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..1ad0fe3 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,10 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi"
> > +   or
> > +   "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >  - reg : Offset and length of the register set for the device
> >  - interrupts : Should contain SPI controller interrupt
> >  - clocks: from common clock binding: handle to dspi clock.
> > --
> > 2.1.0.27.g96db324
> >

RE: [PATCH] dts/ls1021a: add the DTS for QSPI support

[Yao Yuan]

On Tue, Feb 02, 2016 at 03:49PM, Shawn Guo wrote:
> On Thu, Jan 28, 2016 at 04:33:26PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Add in v1:
> > Can merge, but the function depend on the patch:
> > https://patchwork.kernel.org/patch/8118251/
> 
> Please send me dts patch only after the driver part gets applied.

Ok, I will resend the patch after the driver part gets applied.
I just only want to speed up my upstream.

> 
> >
> > mtd: spi-nor: fsl-quadspi: add support for ls1021a
> >
> > LS1021a also support Freescale Quad SPI controller.
> > Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
> > selectable for LS1021A SOC hardwares.
> >
> > ---
> >  arch/arm/boot/dts/ls1021a.dtsi | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi
> > b/arch/arm/boot/dts/ls1021a.dtsi index 9430a99..c764fa5 100644
> > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -252,6 +252,21 @@
> > status = "disabled";
> > };
> >
> > +   qspi: quadspi@155 {
> > +   compatible = "fsl,ls1021a-qspi";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0x0 0x155 0x0 0x1>,
> > +   <0x0 0x4000 0x0 0x400>;
> > +   reg-names = "QuadSPI", "QuadSPI-memory";
> > +   interrupts = ;
> > +   clock-names = "qspi_en", "qspi";
> > +   clocks = <_clk 1>, <_clk 1>;
> > +   big-endian;
> > +   amba-base = <0x4000>;
> 
> What is this property?  I cannot find it in any bindings doc.  Is it added by 
> your
> patches on driver code?

Sorry, it's the legacy property, after the latest discussion we will remove 
this property.
So I will remove it in the next version.
Thanks for your review.

Yuan Yao.

RE: [PATCH] dts/ls1021a: add the DTS for QSPI support

[Yao Yuan]

On Tue, Feb 02, 2016 at 03:49PM, Shawn Guo wrote:
> On Thu, Jan 28, 2016 at 04:33:26PM +0800, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Add in v1:
> > Can merge, but the function depend on the patch:
> > https://patchwork.kernel.org/patch/8118251/
> 
> Please send me dts patch only after the driver part gets applied.

Ok, I will resend the patch after the driver part gets applied.
I just only want to speed up my upstream.

> 
> >
> > mtd: spi-nor: fsl-quadspi: add support for ls1021a
> >
> > LS1021a also support Freescale Quad SPI controller.
> > Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
> > selectable for LS1021A SOC hardwares.
> >
> > ---
> >  arch/arm/boot/dts/ls1021a.dtsi | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi
> > b/arch/arm/boot/dts/ls1021a.dtsi index 9430a99..c764fa5 100644
> > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -252,6 +252,21 @@
> > status = "disabled";
> > };
> >
> > +   qspi: quadspi@155 {
> > +   compatible = "fsl,ls1021a-qspi";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0x0 0x155 0x0 0x1>,
> > +   <0x0 0x4000 0x0 0x400>;
> > +   reg-names = "QuadSPI", "QuadSPI-memory";
> > +   interrupts = ;
> > +   clock-names = "qspi_en", "qspi";
> > +   clocks = <_clk 1>, <_clk 1>;
> > +   big-endian;
> > +   amba-base = <0x4000>;
> 
> What is this property?  I cannot find it in any bindings doc.  Is it added by 
> your
> patches on driver code?

Sorry, it's the legacy property, after the latest discussion we will remove 
this property.
So I will remove it in the next version.
Thanks for your review.

Yuan Yao.

RE: [PATCH v3 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Fri, Jan 22, 2016 at 07:13 AM, Rob Herring wrote:
> On Thu, Jan 21, 2016 at 03:09:15PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> Acked-by: Rob Herring 

Hi Rob,

Thanks for your review and help.

How about this rest:
[PATCH v3 3/4] dts/ls2080a: update the DTS for QSPI and DSPI support

And I also want to send some patches for SPI driver soon.
But those patches depend on this four dts binging patches.
So I should also send this four patches to the SPI driver maintainers.
And they can refer to review my patch for SPI driver.

Can I also send this "dts/ls2080a: update the DTS for QSPI and DSPI support" 
patch with your Acked-by?
Or can you give me a ACK for this patch?

Thanks.

Yuan Yao.

RE: [PATCH v3 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Fri, Jan 22, 2016 at 07:13 AM, Rob Herring wrote:
> On Thu, Jan 21, 2016 at 03:09:15PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> Acked-by: Rob Herring 

Hi Rob,

Thanks for your review and help.

How about this rest:
[PATCH v3 3/4] dts/ls2080a: update the DTS for QSPI and DSPI support

And I also want to send some patches for SPI driver soon.
But those patches depend on this four dts binging patches.
So I should also send this four patches to the SPI driver maintainers.
And they can refer to review my patch for SPI driver.

Can I also send this "dts/ls2080a: update the DTS for QSPI and DSPI support" 
patch with your Acked-by?
Or can you give me a ACK for this patch?

Thanks.

Yuan Yao.

Re: mtd: spi-nor: fsl-quadspi: add support for ls1021a

[Yao Yuan]

On Sun, Jan 24, 2016 05:17 AM +0800, Brian Norris wrote:
On Fri, Jan 22, 2016 at 11:30:55AM -0600, Han Xu wrote:
> On Fri, Jan 22, 2016 at 3:01 AM, Yao Yuan  wrote:
> > On Thu, Jan 21, 2016 at 11:42 PM, Han Xu < xhnj...@gmail.com > wrote:
> >> On Thu, Jan 21, 2016 at 1:53 AM, Yuan Yao  wrote:
> >> > Any extra information you can find them on the patchwork:
> >> > https://patchwork.kernel.org/patch/8078931/
> >> > https://patchwork.kernel.org/patch/8078951/
> >> > https://patchwork.kernel.org/patch/8079091/
> >> > https://patchwork.kernel.org/patch/8078941/
> >>
> >> Please send all patches in one patch set, this is not acceptable.
> >>
> >
> > Thanks for your review.
> > But those patches are dts binding patch. And will send to  
> > devicet...@vger.kernel.org and some corresponding maintainer.
> >
> > Those two patch sets will send to different mail-list and maintainers 
> > separately.
> >
> > So, maybe it's better to send the patch to the maintainer accordingly and 
> > thus I think can also reduce the workload of maintainer.
> >
> > How about your think?
>
> Send the complete patch set to maintainer and cc all related
> sub-module groups, so everybody could understand the whole story.

Agreed. You apparently did not read the suggested documentation from
last time:

  Documentation/devicetree/bindings/submitting-patches.txt

Particularly, points 2 and 3.

Subsystem maintainers merge binding patches, so please send them as part
of the regular series.

OK, Got it.
Thanks Han Xu and  Brian Norris.

I will resend them as a complete patch set.

Re: mtd: spi-nor: fsl-quadspi: add support for ls1021a

[Yao Yuan]

On Sun, Jan 24, 2016 05:17 AM +0800, Brian Norris wrote:
On Fri, Jan 22, 2016 at 11:30:55AM -0600, Han Xu wrote:
> On Fri, Jan 22, 2016 at 3:01 AM, Yao Yuan <yao.y...@nxp.com> wrote:
> > On Thu, Jan 21, 2016 at 11:42 PM, Han Xu < xhnj...@gmail.com > wrote:
> >> On Thu, Jan 21, 2016 at 1:53 AM, Yuan Yao <yao.y...@freescale.com> wrote:
> >> > Any extra information you can find them on the patchwork:
> >> > https://patchwork.kernel.org/patch/8078931/
> >> > https://patchwork.kernel.org/patch/8078951/
> >> > https://patchwork.kernel.org/patch/8079091/
> >> > https://patchwork.kernel.org/patch/8078941/
> >>
> >> Please send all patches in one patch set, this is not acceptable.
> >>
> >
> > Thanks for your review.
> > But those patches are dts binding patch. And will send to  
> > devicet...@vger.kernel.org and some corresponding maintainer.
> >
> > Those two patch sets will send to different mail-list and maintainers 
> > separately.
> >
> > So, maybe it's better to send the patch to the maintainer accordingly and 
> > thus I think can also reduce the workload of maintainer.
> >
> > How about your think?
>
> Send the complete patch set to maintainer and cc all related
> sub-module groups, so everybody could understand the whole story.

Agreed. You apparently did not read the suggested documentation from
last time:

  Documentation/devicetree/bindings/submitting-patches.txt

Particularly, points 2 and 3.

Subsystem maintainers merge binding patches, so please send them as part
of the regular series.

OK, Got it.
Thanks Han Xu and  Brian Norris.

I will resend them as a complete patch set.

RE: mtd: spi-nor: fsl-quadspi: add support for ls1021a

[Yao Yuan]

On Thu, Jan 21, 2016 at 11:42 PM, Han Xu < xhnj...@gmail.com > wrote:
> On Thu, Jan 21, 2016 at 1:53 AM, Yuan Yao  wrote:
> > This patch set is used for add the fsl-quadspi support for ls1021a and
> > ls1043a, so remove the patch:
> > mtd: spi-nor: fsl-quadspi: extend support for some special requerment.
> 
> Please use --cover-letter to generate cover letter.
> 
> >
> > This patch will be send with anther patch set for add QSPI support on 
> > LS2080A.
> >
> > All the new property are document in anther patch set which is already
> > send to linux-kernel@vger.kernel.org and devicet...@vger.kernel.org.
> > Here is the patch name:
> > 0001-Documentation-fsl-quadspi-Add-fsl-ls2080a-dspi-compa.patch
> > 0002-Documentation-fsl-quadspi-Add-fsl-ls2080a-qspi-compa.patch
> > 0003-dts-ls2080a-update-the-DTS-for-QSPI-and-DSPI-support.patch
> > 0004-Documentation-fsl-quadspi-Add-optional-properties.patch
> >
> > Any extra information you can find them on the patchwork:
> > https://patchwork.kernel.org/patch/8078931/
> > https://patchwork.kernel.org/patch/8078951/
> > https://patchwork.kernel.org/patch/8079091/
> > https://patchwork.kernel.org/patch/8078941/
> 
> Please send all patches in one patch set, this is not acceptable.
> 

Thanks for your review.
But those patches are dts binding patch. And will send to  
devicet...@vger.kernel.org and some corresponding maintainer.

Those two patch sets will send to different mail-list and maintainers 
separately.

So, maybe it's better to send the patch to the maintainer accordingly and thus 
I think can also reduce the workload of maintainer.

How about your think?

Thanks.

Yuan Yao.

RE: mtd: spi-nor: fsl-quadspi: add support for ls1021a

[Yao Yuan]

On Thu, Jan 21, 2016 at 11:42 PM, Han Xu < xhnj...@gmail.com > wrote:
> On Thu, Jan 21, 2016 at 1:53 AM, Yuan Yao  wrote:
> > This patch set is used for add the fsl-quadspi support for ls1021a and
> > ls1043a, so remove the patch:
> > mtd: spi-nor: fsl-quadspi: extend support for some special requerment.
> 
> Please use --cover-letter to generate cover letter.
> 
> >
> > This patch will be send with anther patch set for add QSPI support on 
> > LS2080A.
> >
> > All the new property are document in anther patch set which is already
> > send to linux-kernel@vger.kernel.org and devicet...@vger.kernel.org.
> > Here is the patch name:
> > 0001-Documentation-fsl-quadspi-Add-fsl-ls2080a-dspi-compa.patch
> > 0002-Documentation-fsl-quadspi-Add-fsl-ls2080a-qspi-compa.patch
> > 0003-dts-ls2080a-update-the-DTS-for-QSPI-and-DSPI-support.patch
> > 0004-Documentation-fsl-quadspi-Add-optional-properties.patch
> >
> > Any extra information you can find them on the patchwork:
> > https://patchwork.kernel.org/patch/8078931/
> > https://patchwork.kernel.org/patch/8078951/
> > https://patchwork.kernel.org/patch/8079091/
> > https://patchwork.kernel.org/patch/8078941/
> 
> Please send all patches in one patch set, this is not acceptable.
> 

Thanks for your review.
But those patches are dts binding patch. And will send to  
devicet...@vger.kernel.org and some corresponding maintainer.

Those two patch sets will send to different mail-list and maintainers 
separately.

So, maybe it's better to send the patch to the maintainer accordingly and thus 
I think can also reduce the workload of maintainer.

How about your think?

Thanks.

Yuan Yao.

Re: [PATCH v3 1/4] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

On Tue, Jan 05, 2015 at 04:58AM, Han Xu wrote:
> On Thu, Dec 24, 2015 at 07:00:18PM +0800, Yuan Yao wrote:
> > Add R/W functions for big- or little-endian registers:
> > The qSPI controller's endian is independent of the CPU core's endian.
> > So far, the qSPI have two versions for big-endian and little-endian.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v3:
> > Update my email to 
> >
> > Changed in v2:
> > Rebase to the lastest code.
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 157 
> > +++---
> >  1 file changed, 97 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
> > b/drivers/mtd/spi-nor/fsl-quadspi.c
> > index 54640f1..04e8a93 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -275,6 +275,7 @@ struct fsl_qspi {
> >   u32 clk_rate;
> >   unsigned int chip_base_addr; /* We may support two chips. */
> >   bool has_second_chip;
> > + bool big_endian;
> >   struct mutex lock;
> >   struct pm_qos_request pm_qos_req;
> >  };
> > @@ -300,6 +301,28 @@ static inline int needs_wakeup_wait_mode(struct 
> > fsl_qspi *q)
> >  }
> >
> > 
> > @@ -954,6 +990,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
> >   if (IS_ERR(q->iobase))
> >   return PTR_ERR(q->iobase);
> >
> > + q->big_endian = of_property_read_bool(np, "big-endian");

> once again, please document the new property.

Thanks for your review.
I have already send the patch named "Documentation: fsl-quadspi: Add optional 
properties" to community on Dec 24.
Sorry for forget to send this patch to you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

On Tue, Jan 05, 2015 at 04:58AM, Han Xu wrote:
> On Thu, Dec 24, 2015 at 07:00:18PM +0800, Yuan Yao wrote:
> > Add R/W functions for big- or little-endian registers:
> > The qSPI controller's endian is independent of the CPU core's endian.
> > So far, the qSPI have two versions for big-endian and little-endian.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v3:
> > Update my email to 
> >
> > Changed in v2:
> > Rebase to the lastest code.
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 157 
> > +++---
> >  1 file changed, 97 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
> > b/drivers/mtd/spi-nor/fsl-quadspi.c
> > index 54640f1..04e8a93 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -275,6 +275,7 @@ struct fsl_qspi {
> >   u32 clk_rate;
> >   unsigned int chip_base_addr; /* We may support two chips. */
> >   bool has_second_chip;
> > + bool big_endian;
> >   struct mutex lock;
> >   struct pm_qos_request pm_qos_req;
> >  };
> > @@ -300,6 +301,28 @@ static inline int needs_wakeup_wait_mode(struct 
> > fsl_qspi *q)
> >  }
> >
> > 
> > @@ -954,6 +990,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
> >   if (IS_ERR(q->iobase))
> >   return PTR_ERR(q->iobase);
> >
> > + q->big_endian = of_property_read_bool(np, "big-endian");

> once again, please document the new property.

Thanks for your review.
I have already send the patch named "Documentation: fsl-quadspi: Add optional 
properties" to community on Dec 24.
Sorry for forget to send this patch to you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Wed, Dec 30, 2015 at 11:20 PM, Rob Herring wrote:
> On Tue, Dec 29, 2015 at 9:17 PM, Yao Yuan  wrote:
> > Hi Rob,
> >
> > Thanks for your review.
> > So you mean that I should add the commit message for why I add this new
> compatible?
> 
> Please don't top post on the lists.
> 
> No, the binding doc should explain what are valid combinations of compatible
> strings and the order when the dts can have multiple strings. For example, is
> this valid:
> 
> compatible = "fsl,vf610-dspi", "fsl,ls2080a-dspi";
> 
> In other words, I should be able to check a dts file against what the binding 
> doc
> says.
> 
> Rob

OK, I got it.
The "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi" is valid and 
used in driver.
But "fsl,ls2080a-dspi" is just used for platform flag.
Could you help to give an example that how can I explain it in Documents?
Or should I not write this compatible in Document.

I find that many compatible strings like this (not valid just a platform flag) 
for other driver are not record in document.

Thanks.

Yuan Yao

> 
> > On Wed, Dec 30, 2015 at 02:35AM, Rob Herring wrote:
> >> On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> >> > new compatible string: "fsl,ls2080a-qspi".
> >> >
> >> > Signed-off-by: Yuan Yao 
> >> > ---
> >> > Changed in v2:
> >> > Update my email to 
> >> > ---
> >> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> > index fa77f87..2fe51d6 100644
> >> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> > @@ -1,7 +1,8 @@
> >> >  ARM Freescale DSPI controller
> >> >
> >> >  Required properties:
> >> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> >> > "fsl,ls2085a-dspi"
> >> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> >> > +   "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"
> >>
> >> You should explain what combinations of compatible strings are valid.
> >>
> >> Rob
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Wed, Dec 30, 2015 at 11:20 PM, Rob Herring wrote:
> On Tue, Dec 29, 2015 at 9:17 PM, Yao Yuan <yao.y...@nxp.com> wrote:
> > Hi Rob,
> >
> > Thanks for your review.
> > So you mean that I should add the commit message for why I add this new
> compatible?
> 
> Please don't top post on the lists.
> 
> No, the binding doc should explain what are valid combinations of compatible
> strings and the order when the dts can have multiple strings. For example, is
> this valid:
> 
> compatible = "fsl,vf610-dspi", "fsl,ls2080a-dspi";
> 
> In other words, I should be able to check a dts file against what the binding 
> doc
> says.
> 
> Rob

OK, I got it.
The "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi" is valid and 
used in driver.
But "fsl,ls2080a-dspi" is just used for platform flag.
Could you help to give an example that how can I explain it in Documents?
Or should I not write this compatible in Document.

I find that many compatible strings like this (not valid just a platform flag) 
for other driver are not record in document.

Thanks.

Yuan Yao

> 
> > On Wed, Dec 30, 2015 at 02:35AM, Rob Herring wrote:
> >> On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> >> > new compatible string: "fsl,ls2080a-qspi".
> >> >
> >> > Signed-off-by: Yuan Yao <yao.y...@nxp.com>
> >> > ---
> >> > Changed in v2:
> >> > Update my email to <yao.y...@nxp.com>
> >> > ---
> >> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> > index fa77f87..2fe51d6 100644
> >> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> >> > @@ -1,7 +1,8 @@
> >> >  ARM Freescale DSPI controller
> >> >
> >> >  Required properties:
> >> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> >> > "fsl,ls2085a-dspi"
> >> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> >> > +   "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"
> >>
> >> You should explain what combinations of compatible strings are valid.
> >>
> >> Rob
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi Rob,

Thanks for your review.
So you mean that I should add the commit message for why I add this new 
compatible?

Best Regards,
Yuan Yao

On Wed, Dec 30, 2015 at 02:35AM, Rob Herring wrote:
> On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..2fe51d6 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,8 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"
> 
> You should explain what combinations of compatible strings are valid.
> 
> Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi Rob,

Thanks for your review.
So you mean that I should add the commit message for why I add this new 
compatible?

Best Regards,
Yuan Yao

On Wed, Dec 30, 2015 at 02:35AM, Rob Herring wrote:
> On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..2fe51d6 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,8 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"
> 
> You should explain what combinations of compatible strings are valid.
> 
> Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Woodhouse, Norris,

Do you have any comments for this patch?

Thanks for your review.

Best Regards,
Yuan Yao

> -Original Message-
> From: Han Xu [mailto:han...@freescale.com]
> Sent: Thursday, November 26, 2015 3:09 AM
> To: Yuan Yao-B46683 
> Cc: dw...@infradead.org; computersforpe...@gmail.com; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org
> Subject: Re: [PATCH v2] mtd: spi-nor: fsl-quadspi: add big-endian support
On Thu, Nov 26, 2015 at 
> On Wed, Nov 18, 2015 at 05:13:28PM +0800, Yuan Yao wrote:
> > Add R/W functions for big- or little-endian registers:
> > The qSPI controller's endian is independent of the CPU core's endian.
> > So far, the qSPI have two versions for big-endian and little-endian.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Rebase to the lastest code.
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 157
> > +++---
> >  1 file changed, 97 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl-quadspi.c
> > index 9e7f657..0ce7768 100644

...

> > @@ -954,6 +990,7 @@ static int fsl_qspi_probe(struct platform_device
> *pdev)
> > if (IS_ERR(q->iobase))
> > return PTR_ERR(q->iobase);
> >
> > +   q->big_endian = of_property_read_bool(np, "big-endian");
> 
> I am fine with this patch, but need document the new property with another
> patch
> 
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "QuadSPI-memory");
> > if (!devm_request_mem_region(dev, res->start, resource_size(res),
> @@

...

> >
> 
> Acked-by: Han xu 
> --

Best Regards,
Yuan Yao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Woodhouse, Norris,

Do you have any comments for this patch?

Thanks for your review.

Best Regards,
Yuan Yao

> -Original Message-
> From: Han Xu [mailto:han...@freescale.com]
> Sent: Thursday, November 26, 2015 3:09 AM
> To: Yuan Yao-B46683 
> Cc: dw...@infradead.org; computersforpe...@gmail.com; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org
> Subject: Re: [PATCH v2] mtd: spi-nor: fsl-quadspi: add big-endian support
On Thu, Nov 26, 2015 at 
> On Wed, Nov 18, 2015 at 05:13:28PM +0800, Yuan Yao wrote:
> > Add R/W functions for big- or little-endian registers:
> > The qSPI controller's endian is independent of the CPU core's endian.
> > So far, the qSPI have two versions for big-endian and little-endian.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Rebase to the lastest code.
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 157
> > +++---
> >  1 file changed, 97 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl-quadspi.c
> > index 9e7f657..0ce7768 100644

...

> > @@ -954,6 +990,7 @@ static int fsl_qspi_probe(struct platform_device
> *pdev)
> > if (IS_ERR(q->iobase))
> > return PTR_ERR(q->iobase);
> >
> > +   q->big_endian = of_property_read_bool(np, "big-endian");
> 
> I am fine with this patch, but need document the new property with another
> patch
> 
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "QuadSPI-memory");
> > if (!devm_request_mem_region(dev, res->start, resource_size(res),
> @@

...

> >
> 
> Acked-by: Han xu 
> --

Best Regards,
Yuan Yao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 4/5] mtd: spi-nor: fsl-quadspi: add support for layerscape

[Yao Yuan]

Hi Allen,

Yes, I will.
In fact, I have already send the patch.
This patch will add the new compatible entries in qspi driver for the ls1021a 
platform.

Thanks for your review.

Best Regards,

Yuan Yao

-Original Message-
From: Han Xu [mailto:han...@freescale.com] 
Sent: Wednesday, November 25, 2015 2:16 PM
To: Yuan Yao-B46683 
Cc: dw...@infradead.org; computersforpe...@gmail.com; 
linux-kernel@vger.kernel.org; linux-...@lists.infradead.org
Subject: Re: [PATCH 4/5] mtd: spi-nor: fsl-quadspi: add support for layerscape

On Wed, Nov 18, 2015 at 05:19:02PM +0800, Yuan Yao wrote:
> LS1043a and LS2080A in the Layerscape family also support Freescale 
> Quad SPI, make Quad SPI selectable for these hardwares.
> 
> Signed-off-by: Yuan Yao 
> ---
>  drivers/mtd/spi-nor/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig 
> index 1368221..9373141 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -23,7 +23,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>  
>  config SPI_FSL_QUADSPI
>   tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
> + depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || 
> +COMPILE_TEST

So will you add new compatible entries in qspi driver for these two platforms?

>   depends on HAS_IOMEM
>   help
> This enables support for the Quad SPI controller in master mode.
> --
> 2.1.0.27.g96db324
> 

-- 
Best Regards,

Han "Allen" Xu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add support for ls1021a

[Yao Yuan]

Ok.
Thanks.

-Original Message-
From: Han Xu [mailto:han...@freescale.com] 
Sent: Wednesday, November 25, 2015 2:15 PM
To: Yuan Yao-B46683 
Cc: dw...@infradead.org; computersforpe...@gmail.com; 
linux-kernel@vger.kernel.org; linux-...@lists.infradead.org
Subject: Re: [PATCH] mtd: spi-nor: fsl-quadspi: add support for ls1021a

On Wed, Nov 18, 2015 at 05:15:03PM +0800, Yuan Yao wrote:
> LS1021a also support Freescale Quad SPI controller.
> Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI 
> selectable for LS1021A SOC hardwares.
> 
> Signed-off-by: Yuan Yao 
> ---
>  drivers/mtd/spi-nor/Kconfig   |  2 +-
>  drivers/mtd/spi-nor/fsl-quadspi.c | 10 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig 
> index 2fe2a7e..1368221 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -23,7 +23,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>  
>  config SPI_FSL_QUADSPI
>   tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || COMPILE_TEST
> + depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
>   depends on HAS_IOMEM
>   help
> This enables support for the Quad SPI controller in master mode.
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 0ce7768..03a589d 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -213,6 +213,7 @@ enum fsl_qspi_devtype {
>   FSL_QUADSPI_IMX6SX,
>   FSL_QUADSPI_IMX7D,
>   FSL_QUADSPI_IMX6UL,
> + FSL_QUADSPI_LS1021A,
>  };
>  
>  struct fsl_qspi_devtype_data {
> @@ -258,6 +259,14 @@ static struct fsl_qspi_devtype_data imx6ul_data = {
>  | QUADSPI_QUIRK_4X_INT_CLK,
>  };
>  
> +static struct fsl_qspi_devtype_data ls1021a_data = {
> + .devtype = FSL_QUADSPI_LS1021A,
> + .rxfifo = 128,
> + .txfifo = 64,
> + .ahb_buf_size = 1024,
> + .driver_data = 0,
> +};
> +
>  #define FSL_QSPI_MAX_CHIP4
>  struct fsl_qspi {
>   struct spi_nor nor[FSL_QSPI_MAX_CHIP]; @@ -812,6 +821,7 @@ static 
> const struct of_device_id fsl_qspi_dt_ids[] = {
>   { .compatible = "fsl,imx6sx-qspi", .data = (void *)_data, },
>   { .compatible = "fsl,imx7d-qspi", .data = (void *)_data, },
>   { .compatible = "fsl,imx6ul-qspi", .data = (void *)_data, },
> + { .compatible = "fsl,ls1021a-qspi", .data = (void *)_data, 
> +},

Same comments, document this compatible.

>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, fsl_qspi_dt_ids);
> --
> 2.1.0.27.g96db324
> 

Acked-by: Han xu 
-- 
Best Regards,

Han "Allen" Xu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v4] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi vinod,

Thanks for your review.
I have updated the patch as your comments before.
And then send the v4.
Do you have any comments for it?

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Yuan Yao
> Sent: Friday, October 30, 2015 7:04 PM
> To: vinod.k...@intel.com; ste...@agner.ch; a...@arndb.de
> Cc: dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v4] dmaengine: fsl-edma: add PM suspend/resume support
> 
> This add power management suspend/resume support for the fsl-edma driver.
> 
> eDMA acted as a basic function used by others. What it needs to do is the two
> steps below to support power management.
> 
> In fsl_edma_suspend_late:
> Check whether the DMA chan is idle, if it is not idle disable DMA request.
> 
> In fsl_edma_resume_early:
> Enable the eDMA and wait for being used.
> 
> Signed-off-by: Yuan Yao 
> ---
> Changes in v4:
> - Add comments for why use suspend_late and resume_early; Changes in v3:
> - Force terminate the active channels in suspend if the channel
>   is not idle.
> Changes in v2: None
> ---
>  drivers/dma/fsl-edma.c | 85
> --
>  1 file changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> 915eec3..be2e62b 100644
> --- a/drivers/dma/fsl-edma.c
> +++ b/drivers/dma/fsl-edma.c
> @@ -116,6 +116,10 @@
>   BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
>   BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
>   BIT(DMA_SLAVE_BUSWIDTH_8_BYTES)
> +enum fsl_edma_pm_state {
> + RUNNING = 0,
> + SUSPENDED,
> +};
> 
>  struct fsl_edma_hw_tcd {
>   __le32  saddr;
> @@ -147,6 +151,9 @@ struct fsl_edma_slave_config {  struct fsl_edma_chan {
>   struct virt_dma_chanvchan;
>   enum dma_status status;
> + enum fsl_edma_pm_state  pm_state;
> + boolidle;
> + u32 slave_id;
>   struct fsl_edma_engine  *edma;
>   struct fsl_edma_desc*edesc;
>   struct fsl_edma_slave_configfsc;
> @@ -298,6 +305,7 @@ static int fsl_edma_terminate_all(struct dma_chan
> *chan)
>   spin_lock_irqsave(_chan->vchan.lock, flags);
>   fsl_edma_disable_request(fsl_chan);
>   fsl_chan->edesc = NULL;
> + fsl_chan->idle = true;
>   vchan_get_all_descriptors(_chan->vchan, );
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   vchan_dma_desc_free_list(_chan->vchan, ); @@ -313,6
> +321,7 @@ static int fsl_edma_pause(struct dma_chan *chan)
>   if (fsl_chan->edesc) {
>   fsl_edma_disable_request(fsl_chan);
>   fsl_chan->status = DMA_PAUSED;
> + fsl_chan->idle = true;
>   }
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   return 0;
> @@ -327,6 +336,7 @@ static int fsl_edma_resume(struct dma_chan *chan)
>   if (fsl_chan->edesc) {
>   fsl_edma_enable_request(fsl_chan);
>   fsl_chan->status = DMA_IN_PROGRESS;
> + fsl_chan->idle = false;
>   }
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   return 0;
> @@ -648,6 +658,7 @@ static void fsl_edma_xfer_desc(struct fsl_edma_chan
> *fsl_chan)
>   fsl_edma_set_tcd_regs(fsl_chan, fsl_chan->edesc->tcd[0].vtcd);
>   fsl_edma_enable_request(fsl_chan);
>   fsl_chan->status = DMA_IN_PROGRESS;
> + fsl_chan->idle = false;
>  }
> 
>  static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id) @@ -676,6
> +687,7 @@ static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id)
>   vchan_cookie_complete(_chan->edesc-
> >vdesc);
>   fsl_chan->edesc = NULL;
>   fsl_chan->status = DMA_COMPLETE;
> + fsl_chan->idle = true;
>   } else {
>   vchan_cyclic_callback(_chan->edesc-
> >vdesc);
>   }
> @@ -704,6 +716,7 @@ static irqreturn_t fsl_edma_err_handler(int irq, void
> *dev_id)
>   edma_writeb(fsl_edma, EDMA_CERR_CERR(ch),
>   fsl_edma->membase + EDMA_CERR);
>   fsl_edma->chans[ch].status = DMA_ERROR;
> + fsl_edma->chans[ch].idle = true;
>   }
>   }
>   return IRQ_HANDLED;
> @@ -724,6 +737,12 @@ static void fsl_edma_issue_pending(struct dma_chan
> *chan)
> 
>   spin_lock_irqsave(_chan->vchan.lock, flags);
> 
> + if (unlikely(fsl_chan->pm_state != RUNNING)) {
> + spin_unlock_irqrestore(_chan->vchan.lock, flags);
> + /* cannot submit due to suspend */
> + return;
> + }
> +
>   if 

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add support for ls1021a

[Yao Yuan]

Ok.
Thanks.

-Original Message-
From: Han Xu [mailto:han...@freescale.com] 
Sent: Wednesday, November 25, 2015 2:15 PM
To: Yuan Yao-B46683 
Cc: dw...@infradead.org; computersforpe...@gmail.com; 
linux-kernel@vger.kernel.org; linux-...@lists.infradead.org
Subject: Re: [PATCH] mtd: spi-nor: fsl-quadspi: add support for ls1021a

On Wed, Nov 18, 2015 at 05:15:03PM +0800, Yuan Yao wrote:
> LS1021a also support Freescale Quad SPI controller.
> Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI 
> selectable for LS1021A SOC hardwares.
> 
> Signed-off-by: Yuan Yao 
> ---
>  drivers/mtd/spi-nor/Kconfig   |  2 +-
>  drivers/mtd/spi-nor/fsl-quadspi.c | 10 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig 
> index 2fe2a7e..1368221 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -23,7 +23,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>  
>  config SPI_FSL_QUADSPI
>   tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || COMPILE_TEST
> + depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
>   depends on HAS_IOMEM
>   help
> This enables support for the Quad SPI controller in master mode.
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 0ce7768..03a589d 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -213,6 +213,7 @@ enum fsl_qspi_devtype {
>   FSL_QUADSPI_IMX6SX,
>   FSL_QUADSPI_IMX7D,
>   FSL_QUADSPI_IMX6UL,
> + FSL_QUADSPI_LS1021A,
>  };
>  
>  struct fsl_qspi_devtype_data {
> @@ -258,6 +259,14 @@ static struct fsl_qspi_devtype_data imx6ul_data = {
>  | QUADSPI_QUIRK_4X_INT_CLK,
>  };
>  
> +static struct fsl_qspi_devtype_data ls1021a_data = {
> + .devtype = FSL_QUADSPI_LS1021A,
> + .rxfifo = 128,
> + .txfifo = 64,
> + .ahb_buf_size = 1024,
> + .driver_data = 0,
> +};
> +
>  #define FSL_QSPI_MAX_CHIP4
>  struct fsl_qspi {
>   struct spi_nor nor[FSL_QSPI_MAX_CHIP]; @@ -812,6 +821,7 @@ static 
> const struct of_device_id fsl_qspi_dt_ids[] = {
>   { .compatible = "fsl,imx6sx-qspi", .data = (void *)_data, },
>   { .compatible = "fsl,imx7d-qspi", .data = (void *)_data, },
>   { .compatible = "fsl,imx6ul-qspi", .data = (void *)_data, },
> + { .compatible = "fsl,ls1021a-qspi", .data = (void *)_data, 
> +},

Same comments, document this compatible.

>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, fsl_qspi_dt_ids);
> --
> 2.1.0.27.g96db324
> 

Acked-by: Han xu 
-- 
Best Regards,

Han "Allen" Xu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 4/5] mtd: spi-nor: fsl-quadspi: add support for layerscape

[Yao Yuan]

Hi Allen,

Yes, I will.
In fact, I have already send the patch.
This patch will add the new compatible entries in qspi driver for the ls1021a 
platform.

Thanks for your review.

Best Regards,

Yuan Yao

-Original Message-
From: Han Xu [mailto:han...@freescale.com] 
Sent: Wednesday, November 25, 2015 2:16 PM
To: Yuan Yao-B46683 
Cc: dw...@infradead.org; computersforpe...@gmail.com; 
linux-kernel@vger.kernel.org; linux-...@lists.infradead.org
Subject: Re: [PATCH 4/5] mtd: spi-nor: fsl-quadspi: add support for layerscape

On Wed, Nov 18, 2015 at 05:19:02PM +0800, Yuan Yao wrote:
> LS1043a and LS2080A in the Layerscape family also support Freescale 
> Quad SPI, make Quad SPI selectable for these hardwares.
> 
> Signed-off-by: Yuan Yao 
> ---
>  drivers/mtd/spi-nor/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig 
> index 1368221..9373141 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -23,7 +23,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>  
>  config SPI_FSL_QUADSPI
>   tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
> + depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || 
> +COMPILE_TEST

So will you add new compatible entries in qspi driver for these two platforms?

>   depends on HAS_IOMEM
>   help
> This enables support for the Quad SPI controller in master mode.
> --
> 2.1.0.27.g96db324
> 

-- 
Best Regards,

Han "Allen" Xu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v4] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi vinod,

Thanks for your review.
I have updated the patch as your comments before.
And then send the v4.
Do you have any comments for it?

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Yuan Yao
> Sent: Friday, October 30, 2015 7:04 PM
> To: vinod.k...@intel.com; ste...@agner.ch; a...@arndb.de
> Cc: dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v4] dmaengine: fsl-edma: add PM suspend/resume support
> 
> This add power management suspend/resume support for the fsl-edma driver.
> 
> eDMA acted as a basic function used by others. What it needs to do is the two
> steps below to support power management.
> 
> In fsl_edma_suspend_late:
> Check whether the DMA chan is idle, if it is not idle disable DMA request.
> 
> In fsl_edma_resume_early:
> Enable the eDMA and wait for being used.
> 
> Signed-off-by: Yuan Yao 
> ---
> Changes in v4:
> - Add comments for why use suspend_late and resume_early; Changes in v3:
> - Force terminate the active channels in suspend if the channel
>   is not idle.
> Changes in v2: None
> ---
>  drivers/dma/fsl-edma.c | 85
> --
>  1 file changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> 915eec3..be2e62b 100644
> --- a/drivers/dma/fsl-edma.c
> +++ b/drivers/dma/fsl-edma.c
> @@ -116,6 +116,10 @@
>   BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
>   BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
>   BIT(DMA_SLAVE_BUSWIDTH_8_BYTES)
> +enum fsl_edma_pm_state {
> + RUNNING = 0,
> + SUSPENDED,
> +};
> 
>  struct fsl_edma_hw_tcd {
>   __le32  saddr;
> @@ -147,6 +151,9 @@ struct fsl_edma_slave_config {  struct fsl_edma_chan {
>   struct virt_dma_chanvchan;
>   enum dma_status status;
> + enum fsl_edma_pm_state  pm_state;
> + boolidle;
> + u32 slave_id;
>   struct fsl_edma_engine  *edma;
>   struct fsl_edma_desc*edesc;
>   struct fsl_edma_slave_configfsc;
> @@ -298,6 +305,7 @@ static int fsl_edma_terminate_all(struct dma_chan
> *chan)
>   spin_lock_irqsave(_chan->vchan.lock, flags);
>   fsl_edma_disable_request(fsl_chan);
>   fsl_chan->edesc = NULL;
> + fsl_chan->idle = true;
>   vchan_get_all_descriptors(_chan->vchan, );
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   vchan_dma_desc_free_list(_chan->vchan, ); @@ -313,6
> +321,7 @@ static int fsl_edma_pause(struct dma_chan *chan)
>   if (fsl_chan->edesc) {
>   fsl_edma_disable_request(fsl_chan);
>   fsl_chan->status = DMA_PAUSED;
> + fsl_chan->idle = true;
>   }
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   return 0;
> @@ -327,6 +336,7 @@ static int fsl_edma_resume(struct dma_chan *chan)
>   if (fsl_chan->edesc) {
>   fsl_edma_enable_request(fsl_chan);
>   fsl_chan->status = DMA_IN_PROGRESS;
> + fsl_chan->idle = false;
>   }
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   return 0;
> @@ -648,6 +658,7 @@ static void fsl_edma_xfer_desc(struct fsl_edma_chan
> *fsl_chan)
>   fsl_edma_set_tcd_regs(fsl_chan, fsl_chan->edesc->tcd[0].vtcd);
>   fsl_edma_enable_request(fsl_chan);
>   fsl_chan->status = DMA_IN_PROGRESS;
> + fsl_chan->idle = false;
>  }
> 
>  static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id) @@ -676,6
> +687,7 @@ static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id)
>   vchan_cookie_complete(_chan->edesc-
> >vdesc);
>   fsl_chan->edesc = NULL;
>   fsl_chan->status = DMA_COMPLETE;
> + fsl_chan->idle = true;
>   } else {
>   vchan_cyclic_callback(_chan->edesc-
> >vdesc);
>   }
> @@ -704,6 +716,7 @@ static irqreturn_t fsl_edma_err_handler(int irq, void
> *dev_id)
>   edma_writeb(fsl_edma, EDMA_CERR_CERR(ch),
>   fsl_edma->membase + EDMA_CERR);
>   fsl_edma->chans[ch].status = DMA_ERROR;
> + fsl_edma->chans[ch].idle = true;
>   }
>   }
>   return IRQ_HANDLED;
> @@ -724,6 +737,12 @@ static void fsl_edma_issue_pending(struct dma_chan
> *chan)
> 
>   spin_lock_irqsave(_chan->vchan.lock, flags);
> 
> + if (unlikely(fsl_chan->pm_state != RUNNING)) {
> + spin_unlock_irqrestore(_chan->vchan.lock, flags);
> + /* cannot submit due to suspend */
> + return;
> + }
> +
>

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Brian,

Thanks for your information.

Best Regards,
Yuan Yao

On Mon, Nov 16, 2015 at 12:22:30PM +, Brian Norris wrote:
> On Mon, Nov 16, 2015 at 04:08:39AM +0000, Yao Yuan wrote:
> > It looks like easier to read, use and change.
> > Is it?
> 
> It looks fine either way, IMO.
> 
> > And David Woodhouse, Xu Han, Mark Brown is there any other comments
> > from you?
> 
> FYI, Mark Brown doesn't really have much to do with this. Though he maintains
> the SPI subsystem (and regmap, as a matter of fact), SPI *NOR* code is only a
> user of the SPI subsystem (and, potentially, regmap). I hear he's not 
> interested
> in reviewing MTD work, given the volume of email he already receives.
> 
> Regards,
> Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Brian,

Thanks for your information.

Best Regards,
Yuan Yao

On Mon, Nov 16, 2015 at 12:22:30PM +, Brian Norris wrote:
> On Mon, Nov 16, 2015 at 04:08:39AM +0000, Yao Yuan wrote:
> > It looks like easier to read, use and change.
> > Is it?
> 
> It looks fine either way, IMO.
> 
> > And David Woodhouse, Xu Han, Mark Brown is there any other comments
> > from you?
> 
> FYI, Mark Brown doesn't really have much to do with this. Though he maintains
> the SPI subsystem (and regmap, as a matter of fact), SPI *NOR* code is only a
> user of the SPI subsystem (and, potentially, regmap). I hear he's not 
> interested
> in reviewing MTD work, given the volume of email he already receives.
> 
> Regards,
> Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Brian Norris,

Thanks for your information and the documents shared by you.
It's very helpful for me to understand the regmap.

But I think if we use:
static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
*addr) {
   if (q->big_endian)
   iowrite32be(val, addr);
   else
   iowrite32(val, addr);
 }
It looks like easier to read, use and change.
Is it?

And David Woodhouse, Xu Han, Mark Brown
is there any other comments from you?

Thank.

On Thu, Nov 12, 2015 3:04 AM Brian Norris wrote:
> On Fri, Oct 30, 2015 at 09:49:41AM +0000, Yao Yuan wrote:
> > Hi Fabio Estevam,
> >
> > Thanks for your suggestion.
> > We have an internal discussions for that.
> >
> > We think that:
> > According to the initial commit message of regmap, it is targeting
> > non-memory mapped buses. (regmap: Add generic non-memory mapped
> > register access API)  But in the imx2_wdt driver, it is used for
> > memory-mapped register space.  So it seems that using such a complex
> > framework just to deal with endian is an over-kill.
> 
> It is definitely useful for non-MMIO cases, but it's certainly not exclusive 
> too it.
> 
> > when it is not necessary to enable the clock every time we access the 
> > register.
> 
> You don't have to give it a clock. Just pass a NULL clk_id.
> 
> > We don't think it is obvious to us how to use it for handling
> > endianness, especially not the way imx2_wdt uses regmap.
> > __regmap_init_mmio_clk() calls regmap_mmio_gen_context() which errors
> > out if reg_format_endian is not REGMAP_ENDIAN_DEFAULT or
> > REGMAP_ENDIAN_NATIVE, and elsewhere regmap-mmio.c It seems only
> > little-endian accessors.
> >
> > Although it is possible to add the endianness support in the
> > regmap_mmio driver, we don't see too much value in using it especially
> 
> It already has DT endianness configuration support. See __regmap_init(),
> which reconfigures the endianness according to regmap_get_val_endian().
> So you don't need to do anything but just try it... I exepct it'll work just 
> fine.
> 
> > So we think:
> > static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > *addr) {
> >   if (q->big_endian)
> >   iowrite32be(val, addr);
> >   else
> >   iowrite32(val, addr);
> > }
> > This way is an easier, more effective solution to do the endian issue.
> >
> > How about your think?
> 
> I think there's at least one more advantage: you get pretty good tracing
> support for free. For debugging, for example, you can turn on regmap tracing
> to see all the register reads and writes done in your driver, all within the 
> nice
> tracefs event infrastructure. I'm sure there are other advantages too, but not
> all are applicable here.
> 
> Anyway, I do agree on the complexity argument. It's not actually that complex
> to use (the imx2_wdt.c example really does show you everything you need to
> know), it is a bit more complex to sort through all its features and 
> understand
> exactly what it's doing. But I'm confident it has everything you need.
> 
> So, make your choice. I just wanted to educate on several points, so that your
> decision is not just driven by lack of correct information.
> 
> For more information, a quick google search shows a few links, but no official
> docs:
> 
> http://elinux.org/images/a/a3/Regmap-
> _The_Power_of_Subsystems_and_Abstractions.pdf
> https://lwn.net/Articles/451789/
> 
> Brian
> 
> > Best Regards,
> > Yuan Yao
> >
> > On Sat, Oct 24, 2015 at 11:47 PM, Fabio Estevam 
> wrote:
> > > On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao  wrote:
> > >
> > > > +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > > > +*addr) {
> > > > +   if (q->big_endian)
> > > > +   iowrite32be(val, addr);
> > > > +   else
> > > > +   iowrite32(val, addr); }
> > >
> > > I suggest you to implement regmap support for this driver instead.
> > >
> > > Take a look at drivers/watchdog/imx2_wdt.c for a reference.
> > >
> > > Then you only need to pass 'big-endian' as a property for the qspi
> > > in the .dtsi file and regmap core will take care of endianness.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Brian Norris,

Thanks for your information and the documents shared by you.
It's very helpful for me to understand the regmap.

But I think if we use:
static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
*addr) {
   if (q->big_endian)
   iowrite32be(val, addr);
   else
   iowrite32(val, addr);
 }
It looks like easier to read, use and change.
Is it?

And David Woodhouse, Xu Han, Mark Brown
is there any other comments from you?

Thank.

On Thu, Nov 12, 2015 3:04 AM Brian Norris wrote:
> On Fri, Oct 30, 2015 at 09:49:41AM +0000, Yao Yuan wrote:
> > Hi Fabio Estevam,
> >
> > Thanks for your suggestion.
> > We have an internal discussions for that.
> >
> > We think that:
> > According to the initial commit message of regmap, it is targeting
> > non-memory mapped buses. (regmap: Add generic non-memory mapped
> > register access API)  But in the imx2_wdt driver, it is used for
> > memory-mapped register space.  So it seems that using such a complex
> > framework just to deal with endian is an over-kill.
> 
> It is definitely useful for non-MMIO cases, but it's certainly not exclusive 
> too it.
> 
> > when it is not necessary to enable the clock every time we access the 
> > register.
> 
> You don't have to give it a clock. Just pass a NULL clk_id.
> 
> > We don't think it is obvious to us how to use it for handling
> > endianness, especially not the way imx2_wdt uses regmap.
> > __regmap_init_mmio_clk() calls regmap_mmio_gen_context() which errors
> > out if reg_format_endian is not REGMAP_ENDIAN_DEFAULT or
> > REGMAP_ENDIAN_NATIVE, and elsewhere regmap-mmio.c It seems only
> > little-endian accessors.
> >
> > Although it is possible to add the endianness support in the
> > regmap_mmio driver, we don't see too much value in using it especially
> 
> It already has DT endianness configuration support. See __regmap_init(),
> which reconfigures the endianness according to regmap_get_val_endian().
> So you don't need to do anything but just try it... I exepct it'll work just 
> fine.
> 
> > So we think:
> > static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > *addr) {
> >   if (q->big_endian)
> >   iowrite32be(val, addr);
> >   else
> >   iowrite32(val, addr);
> > }
> > This way is an easier, more effective solution to do the endian issue.
> >
> > How about your think?
> 
> I think there's at least one more advantage: you get pretty good tracing
> support for free. For debugging, for example, you can turn on regmap tracing
> to see all the register reads and writes done in your driver, all within the 
> nice
> tracefs event infrastructure. I'm sure there are other advantages too, but not
> all are applicable here.
> 
> Anyway, I do agree on the complexity argument. It's not actually that complex
> to use (the imx2_wdt.c example really does show you everything you need to
> know), it is a bit more complex to sort through all its features and 
> understand
> exactly what it's doing. But I'm confident it has everything you need.
> 
> So, make your choice. I just wanted to educate on several points, so that your
> decision is not just driven by lack of correct information.
> 
> For more information, a quick google search shows a few links, but no official
> docs:
> 
> http://elinux.org/images/a/a3/Regmap-
> _The_Power_of_Subsystems_and_Abstractions.pdf
> https://lwn.net/Articles/451789/
> 
> Brian
> 
> > Best Regards,
> > Yuan Yao
> >
> > On Sat, Oct 24, 2015 at 11:47 PM, Fabio Estevam <feste...@gmail.com>
> wrote:
> > > On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao <yao.y...@freescale.com> wrote:
> > >
> > > > +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > > > +*addr) {
> > > > +   if (q->big_endian)
> > > > +   iowrite32be(val, addr);
> > > > +   else
> > > > +   iowrite32(val, addr); }
> > >
> > > I suggest you to implement regmap support for this driver instead.
> > >
> > > Take a look at drivers/watchdog/imx2_wdt.c for a reference.
> > >
> > > Then you only need to pass 'big-endian' as a property for the qspi
> > > in the .dtsi file and regmap core will take care of endianness.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 1/3] dma: Add Freescale qDMA engine driver support

[Yao Yuan]

On Wed, Nov 11, 2015 4:14 PM, Vinod Koul wrote:
> On Fri, Oct 23, 2015 at 09:59:11AM +0800, Yuan Yao wrote:
> 
> > +config FSL_QDMA
> > +   tristate "Freescale qDMA engine support"
> > +   depends on SOC_LS1021A || ARCH_LAYERSCAPE
> 
> Where is this ARCH defined, quick grep revealed none
> 
This is a generic  family naming for freescale a set of ARMv8 based SoCs.
The patch is merged in arm soc but not yet merge into Linux next.

> > +static void fsl_qdma_set_tcd_params(struct fsl_qdma_chan *fsl_chan,
> > +   u64 src, u64 dst, u32 nbytes)
> > +{
> > +   void __iomem *addr = fsl_chan->qdma->membase;
> > +   u32 reg;
> > +
> > +   /*
> > +* Source address.
> > +* Represents address bits 31-0 of a 49-bit source address.
> > +*/
> > +   qdma_writel(fsl_chan->qdma, (u32)src, addr + FSL_QDMA_DLSAR);
> > +   /*
> > +* Source address.
> > +* Represents address bits 47-32 of a 49-bit source address.
> > +*/
> > +   reg = qdma_readl(fsl_chan->qdma, addr + FSL_QDMA_DLSATR);
> > +   reg |= (u16)(src >> 32) & 0x;
> > +   reg |= FSL_QDMA_SRTTYPE_R_N;
> > +   qdma_writel(fsl_chan->qdma, reg, addr + FSL_QDMA_DLSATR);
> 
> How does this work on systems with enither endieness ?
[Yuan Yao] I'm sorry for confused. Is there any other endianness?
As I know in SOC_LS1021A and ARCH_LAYERSCAPE, there are just 32BE and 32LE for 
the register R/W.
> 
> Also why not use readq/writeq helpers, registers seem to be contagious
[Yuan Yao] It's hard to use readq/writeq because of the endianness.
> 
> > +static enum dma_status fsl_qdma_tx_status(struct dma_chan *chan,
> > +   dma_cookie_t cookie, struct dma_tx_state *txstate) {
> > +   return dma_cookie_status(chan, cookie, txstate);
> 
> No residue ?
[Yuan Yao] The QDMA is a strange DMA that I can't find any hardware interface 
to query the data transfer size.
> 
> > +static irqreturn_t fsl_qdma_controller_handler_err(int irq, void
> > +*dev_id) {
> > +   struct fsl_qdma_engine *fsl_qdma = dev_id;
> > +   u32 reg;
> > +
> > +   reg = qdma_readl(fsl_qdma, fsl_qdma->membase + FSL_QDMA_DLSR);
> > +
> > +   if (reg & FSL_QDMA_DLSR_TE) {
> > +   dev_err(fsl_qdma->dma_dev.dev,
> > +   "Transfer error. Check your address please!\n");
> 
> It would help to print the addresses...
[Yuan Yao] Ok, The bus address or the virtual address?
> 
> > +   ret = devm_request_irq(>dev, fsl_qdma-
> >controller_irq,
> > +   fsl_qdma_controller_handler, 0,
> > +   "qDMA controller", fsl_qdma);
> > +   if (ret) {
> > +   dev_err(>dev,
> > +   "Can't register qDMA controller IRQ.\n");
> > +   return  ret;
> > +   }
> > +
> > +   ret = devm_request_irq(>dev, fsl_qdma->err_irq,
> > +   fsl_qdma_controller_handler_err, 0,
> > +   "qDMA err", fsl_qdma);
> > +   if (ret) {
> > +   dev_err(>dev, "Can't register qDMA err
> IRQ.\n");
> > +   return  ret;
> > +   }
> 
> why do you want devm variant here..?
[Yuan Yao] There is a different err IRQ in some SOCs. So I should do like this 
to support those different hardware. 
> 
> > +   dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> > +   dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> > +
> > +   fsl_qdma->dma_dev.dev = >dev;
> > +   fsl_qdma->dma_dev.device_free_chan_resources
> > +   = fsl_qdma_free_chan_resources;
> > +   fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> > +   fsl_qdma->dma_dev.device_prep_dma_memcpy =
> fsl_qdma_prep_memcpy;
> > +   fsl_qdma->dma_dev.device_issue_pending =
> fsl_qdma_issue_pending;
> 
> No terminate_all callback?
[Yuan Yao] QDMA is such a strange DMA that I can't find any hardware interface 
to stop a  in progress transmission.
> 
> > +static int fsl_qdma_remove(struct platform_device *pdev) {
> > +   struct device_node *np = pdev->dev.of_node;
> > +   struct fsl_qdma_engine *fsl_qdma = platform_get_drvdata(pdev);
> > +
> > +   of_dma_controller_free(np);
> > +   dma_async_device_unregister(_qdma->dma_dev);
> 
> And as i said above, the irq is left enabled, pls free that up
[Yuan Yao] Ok, Thanks.
> 
> > +static int __init fsl_qdma_init(void) {
> > +   return platform_driver_register(_qdma_driver);
> > +}
> > +subsys_initcall(fsl_qdma_init);
> > +
> > +static void __exit fsl_qdma_exit(void) {
> > +   platform_driver_unregister(_qdma_driver);
> > +}
> > +module_exit(fsl_qdma_exit);
> 
> module_platform_driver please
[Yuan Yao] Ok ,thanks.
> 
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

On Wed, 2015-11-11 at 11:51 -0600, Han Xu wrote:
> On Fri, Oct 30, 2015 at 04:49:41AM -0500, Yuan Yao-B46683 wrote:
> > Hi Fabio Estevam,
> >
> > Thanks for your suggestion.
> > We have an internal discussions for that.
> >
> > We think that:
> > According to the initial commit message of regmap, it is targeting non-
> memory mapped buses. (regmap: Add generic non-memory mapped register
> access API)  But in the imx2_wdt driver, it is used for memory-mapped register
> space.  So it seems that using such a complex framework just to deal with
> endian is an over-kill.
> >
> > when it is not necessary to enable the clock every time we access the 
> > register.
> > We don't think it is obvious to us how to use it for handling endianness,
> especially not the way imx2_wdt uses regmap.  __regmap_init_mmio_clk()
> calls regmap_mmio_gen_context() which errors out if reg_format_endian is
> not REGMAP_ENDIAN_DEFAULT or REGMAP_ENDIAN_NATIVE, and elsewhere
> regmap-mmio.c It seems only little-endian accessors.
> >
> > Although it is possible to add the endianness support in the
> > regmap_mmio driver, we don't see too much value in using it especially
> >
> > So we think:
> > static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > *addr) {
> >   if (q->big_endian)
> >   iowrite32be(val, addr);
> >   else
> >   iowrite32(val, addr);
> > }
> > This way is an easier, more effective solution to do the endian issue.
> >
> > How about your think?
> 
> I think the implement is fine, but I prefer to use quirk rather than read 
> from dts?
> Please also rebase the patch to latest l2-mtd code.
> 

Ok, I will rebase the patch to latest l2-mtd code in the next version.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

On Wed, 2015-11-11 at 11:51 -0600, Han Xu wrote:
> On Fri, Oct 30, 2015 at 04:49:41AM -0500, Yuan Yao-B46683 wrote:
> > Hi Fabio Estevam,
> >
> > Thanks for your suggestion.
> > We have an internal discussions for that.
> >
> > We think that:
> > According to the initial commit message of regmap, it is targeting non-
> memory mapped buses. (regmap: Add generic non-memory mapped register
> access API)  But in the imx2_wdt driver, it is used for memory-mapped register
> space.  So it seems that using such a complex framework just to deal with
> endian is an over-kill.
> >
> > when it is not necessary to enable the clock every time we access the 
> > register.
> > We don't think it is obvious to us how to use it for handling endianness,
> especially not the way imx2_wdt uses regmap.  __regmap_init_mmio_clk()
> calls regmap_mmio_gen_context() which errors out if reg_format_endian is
> not REGMAP_ENDIAN_DEFAULT or REGMAP_ENDIAN_NATIVE, and elsewhere
> regmap-mmio.c It seems only little-endian accessors.
> >
> > Although it is possible to add the endianness support in the
> > regmap_mmio driver, we don't see too much value in using it especially
> >
> > So we think:
> > static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > *addr) {
> >   if (q->big_endian)
> >   iowrite32be(val, addr);
> >   else
> >   iowrite32(val, addr);
> > }
> > This way is an easier, more effective solution to do the endian issue.
> >
> > How about your think?
> 
> I think the implement is fine, but I prefer to use quirk rather than read 
> from dts?
> Please also rebase the patch to latest l2-mtd code.
> 

Ok, I will rebase the patch to latest l2-mtd code in the next version.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 1/3] dma: Add Freescale qDMA engine driver support

[Yao Yuan]

On Wed, Nov 11, 2015 4:14 PM, Vinod Koul wrote:
> On Fri, Oct 23, 2015 at 09:59:11AM +0800, Yuan Yao wrote:
> 
> > +config FSL_QDMA
> > +   tristate "Freescale qDMA engine support"
> > +   depends on SOC_LS1021A || ARCH_LAYERSCAPE
> 
> Where is this ARCH defined, quick grep revealed none
> 
This is a generic  family naming for freescale a set of ARMv8 based SoCs.
The patch is merged in arm soc but not yet merge into Linux next.

> > +static void fsl_qdma_set_tcd_params(struct fsl_qdma_chan *fsl_chan,
> > +   u64 src, u64 dst, u32 nbytes)
> > +{
> > +   void __iomem *addr = fsl_chan->qdma->membase;
> > +   u32 reg;
> > +
> > +   /*
> > +* Source address.
> > +* Represents address bits 31-0 of a 49-bit source address.
> > +*/
> > +   qdma_writel(fsl_chan->qdma, (u32)src, addr + FSL_QDMA_DLSAR);
> > +   /*
> > +* Source address.
> > +* Represents address bits 47-32 of a 49-bit source address.
> > +*/
> > +   reg = qdma_readl(fsl_chan->qdma, addr + FSL_QDMA_DLSATR);
> > +   reg |= (u16)(src >> 32) & 0x;
> > +   reg |= FSL_QDMA_SRTTYPE_R_N;
> > +   qdma_writel(fsl_chan->qdma, reg, addr + FSL_QDMA_DLSATR);
> 
> How does this work on systems with enither endieness ?
[Yuan Yao] I'm sorry for confused. Is there any other endianness?
As I know in SOC_LS1021A and ARCH_LAYERSCAPE, there are just 32BE and 32LE for 
the register R/W.
> 
> Also why not use readq/writeq helpers, registers seem to be contagious
[Yuan Yao] It's hard to use readq/writeq because of the endianness.
> 
> > +static enum dma_status fsl_qdma_tx_status(struct dma_chan *chan,
> > +   dma_cookie_t cookie, struct dma_tx_state *txstate) {
> > +   return dma_cookie_status(chan, cookie, txstate);
> 
> No residue ?
[Yuan Yao] The QDMA is a strange DMA that I can't find any hardware interface 
to query the data transfer size.
> 
> > +static irqreturn_t fsl_qdma_controller_handler_err(int irq, void
> > +*dev_id) {
> > +   struct fsl_qdma_engine *fsl_qdma = dev_id;
> > +   u32 reg;
> > +
> > +   reg = qdma_readl(fsl_qdma, fsl_qdma->membase + FSL_QDMA_DLSR);
> > +
> > +   if (reg & FSL_QDMA_DLSR_TE) {
> > +   dev_err(fsl_qdma->dma_dev.dev,
> > +   "Transfer error. Check your address please!\n");
> 
> It would help to print the addresses...
[Yuan Yao] Ok, The bus address or the virtual address?
> 
> > +   ret = devm_request_irq(>dev, fsl_qdma-
> >controller_irq,
> > +   fsl_qdma_controller_handler, 0,
> > +   "qDMA controller", fsl_qdma);
> > +   if (ret) {
> > +   dev_err(>dev,
> > +   "Can't register qDMA controller IRQ.\n");
> > +   return  ret;
> > +   }
> > +
> > +   ret = devm_request_irq(>dev, fsl_qdma->err_irq,
> > +   fsl_qdma_controller_handler_err, 0,
> > +   "qDMA err", fsl_qdma);
> > +   if (ret) {
> > +   dev_err(>dev, "Can't register qDMA err
> IRQ.\n");
> > +   return  ret;
> > +   }
> 
> why do you want devm variant here..?
[Yuan Yao] There is a different err IRQ in some SOCs. So I should do like this 
to support those different hardware. 
> 
> > +   dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> > +   dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> > +
> > +   fsl_qdma->dma_dev.dev = >dev;
> > +   fsl_qdma->dma_dev.device_free_chan_resources
> > +   = fsl_qdma_free_chan_resources;
> > +   fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> > +   fsl_qdma->dma_dev.device_prep_dma_memcpy =
> fsl_qdma_prep_memcpy;
> > +   fsl_qdma->dma_dev.device_issue_pending =
> fsl_qdma_issue_pending;
> 
> No terminate_all callback?
[Yuan Yao] QDMA is such a strange DMA that I can't find any hardware interface 
to stop a  in progress transmission.
> 
> > +static int fsl_qdma_remove(struct platform_device *pdev) {
> > +   struct device_node *np = pdev->dev.of_node;
> > +   struct fsl_qdma_engine *fsl_qdma = platform_get_drvdata(pdev);
> > +
> > +   of_dma_controller_free(np);
> > +   dma_async_device_unregister(_qdma->dma_dev);
> 
> And as i said above, the irq is left enabled, pls free that up
[Yuan Yao] Ok, Thanks.
> 
> > +static int __init fsl_qdma_init(void) {
> > +   return platform_driver_register(_qdma_driver);
> > +}
> > +subsys_initcall(fsl_qdma_init);
> > +
> > +static void __exit fsl_qdma_exit(void) {
> > +   platform_driver_unregister(_qdma_driver);
> > +}
> > +module_exit(fsl_qdma_exit);
> 
> module_platform_driver please
[Yuan Yao] Ok ,thanks.
> 
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Fabio Estevam,

Thanks for your suggestion.
We have an internal discussions for that.

We think that:
According to the initial commit message of regmap, it is targeting non-memory 
mapped buses. (regmap: Add generic non-memory mapped register access API)  But 
in the imx2_wdt driver, it is used for memory-mapped register space.  So it 
seems that using such a complex framework just to deal with endian is an 
over-kill.

when it is not necessary to enable the clock every time we access the register. 
 
We don't think it is obvious to us how to use it for handling endianness, 
especially not the way imx2_wdt uses regmap.  __regmap_init_mmio_clk() calls 
regmap_mmio_gen_context() which errors out if reg_format_endian is not 
REGMAP_ENDIAN_DEFAULT or REGMAP_ENDIAN_NATIVE, and elsewhere regmap-mmio.c It 
seems only little-endian accessors.

Although it is possible to add the endianness support in the regmap_mmio 
driver, we don't see too much value in using it especially 

So we think:
static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
*addr) {
  if (q->big_endian)
  iowrite32be(val, addr);
  else
  iowrite32(val, addr);
}
This way is an easier, more effective solution to do the endian issue.

How about your think?

Best Regards,
Yuan Yao

On Sat, Oct 24, 2015 at 11:47 PM, Fabio Estevam  wrote:
> On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao  wrote:
> 
> > +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > +*addr) {
> > +   if (q->big_endian)
> > +   iowrite32be(val, addr);
> > +   else
> > +   iowrite32(val, addr);
> > +}
> 
> I suggest you to implement regmap support for this driver instead.
> 
> Take a look at drivers/watchdog/imx2_wdt.c for a reference.
> 
> Then you only need to pass 'big-endian' as a property for the qspi in the 
> .dtsi
> file and regmap core will take care of endianness.

RE: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Fabio Estevam,

Thanks for your suggestion.
We have an internal discussions for that.

We think that:
According to the initial commit message of regmap, it is targeting non-memory 
mapped buses. (regmap: Add generic non-memory mapped register access API)  But 
in the imx2_wdt driver, it is used for memory-mapped register space.  So it 
seems that using such a complex framework just to deal with endian is an 
over-kill.

when it is not necessary to enable the clock every time we access the register. 
 
We don't think it is obvious to us how to use it for handling endianness, 
especially not the way imx2_wdt uses regmap.  __regmap_init_mmio_clk() calls 
regmap_mmio_gen_context() which errors out if reg_format_endian is not 
REGMAP_ENDIAN_DEFAULT or REGMAP_ENDIAN_NATIVE, and elsewhere regmap-mmio.c It 
seems only little-endian accessors.

Although it is possible to add the endianness support in the regmap_mmio 
driver, we don't see too much value in using it especially 

So we think:
static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
*addr) {
  if (q->big_endian)
  iowrite32be(val, addr);
  else
  iowrite32(val, addr);
}
This way is an easier, more effective solution to do the endian issue.

How about your think?

Best Regards,
Yuan Yao

On Sat, Oct 24, 2015 at 11:47 PM, Fabio Estevam  wrote:
> On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao  wrote:
> 
> > +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > +*addr) {
> > +   if (q->big_endian)
> > +   iowrite32be(val, addr);
> > +   else
> > +   iowrite32(val, addr);
> > +}
> 
> I suggest you to implement regmap support for this driver instead.
> 
> Take a look at drivers/watchdog/imx2_wdt.c for a reference.
> 
> Then you only need to pass 'big-endian' as a property for the qspi in the 
> .dtsi
> file and regmap core will take care of endianness.

RE: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

Thanks for your review.
I did the test and it seems that it should be ok when CONFIG_PM is not defined.
So I removed the protection code to make it more readable.
Do you think is it ok?

Best Regards,
Yuan Yao

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, October 27, 2015 10:01 AM
> To: Yuan Yao-B46683 
> Cc: ste...@agner.ch; a...@arndb.de; dan.j.willi...@intel.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume
> support
> 
> On Mon, Oct 19, 2015 at 04:31:05PM +0800, Yuan Yao wrote:
> 
> The patch overall looks fine, but
> >
> > +static int fsl_edma_suspend_late(struct device *dev)
> 
> This needs protection and will have build failure when CONFIG_PM is not
> defined
> 
> > +{
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   unsigned long flags;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   spin_lock_irqsave(_chan->vchan.lock, flags);
> > +   /* Make sure chan is idle or will force disable. */
> > +   if (unlikely(!fsl_chan->idle)) {
> > +   dev_warn(dev, "WARN: There is non-idle channel.");
> > +   fsl_edma_disable_request(fsl_chan);
> > +   fsl_edma_chan_mux(fsl_chan, 0, false);
> > +   }
> > +
> > +   fsl_chan->pm_state = SUSPENDED;
> > +   spin_unlock_irqrestore(_chan->vchan.lock, flags);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int fsl_edma_resume_early(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   fsl_chan->pm_state = RUNNING;
> > +   edma_writew(fsl_edma, 0x0, fsl_edma->membase +
> EDMA_TCD_CSR(i));
> > +   if (fsl_chan->slave_id != 0)
> > +   fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id,
> true);
> > +   }
> > +
> > +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> > +   fsl_edma->membase + EDMA_CR);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct dev_pm_ops fsl_edma_pm_ops = {
> > +   .suspend_late   = fsl_edma_suspend_late,
> > +   .resume_early   = fsl_edma_resume_early,
> > +};
> 
> This one too, also why use late and early, pls add the note here
> 
> >  static const struct of_device_id fsl_edma_dt_ids[] = {
> > { .compatible = "fsl,vf610-edma", },
> > { /* sentinel */ }
> > @@ -969,6 +1042,7 @@ static struct platform_driver fsl_edma_driver = {
> > .driver = {
> > .name   = "fsl-edma",
> > .of_match_table = fsl_edma_dt_ids,
> > +   .pm = _edma_pm_ops,
> This will fail too if CONFIG_PM is not defined
> 
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

Thanks for your review.
I did the test and it seems that it should be ok when CONFIG_PM is not defined.
So I removed the protection code to make it more readable.
Do you think is it ok?

Best Regards,
Yuan Yao

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, October 27, 2015 10:01 AM
> To: Yuan Yao-B46683 
> Cc: ste...@agner.ch; a...@arndb.de; dan.j.willi...@intel.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume
> support
> 
> On Mon, Oct 19, 2015 at 04:31:05PM +0800, Yuan Yao wrote:
> 
> The patch overall looks fine, but
> >
> > +static int fsl_edma_suspend_late(struct device *dev)
> 
> This needs protection and will have build failure when CONFIG_PM is not
> defined
> 
> > +{
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   unsigned long flags;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   spin_lock_irqsave(_chan->vchan.lock, flags);
> > +   /* Make sure chan is idle or will force disable. */
> > +   if (unlikely(!fsl_chan->idle)) {
> > +   dev_warn(dev, "WARN: There is non-idle channel.");
> > +   fsl_edma_disable_request(fsl_chan);
> > +   fsl_edma_chan_mux(fsl_chan, 0, false);
> > +   }
> > +
> > +   fsl_chan->pm_state = SUSPENDED;
> > +   spin_unlock_irqrestore(_chan->vchan.lock, flags);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int fsl_edma_resume_early(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   fsl_chan->pm_state = RUNNING;
> > +   edma_writew(fsl_edma, 0x0, fsl_edma->membase +
> EDMA_TCD_CSR(i));
> > +   if (fsl_chan->slave_id != 0)
> > +   fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id,
> true);
> > +   }
> > +
> > +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> > +   fsl_edma->membase + EDMA_CR);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct dev_pm_ops fsl_edma_pm_ops = {
> > +   .suspend_late   = fsl_edma_suspend_late,
> > +   .resume_early   = fsl_edma_resume_early,
> > +};
> 
> This one too, also why use late and early, pls add the note here
> 
> >  static const struct of_device_id fsl_edma_dt_ids[] = {
> > { .compatible = "fsl,vf610-edma", },
> > { /* sentinel */ }
> > @@ -969,6 +1042,7 @@ static struct platform_driver fsl_edma_driver = {
> > .driver = {
> > .name   = "fsl-edma",
> > .of_match_table = fsl_edma_dt_ids,
> > +   .pm = _edma_pm_ops,
> This will fail too if CONFIG_PM is not defined
> 
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] dma: Add Freescale qDMA engine driver support

[Yao Yuan]

Hi Vinod,

Thanks for your review, please see my comments inline.

Best Regards,
Yuan Yao

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Monday, October 05, 2015 10:37 PM
> To: Yuan Yao-B46683 
> Cc: shawn@linaro.org; dan.j.willi...@intel.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH 1/2] dma: Add Freescale qDMA engine driver support
> 
> On Fri, Sep 11, 2015 at 01:53:52PM +0800, Yuan Yao wrote:
> 
> > +Examples:
> > +
> > +   qdma: qdma@839 {
> > +   compatible = "fsl,ls-qdma";
> > +   reg = <0x0 0x838 0x0 0x2>;
> > +   interrupts = ,
> > +   ;
> > +   interrupt-names = "qdma-tx", "qdma-err";
> > +   big-endian;
> > +   channels = <1>;
> > +   };
> 
> Binding should be a separate patch
[Yuan Yao] 
Ok, Thanks.

> 
> > +FREESCALE qDMA DRIVER
> > +M: Yuan Yao 
> > +L: linux-arm-ker...@lists.infradead.org
> 
> not dmaengine ML ?
[Yuan Yao] Ok, Thanks.

> 
> 
> > +config FSL_QDMA
> > +   tristate "Freescale qDMA engine support"
> > +   select DMA_ENGINE
> > +   select DMA_VIRTUAL_CHANNELS
> 
> No depends on arch, can it work on x86?
[Yuan Yao] Ok, Thanks.

> 
> > +static int fsl_qdma_alloc_chan_resources(struct dma_chan *chan) {
> > +   struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
> > +
> > +   fsl_chan->desc = NULL;
> > +   return 0;
> > +}
> 
> why do you need this it seems to do nothing
[Yuan Yao] I will remove it.

> 
> > +static struct fsl_qdma_desc *fsl_qdma_alloc_desc(struct fsl_qdma_chan
> > +*fsl_chan) {
> > +   struct fsl_qdma_desc *fsl_desc;
> > +
> > +   fsl_desc = kzalloc(sizeof(*fsl_desc), GFP_NOWAIT);
> > +
> 
> empty line here is not required
> 
> > +   if (!fsl_desc)
> > +   return NULL;
> > +
> > +   fsl_desc->qchan = fsl_chan;
> > +
> > +   return fsl_desc;
> 
> why not return fsl_desc->qchan ;
> 
[Yuan Yao] 
I still need some data in fsl_desc. So I have to return fsl_desc  here.

> 
> > +   dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> > +   dma_cap_set(DMA_SLAVE, fsl_qdma->dma_dev.cap_mask);
> > +   dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> > +
> > +   fsl_qdma->dma_dev.dev = >dev;
> > +   fsl_qdma->dma_dev.device_alloc_chan_resources
> > +   = fsl_qdma_alloc_chan_resources;
> > +   fsl_qdma->dma_dev.device_free_chan_resources
> > +   = fsl_qdma_free_chan_resources;
> > +   fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> > +   fsl_qdma->dma_dev.device_prep_dma_memcpy =
> fsl_qdma_prep_memcpy;
> > +   fsl_qdma->dma_dev.device_issue_pending =
> fsl_qdma_issue_pending;
> 
> You claim DMA_SLAVE but no prep_ for that?
> 
[Yuan Yao] It's a mistake. I will remove it.\

> > +
> > +static int __init fsl_qdma_init(void) {
> > +   return platform_driver_register(_qdma_driver);
> > +}
> > +subsys_initcall(fsl_qdma_init);
> why subsys_init?
> 
[Yuan Yao] For a preventive, some driver base on DMA, QDMA have to initialize 
earlier than them.
Even now there is no kernel driver base on QDMA, But I still think the 
subsys_init is better.

> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] dma: Add Freescale qDMA engine driver support

[Yao Yuan]

Hi Vinod,

Thanks for your review, please see my comments inline.

Best Regards,
Yuan Yao

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Monday, October 05, 2015 10:37 PM
> To: Yuan Yao-B46683 
> Cc: shawn@linaro.org; dan.j.willi...@intel.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH 1/2] dma: Add Freescale qDMA engine driver support
> 
> On Fri, Sep 11, 2015 at 01:53:52PM +0800, Yuan Yao wrote:
> 
> > +Examples:
> > +
> > +   qdma: qdma@839 {
> > +   compatible = "fsl,ls-qdma";
> > +   reg = <0x0 0x838 0x0 0x2>;
> > +   interrupts = ,
> > +   ;
> > +   interrupt-names = "qdma-tx", "qdma-err";
> > +   big-endian;
> > +   channels = <1>;
> > +   };
> 
> Binding should be a separate patch
[Yuan Yao] 
Ok, Thanks.

> 
> > +FREESCALE qDMA DRIVER
> > +M: Yuan Yao 
> > +L: linux-arm-ker...@lists.infradead.org
> 
> not dmaengine ML ?
[Yuan Yao] Ok, Thanks.

> 
> 
> > +config FSL_QDMA
> > +   tristate "Freescale qDMA engine support"
> > +   select DMA_ENGINE
> > +   select DMA_VIRTUAL_CHANNELS
> 
> No depends on arch, can it work on x86?
[Yuan Yao] Ok, Thanks.

> 
> > +static int fsl_qdma_alloc_chan_resources(struct dma_chan *chan) {
> > +   struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
> > +
> > +   fsl_chan->desc = NULL;
> > +   return 0;
> > +}
> 
> why do you need this it seems to do nothing
[Yuan Yao] I will remove it.

> 
> > +static struct fsl_qdma_desc *fsl_qdma_alloc_desc(struct fsl_qdma_chan
> > +*fsl_chan) {
> > +   struct fsl_qdma_desc *fsl_desc;
> > +
> > +   fsl_desc = kzalloc(sizeof(*fsl_desc), GFP_NOWAIT);
> > +
> 
> empty line here is not required
> 
> > +   if (!fsl_desc)
> > +   return NULL;
> > +
> > +   fsl_desc->qchan = fsl_chan;
> > +
> > +   return fsl_desc;
> 
> why not return fsl_desc->qchan ;
> 
[Yuan Yao] 
I still need some data in fsl_desc. So I have to return fsl_desc  here.

> 
> > +   dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> > +   dma_cap_set(DMA_SLAVE, fsl_qdma->dma_dev.cap_mask);
> > +   dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> > +
> > +   fsl_qdma->dma_dev.dev = >dev;
> > +   fsl_qdma->dma_dev.device_alloc_chan_resources
> > +   = fsl_qdma_alloc_chan_resources;
> > +   fsl_qdma->dma_dev.device_free_chan_resources
> > +   = fsl_qdma_free_chan_resources;
> > +   fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> > +   fsl_qdma->dma_dev.device_prep_dma_memcpy =
> fsl_qdma_prep_memcpy;
> > +   fsl_qdma->dma_dev.device_issue_pending =
> fsl_qdma_issue_pending;
> 
> You claim DMA_SLAVE but no prep_ for that?
> 
[Yuan Yao] It's a mistake. I will remove it.\

> > +
> > +static int __init fsl_qdma_init(void) {
> > +   return platform_driver_register(_qdma_driver);
> > +}
> > +subsys_initcall(fsl_qdma_init);
> why subsys_init?
> 
[Yuan Yao] For a preventive, some driver base on DMA, QDMA have to initialize 
earlier than them.
Even now there is no kernel driver base on QDMA, But I still think the 
subsys_init is better.

> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] arm/dts: Add node for ina220 on LS1021ATWR

[Yao Yuan]

Thanks for your review. I will be care for other patches. 

Best Regards,
Yuan Yao

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Thursday, September 24, 2015 8:05 PM
> To: Yuan Yao-B46683 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Jia
> Hongtao-B38951 
> Subject: Re: [PATCH] arm/dts: Add node for ina220 on LS1021ATWR
> 
> On Wed, Sep 16, 2015 at 04:20:43PM +0800, Yuan Yao wrote:
> > The INA220 monitors both shunt drop and supply voltage.
> >
> > Signed-off-by: Yuan Yao 
> 
> For sake of consistency, the subject prefix of dts patches that I collect 
> should
> be like "ARM: dts: ...".  I changed prefix and applied patch.
> 
> Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] arm/dts: Add node for ina220 on LS1021ATWR

[Yao Yuan]

Thanks for your review. I will be care for other patches. 

Best Regards,
Yuan Yao

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Thursday, September 24, 2015 8:05 PM
> To: Yuan Yao-B46683 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Jia
> Hongtao-B38951 
> Subject: Re: [PATCH] arm/dts: Add node for ina220 on LS1021ATWR
> 
> On Wed, Sep 16, 2015 at 04:20:43PM +0800, Yuan Yao wrote:
> > The INA220 monitors both shunt drop and supply voltage.
> >
> > Signed-off-by: Yuan Yao 
> 
> For sake of consistency, the subject prefix of dts patches that I collect 
> should
> be like "ARM: dts: ...".  I changed prefix and applied patch.
> 
> Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote:
> On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote:
> > >> Think of it from the end user perspective. Would you like your
> > >> laptop (or
> > >> whatever) to refuse to suspend because of this condition? The user
> > >> may well expect that closing the lid on their laptop will reliably
> > >> lead to it suspending to ram. Returning a failure here could result
> > >> in a loss of data if the condition is not detected and the machine
> subsequently runs out of power.
> > >>
> > >
> > > Yes, the user may well expect that closing the lid on their laptop will 
> > > reliably
> lead to it suspending to ram.
> > > So the client(the user of the DMA) must  to PAUSE or terminate the DMA
> transmission.
> > >
> > > We need to rely on client doing the right thing here.
> > > The DMA should not make a decision instead of client.
> > > If the DMA is not idle in DMA suspend, it should be the client's issue.
> > > We don't know what the client really want to do, so just return the non-
> success value.
> >
> > The problem here is that neither the client nor the DMA controller
> > driver should easily decide to stop the suspend entrance and rollback.
> > I don't think the non-idle situation is serious enough to cause a
> > rollback.  You should do whatever can be done with the DMA
> > controller(such as stop the controller and leave whatever to be done
> > to the wake up) and continue with the suspend.
> 
> Ideally yes client should suspend first and dmaengine driver then being idle
> when suspend is invoked. But we know we are in idle world!
> So, driver should ensure it suspends the active channels and then goes to
> suspend and restores that on resume
> 

Hi Vinod, 
Hi Leo,

Is there any other discussions?

I think we can have the following solutions for DMA driver:
1, Force terminate the active channels in its suspend and then return.
2, DMA have to wait until the active channels idle.
3, Don't care about the active channels and direct return.
4, Return BUS BUSY error and stop PM progress.


I prefer the last one, because I think client should make sure the channel is 
idle. 

But also the first one should be works.

Can we have a conclusion and suggestion for which one is better?

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote:
> On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote:
> > >> Think of it from the end user perspective. Would you like your
> > >> laptop (or
> > >> whatever) to refuse to suspend because of this condition? The user
> > >> may well expect that closing the lid on their laptop will reliably
> > >> lead to it suspending to ram. Returning a failure here could result
> > >> in a loss of data if the condition is not detected and the machine
> subsequently runs out of power.
> > >>
> > >
> > > Yes, the user may well expect that closing the lid on their laptop will 
> > > reliably
> lead to it suspending to ram.
> > > So the client(the user of the DMA) must  to PAUSE or terminate the DMA
> transmission.
> > >
> > > We need to rely on client doing the right thing here.
> > > The DMA should not make a decision instead of client.
> > > If the DMA is not idle in DMA suspend, it should be the client's issue.
> > > We don't know what the client really want to do, so just return the non-
> success value.
> >
> > The problem here is that neither the client nor the DMA controller
> > driver should easily decide to stop the suspend entrance and rollback.
> > I don't think the non-idle situation is serious enough to cause a
> > rollback.  You should do whatever can be done with the DMA
> > controller(such as stop the controller and leave whatever to be done
> > to the wake up) and continue with the suspend.
> 
> Ideally yes client should suspend first and dmaengine driver then being idle
> when suspend is invoked. But we know we are in idle world!
> So, driver should ensure it suspends the active channels and then goes to
> suspend and restores that on resume
> 

Hi Vinod, 
Hi Leo,

Is there any other discussions?

I think we can have the following solutions for DMA driver:
1, Force terminate the active channels in its suspend and then return.
2, DMA have to wait until the active channels idle.
3, Don't care about the active channels and direct return.
4, Return BUS BUSY error and stop PM progress.


I prefer the last one, because I think client should make sure the channel is 
idle. 

But also the first one should be works.

Can we have a conclusion and suggestion for which one is better?

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Nigel,

On Mon, Aug 17, 2015 at 2:49 PM, Nigel Cunningham < 
ni...@nigelcunningham.com.au > wrote:
> On 17/08/15 13:59, Yao Yuan wrote:
> > On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku@gmail.com > wrote:
> >> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan  wrote:
> >>> Hi Leo,
> >>>
> >>> Thanks for your review.
> >>> About those two methods for DMA suspend that you have mentioned.
> We
> >> have a lot of the discussions in other DMA driver like DMA for
> >> Freescale PowerPC.
> >>> Finally, we think the device which used the DMA transmission service
> >>> should
> >> cancel the transmission service in its suspend.
> >>> So DMA in suspend should be idle.
> >> If that's the case you should clearly state this in the commit
> >> message and in code, although I don't know if it is safe to make such
> >> assumption.  There could be user of the DMA that doesn't track the
> completion of transfers.
> > I think it should be safe. In my opinion, even some client(the user of
> > the DMA) forget to cancel its DMA transmission, It will just lead to PM 
> > failed
> but no other system and data risk.
> > Although we should first fix the behavior of the client.
> > Once you are no need the DMA transmission, why not stop it?
> >
> > Is it right?
> Think of it from the end user perspective. Would you like your laptop (or
> whatever) to refuse to suspend because of this condition? The user may well
> expect that closing the lid on their laptop will reliably lead to it 
> suspending to
> ram. Returning a failure here could result in a loss of data if the condition 
> is not
> detected and the machine subsequently runs out of power.
> 

Yes, the user may well expect that closing the lid on their laptop will 
reliably lead to it suspending to ram.
So the client(the user of the DMA) must  to PAUSE or terminate the DMA 
transmission.

We need to rely on client doing the right thing here. 
The DMA should not make a decision instead of client.
If the DMA is not idle in DMA suspend, it should be the client's issue.
We don't know what the client really want to do, so just return the non-success 
value.

> I do agree that whatever is submitting DMA should be stopped first; ideally 
> this
> driver would always be idle because whatever producers of work exist would
> already have been quiesced and output flushed.
> 

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Nigel,

On Mon, Aug 17, 2015 at 2:49 PM, Nigel Cunningham  
ni...@nigelcunningham.com.au  wrote:
 On 17/08/15 13:59, Yao Yuan wrote:
  On Sat, Aug 15, 2015 at 7:48 AM, pku.leo  pku@gmail.com  wrote:
  On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan yao.y...@freescale.com wrote:
  Hi Leo,
 
  Thanks for your review.
  About those two methods for DMA suspend that you have mentioned.
 We
  have a lot of the discussions in other DMA driver like DMA for
  Freescale PowerPC.
  Finally, we think the device which used the DMA transmission service
  should
  cancel the transmission service in its suspend.
  So DMA in suspend should be idle.
  If that's the case you should clearly state this in the commit
  message and in code, although I don't know if it is safe to make such
  assumption.  There could be user of the DMA that doesn't track the
 completion of transfers.
  I think it should be safe. In my opinion, even some client(the user of
  the DMA) forget to cancel its DMA transmission, It will just lead to PM 
  failed
 but no other system and data risk.
  Although we should first fix the behavior of the client.
  Once you are no need the DMA transmission, why not stop it?
 
  Is it right?
 Think of it from the end user perspective. Would you like your laptop (or
 whatever) to refuse to suspend because of this condition? The user may well
 expect that closing the lid on their laptop will reliably lead to it 
 suspending to
 ram. Returning a failure here could result in a loss of data if the condition 
 is not
 detected and the machine subsequently runs out of power.
 

Yes, the user may well expect that closing the lid on their laptop will 
reliably lead to it suspending to ram.
So the client(the user of the DMA) must  to PAUSE or terminate the DMA 
transmission.

We need to rely on client doing the right thing here. 
The DMA should not make a decision instead of client.
If the DMA is not idle in DMA suspend, it should be the client's issue.
We don't know what the client really want to do, so just return the non-success 
value.

 I do agree that whatever is submitting DMA should be stopped first; ideally 
 this
 driver would always be idle because whatever producers of work exist would
 already have been quiesced and output flushed.
 

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku@gmail.com > wrote:
> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan  wrote:
> > Hi Leo,
> >
> > Thanks for your review.
> > About those two methods for DMA suspend that you have mentioned. We
> have a lot of the discussions in other DMA driver like DMA for Freescale
> PowerPC.
> >
> > Finally, we think the device which used the DMA transmission service should
> cancel the transmission service in its suspend.
> > So DMA in suspend should be idle.
> 
> If that's the case you should clearly state this in the commit message and in
> code, although I don't know if it is safe to make such assumption.  There 
> could
> be user of the DMA that doesn't track the completion of transfers.

I think it should be safe. In my opinion, even some client(the user of the DMA) 
forget to cancel its DMA transmission,
It will just lead to PM failed but no other system and data risk.
Although we should first fix the behavior of the client.
Once you are no need the DMA transmission, why not stop it?

Is it right?

> >
> > Once the DMA in late_suspend is not be idle, we think some driver haven't
> canceled the DMA transmission. So maybe something is error when other
> driver in suspend.
> >
> > In the case, we should return failed to stop PM. DMA should not make a
> choice for other drivers(which used DMA) to force stop DMA transmission.
> 
> The suspend entrance should be terminated by wakeup events and only critical
> issues.  I don't think we should just terminate the suspend entrance just
> because having on-going I/O without even try to stop it.

The graceful behavior would be to for client to PAUSE or terminate and then 
suspend
followed by DMA suspend.
We need to rely on client doing the right thing here. 
The DMA should not make a decision instead of client.
If the DMA is not idle in DMA suspend, it should be the client's issue.
We don't know what the client really want to do, so just return the non-success 
value.

I'm not sure my description is clear.  So we may refer the discussion about the 
DMA PM support before.
Such as "DMA: Freescale: add suspend resume functions for DMA driver"

Like:https://lkml.org/lkml/2014/5/21/1

> >
> > Thanks.
> >
> > Best Regards,
> > Yuan Yao
> >
> >> -Original Message-
> >> From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li
> >> Yang
> >> Sent: Friday, August 14, 2015 4:58 AM
> >> To: Yuan Yao-B46683
> >> Cc: Vinod Koul; ste...@agner.ch; Arnd Bergmann; Dan Williams;
> >> dmaeng...@vger.kernel.org; lkml;
> >> linux-arm-ker...@lists.infradead.org; linux- p...@vger.kernel.org
> >> Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume
> >> support
> >>
> >> On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao  wrote:
> >> > This add power management suspend/resume support for the fsl-edma
> >> > driver.
> >> >
> >> > eDMA acted as a basic function used by others. What it needs to do
> >> > is the two steps below to support power management.
> >> >
> >> > In fsl_edma_suspend_late:
> >> > Check whether the DMA chan is idle and if it is not idle, stop PM
> >> > operation.
> >>
> >> You should try to quiesce the device on suspend instead of depending
> >> on itself to be happen in idle and failing if it is not.
> >>
> >> Regards,
> >> Leo
> 
> 
> 
> --
> - Leo

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

On Sat, Aug 15, 2015 at 7:48 AM, pku.leo  pku@gmail.com  wrote:
 On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan yao.y...@freescale.com wrote:
  Hi Leo,
 
  Thanks for your review.
  About those two methods for DMA suspend that you have mentioned. We
 have a lot of the discussions in other DMA driver like DMA for Freescale
 PowerPC.
 
  Finally, we think the device which used the DMA transmission service should
 cancel the transmission service in its suspend.
  So DMA in suspend should be idle.
 
 If that's the case you should clearly state this in the commit message and in
 code, although I don't know if it is safe to make such assumption.  There 
 could
 be user of the DMA that doesn't track the completion of transfers.

I think it should be safe. In my opinion, even some client(the user of the DMA) 
forget to cancel its DMA transmission,
It will just lead to PM failed but no other system and data risk.
Although we should first fix the behavior of the client.
Once you are no need the DMA transmission, why not stop it?

Is it right?

 
  Once the DMA in late_suspend is not be idle, we think some driver haven't
 canceled the DMA transmission. So maybe something is error when other
 driver in suspend.
 
  In the case, we should return failed to stop PM. DMA should not make a
 choice for other drivers(which used DMA) to force stop DMA transmission.
 
 The suspend entrance should be terminated by wakeup events and only critical
 issues.  I don't think we should just terminate the suspend entrance just
 because having on-going I/O without even try to stop it.

The graceful behavior would be to for client to PAUSE or terminate and then 
suspend
followed by DMA suspend.
We need to rely on client doing the right thing here. 
The DMA should not make a decision instead of client.
If the DMA is not idle in DMA suspend, it should be the client's issue.
We don't know what the client really want to do, so just return the non-success 
value.

I'm not sure my description is clear.  So we may refer the discussion about the 
DMA PM support before.
Such as DMA: Freescale: add suspend resume functions for DMA driver

Like:https://lkml.org/lkml/2014/5/21/1

 
  Thanks.
 
  Best Regards,
  Yuan Yao
 
  -Original Message-
  From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li
  Yang
  Sent: Friday, August 14, 2015 4:58 AM
  To: Yuan Yao-B46683
  Cc: Vinod Koul; ste...@agner.ch; Arnd Bergmann; Dan Williams;
  dmaeng...@vger.kernel.org; lkml;
  linux-arm-ker...@lists.infradead.org; linux- p...@vger.kernel.org
  Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume
  support
 
  On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao yao.y...@freescale.com wrote:
   This add power management suspend/resume support for the fsl-edma
   driver.
  
   eDMA acted as a basic function used by others. What it needs to do
   is the two steps below to support power management.
  
   In fsl_edma_suspend_late:
   Check whether the DMA chan is idle and if it is not idle, stop PM
   operation.
 
  You should try to quiesce the device on suspend instead of depending
  on itself to be happen in idle and failing if it is not.
 
  Regards,
  Leo
 
 
 
 --
 - Leo

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Leo,

Thanks for your review.
About those two methods for DMA suspend that you have mentioned. We have a lot 
of the discussions in other DMA driver like DMA for Freescale PowerPC.

Finally, we think the device which used the DMA transmission service should 
cancel the transmission service in its suspend. 
So DMA in suspend should be idle.

Once the DMA in late_suspend is not be idle, we think some driver haven't 
canceled the DMA transmission. So maybe something is error when other driver in 
suspend.

In the case, we should return failed to stop PM. DMA should not make a choice 
for other drivers(which used DMA) to force stop DMA transmission.

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li Yang
> Sent: Friday, August 14, 2015 4:58 AM
> To: Yuan Yao-B46683
> Cc: Vinod Koul; ste...@agner.ch; Arnd Bergmann; Dan Williams;
> dmaeng...@vger.kernel.org; lkml; linux-arm-ker...@lists.infradead.org; linux-
> p...@vger.kernel.org
> Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume
> support
> 
> On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao  wrote:
> > This add power management suspend/resume support for the fsl-edma
> > driver.
> >
> > eDMA acted as a basic function used by others. What it needs to do is
> > the two steps below to support power management.
> >
> > In fsl_edma_suspend_late:
> > Check whether the DMA chan is idle and if it is not idle, stop PM
> > operation.
> 
> You should try to quiesce the device on suspend instead of depending on itself
> to be happen in idle and failing if it is not.
> 
> Regards,
> Leo

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Leo,

Thanks for your review.
About those two methods for DMA suspend that you have mentioned. We have a lot 
of the discussions in other DMA driver like DMA for Freescale PowerPC.

Finally, we think the device which used the DMA transmission service should 
cancel the transmission service in its suspend. 
So DMA in suspend should be idle.

Once the DMA in late_suspend is not be idle, we think some driver haven't 
canceled the DMA transmission. So maybe something is error when other driver in 
suspend.

In the case, we should return failed to stop PM. DMA should not make a choice 
for other drivers(which used DMA) to force stop DMA transmission.

Thanks.

Best Regards,
Yuan Yao

 -Original Message-
 From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li Yang
 Sent: Friday, August 14, 2015 4:58 AM
 To: Yuan Yao-B46683
 Cc: Vinod Koul; ste...@agner.ch; Arnd Bergmann; Dan Williams;
 dmaeng...@vger.kernel.org; lkml; linux-arm-ker...@lists.infradead.org; linux-
 p...@vger.kernel.org
 Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume
 support
 
 On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao yao.y...@freescale.com wrote:
  This add power management suspend/resume support for the fsl-edma
  driver.
 
  eDMA acted as a basic function used by others. What it needs to do is
  the two steps below to support power management.
 
  In fsl_edma_suspend_late:
  Check whether the DMA chan is idle and if it is not idle, stop PM
  operation.
 
 You should try to quiesce the device on suspend instead of depending on itself
 to be happen in idle and failing if it is not.
 
 Regards,
 Leo

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod, 

After our discuss, I have already send the v2.
Could you please take some times help to review this patch again? 
Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Yuan Yao
> Sent: Tuesday, July 21, 2015 4:57 PM
> To: vinod.k...@intel.com; ste...@agner.ch; a...@arndb.de
> Cc: dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support
> 
> This add power management suspend/resume support for the fsl-edma driver.
> 
> eDMA acted as a basic function used by others. What it needs to do is the two
> steps below to support power management.
> 
> In fsl_edma_suspend_late:
> Check whether the DMA chan is idle and if it is not idle, stop PM operation.
> 
> In fsl_edma_resume_early:
> Enable the eDMA and wait for being used.
> 
> Signed-off-by: Yuan Yao 
> ---
>  drivers/dma/fsl-edma.c | 83
> --
>  1 file changed, 80 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> 915eec3..cf8b06c 100644
> --- a/drivers/dma/fsl-edma.c
> +++ b/drivers/dma/fsl-edma.c
> @@ -116,6 +116,10 @@
>   BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
>   BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
>   BIT(DMA_SLAVE_BUSWIDTH_8_BYTES)
> +enum fsl_edma_pm_state {
> + RUNNING = 0,
> + SUSPENDED,
> +};
> 
>  struct fsl_edma_hw_tcd {
>   __le32  saddr;
> @@ -147,6 +151,9 @@ struct fsl_edma_slave_config {  struct fsl_edma_chan {
>   struct virt_dma_chanvchan;
>   enum dma_status status;
> + enum fsl_edma_pm_state  pm_state;
> + boolidle;
> + u32 slave_id;
>   struct fsl_edma_engine  *edma;
>   struct fsl_edma_desc*edesc;
>   struct fsl_edma_slave_configfsc;
> @@ -298,6 +305,7 @@ static int fsl_edma_terminate_all(struct dma_chan
> *chan)
>   spin_lock_irqsave(_chan->vchan.lock, flags);
>   fsl_edma_disable_request(fsl_chan);
>   fsl_chan->edesc = NULL;
> + fsl_chan->idle = true;
>   vchan_get_all_descriptors(_chan->vchan, );
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   vchan_dma_desc_free_list(_chan->vchan, ); @@ -313,6
> +321,7 @@ static int fsl_edma_pause(struct dma_chan *chan)
>   if (fsl_chan->edesc) {
>   fsl_edma_disable_request(fsl_chan);
>   fsl_chan->status = DMA_PAUSED;
> + fsl_chan->idle = true;
>   }
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   return 0;
> @@ -327,6 +336,7 @@ static int fsl_edma_resume(struct dma_chan *chan)
>   if (fsl_chan->edesc) {
>   fsl_edma_enable_request(fsl_chan);
>   fsl_chan->status = DMA_IN_PROGRESS;
> + fsl_chan->idle = false;
>   }
>   spin_unlock_irqrestore(_chan->vchan.lock, flags);
>   return 0;
> @@ -648,6 +658,7 @@ static void fsl_edma_xfer_desc(struct fsl_edma_chan
> *fsl_chan)
>   fsl_edma_set_tcd_regs(fsl_chan, fsl_chan->edesc->tcd[0].vtcd);
>   fsl_edma_enable_request(fsl_chan);
>   fsl_chan->status = DMA_IN_PROGRESS;
> + fsl_chan->idle = false;
>  }
> 
>  static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id) @@ -676,6
> +687,7 @@ static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id)
>   vchan_cookie_complete(_chan->edesc-
> >vdesc);
>   fsl_chan->edesc = NULL;
>   fsl_chan->status = DMA_COMPLETE;
> + fsl_chan->idle = true;
>   } else {
>   vchan_cyclic_callback(_chan->edesc-
> >vdesc);
>   }
> @@ -704,6 +716,7 @@ static irqreturn_t fsl_edma_err_handler(int irq, void
> *dev_id)
>   edma_writeb(fsl_edma, EDMA_CERR_CERR(ch),
>   fsl_edma->membase + EDMA_CERR);
>   fsl_edma->chans[ch].status = DMA_ERROR;
> + fsl_edma->chans[ch].idle = true;
>   }
>   }
>   return IRQ_HANDLED;
> @@ -724,6 +737,12 @@ static void fsl_edma_issue_pending(struct dma_chan
> *chan)
> 
>   spin_lock_irqsave(_chan->vchan.lock, flags);
> 
> + if (unlikely(fsl_chan->pm_state != RUNNING)) {
> + spin_unlock_irqrestore(_chan->vchan.lock, flags);
> + /* cannot submit due to suspend */
> + return;
> + }
> +
>   if (vchan_issue_pending(_chan->vchan) && !fsl_chan->edesc)
>   fsl_edma_xfer_desc(fsl_chan);
> 
> @@ -735,6 +754,7 @@ static struct dma_chan *fsl_edma_xlate(struct
> of_phandle_args *dma_spec,  {
>   struct fsl_edma_engine 

RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod, 

After our discuss, I have already send the v2.
Could you please take some times help to review this patch again? 
Thanks.

Best Regards,
Yuan Yao

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
 On Behalf Of Yuan Yao
 Sent: Tuesday, July 21, 2015 4:57 PM
 To: vinod.k...@intel.com; ste...@agner.ch; a...@arndb.de
 Cc: dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
 ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support
 
 This add power management suspend/resume support for the fsl-edma driver.
 
 eDMA acted as a basic function used by others. What it needs to do is the two
 steps below to support power management.
 
 In fsl_edma_suspend_late:
 Check whether the DMA chan is idle and if it is not idle, stop PM operation.
 
 In fsl_edma_resume_early:
 Enable the eDMA and wait for being used.
 
 Signed-off-by: Yuan Yao yao.y...@freescale.com
 ---
  drivers/dma/fsl-edma.c | 83
 --
  1 file changed, 80 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
 915eec3..cf8b06c 100644
 --- a/drivers/dma/fsl-edma.c
 +++ b/drivers/dma/fsl-edma.c
 @@ -116,6 +116,10 @@
   BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
   BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) | \
   BIT(DMA_SLAVE_BUSWIDTH_8_BYTES)
 +enum fsl_edma_pm_state {
 + RUNNING = 0,
 + SUSPENDED,
 +};
 
  struct fsl_edma_hw_tcd {
   __le32  saddr;
 @@ -147,6 +151,9 @@ struct fsl_edma_slave_config {  struct fsl_edma_chan {
   struct virt_dma_chanvchan;
   enum dma_status status;
 + enum fsl_edma_pm_state  pm_state;
 + boolidle;
 + u32 slave_id;
   struct fsl_edma_engine  *edma;
   struct fsl_edma_desc*edesc;
   struct fsl_edma_slave_configfsc;
 @@ -298,6 +305,7 @@ static int fsl_edma_terminate_all(struct dma_chan
 *chan)
   spin_lock_irqsave(fsl_chan-vchan.lock, flags);
   fsl_edma_disable_request(fsl_chan);
   fsl_chan-edesc = NULL;
 + fsl_chan-idle = true;
   vchan_get_all_descriptors(fsl_chan-vchan, head);
   spin_unlock_irqrestore(fsl_chan-vchan.lock, flags);
   vchan_dma_desc_free_list(fsl_chan-vchan, head); @@ -313,6
 +321,7 @@ static int fsl_edma_pause(struct dma_chan *chan)
   if (fsl_chan-edesc) {
   fsl_edma_disable_request(fsl_chan);
   fsl_chan-status = DMA_PAUSED;
 + fsl_chan-idle = true;
   }
   spin_unlock_irqrestore(fsl_chan-vchan.lock, flags);
   return 0;
 @@ -327,6 +336,7 @@ static int fsl_edma_resume(struct dma_chan *chan)
   if (fsl_chan-edesc) {
   fsl_edma_enable_request(fsl_chan);
   fsl_chan-status = DMA_IN_PROGRESS;
 + fsl_chan-idle = false;
   }
   spin_unlock_irqrestore(fsl_chan-vchan.lock, flags);
   return 0;
 @@ -648,6 +658,7 @@ static void fsl_edma_xfer_desc(struct fsl_edma_chan
 *fsl_chan)
   fsl_edma_set_tcd_regs(fsl_chan, fsl_chan-edesc-tcd[0].vtcd);
   fsl_edma_enable_request(fsl_chan);
   fsl_chan-status = DMA_IN_PROGRESS;
 + fsl_chan-idle = false;
  }
 
  static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id) @@ -676,6
 +687,7 @@ static irqreturn_t fsl_edma_tx_handler(int irq, void *dev_id)
   vchan_cookie_complete(fsl_chan-edesc-
 vdesc);
   fsl_chan-edesc = NULL;
   fsl_chan-status = DMA_COMPLETE;
 + fsl_chan-idle = true;
   } else {
   vchan_cyclic_callback(fsl_chan-edesc-
 vdesc);
   }
 @@ -704,6 +716,7 @@ static irqreturn_t fsl_edma_err_handler(int irq, void
 *dev_id)
   edma_writeb(fsl_edma, EDMA_CERR_CERR(ch),
   fsl_edma-membase + EDMA_CERR);
   fsl_edma-chans[ch].status = DMA_ERROR;
 + fsl_edma-chans[ch].idle = true;
   }
   }
   return IRQ_HANDLED;
 @@ -724,6 +737,12 @@ static void fsl_edma_issue_pending(struct dma_chan
 *chan)
 
   spin_lock_irqsave(fsl_chan-vchan.lock, flags);
 
 + if (unlikely(fsl_chan-pm_state != RUNNING)) {
 + spin_unlock_irqrestore(fsl_chan-vchan.lock, flags);
 + /* cannot submit due to suspend */
 + return;
 + }
 +
   if (vchan_issue_pending(fsl_chan-vchan)  !fsl_chan-edesc)
   fsl_edma_xfer_desc(fsl_chan);
 
 @@ -735,6 +754,7 @@ static struct dma_chan *fsl_edma_xlate(struct
 of_phandle_args *dma_spec,  {
   struct fsl_edma_engine *fsl_edma = ofdma-of_dma_data;
   struct dma_chan *chan, *_chan;
 + struct 

RE: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

eDMA sullpies the data transmission service for other IPs, so it should be 
suspended later and resumed earlier.
For example:
Synchronous Audio Interface (SAI), SAI use DMA to transfer the data.
When suspend:
1, SAI using suspend handlers to stop the DMA transmission.
2, DMA using suspend_late  handlers to check whether DMA chan is idle.
When resume:
1, DMA using resume_early   to enable. And then can servicing for others.
2, SAI using resume and then can use DMA to data transmission.

We must sure the order is right, so I think DMA should using early/late 
handlers.

Thanks.

Best Regards,
Yuan Yao

On Thursday, July 16, 2015 9:24 PM, Vinod wrote:
> On Wed, Jul 15, 2015 at 05:32:58PM +0800, Yuan Yao wrote:
> > +
> > +static const struct dev_pm_ops fsl_edma_pm_ops = {
> > +   .suspend_late   = fsl_edma_suspend_late,
> > +   .resume_early   = fsl_edma_resume_early,
> any reason why you are using early/late handlers?
> 
> --
> ~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Arnd,
Ok, I will remove the #ifdef in the next version.
Thanks.

Hi All,
Is there any others comments?

Thanks for your review.

Best Regards,
Yuan Yao

On Wednesday, July 15, 2015 10:55 PM Arnd wrote:
> On Wednesday 15 July 2015 10:29:55 Yao Yuan wrote:
> > Hi Arnd,
> >
> > Thanks for your review.
> > And can you give me more information?
> > In my opinion, The fsl_edma_pm_state will just be used when CONFIG_PM
> > support. So why not use the #ifdefs to remove the unnecessary code? Since
> the PM will not be selected in many use cases.
> 
> I would consider code readability more important than saving a few 
> instructions,
> and the #ifdef interrupts the reading flow.
> Another aspect is that the compiler does not produce warnings for incorrect
> code in an #ifdef, so we try to use e.g. 'if (IS_ENABLED(CONFIG_FOO))'
> instead of '#ifdef CONFIG_FOO' wherever possible.
> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Arnd,
Ok, I will remove the #ifdef in the next version.
Thanks.

Hi All,
Is there any others comments?

Thanks for your review.

Best Regards,
Yuan Yao

On Wednesday, July 15, 2015 10:55 PM Arnd wrote:
 On Wednesday 15 July 2015 10:29:55 Yao Yuan wrote:
  Hi Arnd,
 
  Thanks for your review.
  And can you give me more information?
  In my opinion, The fsl_edma_pm_state will just be used when CONFIG_PM
  support. So why not use the #ifdefs to remove the unnecessary code? Since
 the PM will not be selected in many use cases.
 
 I would consider code readability more important than saving a few 
 instructions,
 and the #ifdef interrupts the reading flow.
 Another aspect is that the compiler does not produce warnings for incorrect
 code in an #ifdef, so we try to use e.g. 'if (IS_ENABLED(CONFIG_FOO))'
 instead of '#ifdef CONFIG_FOO' wherever possible.
 
   Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

eDMA sullpies the data transmission service for other IPs, so it should be 
suspended later and resumed earlier.
For example:
Synchronous Audio Interface (SAI), SAI use DMA to transfer the data.
When suspend:
1, SAI using suspend handlers to stop the DMA transmission.
2, DMA using suspend_late  handlers to check whether DMA chan is idle.
When resume:
1, DMA using resume_early   to enable. And then can servicing for others.
2, SAI using resume and then can use DMA to data transmission.

We must sure the order is right, so I think DMA should using early/late 
handlers.

Thanks.

Best Regards,
Yuan Yao

On Thursday, July 16, 2015 9:24 PM, Vinod wrote:
 On Wed, Jul 15, 2015 at 05:32:58PM +0800, Yuan Yao wrote:
  +
  +static const struct dev_pm_ops fsl_edma_pm_ops = {
  +   .suspend_late   = fsl_edma_suspend_late,
  +   .resume_early   = fsl_edma_resume_early,
 any reason why you are using early/late handlers?
 
 --
 ~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Arnd,

Thanks for your review.
And can you give me more information?
In my opinion, The fsl_edma_pm_state will just be used when CONFIG_PM support. 
So why not use the #ifdefs to remove the 
unnecessary code? Since the PM will not be selected in many use cases.

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, July 15, 2015 5:57 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Yuan Yao-B46683; vinod.k...@intel.com; ste...@agner.ch;
> dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support
> 
> On Wednesday 15 July 2015 17:32:58 Yuan Yao wrote:
> > +#ifdef CONFIG_PM
> > +enum fsl_edma_pm_state {
> > +   RUNNING = 0,
> > +   SUSPENDED,
> > +};
> > +#endif
> >
> >  struct fsl_edma_hw_tcd {
> >
> 
> The #ifdefs here seem unnecessary, at least most of them, better just do this
> all unconditionally.
> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Re: [PATCH 2/2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Stefan,

Thanks for your review, now I will take over the eDMA.
I have some different in understanding with PM suspend/resume support. And I 
will send a patch for RFC later.
Also please check my comment in line for this patch.
I hope you can help to review it for me.

Thanks.

Best Regards,
Yuan Yao

On 2015-1-30 21:01,  Stefan Agner wrote:
> On Tue, Dec 30, 2014 at 04:41:47PM +0800, Jingchang Lu wrote:
> > This adds power management suspend/resume support for the fsl-edma
> > driver.
> >
> > Signed-off-by: Jingchang Lu 
> > ---
> >  drivers/dma/fsl-edma.c | 38
> ++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> > e0bd517..6a81699 100644
> > --- a/drivers/dma/fsl-edma.c
> > +++ b/drivers/dma/fsl-edma.c
> > @@ -1017,6 +1017,43 @@ static int fsl_edma_remove(struct
> platform_device *pdev)
> > return 0;
> >  }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int fsl_edma_pm_suspend(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   fsl_edma_chan_mux(fsl_chan, 0, false);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int fsl_edma_pm_resume(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   edma_writew(fsl_edma, 0x0, fsl_edma->membase +
> EDMA_TCD_CSR(i));
> > +   /* restore the channel slave id configuration */
> > +   fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id, true);
> Wouldnt this be reconfigured? Should you do this for all channels or active 
> ones.
> Also I dont see you pausing or suspending active channels or checking for 
> them?
> 
No, here is no need more reconfigured. I will send a new patch for what your 
consideration.
Thanks.

> --
> ~Vinod
> 
> > +   }
> > +
> > +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> > +   fsl_edma->membase + EDMA_CR);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +static
> > +SIMPLE_DEV_PM_OPS(fsl_edma_pm_ops, fsl_edma_pm_suspend,
> > +fsl_edma_pm_resume);
> > +
> >  static const struct of_device_id fsl_edma_dt_ids[] = {
> > { .compatible = "fsl,vf610-edma", },
> > { /* sentinel */ }
> > @@ -1027,6 +1064,7 @@ static struct platform_driver fsl_edma_driver = {
> > .driver = {
> > .name   = "fsl-edma",
> > .of_match_table = fsl_edma_dt_ids,
> > +   .pm = _edma_pm_ops,
> > },
> > .probe  = fsl_edma_probe,
> > .remove = fsl_edma_remove,
> > --
> > 1.8.0
> >
> 
> --
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Re: [PATCH 2/2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

Thanks for your review, now I will take over the eDMA.
I have some different in understanding with PM suspend/resume support. And I 
will send a patch for RFC later.
Also please check my comment in line for this patch.
I hope you can help to review it for me.

Thanks.

Best Regards,
Yuan Yao

On 2015-5-5 18:35, Vinod Koul wrote:
> On 2014-12-30 09:41, Jingchang Lu wrote:
> > This adds power management suspend/resume support for the fsl-edma
> > driver.
> >
> > Signed-off-by: Jingchang Lu 
> > ---
> >  drivers/dma/fsl-edma.c | 38
> ++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> > e0bd517..6a81699 100644
> > --- a/drivers/dma/fsl-edma.c
> > +++ b/drivers/dma/fsl-edma.c
> > @@ -1017,6 +1017,43 @@ static int fsl_edma_remove(struct
> platform_device *pdev)
> > return 0;
> >  }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int fsl_edma_pm_suspend(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   fsl_edma_chan_mux(fsl_chan, 0, false);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int fsl_edma_pm_resume(struct device *dev) {
> > +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > +   struct fsl_edma_chan *fsl_chan;
> > +   int i;
> > +
> > +   for (i = 0; i < fsl_edma->n_chans; i++) {
> > +   fsl_chan = _edma->chans[i];
> > +   edma_writew(fsl_edma, 0x0, fsl_edma->membase +
> EDMA_TCD_CSR(i));
> 
> What is the expectation of the suspend mode, are the registers and descriptors
> cleared during suspend? So this makes sure we have all descriptors disabled on
> wake-up, right?
Yes, suspend mode will power down the eDMA controller.

> 
> > +   /* restore the channel slave id configuration */
> > +   fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id, true);
> 
> And here the channel gets muxed again.
> 
> But the user is expected to reconfigure a channel, e.g. using
> dmaengine_slave_config and the dmaengine_prep*? Also and cyclic DMA
> which has been paused before would be interrupted, is this correct?

No, In fact the channel in eDMA is a little different form the other channel. 
Every IP just have only one channel. The IP should get his corresponding 
channel when boot up and release it until power down or IP removed.

> I don't know what the common exception of the API is, I'm just asking so I now
> what I can expect when using the DMA driver in other device drivers...
> 
> --
> Stefan
> 
> > +   }
> > +
> > +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> > +   fsl_edma->membase + EDMA_CR);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +static
> > +SIMPLE_DEV_PM_OPS(fsl_edma_pm_ops, fsl_edma_pm_suspend,
> > +fsl_edma_pm_resume);
> > +
> >  static const struct of_device_id fsl_edma_dt_ids[] = {
> > { .compatible = "fsl,vf610-edma", },
> > { /* sentinel */ }
> > @@ -1027,6 +1064,7 @@ static struct platform_driver fsl_edma_driver = {
> > .driver = {
> > .name   = "fsl-edma",
> > .of_match_table = fsl_edma_dt_ids,
> > +   .pm = _edma_pm_ops,
> > },
> > .probe  = fsl_edma_probe,
> > .remove = fsl_edma_remove,
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Re: [PATCH 2/2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Vinod,

Thanks for your review, now I will take over the eDMA.
I have some different in understanding with PM suspend/resume support. And I 
will send a patch for RFC later.
Also please check my comment in line for this patch.
I hope you can help to review it for me.

Thanks.

Best Regards,
Yuan Yao

On 2015-5-5 18:35, Vinod Koul wrote:
 On 2014-12-30 09:41, Jingchang Lu wrote:
  This adds power management suspend/resume support for the fsl-edma
  driver.
 
  Signed-off-by: Jingchang Lu jingchang...@freescale.com
  ---
   drivers/dma/fsl-edma.c | 38
 ++
   1 file changed, 38 insertions(+)
 
  diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
  e0bd517..6a81699 100644
  --- a/drivers/dma/fsl-edma.c
  +++ b/drivers/dma/fsl-edma.c
  @@ -1017,6 +1017,43 @@ static int fsl_edma_remove(struct
 platform_device *pdev)
  return 0;
   }
 
  +#ifdef CONFIG_PM_SLEEP
  +static int fsl_edma_pm_suspend(struct device *dev) {
  +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
  +   struct fsl_edma_chan *fsl_chan;
  +   int i;
  +
  +   for (i = 0; i  fsl_edma-n_chans; i++) {
  +   fsl_chan = fsl_edma-chans[i];
  +   fsl_edma_chan_mux(fsl_chan, 0, false);
  +   }
  +
  +   return 0;
  +}
  +
  +static int fsl_edma_pm_resume(struct device *dev) {
  +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
  +   struct fsl_edma_chan *fsl_chan;
  +   int i;
  +
  +   for (i = 0; i  fsl_edma-n_chans; i++) {
  +   fsl_chan = fsl_edma-chans[i];
  +   edma_writew(fsl_edma, 0x0, fsl_edma-membase +
 EDMA_TCD_CSR(i));
 
 What is the expectation of the suspend mode, are the registers and descriptors
 cleared during suspend? So this makes sure we have all descriptors disabled on
 wake-up, right?
Yes, suspend mode will power down the eDMA controller.

 
  +   /* restore the channel slave id configuration */
  +   fsl_edma_chan_mux(fsl_chan, fsl_chan-slave_id, true);
 
 And here the channel gets muxed again.
 
 But the user is expected to reconfigure a channel, e.g. using
 dmaengine_slave_config and the dmaengine_prep*? Also and cyclic DMA
 which has been paused before would be interrupted, is this correct?

No, In fact the channel in eDMA is a little different form the other channel. 
Every IP just have only one channel. The IP should get his corresponding 
channel when boot up and release it until power down or IP removed.

 I don't know what the common exception of the API is, I'm just asking so I now
 what I can expect when using the DMA driver in other device drivers...
 
 --
 Stefan
 
  +   }
  +
  +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
  +   fsl_edma-membase + EDMA_CR);
  +
  +   return 0;
  +}
  +#endif
  +static
  +SIMPLE_DEV_PM_OPS(fsl_edma_pm_ops, fsl_edma_pm_suspend,
  +fsl_edma_pm_resume);
  +
   static const struct of_device_id fsl_edma_dt_ids[] = {
  { .compatible = fsl,vf610-edma, },
  { /* sentinel */ }
  @@ -1027,6 +1064,7 @@ static struct platform_driver fsl_edma_driver = {
  .driver = {
  .name   = fsl-edma,
  .of_match_table = fsl_edma_dt_ids,
  +   .pm = fsl_edma_pm_ops,
  },
  .probe  = fsl_edma_probe,
  .remove = fsl_edma_remove,
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Re: [PATCH 2/2] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Stefan,

Thanks for your review, now I will take over the eDMA.
I have some different in understanding with PM suspend/resume support. And I 
will send a patch for RFC later.
Also please check my comment in line for this patch.
I hope you can help to review it for me.

Thanks.

Best Regards,
Yuan Yao

On 2015-1-30 21:01,  Stefan Agner wrote:
 On Tue, Dec 30, 2014 at 04:41:47PM +0800, Jingchang Lu wrote:
  This adds power management suspend/resume support for the fsl-edma
  driver.
 
  Signed-off-by: Jingchang Lu jingchang...@freescale.com
  ---
   drivers/dma/fsl-edma.c | 38
 ++
   1 file changed, 38 insertions(+)
 
  diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
  e0bd517..6a81699 100644
  --- a/drivers/dma/fsl-edma.c
  +++ b/drivers/dma/fsl-edma.c
  @@ -1017,6 +1017,43 @@ static int fsl_edma_remove(struct
 platform_device *pdev)
  return 0;
   }
 
  +#ifdef CONFIG_PM_SLEEP
  +static int fsl_edma_pm_suspend(struct device *dev) {
  +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
  +   struct fsl_edma_chan *fsl_chan;
  +   int i;
  +
  +   for (i = 0; i  fsl_edma-n_chans; i++) {
  +   fsl_chan = fsl_edma-chans[i];
  +   fsl_edma_chan_mux(fsl_chan, 0, false);
  +   }
  +
  +   return 0;
  +}
  +
  +static int fsl_edma_pm_resume(struct device *dev) {
  +   struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
  +   struct fsl_edma_chan *fsl_chan;
  +   int i;
  +
  +   for (i = 0; i  fsl_edma-n_chans; i++) {
  +   fsl_chan = fsl_edma-chans[i];
  +   edma_writew(fsl_edma, 0x0, fsl_edma-membase +
 EDMA_TCD_CSR(i));
  +   /* restore the channel slave id configuration */
  +   fsl_edma_chan_mux(fsl_chan, fsl_chan-slave_id, true);
 Wouldnt this be reconfigured? Should you do this for all channels or active 
 ones.
 Also I dont see you pausing or suspending active channels or checking for 
 them?
 
No, here is no need more reconfigured. I will send a new patch for what your 
consideration.
Thanks.

 --
 ~Vinod
 
  +   }
  +
  +   edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
  +   fsl_edma-membase + EDMA_CR);
  +
  +   return 0;
  +}
  +#endif
  +static
  +SIMPLE_DEV_PM_OPS(fsl_edma_pm_ops, fsl_edma_pm_suspend,
  +fsl_edma_pm_resume);
  +
   static const struct of_device_id fsl_edma_dt_ids[] = {
  { .compatible = fsl,vf610-edma, },
  { /* sentinel */ }
  @@ -1027,6 +1064,7 @@ static struct platform_driver fsl_edma_driver = {
  .driver = {
  .name   = fsl-edma,
  .of_match_table = fsl_edma_dt_ids,
  +   .pm = fsl_edma_pm_ops,
  },
  .probe  = fsl_edma_probe,
  .remove = fsl_edma_remove,
  --
  1.8.0
 
 
 --
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support

[Yao Yuan]

Hi Arnd,

Thanks for your review.
And can you give me more information?
In my opinion, The fsl_edma_pm_state will just be used when CONFIG_PM support. 
So why not use the #ifdefs to remove the 
unnecessary code? Since the PM will not be selected in many use cases.

Thanks.

Best Regards,
Yuan Yao

 -Original Message-
 From: Arnd Bergmann [mailto:a...@arndb.de]
 Sent: Wednesday, July 15, 2015 5:57 PM
 To: linux-arm-ker...@lists.infradead.org
 Cc: Yuan Yao-B46683; vinod.k...@intel.com; ste...@agner.ch;
 dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
 ker...@vger.kernel.org
 Subject: Re: [PATCH] dmaengine: fsl-edma: add PM suspend/resume support
 
 On Wednesday 15 July 2015 17:32:58 Yuan Yao wrote:
  +#ifdef CONFIG_PM
  +enum fsl_edma_pm_state {
  +   RUNNING = 0,
  +   SUSPENDED,
  +};
  +#endif
 
   struct fsl_edma_hw_tcd {
 
 
 The #ifdefs here seem unnecessary, at least most of them, better just do this
 all unconditionally.
 
   Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] dma: Add Freescale qDMA engine driver support

[Yao Yuan]

Thanks for your review. I will fix it in the next version.

Best Regards,
Yuan Yao

> -Original Message-
> From: Paul Bolle [mailto:pebo...@tiscali.nl]
> Sent: Wednesday, March 18, 2015 2:57 AM
> To: Yuan Yao-B46683
> Cc: vinod.k...@intel.com; shawn@linaro.org; dan.j.willi...@intel.com;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] dma: Add Freescale qDMA engine driver support
> 
> Just a license nit.
> 
> On Tue, 2015-03-17 at 13:28 +0800, Yuan Yao wrote:
> > --- /dev/null
> > +++ b/drivers/dma/fsl-qdma.c
> 
> > + * This program is free software; you can redistribute  it and/or modify it
> > + * under  the terms of  the GNU General  Public License as published by the
> > + * Free Software Foundation;  either version 2 of the  License, or (at your
> > + * option) any later version.
> 
> This states the license is GPL v2 or later.
> 
> > +MODULE_LICENSE("GPL v2");
> 
> And
> MODULE_LICENSE("GPL");
> 
> would match that statement.
> 
> 
> Paul Bolle

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 1/2] dma: Add Freescale qDMA engine driver support

[Yao Yuan]

Thanks for your review. I will fix it in the next version.

Best Regards,
Yuan Yao

 -Original Message-
 From: Paul Bolle [mailto:pebo...@tiscali.nl]
 Sent: Wednesday, March 18, 2015 2:57 AM
 To: Yuan Yao-B46683
 Cc: vinod.k...@intel.com; shawn@linaro.org; dan.j.willi...@intel.com;
 linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: Re: [PATCH 1/2] dma: Add Freescale qDMA engine driver support
 
 Just a license nit.
 
 On Tue, 2015-03-17 at 13:28 +0800, Yuan Yao wrote:
  --- /dev/null
  +++ b/drivers/dma/fsl-qdma.c
 
  + * This program is free software; you can redistribute  it and/or modify it
  + * under  the terms of  the GNU General  Public License as published by the
  + * Free Software Foundation;  either version 2 of the  License, or (at your
  + * option) any later version.
 
 This states the license is GPL v2 or later.
 
  +MODULE_LICENSE(GPL v2);
 
 And
 MODULE_LICENSE(GPL);
 
 would match that statement.
 
 
 Paul Bolle

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support

[Yao Yuan]

Hi Stefan,

Thanks for your test.

Yes, it's not a huge number.

The number is always very small especially when the "test_buf_size" is small.

For dmatest tool, the measure transmission time is far greater than the actual 
transmission time.
So the number is small. In fact, the DMA with memory copy mode is very fast.

Best Regards,
Yuan Yao

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Stefan Agner
> Sent: Friday, January 30, 2015 8:39 PM
> To: Lu Jingchang-B35083
> Cc: vinod.k...@intel.com; dmaeng...@vger.kernel.org;
> dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support
> 
> On 2014-12-30 09:41, Jingchang Lu wrote:
> > This adds the memory copy capability support, the memcpy functionality
> > needs to configure the DMAMUX of the channel with the always on slave
> > id.
> 
> Hi Jingchang,
> 
> I run some tests on v3.19-rc6 with this patches applied on Vybrid SoC
> VF500 and VF610.
> 
> On VF500 clocked at 400MHz I get this numbers:
> # insmod dmatest.ko max_channels=1 iterations=100 run=1 [  616.809594]
> dmatest: Started 1 threads using dma0chan0 [  617.293498] dmatest:
> dma0chan0-copy0: summary 100 tests, 0 failures
> 209 iops 1613 KB/s (0)
> 
> In contrast, on a VF610 clocked at 500MHz I get this:
> # insmod dmatest.ko max_channels=1 iterations=100 run=1 [  154.203290]
> dmatest: Started 1 threads using dma0chan4 [  154.614225] dmatest:
> dma0chan4-copy0: summary 100 tests, 0 failures
> 246 iops 2002 KB/s (0)
> 
> Not that huge numbers, but I guess this is what the hardware can deliver... 
> Did
> you run some performance tests?
> 
> But generally, looks good.
> 
> Tested-by: Stefan Agner 
> 
> >
> > Signed-off-by: Jingchang Lu 
> > ---
> >  drivers/dma/fsl-edma.c | 63
> > --
> >  1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> > 09e2842..e0bd517 100644
> > --- a/drivers/dma/fsl-edma.c
> > +++ b/drivers/dma/fsl-edma.c
> > @@ -110,6 +110,8 @@
> >  #define EDMAMUX_CHCFG_ENBL 0x80
> >  #define EDMAMUX_CHCFG_SOURCE(n)((n) & 0x3F)
> >
> > +#define SLAVE_ID_ALWAYSON  63 /* the always on slave id */
> > +
> >  #define DMAMUX_NR  2
> >
> >  #define FSL_EDMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> \
> > @@ -147,6 +149,7 @@ struct fsl_edma_slave_config {  struct
> > fsl_edma_chan {
> > struct virt_dma_chanvchan;
> > enum dma_status status;
> > +   u32 slave_id;
> > struct fsl_edma_engine  *edma;
> > struct fsl_edma_desc*edesc;
> > struct fsl_edma_slave_configfsc;
> > @@ -637,6 +640,45 @@ static struct dma_async_tx_descriptor
> > *fsl_edma_prep_slave_sg(
> > return vchan_tx_prep(_chan->vchan, _desc->vdesc, flags);  }
> >
> > +static struct dma_async_tx_descriptor * fsl_edma_prep_memcpy(struct
> > +dma_chan *chan, dma_addr_t dst,
> > +   dma_addr_t src, size_t len, unsigned long tx_flags) {
> > +   struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > +   struct fsl_edma_desc *fsl_desc;
> > +   u16 soff, doff, attr;
> > +
> > +   /*
> > +* use 4-bytes data transfer size if all is 4-bytes aligned,
> > +* else 2-bytes data transfer size of all is 2-bytes aligned,
> > +* otherwise 1-byte tranfer size.
> > +*/
> > +   if (src & 0x1 || dst & 0x1 || len & 0x1) {
> > +   attr = EDMA_TCD_ATTR_SSIZE_8BIT |
> EDMA_TCD_ATTR_DSIZE_8BIT;
> > +   soff = 0x1;
> > +   doff = 0x1;
> > +   } else if (src & 0x2 || dst & 0x2 || len & 0x2) {
> > +   attr = EDMA_TCD_ATTR_SSIZE_16BIT |
> EDMA_TCD_ATTR_DSIZE_16BIT;
> > +   soff = 0x2;
> > +   doff = 0x2;
> > +   } else {
> > +   attr = EDMA_TCD_ATTR_SSIZE_32BIT |
> EDMA_TCD_ATTR_DSIZE_32BIT;
> > +   soff = 0x4;
> > +   doff = 0x4;
> > +   }
> > +
> > +   fsl_desc = fsl_edma_alloc_desc(fsl_chan, 1);
> > +   if (!fsl_desc)
> > +   return NULL;
> > +   fsl_desc->iscyclic = false;
> > +
> > +   fsl_edma_fill_tcd(fsl_desc->tcd[0].vtcd, src, dst, attr, soff, len,
> > + 0, 1, 1, doff, 0, true, true, false);
> > +
> > +   return vchan_tx_prep(_chan->vchan, _desc->vdesc, tx_flags);
> > +
> > +}
> > +
> >  static void fsl_edma_xfer_desc(struct fsl_edma_chan *fsl_chan)  {
> > struct virt_dma_desc *vdesc;
> > @@ -735,6 +777,7 @@ static struct dma_chan *fsl_edma_xlate(struct
> > of_phandle_args *dma_spec,  {
> > struct fsl_edma_engine *fsl_edma = ofdma->of_dma_data;
> > struct dma_chan *chan, *_chan;
> > +   struct fsl_edma_chan *fsl_chan;
> > unsigned long chans_per_mux = fsl_edma->n_chans / DMAMUX_NR;
> >
> > if (dma_spec->args_count != 2)
> > @@ -748,8 +791,10 @@ static struct dma_chan 

RE: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support

[Yao Yuan]

Hi Stefan,

Thanks for your test.

Yes, it's not a huge number.

The number is always very small especially when the test_buf_size is small.

For dmatest tool, the measure transmission time is far greater than the actual 
transmission time.
So the number is small. In fact, the DMA with memory copy mode is very fast.

Best Regards,
Yuan Yao

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
 On Behalf Of Stefan Agner
 Sent: Friday, January 30, 2015 8:39 PM
 To: Lu Jingchang-B35083
 Cc: vinod.k...@intel.com; dmaeng...@vger.kernel.org;
 dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org
 Subject: Re: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support
 
 On 2014-12-30 09:41, Jingchang Lu wrote:
  This adds the memory copy capability support, the memcpy functionality
  needs to configure the DMAMUX of the channel with the always on slave
  id.
 
 Hi Jingchang,
 
 I run some tests on v3.19-rc6 with this patches applied on Vybrid SoC
 VF500 and VF610.
 
 On VF500 clocked at 400MHz I get this numbers:
 # insmod dmatest.ko max_channels=1 iterations=100 run=1 [  616.809594]
 dmatest: Started 1 threads using dma0chan0 [  617.293498] dmatest:
 dma0chan0-copy0: summary 100 tests, 0 failures
 209 iops 1613 KB/s (0)
 
 In contrast, on a VF610 clocked at 500MHz I get this:
 # insmod dmatest.ko max_channels=1 iterations=100 run=1 [  154.203290]
 dmatest: Started 1 threads using dma0chan4 [  154.614225] dmatest:
 dma0chan4-copy0: summary 100 tests, 0 failures
 246 iops 2002 KB/s (0)
 
 Not that huge numbers, but I guess this is what the hardware can deliver... 
 Did
 you run some performance tests?
 
 But generally, looks good.
 
 Tested-by: Stefan Agner ste...@agner.ch
 
 
  Signed-off-by: Jingchang Lu jingchang...@freescale.com
  ---
   drivers/dma/fsl-edma.c | 63
  --
   1 file changed, 61 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
  09e2842..e0bd517 100644
  --- a/drivers/dma/fsl-edma.c
  +++ b/drivers/dma/fsl-edma.c
  @@ -110,6 +110,8 @@
   #define EDMAMUX_CHCFG_ENBL 0x80
   #define EDMAMUX_CHCFG_SOURCE(n)((n)  0x3F)
 
  +#define SLAVE_ID_ALWAYSON  63 /* the always on slave id */
  +
   #define DMAMUX_NR  2
 
   #define FSL_EDMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
 \
  @@ -147,6 +149,7 @@ struct fsl_edma_slave_config {  struct
  fsl_edma_chan {
  struct virt_dma_chanvchan;
  enum dma_status status;
  +   u32 slave_id;
  struct fsl_edma_engine  *edma;
  struct fsl_edma_desc*edesc;
  struct fsl_edma_slave_configfsc;
  @@ -637,6 +640,45 @@ static struct dma_async_tx_descriptor
  *fsl_edma_prep_slave_sg(
  return vchan_tx_prep(fsl_chan-vchan, fsl_desc-vdesc, flags);  }
 
  +static struct dma_async_tx_descriptor * fsl_edma_prep_memcpy(struct
  +dma_chan *chan, dma_addr_t dst,
  +   dma_addr_t src, size_t len, unsigned long tx_flags) {
  +   struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
  +   struct fsl_edma_desc *fsl_desc;
  +   u16 soff, doff, attr;
  +
  +   /*
  +* use 4-bytes data transfer size if all is 4-bytes aligned,
  +* else 2-bytes data transfer size of all is 2-bytes aligned,
  +* otherwise 1-byte tranfer size.
  +*/
  +   if (src  0x1 || dst  0x1 || len  0x1) {
  +   attr = EDMA_TCD_ATTR_SSIZE_8BIT |
 EDMA_TCD_ATTR_DSIZE_8BIT;
  +   soff = 0x1;
  +   doff = 0x1;
  +   } else if (src  0x2 || dst  0x2 || len  0x2) {
  +   attr = EDMA_TCD_ATTR_SSIZE_16BIT |
 EDMA_TCD_ATTR_DSIZE_16BIT;
  +   soff = 0x2;
  +   doff = 0x2;
  +   } else {
  +   attr = EDMA_TCD_ATTR_SSIZE_32BIT |
 EDMA_TCD_ATTR_DSIZE_32BIT;
  +   soff = 0x4;
  +   doff = 0x4;
  +   }
  +
  +   fsl_desc = fsl_edma_alloc_desc(fsl_chan, 1);
  +   if (!fsl_desc)
  +   return NULL;
  +   fsl_desc-iscyclic = false;
  +
  +   fsl_edma_fill_tcd(fsl_desc-tcd[0].vtcd, src, dst, attr, soff, len,
  + 0, 1, 1, doff, 0, true, true, false);
  +
  +   return vchan_tx_prep(fsl_chan-vchan, fsl_desc-vdesc, tx_flags);
  +
  +}
  +
   static void fsl_edma_xfer_desc(struct fsl_edma_chan *fsl_chan)  {
  struct virt_dma_desc *vdesc;
  @@ -735,6 +777,7 @@ static struct dma_chan *fsl_edma_xlate(struct
  of_phandle_args *dma_spec,  {
  struct fsl_edma_engine *fsl_edma = ofdma-of_dma_data;
  struct dma_chan *chan, *_chan;
  +   struct fsl_edma_chan *fsl_chan;
  unsigned long chans_per_mux = fsl_edma-n_chans / DMAMUX_NR;
 
  if (dma_spec-args_count != 2)
  @@ -748,8 +791,10 @@ static struct dma_chan *fsl_edma_xlate(struct
  of_phandle_args *dma_spec,
  chan = dma_get_slave_channel(chan);
  if (chan) {
  

RE: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support

[Yao Yuan]

Hi Vinod,

Could you please take some times help to review the two patches?

Thanks.

Best Regards,
Yuan Yao

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Jingchang Lu
> Sent: Wednesday, January 14, 2015 5:37 PM
> To: Lu Jingchang-B35083; vinod.k...@intel.com
> Cc: dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support
> 
> Hi, Vinod,
> 
>Could you please help review the two patches, and merge them if possible?
> Thanks!
> 
> 
> Best Regards,
> Jingchang
> 
> >-Original Message-
> >From: Jingchang Lu [mailto:jingchang...@freescale.com]
> >Sent: Tuesday, December 30, 2014 4:42 PM
> >To: vinod.k...@intel.com
> >Cc: dan.j.willi...@intel.com; dmaeng...@vger.kernel.org; linux-
> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Lu
> >Jingchang-B35083
> >Subject: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support
> >
> >This adds the memory copy capability support, the memcpy functionality
> >needs to configure the DMAMUX of the channel with the always on slave id.
> >
> >Signed-off-by: Jingchang Lu 
> >---
> > drivers/dma/fsl-edma.c | 63
> >--
> > 1 file changed, 61 insertions(+), 2 deletions(-)
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support

[Yao Yuan]

Hi Vinod,

Could you please take some times help to review the two patches?

Thanks.

Best Regards,
Yuan Yao

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
 On Behalf Of Jingchang Lu
 Sent: Wednesday, January 14, 2015 5:37 PM
 To: Lu Jingchang-B35083; vinod.k...@intel.com
 Cc: dmaeng...@vger.kernel.org; dan.j.willi...@intel.com; linux-
 ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: RE: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support
 
 Hi, Vinod,
 
Could you please help review the two patches, and merge them if possible?
 Thanks!
 
 
 Best Regards,
 Jingchang
 
 -Original Message-
 From: Jingchang Lu [mailto:jingchang...@freescale.com]
 Sent: Tuesday, December 30, 2014 4:42 PM
 To: vinod.k...@intel.com
 Cc: dan.j.willi...@intel.com; dmaeng...@vger.kernel.org; linux-
 ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Lu
 Jingchang-B35083
 Subject: [PATCH 1/2] dmaengine: fsl-edma: add dma memcpy support
 
 This adds the memory copy capability support, the memcpy functionality
 needs to configure the DMAMUX of the channel with the always on slave id.
 
 Signed-off-by: Jingchang Lu jingchang...@freescale.com
 ---
  drivers/dma/fsl-edma.c | 63
 --
  1 file changed, 61 insertions(+), 2 deletions(-)
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/