Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 3月, 2016 1 次提交
  3. 21 3月, 2016 1 次提交
  5. 12 3月, 2016 1 次提交
  7. 11 3月, 2016 2 次提交
    • A
      mtd: nand: Qualcomm NAND controller driver · c76b78d8
      由 Archit Taneja 提交于 
      The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx,
MDM9x15 series.

It exists as a sub block inside the IPs EBI2 (External Bus Interface 2)
and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a
broader interface for external slow peripheral devices such as LCD and
NAND/NOR flash memory or SRAM like interfaces.

We add support for the NAND controller found within EBI2. For the SoCs
of our interest, we only use the NAND controller within EBI2. Therefore,
it's safe for us to assume that the NAND controller is a standalone block
within the SoC.

The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND
flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and
16 bit correction/step) and RS ECC(4 bit correction/step) that covers main
and spare data. The controller contains an internal 512 byte page buffer
to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA
for register read/write and data transfers. The controller performs page
reads and writes at a codeword/step level of 512 bytes. It can support up
to 2 external chips of different configurations.

The driver prepares register read and write configuration descriptors for
each codeword, followed by data descriptors to read or write data from the
controller's internal buffer. It uses a single ADM DMA channel that we get
via dmaengine API. The controller requires 2 ADM CRCIs for command and
data flow control. These are passed via DT.

The ecc layout used by the controller is syndrome like, but we can't use
the standard syndrome ecc ops because of several reasons. First, the amount
of data bytes covered by ecc isn't same in each step. Second, writing to
free oob space requires us writing to the entire step in which the oob
lies. This forces us to create our own ecc ops.

One more difference is how the controller accesses the bad block marker.
The controller ignores reading the marker when ECC is enabled. ECC needs
to be explicity disabled to read or write to the bad block marker. The
nand_bbt helpers library hence can't access BBMs for the controller.
For now, we skip the creation of BBT and populate chip->block_bad and
chip->block_markbad helpers instead.
Reviewed-by: NAndy Gross <agross@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c76b78d8
    • A
      mtd: nand: don't select chip in nand_chip's block_bad op · 9f3e0429
      由 Archit Taneja 提交于 
      One of the arguments passed to struct nand_chip's block_bad op is
'getchip', which, if true, is supposed to get and select the nand device,
and later unselect and release the device.

This op is intended to be replaceable by drivers. The drivers shouldn't
be responsible for selecting/unselecting chip. Like other ops, the chip
should already be selected before the block_bad op is called.

Remove the getchip argument from the block_bad op and
nand_block_checkbad. Move the chip selection to nand_block_isbad, since it
is the only caller to nand_block_checkbad which requires chip selection.

Modify nand_block_bad (the default function for the op) such that it
doesn't select the chip.

Remove the getchip argument from the bad_block funcs in cafe_nand,
diskonchip and docg4 drivers.
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      9f3e0429
  9. 08 3月, 2016 19 次提交
  11. 06 3月, 2016 1 次提交
  13. 05 3月, 2016 4 次提交
  15. 01 3月, 2016 1 次提交
  17. 25 2月, 2016 1 次提交
  19. 16 2月, 2016 1 次提交
  21. 13 2月, 2016 8 次提交
    • C
      mtd: spi-nor: remove micron_quad_enable() · 3b5394a3
      由 Cyrille Pitchen 提交于 
      This patch remove the micron_quad_enable() function which force the Quad
SPI mode. However, once this mode is enabled, the Micron memory expect ALL
commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
calling spi_nor_wait_till_ready() right after the update of the Enhanced
Volatile Configuration Register (EVCR) in the micron_quad_enable() as
the SPI controller driver is not aware about the protocol change.

Since there is almost no performance increase using Fast Read 4-4-4
commands instead of Fast Read 1-1-4 commands, we rather keep on using the
Extended SPI mode than enabling the Quad SPI mode.

Let's take the example of the pretty standard use of 8 dummy cycles during
Fast Read operations on 64KB erase sectors:

Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
for the read data; so 131112 clock cycles.

On the other hand the Fast Read 4-4-4 would require 2 cycles for the
command, then 6 cycles for the 3byte address followed by 8 dummy clock
cycles and finally 65536*2 cycles for the read data. So 131088 clock
cycles. The theorical bandwidth increase is 0.0%.

Now using Fast Read operations on 512byte pages:
Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
theorical bandwidth increase is 2.3%.
Consecutive reads for non sequential pages is not a relevant use case so
The Quad SPI mode is not worth it.

mtd_speedtest seems to confirm these figures.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Fixes: 548cd3ab ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      3b5394a3
    • S
      mtd: spi-nor: Add support for s25fl116k · c0826679
      由 Sascha Hauer 提交于 
      The Spansion s25fl116k is a 16MBit NOR Flash supporting dual and
