All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@sig21.net>
To: yuhang wang <wangyuhang2014@gmail.com>
Cc: linux-mtd <linux-mtd-bounces@lists.infradead.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Mark Brown <broonie@kernel.org>,
	linux-mtd@lists.infradead.org, Thomas.Betker@rohde-schwarz.com,
	spi-devel-general@lists.sourceforge.net,
	Sourav Poddar <sourav.poddar@ti.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: SPI: DUAL/QUAD support
Date: Fri, 5 Jul 2013 16:34:52 +0200	[thread overview]
Message-ID: <20130705143452.GA7738@sig21.net> (raw)
In-Reply-To: <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA@mail.gmail.com>

On Fri, Jul 05, 2013 at 06:24:40PM +0800, yuhang wang wrote:
> 
> 2 Questions here:
> 1.In m25p80.c probe, the kmalloc below I feel very strange.
>       flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
>                                       GFP_KERNEL);
> 
>  (flash->fast_read ? 1 : 0) must be 0! So why do it like that.

Maybe just increase MAX_CMD_SIZE by 1 unconditonally?
Yeah, looks like a bug in m25p80.c, flash->fast_read
is initialized too late.

> +#define        OPCODE_DOR              0x3B    /* Dual Output Read */
> +#define        OPCODE_QOR              0x6B    /* Quad Output Read */
> +#define        OPCODE_QPP              0x32    /* Quad Page Programming */
> +#define        OPCODE_QEN              0x02 /* Quad Mode Enable Flag */

Which flash chip are these for?  The OPCODE_DOR and OPCODE_QOR
match MX25L25635E, but OPCODE_QPP not (Macronix uses 0x38).



> +#ifdef CONFIG_M25PXX_USE_FAST_READ
> +#define OPCODE_READ    OPCODE_FAST_READ
> +#define FAST_READ_DUMMY_BYTE 1
> +#else
> +#define OPCODE_READ    OPCODE_NORM_READ
> +#define FAST_READ_DUMMY_BYTE 0
> +#endif

this doesn't work with the flash->fast_read setting from DT

BTW, if we add "bitwidths" to spi_board_info, wouldn't
it make sense to also add "use_fast_read" and remove the
CONFIG_M25PXX_USE_FAST_READ option?

> +/*
> + * Write configuration register 2 byte
> + * Returns negative if error occurred.
> + */
> +static int write_cr(struct m25p *flash, u16 val)
> +{
> +       flash->command[0] = OPCODE_WRSR;
> +       flash->command[1] = val >> 8;
> +       flash->command[2] = val;
> +
> +       return spi_write(flash->spi, flash->command, 3);
> +}

> +       if ((flash->spi->rx_bitwidth == SPI_BITWIDTH_QUAD) ||
> +               (flash->spi->tx_bitwidth == SPI_BITWIDTH_QUAD)) {
> +               write_enable(flash);
> +               write_cr(flash, OPCODE_QEN);
> +       }

MX25L25635E doesn't have a cr, instead a bit needs to be set in the sr

Maybe we need to add some fields to m25p_ids[] to manage variation
between flash devices.


Thanks,
Johannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
To: yuhang wang <wangyuhang2014-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-mtd
	<linux-mtd-bounces-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Thomas.Betker-Bf/A/FSCP0w3s4ca2cGeAgC/G2K4zDHf@public.gmane.org,
	spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Sourav Poddar <sourav.poddar-l0cyMroinI0@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: SPI: DUAL/QUAD support
Date: Fri, 5 Jul 2013 16:34:52 +0200	[thread overview]
Message-ID: <20130705143452.GA7738@sig21.net> (raw)
In-Reply-To: <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Jul 05, 2013 at 06:24:40PM +0800, yuhang wang wrote:
> 
> 2 Questions here:
> 1.In m25p80.c probe, the kmalloc below I feel very strange.
>       flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
>                                       GFP_KERNEL);
> 
>  (flash->fast_read ? 1 : 0) must be 0! So why do it like that.

Maybe just increase MAX_CMD_SIZE by 1 unconditonally?
Yeah, looks like a bug in m25p80.c, flash->fast_read
is initialized too late.

> +#define        OPCODE_DOR              0x3B    /* Dual Output Read */
> +#define        OPCODE_QOR              0x6B    /* Quad Output Read */
> +#define        OPCODE_QPP              0x32    /* Quad Page Programming */
> +#define        OPCODE_QEN              0x02 /* Quad Mode Enable Flag */

Which flash chip are these for?  The OPCODE_DOR and OPCODE_QOR
match MX25L25635E, but OPCODE_QPP not (Macronix uses 0x38).



