All of lore.kernel.org
 help / color / mirror / Atom feed
From: Graham Moore <grmoore@opensource.altera.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Alan Tull <atull@opensource.altera.com>,
	Yves Vandervennet <yvanderv@opensource.altera.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	Dinh Nguyen <dinguyen@opensource.altera.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH V4 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Date: Mon, 1 Jun 2015 08:49:22 -0500	[thread overview]
Message-ID: <556C62E2.3030808@opensource.altera.com> (raw)
In-Reply-To: <20150520222606.GQ11598@ld-irv-0074>



On 05/20/2015 05:26 PM, Brian Norris wrote:
> On Mon, Mar 23, 2015 at 08:36:22AM -0500, Graham Moore wrote:
...
I'm fixing the sparse, smatch, unused variables, etc.
...
>> +	if (n_tx && opcode == SPINOR_OP_WD_EVCR &&
>> +	    !(txbuf[0] & EVCR_QUAD_EN_MICRON)) {
>> +		struct cqspi_flash_pdata *f_pdata;
>> +
>> +		f_pdata = &cqspi->f_pdata[cqspi->current_cs];
>> +		f_pdata->quad_mode_set = 1;
>
> No, please don't do this. The whole point of the spi-nor layer is that
> we don't want low-level drivers having to snoop every type of flash
> command. We want to have proper feedback between spi-nor.c and your
> driver, so you *know* when you're using a quad-enabled device.
>
> Food for thought: what happens for a non-Micron SPI flash that uses quad
> mode?
>
> Is it sufficient to just check if nor->flash_read == SPI_NOR_QUAD?
>

I *said* it was ugly :)

Here's the deal.  The Cadence controller has its own quad mode setting, 
which must match the setting of the chip (or the quad-mode command.) 
Before the addition of micron_quad_enable(), spi-nor was using a 
quad-mode read command.  That was all good, because we could use 
nor->flash_read == SPI_NOR_QUAD to set the Cadence controller properly.

However, micron_quad_enable() sets quad mode in the Micron chip.  At 
that point, all communication with the chip must be in quad mode, even 
the very next read-status command.  The micron_quad_enable() function 
reads status and EVCR register to see if the quad-mode command 'took'. 
This all happens before nor->flash_read is set to SPI_NOR_QUAD.  If I 
don't set the Cadence controller into quad mode immediately after the 
chip is set into quad mode, then status is garbage and the probe fails.

I agree that any other chip with a quad mode, separate from quad 
commands, will be jacked up too.

So...how can I know when to set the Cadence controller into quad mode?
  Perhaps the micron_quad_enable() should set nor->flash_read = 
SPI_NOR_QUAD as soon as it sends the command to the chip?

...

-Graham

WARNING: multiple messages have this Message-ID (diff)
From: Graham Moore <grmoore@opensource.altera.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: <linux-mtd@lists.infradead.org>,
	David Woodhouse <dwmw2@infradead.org>,
	<linux-kernel@vger.kernel.org>,
	Alan Tull <atull@opensource.altera.com>,
	"Dinh Nguyen" <dinguyen@opensource.altera.com>,
	Yves Vandervennet <yvanderv@opensource.altera.com>
Subject: Re: [PATCH V4 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Date: Mon, 1 Jun 2015 08:49:22 -0500	[thread overview]
Message-ID: <556C62E2.3030808@opensource.altera.com> (raw)
In-Reply-To: <20150520222606.GQ11598@ld-irv-0074>



On 05/20/2015 05:26 PM, Brian Norris wrote:
> On Mon, Mar 23, 2015 at 08:36:22AM -0500, Graham Moore wrote:
...
I'm fixing the sparse, smatch, unused variables, etc.
...
>> +	if (n_tx && opcode == SPINOR_OP_WD_EVCR &&
>> +	    !(txbuf[0] & EVCR_QUAD_EN_MICRON)) {
>> +		struct cqspi_flash_pdata *f_pdata;
>> +
>> +		f_pdata = &cqspi->f_pdata[cqspi->current_cs];
>> +		f_pdata->quad_mode_set = 1;
>
> No, please don't do this. The whole point of the spi-nor layer is that
> we don't want low-level drivers having to snoop every type of flash
> command. We want to have proper feedback between spi-nor.c and your
> driver, so you *know* when you're using a quad-enabled device.
>
> Food for thought: what happens for a non-Micron SPI flash that uses quad
> mode?
>
> Is it sufficient to just check if nor->flash_read == SPI_NOR_QUAD?
>

I *said* it was ugly :)

Here's the deal.  The Cadence controller has its own quad mode setting, 
which must match the setting of the chip (or the quad-mode command.) 
Before the addition of micron_quad_enable(), spi-nor was using a 
quad-mode read command.  That was all good, because we could use 
nor->flash_read == SPI_NOR_QUAD to set the Cadence controller properly.

However, micron_quad_enable() sets quad mode in the Micron chip.  At 
that point, all communication with the chip must be in quad mode, even 
the very next read-status command.  The micron_quad_enable() function 
reads status and EVCR register to see if the quad-mode command 'took'. 
This all happens before nor->flash_read is set to SPI_NOR_QUAD.  If I 
don't set the Cadence controller into quad mode immediately after the 
chip is set into quad mode, then status is garbage and the probe fails.

I agree that any other chip with a quad mode, separate from quad 
commands, will be jacked up too.

So...how can I know when to set the Cadence controller into quad mode?
  Perhaps the micron_quad_enable() should set nor->flash_read = 
SPI_NOR_QUAD as soon as it sends the command to the chip?

...

-Graham

  reply	other threads:[~2015-06-01 13:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-23 13:36 [PATCH V4 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver Graham Moore
2015-03-23 13:36 ` Graham Moore
2015-03-23 13:36 ` [PATCH V4 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller Graham Moore
2015-03-23 13:36   ` Graham Moore
2015-05-11 13:50   ` Graham Moore
2015-05-11 13:50     ` Graham Moore
2015-05-20 22:26   ` Brian Norris
2015-05-20 22:26     ` Brian Norris
2015-06-01 13:49     ` Graham Moore [this message]
2015-06-01 13:49       ` Graham Moore
2015-07-24 12:45 ` [PATCH V4 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver Marek Vasut
2015-07-24 16:12   ` Graham Moore
2015-07-24 16:25     ` Marek Vasut
2015-07-24 17:16       ` Graham Moore
2015-07-24 19:57         ` Marek Vasut

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=556C62E2.3030808@opensource.altera.com \
    --to=grmoore@opensource.altera.com \
    --cc=atull@opensource.altera.com \
    --cc=computersforpeace@gmail.com \
    --cc=dinguyen@opensource.altera.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=yvanderv@opensource.altera.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.