quad read operations.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c0826679
    • T
      mtd: nand: pxa3xx_nand: add support for partial chunks · c2cdace7
      由 Thomas Petazzoni 提交于 
      This commit is needed to properly support the 8-bits ECC configuration
with 4KB pages.

When pages larger than 2 KB are used on platforms using the PXA3xx
NAND controller, the reading/programming operations need to be split
in chunks of 2 KBs or less because the controller FIFO is limited to
about 2 KB (i.e a bit more than 2 KB to accommodate OOB data). Due to
this requirement, the data layout on NAND is a bit strange, with ECC
interleaved with data, at the end of each chunk.

When a 4-bits ECC configuration is used with 4 KB pages, the physical
data layout on the NAND looks like this:

| 2048 data | 32 spare | 30 ECC | 2048 data | 32 spare | 30 ECC |

So the data chunks have an equal size, 2080 bytes for each chunk,
which the driver supports properly.

When a 8-bits ECC configuration is used with 4KB pages, the physical
data layout on the NAND looks like this:

| 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 1024 data | 30 ECC | 64 spare | 30 ECC |

So, the spare area is stored in its own chunk, which has a different
size than the other chunks. Since OOB is not used by UBIFS, the initial
implementation of the driver has chosen to not support reading this
additional "spare" chunk of data.

Unfortunately, Marvell has chosen to store the BBT signature in the
OOB area. Therefore, if the driver doesn't read this spare area, Linux
has no way of finding the BBT. It thinks there is no BBT, and rewrites
one, which U-Boot does not recognize, causing compatibility problems
between the bootloader and the kernel in terms of NAND usage.

To fix this, this commit implements the support for reading a partial
last chunk. This support is currently only useful for the case of 8
bits ECC with 4 KB pages, but it will be useful in the future to
enable other configurations such as 12 bits and 16 bits ECC with 4 KB
pages, or 8 bits ECC with 8 KB pages, etc. All those configurations
have a "last" chunk that doesn't have the same size as the other
chunks.

In order to implement reading of the last chunk, this commit:

 - Adds a number of new fields to the pxa3xx_nand_info to describe how
   many full chunks and how many chunks we have, the size of full
   chunks and partial chunks, both in terms of data area and spare
   area.

 - Fills in the step_chunk_size and step_spare_size variables to
   describe how much data and spare should be read/written for the
   current read/program step.

 - Reworks the state machine to accommodate doing the additional read
   or program step when a last partial chunk is used.

This commit has been tested on a Marvell Armada 398 DB board, with a
4KB page NAND, tested in both 4 bits ECC and 8 bits ECC
configurations. Robert Jarzmik has tested on some PXA platforms.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c2cdace7
    • S
      mtd: bcm63xxpart: Move NOR flash layout to a separate function · 4110fdd2
      由 Simon Arlott 提交于 
      Move the NOR flash layout to a separate function to allow the NAND flash
layout to be supported.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      4110fdd2
    • S
      mtd: bcm63xxpart: Null terminate and validate conversion of flash strings · 2c4fd433
      由 Simon Arlott 提交于 
      Strings read from flash could be missing null termination characters, or
not contain valid integers.

Null terminate the strings and check for errors when converting them to
integers.

Also validate that the addresses are at least BCM963XX_EXTENDED_SIZE
because this will be subtracted from them.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      2c4fd433
    • S
      mtd: bcm63xxpart: Extract read of image tag to separate function · 7fffa694
      由 Simon Arlott 提交于 
      Extract image tag reading and CRC check to a separate function.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      7fffa694
    • S
      mtd: bcm63xxpart: Remove dependency on mach-bcm63xx · 436e94a6
      由 Simon Arlott 提交于 
      Read nvram directly from flash instead of using the in-memory copy that
mach-bcm63xx has, to remove the dependency on mach-bcm63xx and allow the
parser to work on bmips too.

Rename remaining BCM63XX defines to BCM963XX as these are properties of
the flash layout on the board.

BCM963XX_DEFAULT_PSI_SIZE changes from SZ_64K to 64 because it will be
multiplied by SZ_1K later on.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      436e94a6
    • R
      mtd: atmel_nand: Support 32-bit ECC strength · 94248462
      由 Romain Izard 提交于 
      As the SAMA5D2 controller supports the 32-bit ECC strength, accept it
as a valid setting when required by the device tree or the NAND
parameter page.

Then configure the controller to use this new setting.

For the binding:
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRomain Izard <romain.izard.pro@gmail.com>
Tested-by: NWenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      94248462