> +#ifdef CONFIG_M25PXX_USE_FAST_READ
> +#define OPCODE_READ    OPCODE_FAST_READ
> +#define FAST_READ_DUMMY_BYTE 1
> +#else
> +#define OPCODE_READ    OPCODE_NORM_READ
> +#define FAST_READ_DUMMY_BYTE 0
> +#endif

this doesn't work with the flash->fast_read setting from DT

BTW, if we add "bitwidths" to spi_board_info, wouldn't
it make sense to also add "use_fast_read" and remove the
CONFIG_M25PXX_USE_FAST_READ option?

> +/*
> + * Write configuration register 2 byte
> + * Returns negative if error occurred.
> + */
> +static int write_cr(struct m25p *flash, u16 val)
> +{
> +       flash->command[0] = OPCODE_WRSR;
> +       flash->command[1] = val >> 8;
> +       flash->command[2] = val;
> +
> +       return spi_write(flash->spi, flash->command, 3);
> +}

> +       if ((flash->spi->rx_bitwidth == SPI_BITWIDTH_QUAD) ||
> +               (flash->spi->tx_bitwidth == SPI_BITWIDTH_QUAD)) {
> +               write_enable(flash);
> +               write_cr(flash, OPCODE_QEN);
> +       }

MX25L25635E doesn't have a cr, instead a bit needs to be set in the sr

Maybe we need to add some fields to m25p_ids[] to manage variation
between flash devices.


Thanks,
Johannes

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

WARNING: multiple messages have this Message-ID (diff)
From: js@sig21.net (Johannes Stezenbach)
To: linux-arm-kernel@lists.infradead.org
Subject: SPI: DUAL/QUAD support
Date: Fri, 5 Jul 2013 16:34:52 +0200	[thread overview]
Message-ID: <20130705143452.GA7738@sig21.net> (raw)
In-Reply-To: <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA@mail.gmail.com>

On Fri, Jul 05, 2013 at 06:24:40PM +0800, yuhang wang wrote:
> 
> 2 Questions here:
> 1.In m25p80.c probe, the kmalloc below I feel very strange.
>       flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
>                                       GFP_KERNEL);
> 
>  (flash->fast_read ? 1 : 0) must be 0! So why do it like that.

Maybe just increase MAX_CMD_SIZE by 1 unconditonally?
Yeah, looks like a bug in m25p80.c, flash->fast_read
is initialized too late.

> +#define        OPCODE_DOR              0x3B    /* Dual Output Read */
> +#define        OPCODE_QOR              0x6B    /* Quad Output Read */
> +#define        OPCODE_QPP              0x32    /* Quad Page Programming */
> +#define        OPCODE_QEN              0x02 /* Quad Mode Enable Flag */

Which flash chip are these for?  The OPCODE_DOR and OPCODE_QOR
match MX25L25635E, but OPCODE_QPP not (Macronix uses 0x38).



> +#ifdef CONFIG_M25PXX_USE_FAST_READ
> +#define OPCODE_READ    OPCODE_FAST_READ
> +#define FAST_READ_DUMMY_BYTE 1
> +#else
> +#define OPCODE_READ    OPCODE_NORM_READ
> +#define FAST_READ_DUMMY_BYTE 0
> +#endif

this doesn't work with the flash->fast_read setting from DT

BTW, if we add "bitwidths" to spi_board_info, wouldn't
it make sense to also add "use_fast_read" and remove the
CONFIG_M25PXX_USE_FAST_READ option?

> +/*
> + * Write configuration register 2 byte
> + * Returns negative if error occurred.
> + */
> +static int write_cr(struct m25p *flash, u16 val)
> +{
> +       flash->command[0] = OPCODE_WRSR;
> +       flash->command[1] = val >> 8;
> +       flash->command[2] = val;
> +
> +       return spi_write(flash->spi, flash->command, 3);
> +}

> +       if ((flash->spi->rx_bitwidth == SPI_BITWIDTH_QUAD) ||
> +               (flash->spi->tx_bitwidth == SPI_BITWIDTH_QUAD)) {
> +               write_enable(flash);
> +               write_cr(flash, OPCODE_QEN);
> +       }

MX25L25635E doesn't have a cr, instead a bit needs to be set in the sr

Maybe we need to add some fields to m25p_ids[] to manage variation
between flash devices.


