[PATCH 0/2] MTD: spi-nor: add support for sst26wf016, sst26wf032
Add support for the SST sst26wf016 and sst26wf032 flash IC: sst26wf*** flash series block protection implementation differs from other SST series, so we add implementation for sst26wf*** lock/unlock/is_locked functions. Add sst26wf016 and sst26wf032 flash IC info to spi_flash_ids list. NOTE: these patches is basically following mine u-boot commits port: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3d4fed87a5fa3ffedf64ff2811cd95c5ac4503ac http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a19e97157c3721ef9c4b15c68c1773467a3b4a98 Eugeniy Paltsev (2): mtd: spi-nor: Add support of sst26wf* flash ICs protection ops mtd: spi-nor: add support for sst26wf016, sst26wf032 drivers/mtd/spi-nor/spi-nor.c | 179 ++ include/linux/mtd/spi-nor.h | 4 + 2 files changed, 183 insertions(+) -- 2.14.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/2] mtd: spi-nor: Add support of sst26wf* flash ICs protection ops
sst26wf flash series block protection implementation differs
from other SST series, so add specific implementation
flash_lock/flash_unlock/flash_is_locked functions for sst26wf
flash ICs.
NOTE:
this patch is basically following mine u-boot commit port:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3d4fed87a5fa3ffedf64ff2811cd95c5ac4503ac
Signed-off-by: Eugeniy Paltsev
---
drivers/mtd/spi-nor/spi-nor.c | 177 ++
include/linux/mtd/spi-nor.h | 4 +
2 files changed, 181 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d9c368c44194..6f74c75c9ddc 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -598,6 +598,177 @@ static int write_sr_and_check(struct spi_nor *nor, u8
status_new, u8 mask)
return ((ret & mask) != (status_new & mask)) ? -EIO : 0;
}
+/*
+ * sst26wf016/sst26wf032/sst26wf064 have next block protection:
+ * 4x - 8 KByte blocks - read & write protection bits - upper addresses
+ * 1x - 32 KByte blocks - write protection bits
+ * rest - 64 KByte blocks - write protection bits
+ * 1x - 32 KByte blocks - write protection bits
+ * 4x - 8 KByte blocks - read & write protection bits - lower addresses
+ *
+ * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
+ * will be treated as single block.
+ */
+#define SST26_BPR_8K_NUM 4
+#define SST26_MAX_BPR_REG_LEN (18 + 1)
+#define SST26_BOUND_REG_SIZE ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
+
+enum lock_ctl {
+ SST26_CTL_LOCK,
+ SST26_CTL_UNLOCK,
+ SST26_CTL_CHECK
+};
+
+static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl
ctl)
+{
+ switch (ctl) {
+ case SST26_CTL_LOCK:
+ cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
+ break;
+ case SST26_CTL_UNLOCK:
+ cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
+ break;
+ case SST26_CTL_CHECK:
+ return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
+ }
+
+ return false;
+}
+
+/*
+ * Lock, unlock or check lock status of the flash region of the flash
(depending
+ * on the lock_ctl value)
+ */
+static int sst26_lock_ctl(struct spi_nor *nor, loff_t ofs, uint64_t len, enum
lock_ctl ctl)
+{
+ struct mtd_info *mtd = &nor->mtd;
+ u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
+ bool lower_64k = false, upper_64k = false;
+ u8 bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
+ int ret;
+
+ /* Check length and offset for 64k alignment */
+ if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1))) {
+ dev_err(nor->dev, "length or offset is not 64KiB allighned\n");
+ return -EINVAL;
+ }
+
+ if (ofs + len > mtd->size) {
+ dev_err(nor->dev, "range is more than device size: %#llx +
%#llx > %#llx\n",
+ ofs, len, mtd->size);
+ return -EINVAL;
+ }
+
+ /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
+ if (mtd->size != SZ_2M &&
+ mtd->size != SZ_4M &&
+ mtd->size != SZ_8M)
+ return -EINVAL;
+
+ bpr_size = 2 + (mtd->size / SZ_64K / 8);
+
+ nor->read_reg(nor, SPINOR_OP_READ_BPR, bpr_buff, bpr_size);
+ if (ret < 0) {
+ dev_err(nor->dev, "fail to read block-protection register\n");
+ return ret;
+ }
+
+ rptr_64k = min_t(u32, ofs + len, mtd->size - SST26_BOUND_REG_SIZE);
+ lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
+
+ upper_64k = ((ofs + len) > (mtd->size - SST26_BOUND_REG_SIZE));
+ lower_64k = (ofs < SST26_BOUND_REG_SIZE);
+
+ /* Lower bits in block-protection register are about 64k region */
+ bpr_ptr = lptr_64k / SZ_64K - 1;
+
+ /* Process 64K blocks region */
+ while (lptr_64k < rptr_64k) {
+ if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+ return EACCES;
+
+ bpr_ptr++;
+ lptr_64k += SZ_64K;
+ }
+
+ /* 32K and 8K region bits in BPR are after 64k region bits */
+ bpr_ptr = (mtd->size - 2 * SST26_BOUND_REG_SIZE) / SZ_64K;
+
+ /* Process lower 32K block region */
+ if (lower_64k)
+ if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+ return EACCES;
+
+ bpr_ptr++;
+
+ /* Process upper 32K block region */
+ if (upper_64k)
+ if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+ return EACCES;
+
+ bpr_ptr++;
+
+ /* Process lower 8K block regions */
+ for (i = 0; i < SST26_BPR_8K_NUM; i++) {
+ if (lower_64k)
+ if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+ return EACCES;
+
+ /* In 8K area BPR has both read and write
[PATCH 2/2] mtd: spi-nor: add support for sst26wf016, sst26wf032
This commit adds support for the SST sst26wf016 and sst26wf032
flash IC.
NOTE:
this patch is basically following mine u-boot commit port:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a19e97157c3721ef9c4b15c68c1773467a3b4a98
Signed-off-by: Eugeniy Paltsev
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6f74c75c9ddc..e1562363862a 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1333,6 +1333,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024, 8, SECT_4K) },
{ "sst25wf040", INFO(0xbf2504, 0, 64 * 1024, 8, SECT_4K | SST_WRITE)
},
{ "sst25wf080", INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE)
},
+ { "sst26wf016", INFO(0xbf2651, 0, 64 * 1024, 32, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "sst26wf032", INFO(0xbf2622, 0, 64 * 1024, 64, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
/* ST Microelectronics -- newer production may have feature updates */
--
2.14.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
Hi,
On 08/22/2018 11:40 AM, Eugeniy Paltsev wrote:
>
>> Reading kernel/dma/* I see what you mean. We check @ioc_enable at the time of
>> registering the dma op for coherent vs. non coherent case, so there's common
>> vs.
>> ARC versions of alloc/free for coherent vs. noncoherent.
> Just to be sure that we understand both each other and source code correctly:
> - In coherent case we use dma_direct_* ops which doesn't use ARC alloc
> functions (arch_dma_{alloc|free})
> - In non-coherent case we use dma_noncoherent_* ops which uses ARC alloc
> functions (arch_dma_{alloc|free})
Right I see that.
>> But then I'm curious why
>> do we bother to check the following in new arch_dma_(alloc|free) at all.
>>
>> if (attrs & DMA_ATTR_NON_CONSISTENT)
>>
>> Isn't it supposed to be NON_CONSISTENT always given the way new code works ?
> DMA_ATTR_NON_CONSISTENT flag is not related to IOC topic.
> It is a flag which we can pass to dma_{alloc|free}_attrs function from driver
> side.
>
> According to documentation:
> DMA_ATTR_NON_CONSISTENT: Lets the platform to choose to return either
> consistent or non-consistent memory as it sees fit.
Right I'd them mixed up. But then in case of direct dma ops, the attr is simply
ignored in dma_alloc_attrs() -> dma_direct_alloc(). User always gets coherent
memory.
>
> We check this flag in arch_dma_alloc (which are used in non-coherent case) to
> skip MMU mapping if we are advertised that consistency is not required.
>
> So, actually we can get rid of this flag checking in arch_dma_alloc and
> simply always do MMU mapping to enforce non-cachability and return
> non-cacheable memory even if DMA_ATTR_NON_CONSISTENT is passed.
> But I don't sure we want to do that.
>
> BTW: dma_alloc_coherent is simply dma_alloc_attrs with attrs == 0.
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
On 07/30/2018 09:26 AM, Eugeniy Paltsev wrote:
> The ARC HS processor provides an IOC port (I/O coherency bus
> interface) that allows external devices such as DMA devices
> to access memory through the cache hierarchy, providing
> coherency between I/O transactions and the complete memory
> hierarchy.
>
> Some recent SoC with ARC HS (like HSDK) allow to select bus
> port (IOC or non-IOC port) for connecting DMA devices in runtime.
>
> With this patch we can use both HW-coherent and regular DMA
> peripherals simultaneously.
>
> NOTE:
> This patch series was stress tested on HSDK with iperf3 (ethernet)
> and bonie++ (usb and sdio) in three configurations:
> * IOC enabled globaly
> * IOC disabled globaly
> * IOC enabled partially (USB & SDIO are connected via IOC AXI port,
>ethernet is connected to DDR AXI port (non-IOC port)
>
> NOTE:
> If you want to test some device without IOC it is not enough
> to remove "dma-coherent" property from dts. You had to remap this
> device to regular DDR AXI port intead of IOC AXI port.
> You also need to apply 3 following patches firstly:
> https://www.mail-archive.com/linux-snps-arc@lists.infradead.org/msg03865.html
> https://www.mail-archive.com/linux-snps-arc@lists.infradead.org/msg03889.html
> https://www.mail-archive.com/linux-snps-arc@lists.infradead.org/msg03887.html
>
> NOTE:
> We don't touch any aperture configuration in this patch series. So we
> don't switch any devices between IOC and non-IOC AXI ports on any board.
> It can be done later if it is required.
>
> Changes v1->v2 (Thanks to Christoph):
> * Don't select DMA_DIRECT_OPS explicitly as it is already selected by
>DMA_NONCOHERENT_OPS
> * Remove check for HIGHMEM pages from arch_dma_{alloc, free}
>
> Eugeniy Paltsev (4):
> ARC: DTS: mark DMA devices connected through IOC port as dma-coherent
> ARC: allow to use IOC and non-IOC DMA devices simultaneously
> ARC: IOC: panic if both IOC and ZONE_HIGHMEM enabled
> ARC: don't check for HIGHMEM pages in arch_dma_alloc
>
> arch/arc/boot/dts/axc003.dtsi | 26
> arch/arc/boot/dts/axc003_idu.dtsi | 26
> arch/arc/boot/dts/hsdk.dts | 4 +++
> arch/arc/include/asm/dma-mapping.h | 13
> arch/arc/mm/cache.c| 30 +-
> arch/arc/mm/dma.c | 62
> +++---
> 6 files changed, 115 insertions(+), 46 deletions(-)
> create mode 100644 arch/arc/include/asm/dma-mapping.h
Apologies for the delay in getting to this - series applied and pushed to
for-curr
Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
On Tue, Sep 04, 2018 at 01:14:49PM -0700, Vineet Gupta wrote: > Apologies for the delay in getting to this - series applied and pushed to > for-curr This is going to create really annoying merge conflicts with work pending for the dma-mapping tree. That's why I requested earlier to merge it either via the dma-mapping tree or some shared branch. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
On 09/04/2018 02:07 PM, Christoph Hellwig wrote: > On Tue, Sep 04, 2018 at 01:14:49PM -0700, Vineet Gupta wrote: >> Apologies for the delay in getting to this - series applied and pushed to >> for-curr > This is going to create really annoying merge conflicts with > work pending for the dma-mapping tree. That's why I requested earlier > to merge it either via the dma-mapping tree or some shared branch. Sorry I missed that request of yours on top of the last msg. I would really want this to get into 4.19 (understand that merge window is done etc) given that there's a bunch of other changes lined up behind this one. I was just sucked up into "other" stuff and could not get to it sooner. Please bear with me this once - hopefully it would be smoother going fwd. Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/4] ARC: allow to use IOC and non-IOC DMA devices simultaneously
On Tue, Sep 04, 2018 at 09:34:43PM +, Vineet Gupta wrote: > Sorry I missed that request of yours on top of the last msg. I would really > want > this to get into 4.19 (understand that merge window is done etc) given that > there's a bunch of other changes lined up behind this one. I was just sucked > up > into "other" stuff and could not get to it sooner. Please bear with me this > once - > hopefully it would be smoother going fwd. Oh, if you manage to get it into 4.19 and do so quickly that is fine as well. I just don't want it in your 4.20 queue creating conflicts. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
