Re: [PATCH V4 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
From: Graham Moore
Date: Mon Jun 01 2015 - 09:53:36 EST
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/