Thanks,
Johannes

  reply	other threads:[~2013-07-05 14:34 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 11:36 SPI: DUAL/QUAD support yuhang wang
2013-07-04 11:36 ` yuhang wang
2013-07-04 11:36 ` yuhang wang
2013-07-04 13:00 ` Johannes Stezenbach
2013-07-04 13:00   ` Johannes Stezenbach
2013-07-04 13:00   ` Johannes Stezenbach
2013-07-04 14:58   ` Thomas.Betker
2013-07-04 14:58     ` Thomas.Betker at rohde-schwarz.com
2013-07-04 14:58     ` Thomas.Betker-Bf/A/FSCP0w3s4ca2cGeAgC/G2K4zDHf
2013-07-04 15:49     ` Mark Brown
2013-07-04 15:49       ` Mark Brown
2013-07-04 15:49       ` Mark Brown
2013-07-04 16:04       ` Thomas.Betker
2013-07-04 16:04         ` Thomas.Betker at rohde-schwarz.com
2013-07-04 16:04         ` Thomas.Betker-Bf/A/FSCP0w3s4ca2cGeAgC/G2K4zDHf
2013-07-05  6:25         ` yuhang wang
2013-07-05  6:25           ` yuhang wang
2013-07-05  6:25           ` yuhang wang
2013-07-05  6:45           ` Gupta, Pekon
2013-07-05  6:45             ` Gupta, Pekon
2013-07-05  6:45             ` Gupta, Pekon
2013-07-05  7:35             ` Johannes Stezenbach
2013-07-05  7:35               ` Johannes Stezenbach
2013-07-05  7:35               ` Johannes Stezenbach
2013-07-05  7:41               ` Sourav Poddar
2013-07-05  7:41                 ` Sourav Poddar
2013-07-05  7:41                 ` Sourav Poddar
2013-07-05  8:04               ` Gupta, Pekon
2013-07-05  8:04                 ` Gupta, Pekon
2013-07-05  8:04                 ` Gupta, Pekon
2013-07-05  7:40           ` Sourav Poddar
2013-07-05  7:40             ` Sourav Poddar
2013-07-05  7:40             ` Sourav Poddar
2013-07-05  8:48             ` yuhang wang
2013-07-05  8:48               ` yuhang wang
2013-07-05  8:48               ` yuhang wang
2013-07-05  8:55               ` Sourav Poddar
2013-07-05  8:55                 ` Sourav Poddar
2013-07-05  9:07                 ` yuhang wang
2013-07-05  9:07                   ` yuhang wang
2013-07-05  9:07                   ` yuhang wang
2013-07-05  9:08                   ` Sourav Poddar
2013-07-05  9:08                     ` Sourav Poddar
2013-07-05  9:08                     ` Sourav Poddar
2013-07-05  9:17                     ` yuhang wang
2013-07-05  9:17                       ` yuhang wang
2013-07-05  9:17                       ` yuhang wang
2013-07-05  9:27                       ` Sourav Poddar
2013-07-05  9:27                         ` Sourav Poddar
2013-07-05  9:27                         ` Sourav Poddar
2013-07-05 10:24                         ` yuhang wang
2013-07-05 10:24                           ` yuhang wang
2013-07-05 10:24                           ` yuhang wang
2013-07-05 14:34                           ` Johannes Stezenbach [this message]
2013-07-05 14:34                             ` Johannes Stezenbach
2013-07-05 14:34                             ` Johannes Stezenbach
2013-07-05 15:41                             ` yuhang wang
2013-07-05 15:41                               ` yuhang wang
2013-07-05 15:41                               ` yuhang wang
2013-07-04 14:36 ` Mark Brown
2013-07-04 14:36   ` Mark Brown
2013-07-04 14:36   ` Mark Brown
2013-07-04 18:06   ` Johannes Stezenbach
2013-07-04 18:06     ` Johannes Stezenbach
2013-07-04 18:06     ` Johannes Stezenbach
2013-07-04 19:12     ` Mark Brown
2013-07-04 19:12       ` Mark Brown
2013-07-04 19:12       ` Mark Brown
2013-07-05  9:41       ` yuhang wang
2013-07-05  9:41         ` yuhang wang
2013-07-05  9:41         ` yuhang wang
2013-07-05 10:12         ` Mark Brown
2013-07-05 10:12           ` Mark Brown
2013-07-05 10:12           ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2013-07-04  7:07 SPI : " 王宇航
2013-07-04  7:07 ` 王宇航
2013-07-04  7:07 ` 王宇航
2013-07-04  9:00 ` Mark Brown
2013-07-04  9:00   ` Mark Brown
2013-07-04  9:00   ` Mark Brown

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20130705143452.GA7738@sig21.net \
    --to=js@sig21.net \
    --cc=Thomas.Betker@rohde-schwarz.com \
    --cc=broonie@kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd-bounces@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=sourav.poddar@ti.com \
    --cc=spi-devel-general@lists.sourceforge.net \
    --cc=wangyuhang2014@gmail.com \
    /path/to/YOUR_REPLY

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

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