From: "Rafał Miłecki" <zajec5@gmail.com>
To: linux-mtd@lists.infradead.org,
David Woodhouse <David.Woodhouse@intel.com>,
Artem Bityutskiy <dedekind1@gmail.com>,
Brian Norris <computersforpeace@gmail.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>
Subject: [PATCH V2] mtd: spi-nor: add Kconfig option to disable 4K sectors
Date: Sun, 17 Aug 2014 11:27:26 +0200 [thread overview]
Message-ID: <1408267646-6643-1-git-send-email-zajec5@gmail.com> (raw)
In-Reply-To: <1408220271-21455-1-git-send-email-zajec5@gmail.com>
Current situation with 4K sectors is quite messy. First of all, some
MTD "users" don't work with such small size. An example may be UBIFS
which requires 15 KiB erase blocks as a minimum. In theory spi-nor
should provide multiple erase regions and MTD "users" should use the
one they need. Unforunately that is not implemented.
In the result our flashes database in spi-nor is hackish. For some
flashes we pretend they don't support 4K sectors just because some
distribution uses UBIFS on it. This ofc leads to conflicts, like
Samsung using w25q128 with 4K sectors vs. OpenWrt requiring it to
pretend it's 64 KiB blocks only.
My idea (plan?) for fixing this situation:
1) Use real hw info (this requires a way for disabling 4K for now)
2) Provide detailed info about erase regions
3) Make UBIFS work with devices that support 4K sectors
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
V2: Add extra info about performance in Kconfig. Thanks Kevin.
Fix typo s/users/uses/ in commit message.
---
drivers/mtd/spi-nor/Kconfig | 14 ++++++++++++++
drivers/mtd/spi-nor/spi-nor.c | 5 ++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index f8acfa4..abab223 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -7,6 +7,20 @@ menuconfig MTD_SPI_NOR
if MTD_SPI_NOR
+config MTD_SPI_NOR_USE_4K_SECTORS
+ bool "Use small 4096 B erase sectors"
+ default y
+ help
+ Many flash memories support erasing small (4096 B) sectors. Depending
+ on the usage this feature may provide performance gain in comparison
+ to erasing whole blocks (32/64 KiB).
+ Changing small part of flash content is usually faster with small
+ sectors. On the other hand erasing should be faster when using 64 KiB
+ block instead of 16 × 4 KiB sectors.
+
+ Please note that some tools/drivers/filesystems may not work with
+ 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
+
config SPI_FSL_QUADSPI
tristate "Freescale Quad SPI controller"
depends on ARCH_MXC
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ba3f61e..ae16aa2 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -987,6 +987,7 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
nor->wait_till_ready == spi_nor_wait_till_ready)
nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
+#ifdef CONFIG_MTD_SPI_NOR_USE_4K_SECTORS
/* prefer "small sector" erase if possible */
if (info->flags & SECT_4K) {
nor->erase_opcode = SPINOR_OP_BE_4K;
@@ -994,7 +995,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
} else if (info->flags & SECT_4K_PMC) {
nor->erase_opcode = SPINOR_OP_BE_4K_PMC;
mtd->erasesize = 4096;
- } else {
+ } else
+#endif
+ {
nor->erase_opcode = SPINOR_OP_SE;
mtd->erasesize = info->sector_size;
}
--
1.8.4.5
next prev parent reply other threads:[~2014-08-17 9:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-16 20:17 [PATCH] mtd: spi-nor: add Kconfig option to disable 4K sectors Rafał Miłecki
2014-08-16 21:06 ` Kevin Cernekee
2014-08-17 9:27 ` Rafał Miłecki [this message]
2014-09-28 0:28 ` [PATCH V2] " Brian Norris
2014-09-28 20:29 ` Rafał Miłecki
2014-09-28 21:17 ` Brian Norris
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=1408267646-6643-1-git-send-email-zajec5@gmail.com \
--to=zajec5@gmail.com \
--cc=David.Woodhouse@intel.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).