* [PATCH v8 10/19] mtd: spi-nor: core: use dummy cycle and address width info from SFDP
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in octal DTR mode.
Use that information to send the correct Read SR command.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 642e3c07acf9..2ad248140b6c 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -357,6 +357,8 @@ int spi_nor_write_disable(struct spi_nor *nor)
static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
{
int ret;
+ u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+ u8 dummy = nor->params->rdsr_dummy;
if (nor->spimem) {
struct spi_mem_op op =
@@ -365,10 +367,21 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, sr, 1));
+ if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+ op.addr.nbytes = addr_bytes;
+ op.addr.val = 0;
+ op.dummy.nbytes = dummy;
+ }
+
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
- sr, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
+ sr, 1);
}
if (ret)
@@ -388,6 +401,8 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
{
int ret;
+ u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+ u8 dummy = nor->params->rdsr_dummy;
if (nor->spimem) {
struct spi_mem_op op =
@@ -396,6 +411,12 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, fsr, 1));
+ if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+ op.addr.nbytes = addr_bytes;
+ op.addr.val = 0;
+ op.dummy.nbytes = dummy;
+ }
+
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
dummy cycles, the number of dummy cycles needed for a Read Status
Register command, and the number of address bytes needed for a Read
Status Register command.
We don't know what speed the controller is running at. Find the fast
read dummy cycles for the fastest frequency the flash can run at to be
sure we are never short of dummy cycles. If nothing is available,
default to 20. Flashes that use a different value should update it in
their fixup hooks.
Since we want to set read settings, expose spi_nor_set_read_settings()
in core.h.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 2 +-
drivers/mtd/spi-nor/core.h | 10 ++++
drivers/mtd/spi-nor/sfdp.c | 99 ++++++++++++++++++++++++++++++++++++++
3 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 388e695e763f..642e3c07acf9 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2355,7 +2355,7 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-static void
+void
spi_nor_set_read_settings(struct spi_nor_read_command *read,
u8 num_mode_clocks,
u8 num_wait_states,
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index de1e3917889f..7e6df8322da0 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -192,6 +192,9 @@ struct spi_nor_locking_ops {
*
* @size: the flash memory density in bytes.
* @page_size: the page size of the SPI NOR flash memory.
+ * @rdsr_dummy: dummy cycles needed for Read Status Register command.
+ * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
+ * command.
* @hwcaps: describes the read and page program hardware
* capabilities.
* @reads: read capabilities ordered by priority: the higher index
@@ -214,6 +217,8 @@ struct spi_nor_locking_ops {
struct spi_nor_flash_parameter {
u64 size;
u32 page_size;
+ u8 rdsr_dummy;
+ u8 rdsr_addr_nbytes;
struct spi_nor_hwcaps hwcaps;
struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
@@ -424,6 +429,11 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
int spi_nor_hwcaps_read2cmd(u32 hwcaps);
u8 spi_nor_convert_3to4_read(u8 opcode);
+void spi_nor_set_read_settings(struct spi_nor_read_command *read,
+ u8 num_mode_clocks,
+ u8 num_wait_states,
+ u8 opcode,
+ enum spi_nor_protocol proto);
void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
enum spi_nor_protocol proto);
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index ab086aa4746f..052cabb52df9 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -4,12 +4,15 @@
* Copyright (C) 2014, Freescale Semiconductor, Inc.
*/
+#include <linux/bitfield.h>
#include <linux/slab.h>
#include <linux/sort.h>
#include <linux/mtd/spi-nor.h>
#include "core.h"
+#define ROUND_UP_TO(x, y) (((x) + (y) - 1) / (y) * (y))
+
#define SFDP_PARAM_HEADER_ID(p) (((p)->id_msb << 8) | (p)->id_lsb)
#define SFDP_PARAM_HEADER_PTP(p) \
(((p)->parameter_table_pointer[2] << 16) | \
@@ -19,12 +22,14 @@
#define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
#define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
#define SFDP_4BAIT_ID 0xff84 /* 4-byte Address Instruction Table */
+#define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
#define SFDP_SIGNATURE 0x50444653U
#define SFDP_JESD216_MAJOR 1
#define SFDP_JESD216_MINOR 0
#define SFDP_JESD216A_MINOR 5
#define SFDP_JESD216B_MINOR 6
+#define SFDP_JESD216D_MINOR 8
struct sfdp_header {
u32 signature; /* Ox50444653U <=> "SFDP" */
@@ -70,6 +75,16 @@ struct sfdp_bfpt_erase {
u32 shift;
};
+/* xSPI Profile 1.0 table (from JESD216D.01). */
+#define PROFILE1_DWORD1_RD_FAST_CMD GENMASK(15, 8)
+#define PROFILE1_DWORD1_RDSR_DUMMY BIT(28)
+#define PROFILE1_DWORD1_RDSR_ADDR_BYTES BIT(29)
+#define PROFILE1_DWORD4_DUMMY_200MHZ GENMASK(11, 7)
+#define PROFILE1_DWORD5_DUMMY_166MHZ GENMASK(31, 27)
+#define PROFILE1_DWORD5_DUMMY_133MHZ GENMASK(21, 17)
+#define PROFILE1_DWORD5_DUMMY_100MHZ GENMASK(11, 7)
+#define PROFILE1_DUMMY_DEFAULT 20
+
#define SMPT_CMD_ADDRESS_LEN_MASK GENMASK(23, 22)
#define SMPT_CMD_ADDRESS_LEN_0 (0x0UL << 22)
#define SMPT_CMD_ADDRESS_LEN_3 (0x1UL << 22)
@@ -1110,6 +1125,86 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
return ret;
}
+/**
+ * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
+ * @nor: pointer to a 'struct spi_nor'
+ * @param_header: pointer to the 'struct sfdp_parameter_header' describing
+ * the 4-Byte Address Instruction Table length and version.
+ * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_parse_profile1(struct spi_nor *nor,
+ const struct sfdp_parameter_header *profile1_header,
+ struct spi_nor_flash_parameter *params)
+{
+ u32 *table, opcode, addr;
+ size_t len;
+ int ret, i;
+ u8 dummy;
+
+ len = profile1_header->length * sizeof(*table);
+ table = kmalloc(len, GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
+
+ addr = SFDP_PARAM_HEADER_PTP(profile1_header);
+ ret = spi_nor_read_sfdp(nor, addr, len, table);
+ if (ret)
+ goto out;
+
+ /* Fix endianness of the table DWORDs. */
+ for (i = 0; i < profile1_header->length; i++)
+ table[i] = le32_to_cpu(table[i]);
+
+ /* Get 8D-8D-8D fast read opcode and dummy cycles. */
+ opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
+
+ /*
+ * We don't know what speed the controller is running at. Find the
+ * dummy cycles for the fastest frequency the flash can run at to be
+ * sure we are never short of dummy cycles. A value of 0 means the
+ * frequency is not supported.
+ *
+ * Default to PROFILE1_DUMMY_DEFAULT if we don't find anything, and let
+ * flashes set the correct value if needed in their fixup hooks.
+ */
+ dummy = FIELD_GET(PROFILE1_DWORD4_DUMMY_200MHZ, table[3]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_166MHZ, table[4]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_133MHZ, table[4]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_100MHZ, table[4]);
+ if (!dummy)
+ dummy = PROFILE1_DUMMY_DEFAULT;
+
+ /* Round up to an even value to avoid tripping controllers up. */
+ dummy = ROUND_UP_TO(dummy, 2);
+
+ /* Update the fast read settings. */
+ spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, dummy, opcode,
+ SNOR_PROTO_8_8_8_DTR);
+
+ /*
+ * Set the Read Status Register dummy cycles and dummy address bytes.
+ */
+ if (table[0] & PROFILE1_DWORD1_RDSR_DUMMY)
+ params->rdsr_dummy = 8;
+ else
+ params->rdsr_dummy = 4;
+
+ if (table[0] & PROFILE1_DWORD1_RDSR_ADDR_BYTES)
+ params->rdsr_addr_nbytes = 4;
+ else
+ params->rdsr_addr_nbytes = 0;
+
+out:
+ kfree(table);
+ return ret;
+}
+
/**
* spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters.
* @nor: pointer to a 'struct spi_nor'
@@ -1211,6 +1306,10 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
err = spi_nor_parse_4bait(nor, param_header, params);
break;
+ case SFDP_PROFILE1_ID:
+ err = spi_nor_parse_profile1(nor, param_header, params);
+ break;
+
default:
break;
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 08/19] mtd: spi-nor: sfdp: get command opcode extension type from BFPT
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 17 +++++++++++++++++
drivers/mtd/spi-nor/sfdp.h | 6 ++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 96960f2f3d7a..ab086aa4746f 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -609,6 +609,23 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
+ /* 8D-8D-8D command extension. */
+ switch (bfpt.dwords[BFPT_DWORD(18)] & BFPT_DWORD18_CMD_EXT_MASK) {
+ case BFPT_DWORD18_CMD_EXT_REP:
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_INV:
+ nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_RES:
+ return -EINVAL;
+
+ case BFPT_DWORD18_CMD_EXT_16B:
+ dev_err(nor->dev, "16-bit opcodes not supported\n");
+ return -ENOTSUPP;
+ }
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index f8198af43a63..e15e30796d62 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -84,6 +84,12 @@ struct sfdp_bfpt {
#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD (0x4UL << 20)
#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20) /* Spansion */
+#define BFPT_DWORD18_CMD_EXT_MASK GENMASK(30, 29)
+#define BFPT_DWORD18_CMD_EXT_REP (0x0UL << 29) /* Repeat */
+#define BFPT_DWORD18_CMD_EXT_INV (0x1UL << 29) /* Invert */
+#define BFPT_DWORD18_CMD_EXT_RES (0x2UL << 29) /* Reserved */
+#define BFPT_DWORD18_CMD_EXT_16B (0x3UL << 29) /* 16-bit opcode */
+
struct sfdp_parameter_header {
u8 id_lsb;
u8 minor;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 07/19] mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.
The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.
So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 7 ++++++-
drivers/mtd/spi-nor/sfdp.h | 5 +++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 5cecc4ba2141..96960f2f3d7a 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -549,7 +549,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
SNOR_ERASE_TYPE_MASK;
/* Stop here if not JESD216 rev A or later. */
- if (bfpt_header->length < BFPT_DWORD_MAX)
+ if (bfpt_header->length == BFPT_DWORD_MAX_JESD216)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
@@ -605,6 +605,11 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return -EINVAL;
}
+ /* Stop here if JESD216 rev B. */
+ if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
+ return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
+ params);
+
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index e0a8ded04890..f8198af43a63 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -10,11 +10,11 @@
/* Basic Flash Parameter Table */
/*
- * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * JESD216 rev D defines a Basic Flash Parameter Table of 20 DWORDs.
* They are indexed from 1 but C arrays are indexed from 0.
*/
#define BFPT_DWORD(i) ((i) - 1)
-#define BFPT_DWORD_MAX 16
+#define BFPT_DWORD_MAX 20
struct sfdp_bfpt {
u32 dwords[BFPT_DWORD_MAX];
@@ -22,6 +22,7 @@ struct sfdp_bfpt {
/* The first version of JESD216 defined only 9 DWORDs. */
#define BFPT_DWORD_MAX_JESD216 9
+#define BFPT_DWORD_MAX_JESD216B 16
/* 1st DWORD. */
#define BFPT_DWORD1_FAST_READ_1_1_2 BIT(16)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 06/19] mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
JESD216D.01 says that when the address width can be 3 or 4, it defaults
to 3 and enters 4-byte mode when given the appropriate command. So, when
we see a configurable width, default to 3 and let flash that default to
4 change it in a post-bfpt fixup.
This fixes SMPT parsing for flashes with configurable address width. If
the SMPT descriptor advertises variable address width, we use
nor->addr_width as the address width. But since it was not set to any
value from the SFDP table, the read command uses an address width of 0,
resulting in an incorrect read being issued.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index f917631c8110..5cecc4ba2141 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -460,6 +460,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
/* Number of address bytes. */
switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
+ case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
nor->addr_width = 3;
break;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 05/19] mtd: spi-nor: add support for DTR protocol
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
Double Transfer Rate (DTR) is SPI protocol in which data is transferred
on each clock edge as opposed to on each clock cycle. Make
framework-level changes to allow supporting flashes in DTR mode.
Right now, mixed DTR modes are not supported. So, for example a mode
like 4S-4D-4D will not work. All phases need to be either DTR or STR.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 305 ++++++++++++++++++++++++++++--------
drivers/mtd/spi-nor/core.h | 6 +
drivers/mtd/spi-nor/sfdp.c | 9 +-
include/linux/mtd/spi-nor.h | 51 ++++--
4 files changed, 295 insertions(+), 76 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 1ab4386a099a..388e695e763f 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -40,6 +40,76 @@
#define SPI_NOR_MAX_ADDR_WIDTH 4
+/**
+ * spi_nor_get_cmd_ext() - Get the command opcode extension based on the
+ * extension type.
+ * @nor: pointer to a 'struct spi_nor'
+ * @op: pointer to the 'struct spi_mem_op' whose properties
+ * need to be initialized.
+ *
+ * Right now, only "repeat" and "invert" are supported.
+ *
+ * Return: The opcode extension.
+ */
+static u8 spi_nor_get_cmd_ext(const struct spi_nor *nor,
+ const struct spi_mem_op *op)
+{
+ switch (nor->cmd_ext_type) {
+ case SPI_NOR_EXT_INVERT:
+ return ~op->cmd.opcode;
+
+ case SPI_NOR_EXT_REPEAT:
+ return op->cmd.opcode;
+
+ default:
+ dev_err(nor->dev, "Unknown command extension type\n");
+ return 0;
+ }
+}
+
+/**
+ * spi_nor_spimem_setup_op() - Set up common properties of a spi-mem op.
+ * @nor: pointer to a 'struct spi_nor'
+ * @op: pointer to the 'struct spi_mem_op' whose properties
+ * need to be initialized.
+ * @proto: the protocol from which the properties need to be set.
+ */
+void spi_nor_spimem_setup_op(const struct spi_nor *nor,
+ struct spi_mem_op *op,
+ const enum spi_nor_protocol proto)
+{
+ u8 ext;
+
+ op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(proto);
+
+ if (op->addr.nbytes)
+ op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+ if (op->dummy.nbytes)
+ op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+ if (op->data.nbytes)
+ op->data.buswidth = spi_nor_get_protocol_data_nbits(proto);
+
+ if (spi_nor_protocol_is_dtr(proto)) {
+ /*
+ * spi-mem supports mixed DTR modes, but right now we can only
+ * have all phases either DTR or STR. IOW, spi-mem can have
+ * something like 4S-4D-4D, but spi-nor can't. So, set all 4
+ * phases to either DTR or STR.
+ */
+ op->cmd.dtr = op->addr.dtr = op->dummy.dtr
+ = op->data.dtr = true;
+
+ /* 2 bytes per clock cycle in DTR mode. */
+ op->dummy.nbytes *= 2;
+
+ ext = spi_nor_get_cmd_ext(nor, op);
+ op->cmd.opcode = (op->cmd.opcode << 8) | ext;
+ op->cmd.nbytes = 2;
+ }
+}
+
/**
* spi_nor_spimem_bounce() - check if a bounce buffer is needed for the data
* transfer
@@ -104,14 +174,12 @@ static ssize_t spi_nor_spimem_read_data(struct spi_nor *nor, loff_t from,
ssize_t nbytes;
int error;
- /* get transfer protocols. */
- op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->read_proto);
- op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->read_proto);
- op.dummy.buswidth = op.addr.buswidth;
- op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
+ spi_nor_spimem_setup_op(nor, &op, nor->read_proto);
/* convert the dummy cycles to the number of bytes */
op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
+ if (spi_nor_protocol_is_dtr(nor->read_proto))
+ op.dummy.nbytes *= 2;
usebouncebuf = spi_nor_spimem_bounce(nor, &op);
@@ -169,13 +237,11 @@ static ssize_t spi_nor_spimem_write_data(struct spi_nor *nor, loff_t to,
ssize_t nbytes;
int error;
- op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->write_proto);
- op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->write_proto);
- op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
-
if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
op.addr.nbytes = 0;
+ spi_nor_spimem_setup_op(nor, &op, nor->write_proto);
+
if (spi_nor_spimem_bounce(nor, &op))
memcpy(nor->bouncebuf, buf, op.data.nbytes);
@@ -227,10 +293,16 @@ int spi_nor_write_enable(struct spi_nor *nor)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WREN,
- NULL, 0);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_WREN,
+ NULL, 0);
}
if (ret)
@@ -256,10 +328,16 @@ int spi_nor_write_disable(struct spi_nor *nor)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WRDI,
- NULL, 0);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_WRDI,
+ NULL, 0);
}
if (ret)
@@ -318,10 +396,15 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, fsr, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDFSR,
- fsr, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDFSR,
+ fsr, 1);
}
if (ret)
@@ -350,9 +433,15 @@ static int spi_nor_read_cr(struct spi_nor *nor, u8 *cr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, cr, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDCR, cr, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDCR,
+ cr, 1);
}
if (ret)
@@ -383,12 +472,17 @@ int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor,
- enable ? SPINOR_OP_EN4B :
- SPINOR_OP_EX4B,
- NULL, 0);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ enable ? SPINOR_OP_EN4B :
+ SPINOR_OP_EX4B,
+ NULL, 0);
}
if (ret)
@@ -419,10 +513,15 @@ static int spansion_set_4byte_addr_mode(struct spi_nor *nor, bool enable)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(1, nor->bouncebuf, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_BRWR,
- nor->bouncebuf, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor, SPINOR_OP_BRWR,
+ nor->bouncebuf, 1);
}
if (ret)
@@ -451,10 +550,16 @@ int spi_nor_write_ear(struct spi_nor *nor, u8 ear)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(1, nor->bouncebuf, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WREAR,
- nor->bouncebuf, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_WREAR,
+ nor->bouncebuf, 1);
}
if (ret)
@@ -482,10 +587,16 @@ int spi_nor_xread_sr(struct spi_nor *nor, u8 *sr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, sr, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_XRDSR,
- sr, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor,
+ SPINOR_OP_XRDSR,
+ sr, 1);
}
if (ret)
@@ -527,10 +638,16 @@ static void spi_nor_clear_sr(struct spi_nor *nor)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_CLSR,
- NULL, 0);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_CLSR,
+ NULL, 0);
}
if (ret)
@@ -591,10 +708,16 @@ static void spi_nor_clear_fsr(struct spi_nor *nor)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_CLFSR,
- NULL, 0);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_CLFSR,
+ NULL, 0);
}
if (ret)
@@ -735,10 +858,16 @@ static int spi_nor_write_sr(struct spi_nor *nor, const u8 *sr, size_t len)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(len, sr, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WRSR,
- sr, len);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_WRSR,
+ sr, len);
}
if (ret) {
@@ -937,10 +1066,16 @@ static int spi_nor_write_sr2(struct spi_nor *nor, const u8 *sr2)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(1, sr2, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WRSR2,
- sr2, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_WRSR2,
+ sr2, 1);
}
if (ret) {
@@ -971,10 +1106,16 @@ static int spi_nor_read_sr2(struct spi_nor *nor, u8 *sr2)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, sr2, 1));
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR2,
- sr2, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor,
+ SPINOR_OP_RDSR2,
+ sr2, 1);
}
if (ret)
@@ -1002,10 +1143,16 @@ static int spi_nor_erase_chip(struct spi_nor *nor)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->write_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->write_reg(nor, SPINOR_OP_CHIP_ERASE,
- NULL, 0);
+ if (spi_nor_protocol_is_dtr(nor->write_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->write_reg(nor,
+ SPINOR_OP_CHIP_ERASE,
+ NULL, 0);
}
if (ret)
@@ -1144,7 +1291,11 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, nor->write_proto);
+
return spi_mem_exec_op(nor->spimem, &op);
+ } else if (spi_nor_protocol_is_dtr(nor->write_proto)) {
+ return -ENOTSUPP;
} else if (nor->controller_ops->erase) {
return nor->controller_ops->erase(nor, addr);
}
@@ -2253,6 +2404,7 @@ int spi_nor_hwcaps_read2cmd(u32 hwcaps)
{ SNOR_HWCAPS_READ_1_8_8, SNOR_CMD_READ_1_8_8 },
{ SNOR_HWCAPS_READ_8_8_8, SNOR_CMD_READ_8_8_8 },
{ SNOR_HWCAPS_READ_1_8_8_DTR, SNOR_CMD_READ_1_8_8_DTR },
+ { SNOR_HWCAPS_READ_8_8_8_DTR, SNOR_CMD_READ_8_8_8_DTR },
};
return spi_nor_hwcaps2cmd(hwcaps, hwcaps_read2cmd,
@@ -2269,6 +2421,7 @@ static int spi_nor_hwcaps_pp2cmd(u32 hwcaps)
{ SNOR_HWCAPS_PP_1_1_8, SNOR_CMD_PP_1_1_8 },
{ SNOR_HWCAPS_PP_1_8_8, SNOR_CMD_PP_1_8_8 },
{ SNOR_HWCAPS_PP_8_8_8, SNOR_CMD_PP_8_8_8 },
+ { SNOR_HWCAPS_PP_8_8_8_DTR, SNOR_CMD_PP_8_8_8_DTR },
};
return spi_nor_hwcaps2cmd(hwcaps, hwcaps_pp2cmd,
@@ -2322,13 +2475,11 @@ static int spi_nor_spimem_check_readop(struct spi_nor *nor,
SPI_MEM_OP_DUMMY(0, 1),
SPI_MEM_OP_DATA_IN(0, NULL, 1));
- op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(read->proto);
- op.addr.buswidth = spi_nor_get_protocol_addr_nbits(read->proto);
- op.data.buswidth = spi_nor_get_protocol_data_nbits(read->proto);
- op.dummy.buswidth = op.addr.buswidth;
op.dummy.nbytes = (read->num_mode_clocks + read->num_wait_states) *
op.dummy.buswidth / 8;
+ spi_nor_spimem_setup_op(nor, &op, read->proto);
+
return spi_nor_spimem_check_op(nor, &op);
}
@@ -2348,9 +2499,7 @@ static int spi_nor_spimem_check_pp(struct spi_nor *nor,
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(0, NULL, 1));
- op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(pp->proto);
- op.addr.buswidth = spi_nor_get_protocol_addr_nbits(pp->proto);
- op.data.buswidth = spi_nor_get_protocol_data_nbits(pp->proto);
+ spi_nor_spimem_setup_op(nor, &op, pp->proto);
return spi_nor_spimem_check_op(nor, &op);
}
@@ -2368,12 +2517,16 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
struct spi_nor_flash_parameter *params = nor->params;
unsigned int cap;
- /* DTR modes are not supported yet, mask them all. */
- *hwcaps &= ~SNOR_HWCAPS_DTR;
-
/* X-X-X modes are not supported yet, mask them all. */
*hwcaps &= ~SNOR_HWCAPS_X_X_X;
+ /*
+ * If the reset line is broken, we do not want to enter a stateful
+ * mode.
+ */
+ if (nor->flags & SNOR_F_BROKEN_RESET)
+ *hwcaps &= ~(SNOR_HWCAPS_X_X_X | SNOR_HWCAPS_X_X_X_DTR);
+
for (cap = 0; cap < sizeof(*hwcaps) * BITS_PER_BYTE; cap++) {
int rdidx, ppidx;
@@ -2628,7 +2781,7 @@ static int spi_nor_default_setup(struct spi_nor *nor,
* controller directly implements the spi_nor interface.
* Yet another reason to switch to spi-mem.
*/
- ignored_mask = SNOR_HWCAPS_X_X_X;
+ ignored_mask = SNOR_HWCAPS_X_X_X | SNOR_HWCAPS_X_X_X_DTR;
if (shared_mask & ignored_mask) {
dev_dbg(nor->dev,
"SPI n-n-n protocols are not supported.\n");
@@ -2774,11 +2927,25 @@ static void spi_nor_info_init_params(struct spi_nor *nor)
SNOR_PROTO_1_1_8);
}
+ if (info->flags & SPI_NOR_OCTAL_DTR_READ) {
+ params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
+ spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, 20, SPINOR_OP_READ_FAST,
+ SNOR_PROTO_8_8_8_DTR);
+ }
+
/* Page Program settings. */
params->hwcaps.mask |= SNOR_HWCAPS_PP;
spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP],
SPINOR_OP_PP, SNOR_PROTO_1_1_1);
+ /*
+ * Since xSPI Page Program opcode is backward compatible with
+ * Legacy SPI, use Legacy SPI opcode there as well.
+ */
+ spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP_8_8_8_DTR],
+ SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
+
/*
* Sector Erase settings. Sort Erase Types in ascending order, with the
* smallest erase size starting at BIT(0).
@@ -2886,7 +3053,8 @@ static int spi_nor_init_params(struct spi_nor *nor)
spi_nor_manufacturer_init_params(nor);
- if ((nor->info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
+ if ((nor->info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ)) &&
!(nor->info->flags & SPI_NOR_SKIP_SFDP))
spi_nor_sfdp_init_params(nor);
@@ -2948,7 +3116,9 @@ static int spi_nor_init(struct spi_nor *nor)
return err;
}
- if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES)) {
+ if (nor->addr_width == 4 &&
+ !(nor->info->flags & SPI_NOR_OCTAL_DTR_READ) &&
+ !(nor->flags & SNOR_F_4B_OPCODES)) {
/*
* If the RESET# pin isn't hooked up properly, or the system
* otherwise doesn't perform a reset command in the boot
@@ -3007,6 +3177,9 @@ static int spi_nor_set_addr_width(struct spi_nor *nor)
{
if (nor->addr_width) {
/* already configured from SFDP */
+ } else if (spi_nor_protocol_is_dtr(nor->read_proto)) {
+ /* Always use 4-byte addresses in DTR mode. */
+ nor->addr_width = 4;
} else if (nor->info->addr_width) {
nor->addr_width = nor->info->addr_width;
} else if (nor->mtd.size > 0x1000000) {
@@ -3244,14 +3417,19 @@ static int spi_nor_create_read_dirmap(struct spi_nor *nor)
};
struct spi_mem_op *op = &info.op_tmpl;
- /* get transfer protocols. */
- op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->read_proto);
- op->addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->read_proto);
- op->dummy.buswidth = op->addr.buswidth;
- op->data.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
+ spi_nor_spimem_setup_op(nor, op, nor->read_proto);
/* convert the dummy cycles to the number of bytes */
op->dummy.nbytes = (nor->read_dummy * op->dummy.buswidth) / 8;
+ if (spi_nor_protocol_is_dtr(nor->read_proto))
+ op->dummy.nbytes *= 2;
+
+ /*
+ * Since spi_nor_spimem_setup_op() only sets buswidth when the number
+ * of data bytes is non-zero, the data buswidth won't be set here. So,
+ * do it explicitly.
+ */
+ op->data.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
nor->dirmap.rdesc = devm_spi_mem_dirmap_create(nor->dev, nor->spimem,
&info);
@@ -3270,15 +3448,18 @@ static int spi_nor_create_write_dirmap(struct spi_nor *nor)
};
struct spi_mem_op *op = &info.op_tmpl;
- /* get transfer protocols. */
- op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->write_proto);
- op->addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->write_proto);
- op->dummy.buswidth = op->addr.buswidth;
- op->data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
-
if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
op->addr.nbytes = 0;
+ spi_nor_spimem_setup_op(nor, op, nor->write_proto);
+
+ /*
+ * Since spi_nor_spimem_setup_op() only sets buswidth when the number
+ * of data bytes is non-zero, the data buswidth won't be set here. So,
+ * do it explicitly.
+ */
+ op->data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
+
nor->dirmap.wdesc = devm_spi_mem_dirmap_create(nor->dev, nor->spimem,
&info);
return PTR_ERR_OR_ZERO(nor->dirmap.wdesc);
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 6f2f6b27173f..de1e3917889f 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -62,6 +62,7 @@ enum spi_nor_read_command_index {
SNOR_CMD_READ_1_8_8,
SNOR_CMD_READ_8_8_8,
SNOR_CMD_READ_1_8_8_DTR,
+ SNOR_CMD_READ_8_8_8_DTR,
SNOR_CMD_READ_MAX
};
@@ -78,6 +79,7 @@ enum spi_nor_pp_command_index {
SNOR_CMD_PP_1_1_8,
SNOR_CMD_PP_1_8_8,
SNOR_CMD_PP_8_8_8,
+ SNOR_CMD_PP_8_8_8_DTR,
SNOR_CMD_PP_MAX
};
@@ -311,6 +313,7 @@ struct flash_info {
* BP3 is bit 6 of status register.
* Must be used with SPI_NOR_4BIT_BP.
*/
+#define SPI_NOR_OCTAL_DTR_READ BIT(19) /* Flash supports octal DTR Read. */
/* Part specific fixup hooks. */
const struct spi_nor_fixups *fixups;
@@ -399,6 +402,9 @@ extern const struct spi_nor_manufacturer spi_nor_winbond;
extern const struct spi_nor_manufacturer spi_nor_xilinx;
extern const struct spi_nor_manufacturer spi_nor_xmc;
+void spi_nor_spimem_setup_op(const struct spi_nor *nor,
+ struct spi_mem_op *op,
+ const enum spi_nor_protocol proto);
int spi_nor_write_enable(struct spi_nor *nor);
int spi_nor_write_disable(struct spi_nor *nor);
int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable);
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index f6038d3a3684..f917631c8110 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -1044,9 +1044,16 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
}
/* 4BAIT is the only SFDP table that indicates page program support. */
- if (pp_hwcaps & SNOR_HWCAPS_PP)
+ if (pp_hwcaps & SNOR_HWCAPS_PP) {
spi_nor_set_pp_settings(¶ms_pp[SNOR_CMD_PP],
SPINOR_OP_PP_4B, SNOR_PROTO_1_1_1);
+ /*
+ * Since xSPI Page Program opcode is backward compatible with
+ * Legacy SPI, use Legacy SPI opcode there as well.
+ */
+ spi_nor_set_pp_settings(¶ms_pp[SNOR_CMD_PP_8_8_8_DTR],
+ SPINOR_OP_PP_4B, SNOR_PROTO_8_8_8_DTR);
+ }
if (pp_hwcaps & SNOR_HWCAPS_PP_1_1_4)
spi_nor_set_pp_settings(¶ms_pp[SNOR_CMD_PP_1_1_4],
SPINOR_OP_PP_1_1_4_4B,
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index bebff2729c18..d251a5d02be2 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -182,6 +182,7 @@ enum spi_nor_protocol {
SNOR_PROTO_1_2_2_DTR = SNOR_PROTO_DTR(1, 2, 2),
SNOR_PROTO_1_4_4_DTR = SNOR_PROTO_DTR(1, 4, 4),
SNOR_PROTO_1_8_8_DTR = SNOR_PROTO_DTR(1, 8, 8),
+ SNOR_PROTO_8_8_8_DTR = SNOR_PROTO_DTR(8, 8, 8),
};
static inline bool spi_nor_protocol_is_dtr(enum spi_nor_protocol proto)
@@ -228,7 +229,7 @@ struct spi_nor_hwcaps {
* then Quad SPI protocols before Dual SPI protocols, Fast Read and lastly
* (Slow) Read.
*/
-#define SNOR_HWCAPS_READ_MASK GENMASK(14, 0)
+#define SNOR_HWCAPS_READ_MASK GENMASK(15, 0)
#define SNOR_HWCAPS_READ BIT(0)
#define SNOR_HWCAPS_READ_FAST BIT(1)
#define SNOR_HWCAPS_READ_1_1_1_DTR BIT(2)
@@ -245,11 +246,12 @@ struct spi_nor_hwcaps {
#define SNOR_HWCAPS_READ_4_4_4 BIT(9)
#define SNOR_HWCAPS_READ_1_4_4_DTR BIT(10)
-#define SNOR_HWCAPS_READ_OCTAL GENMASK(14, 11)
+#define SNOR_HWCAPS_READ_OCTAL GENMASK(15, 11)
#define SNOR_HWCAPS_READ_1_1_8 BIT(11)
#define SNOR_HWCAPS_READ_1_8_8 BIT(12)
#define SNOR_HWCAPS_READ_8_8_8 BIT(13)
#define SNOR_HWCAPS_READ_1_8_8_DTR BIT(14)
+#define SNOR_HWCAPS_READ_8_8_8_DTR BIT(15)
/*
* Page Program capabilities.
@@ -260,18 +262,19 @@ struct spi_nor_hwcaps {
* JEDEC/SFDP standard to define them. Also at this moment no SPI flash memory
* implements such commands.
*/
-#define SNOR_HWCAPS_PP_MASK GENMASK(22, 16)
-#define SNOR_HWCAPS_PP BIT(16)
+#define SNOR_HWCAPS_PP_MASK GENMASK(23, 16)
+#define SNOR_HWCAPS_PP BIT(16)
-#define SNOR_HWCAPS_PP_QUAD GENMASK(19, 17)
-#define SNOR_HWCAPS_PP_1_1_4 BIT(17)
-#define SNOR_HWCAPS_PP_1_4_4 BIT(18)
-#define SNOR_HWCAPS_PP_4_4_4 BIT(19)
+#define SNOR_HWCAPS_PP_QUAD GENMASK(19, 17)
+#define SNOR_HWCAPS_PP_1_1_4 BIT(17)
+#define SNOR_HWCAPS_PP_1_4_4 BIT(18)
+#define SNOR_HWCAPS_PP_4_4_4 BIT(19)
-#define SNOR_HWCAPS_PP_OCTAL GENMASK(22, 20)
-#define SNOR_HWCAPS_PP_1_1_8 BIT(20)
-#define SNOR_HWCAPS_PP_1_8_8 BIT(21)
-#define SNOR_HWCAPS_PP_8_8_8 BIT(22)
+#define SNOR_HWCAPS_PP_OCTAL GENMASK(23, 20)
+#define SNOR_HWCAPS_PP_1_1_8 BIT(20)
+#define SNOR_HWCAPS_PP_1_8_8 BIT(21)
+#define SNOR_HWCAPS_PP_8_8_8 BIT(22)
+#define SNOR_HWCAPS_PP_8_8_8_DTR BIT(23)
#define SNOR_HWCAPS_X_X_X (SNOR_HWCAPS_READ_2_2_2 | \
SNOR_HWCAPS_READ_4_4_4 | \
@@ -279,10 +282,14 @@ struct spi_nor_hwcaps {
SNOR_HWCAPS_PP_4_4_4 | \
SNOR_HWCAPS_PP_8_8_8)
+#define SNOR_HWCAPS_X_X_X_DTR (SNOR_HWCAPS_READ_8_8_8_DTR | \
+ SNOR_HWCAPS_PP_8_8_8_DTR)
+
#define SNOR_HWCAPS_DTR (SNOR_HWCAPS_READ_1_1_1_DTR | \
SNOR_HWCAPS_READ_1_2_2_DTR | \
SNOR_HWCAPS_READ_1_4_4_DTR | \
- SNOR_HWCAPS_READ_1_8_8_DTR)
+ SNOR_HWCAPS_READ_1_8_8_DTR | \
+ SNOR_HWCAPS_READ_8_8_8_DTR)
#define SNOR_HWCAPS_ALL (SNOR_HWCAPS_READ_MASK | \
SNOR_HWCAPS_PP_MASK)
@@ -318,6 +325,22 @@ struct spi_nor_controller_ops {
int (*erase)(struct spi_nor *nor, loff_t offs);
};
+/**
+ * enum spi_nor_cmd_ext - describes the command opcode extension in DTR mode
+ * @SPI_NOR_EXT_NONE: no extension. This is the default, and is used in Legacy
+ * SPI mode
+ * @SPI_NOR_EXT_REPEAT: the extension is same as the opcode
+ * @SPI_NOR_EXT_INVERT: the extension is the bitwise inverse of the opcode
+ * @SPI_NOR_EXT_HEX: the extension is any hex value. The command and opcode
+ * combine to form a 16-bit opcode.
+ */
+enum spi_nor_cmd_ext {
+ SPI_NOR_EXT_NONE = 0,
+ SPI_NOR_EXT_REPEAT,
+ SPI_NOR_EXT_INVERT,
+ SPI_NOR_EXT_HEX,
+};
+
/*
* Forward declarations that are used internally by the core and manufacturer
* drivers.
@@ -345,6 +368,7 @@ struct spi_nor_flash_parameter;
* @program_opcode: the program opcode
* @sst_write_second: used by the SST write operation
* @flags: flag options for the current SPI-NOR (SNOR_F_*)
+ * @cmd_ext_type: the command opcode extension type for DTR mode.
* @read_proto: the SPI protocol for read operations
* @write_proto: the SPI protocol for write operations
* @reg_proto: the SPI protocol for read_reg/write_reg/erase operations
@@ -376,6 +400,7 @@ struct spi_nor {
enum spi_nor_protocol reg_proto;
bool sst_write_second;
u32 flags;
+ enum spi_nor_cmd_ext cmd_ext_type;
const struct spi_nor_controller_ops *controller_ops;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 04/19] spi: spi-mtk-nor: reject DTR ops
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mtk-nor.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index d5f393871619..b08d8e9a8ee9 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -211,6 +211,12 @@ static bool mtk_nor_supports_op(struct spi_mem *mem,
if (op->cmd.buswidth != 1)
return false;
+ /* DTR ops not supported. */
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
if ((op->addr.nbytes == 3) || (op->addr.nbytes == 4)) {
if ((op->data.dir == SPI_MEM_DATA_IN) && mtk_nor_match_read(op))
return true;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 03/19] spi: atmel-quadspi: reject DTR ops
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/atmel-quadspi.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index cb44d1e169aa..a898755fb41e 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -285,6 +285,12 @@ static bool atmel_qspi_supports_op(struct spi_mem *mem,
op->dummy.nbytes == 0)
return false;
+ /* DTR ops not supported. */
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
return true;
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 02/19] spi: spi-mem: allow specifying a command's extension
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.
So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.
Some places use sizeof(op->cmd.opcode). Replace them with op->cmd.nbytes
The spi-mxic and spi-zynq-qspi drivers directly use op->cmd.opcode as a
buffer. Now that opcode is a 2-byte field, this can result in different
behaviour depending on if the machine is little endian or big endian.
Extract the opcode in a local 1-byte variable and use that as the buffer
instead. Both these drivers would reject multi-byte opcodes in their
supports_op() hook anyway, so we only need to worry about single-byte
opcodes for now.
The above two changes are put in this commit to keep the series
bisectable.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mem.c | 13 +++++++------
drivers/spi/spi-mtk-nor.c | 4 ++--
drivers/spi/spi-mxic.c | 3 ++-
drivers/spi/spi-zynq-qspi.c | 11 ++++++-----
include/linux/spi/spi-mem.h | 6 +++++-
5 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 93e255287ab9..ef53290b7d24 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -159,6 +159,9 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
return true;
}
EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
@@ -173,7 +176,7 @@ static bool spi_mem_buswidth_is_valid(u8 buswidth)
static int spi_mem_check_op(const struct spi_mem_op *op)
{
- if (!op->cmd.buswidth)
+ if (!op->cmd.buswidth || !op->cmd.nbytes)
return -EINVAL;
if ((op->addr.nbytes && !op->addr.buswidth) ||
@@ -309,8 +312,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
return ret;
}
- tmpbufsize = sizeof(op->cmd.opcode) + op->addr.nbytes +
- op->dummy.nbytes;
+ tmpbufsize = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
/*
* Allocate a buffer to transmit the CMD, ADDR cycles with kmalloc() so
@@ -325,7 +327,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
tmpbuf[0] = op->cmd.opcode;
xfers[xferpos].tx_buf = tmpbuf;
- xfers[xferpos].len = sizeof(op->cmd.opcode);
+ xfers[xferpos].len = op->cmd.nbytes;
xfers[xferpos].tx_nbits = op->cmd.buswidth;
spi_message_add_tail(&xfers[xferpos], &msg);
xferpos++;
@@ -427,8 +429,7 @@ int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
return ctlr->mem_ops->adjust_op_size(mem, op);
if (!ctlr->mem_ops || !ctlr->mem_ops->exec_op) {
- len = sizeof(op->cmd.opcode) + op->addr.nbytes +
- op->dummy.nbytes;
+ len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
if (len > spi_max_transfer_size(mem->spi))
return -EINVAL;
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 7bc302b50396..d5f393871619 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -195,7 +195,7 @@ static int mtk_nor_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
}
}
- len = MTK_NOR_PRG_MAX_SIZE - sizeof(op->cmd.opcode) - op->addr.nbytes -
+ len = MTK_NOR_PRG_MAX_SIZE - op->cmd.nbytes - op->addr.nbytes -
op->dummy.nbytes;
if (op->data.nbytes > len)
op->data.nbytes = len;
@@ -219,7 +219,7 @@ static bool mtk_nor_supports_op(struct spi_mem *mem,
(op->dummy.buswidth == 0) &&
(op->data.buswidth == 1);
}
- len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
+ len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
if ((len > MTK_NOR_PRG_MAX_SIZE) ||
((op->data.nbytes) && (len == MTK_NOR_PRG_MAX_SIZE)))
return false;
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 69491f3a515d..4e4292f0ee1d 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
int nio = 1, i, ret;
u32 ss_ctrl;
u8 addr[8];
+ u8 opcode = op->cmd.opcode & 0xff;
ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
if (ret)
@@ -393,7 +394,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
mxic->regs + HC_CFG);
- ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
+ ret = mxic_spi_data_xfer(mxic, &opcode, NULL, 1);
if (ret)
goto out;
diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index 17641157354d..41389856e14a 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -527,20 +527,21 @@ static int zynq_qspi_exec_mem_op(struct spi_mem *mem,
struct zynq_qspi *xqspi = spi_controller_get_devdata(mem->spi->master);
int err = 0, i;
u8 *tmpbuf;
+ u8 opcode = op->cmd.opcode & 0xff;
dev_dbg(xqspi->dev, "cmd:%#x mode:%d.%d.%d.%d\n",
- op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+ opcode, op->cmd.buswidth, op->addr.buswidth,
op->dummy.buswidth, op->data.buswidth);
zynq_qspi_chipselect(mem->spi, true);
zynq_qspi_config_op(xqspi, mem->spi);
- if (op->cmd.opcode) {
+ if (opcode) {
reinit_completion(&xqspi->data_completion);
- xqspi->txbuf = (u8 *)&op->cmd.opcode;
+ xqspi->txbuf = &opcode;
xqspi->rxbuf = NULL;
- xqspi->tx_bytes = sizeof(op->cmd.opcode);
- xqspi->rx_bytes = sizeof(op->cmd.opcode);
+ xqspi->tx_bytes = op->cmd.nbytes;
+ xqspi->rx_bytes = op->cmd.nbytes;
zynq_qspi_write_op(xqspi, ZYNQ_QSPI_FIFO_DEPTH, true);
zynq_qspi_write(xqspi, ZYNQ_QSPI_IEN_OFFSET,
ZYNQ_QSPI_IXR_RXTX_MASK);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index e3dcb956bf61..159463cc659c 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -17,6 +17,7 @@
{ \
.buswidth = __buswidth, \
.opcode = __opcode, \
+ .nbytes = 1, \
}
#define SPI_MEM_OP_ADDR(__nbytes, __val, __buswidth) \
@@ -69,6 +70,8 @@ enum spi_mem_data_dir {
/**
* struct spi_mem_op - describes a SPI memory operation
+ * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
+ * sent MSB-first.
* @cmd.buswidth: number of IO lines used to transmit the command
* @cmd.opcode: operation opcode
* @cmd.dtr: whether the command opcode should be sent in DTR mode or not
@@ -94,9 +97,10 @@ enum spi_mem_data_dir {
*/
struct spi_mem_op {
struct {
+ u8 nbytes;
u8 buswidth;
u8 dtr : 1;
- u8 opcode;
+ u16 opcode;
} cmd;
struct {
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 01/19] spi: spi-mem: allow specifying whether an op is DTR or not
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522224042.29970-1-p.yadav@ti.com>
Each phase is given a separate 'dtr' field so mixed protocols like
4S-4D-4D can be supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mem.c | 3 +++
include/linux/spi/spi-mem.h | 8 ++++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 9a86cc27fcc0..93e255287ab9 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -156,6 +156,9 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
op->data.dir == SPI_MEM_DATA_OUT))
return false;
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+
return true;
}
EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index af9ff2f0f1b2..e3dcb956bf61 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -71,9 +71,11 @@ enum spi_mem_data_dir {
* struct spi_mem_op - describes a SPI memory operation
* @cmd.buswidth: number of IO lines used to transmit the command
* @cmd.opcode: operation opcode
+ * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
* @addr.nbytes: number of address bytes to send. Can be zero if the operation
* does not need to send an address
* @addr.buswidth: number of IO lines used to transmit the address cycles
+ * @addr.dtr: whether the address should be sent in DTR mode or not
* @addr.val: address value. This value is always sent MSB first on the bus.
* Note that only @addr.nbytes are taken into account in this
* address value, so users should make sure the value fits in the
@@ -81,7 +83,9 @@ enum spi_mem_data_dir {
* @dummy.nbytes: number of dummy bytes to send after an opcode or address. Can
* be zero if the operation does not require dummy bytes
* @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
+ * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or not
* @data.buswidth: number of IO lanes used to send/receive the data
+ * @data.dtr: whether the data should be sent in DTR mode or not
* @data.dir: direction of the transfer
* @data.nbytes: number of data bytes to send/receive. Can be zero if the
* operation does not involve transferring data
@@ -91,22 +95,26 @@ enum spi_mem_data_dir {
struct spi_mem_op {
struct {
u8 buswidth;
+ u8 dtr : 1;
u8 opcode;
} cmd;
struct {
u8 nbytes;
u8 buswidth;
+ u8 dtr : 1;
u64 val;
} addr;
struct {
u8 nbytes;
u8 buswidth;
+ u8 dtr : 1;
} dummy;
struct {
u8 buswidth;
+ u8 dtr : 1;
enum spi_mem_data_dir dir;
unsigned int nbytes;
union {
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 00/19] mtd: spi-nor: add xSPI Octal DTR support
From: Pratyush Yadav @ 2020-05-22 22:40 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, Michal Simek, linux-mtd,
linux-kernel, linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
Hi,
This series adds support for octal DTR flashes in the spi-nor framework,
and then adds hooks for the Cypress Semper and Mircom Xcella flashes to
allow running them in octal DTR mode. This series assumes that the flash
is handed to the kernel in Legacy SPI mode.
Tested on TI J721e EVM with 1-bit ECC on the Cypress flash.
Changes in v8:
- Move controller changes in spi-mxic to the commit which introduces
2-byte opcodes to avoid problems when bisecting.
- Replace usage of sizeof(op->cmd.opcode) with op->cmd.nbytes.
- Extract opcode in spi-zynq-qspi instead of using &op->cmd.opcode.
Changes in v7:
- Reject ops with more than 1 command byte in
spi_mem_default_supports_op().
- Reject ops with more than 1 command byte in atmel and mtk controllers.
- Reject ops with 0 command bytes in spi_mem_check_op().
- Set cmd.nbytes to 1 when using SPI_MEM_OP_CMD().
- Avoid endianness problems in spi-mxic.
Changes in v6:
- Instead of hard-coding 8D-8D-8D Fast Read dummy cycles to 20, find
them out from the Profile 1.0 table.
Changes in v5:
- Do not enable stateful X-X-X modes if the reset line is broken.
- Instead of setting SNOR_READ_HWCAPS_8_8_8_DTR from Profile 1.0 table
parsing, do it in spi_nor_info_init_params() instead based on the
SPI_NOR_OCTAL_DTR_READ flag instead.
- Set SNOR_HWCAPS_PP_8_8_8_DTR in s28hs post_sfdp hook since this
capability is no longer set in Profile 1.0 parsing.
- Instead of just checking for spi_nor_get_protocol_width() in
spi_nor_octal_dtr_enable(), make sure the protocol is
SNOR_PROTO_8_8_8_DTR since get_protocol_width() only cares about data
width.
- Drop flag SPI_NOR_SOFT_RESET. Instead, discover soft reset capability
via BFPT.
- Do not make an invalid Quad Enable BFPT field a fatal error. Silently
ignore it by assuming no quad enable bit is present.
- Set dummy cycles for Cypress Semper flash to 24 instead of 20. This
allows for 200MHz operation in 8D mode compared to the 166MHz with 20.
- Rename spi_nor_cypress_octal_enable() to
spi_nor_cypress_octal_dtr_enable().
- Update spi-mtk-nor.c to reject DTR ops since it doesn't call
spi_mem_default_supports_op().
Changes in v4:
- Refactor the series to use the new spi-nor framework with the
manufacturer-specific bits separated from the core.
- Add support for Micron MT35XU512ABA.
- Use cmd.nbytes as the criteria of whether the data phase exists or not
instead of cmd.buf.in || cmd.buf.out in spi_nor_spimem_setup_op().
- Update Read FSR to use the same dummy cycles and address width as Read
SR.
- Fix BFPT parsing stopping too early for JESD216 rev B flashes.
- Use 2 byte reads for Read SR and FSR commands in DTR mode.
Changes in v3:
- Drop the DT properties "spi-rx-dtr" and "spi-tx-dtr". Instead, if
later a need is felt to disable DTR in case someone has a board with
Octal DTR capable flash but does not support DTR transactions for some
reason, a property like "spi-no-dtr" can be added.
- Remove mode bits SPI_RX_DTR and SPI_TX_DTR.
- Remove the Cadence Quadspi controller patch to un-block this series. I
will submit it as a separate patch.
- Rebase on latest 'master' and fix merge conflicts.
- Update read and write dirmap templates to use DTR.
- Rename 'is_dtr' to 'dtr'.
- Make 'dtr' a bitfield.
- Reject DTR ops in spi_mem_default_supports_op().
- Update atmel-quadspi to reject DTR ops. All other controller drivers
call spi_mem_default_supports_op() so they will automatically reject
DTR ops.
- Add support for both enabling and disabling DTR modes.
- Perform a Software Reset on flashes that support it when shutting
down.
- Disable Octal DTR mode on suspend, and re-enable it on resume.
- Drop enum 'spi_mem_cmd_ext' and make command opcode u16 instead.
Update spi-nor to use the 2-byte command instead of the command
extension. Since we still need a "extension type", mode that enum to
spi-nor and name it 'spi_nor_cmd_ext'.
- Default variable address width to 3 to fix SMPT parsing.
- Drop non-volatile change to uniform sector mode and rely on parsing
SMPT.
Changes in v2:
- Add DT properties "spi-rx-dtr" and "spi-tx-dtr" to allow expressing
DTR capabilities.
- Set the mode bits SPI_RX_DTR and SPI_TX_DTR when we discover the DT
properties "spi-rx-dtr" and spi-tx-dtr".
- spi_nor_cypress_octal_enable() was updating nor->params.read[] with
the intention of setting the correct number of dummy cycles. But this
function is called _after_ selecting the read so setting
nor->params.read[] will have no effect. So, update nor->read_dummy
directly.
- Fix spi_nor_spimem_check_readop() and spi_nor_spimem_check_pp()
passing nor->read_proto and nor->write_proto to
spi_nor_spimem_setup_op() instead of read->proto and pp->proto
respectively.
- Move the call to cqspi_setup_opcode_ext() inside cqspi_enable_dtr().
This avoids repeating the 'if (f_pdata->is_dtr)
cqspi_setup_opcode_ext()...` snippet multiple times.
- Call the default 'supports_op()' from cqspi_supports_mem_op(). This
makes sure the buswidth requirements are also enforced along with the
DTR requirements.
- Drop the 'is_dtr' argument from spi_check_dtr_req(). We only call it
when a phase is DTR so it is redundant.
Pratyush Yadav (19):
spi: spi-mem: allow specifying whether an op is DTR or not
spi: spi-mem: allow specifying a command's extension
spi: atmel-quadspi: reject DTR ops
spi: spi-mtk-nor: reject DTR ops
mtd: spi-nor: add support for DTR protocol
mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths
mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D
mtd: spi-nor: sfdp: get command opcode extension type from BFPT
mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
mtd: spi-nor: core: use dummy cycle and address width info from SFDP
mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode
mtd: spi-nor: core: enable octal DTR mode when possible
mtd: spi-nor: sfdp: do not make invalid quad enable fatal
mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT
mtd: spi-nor: core: perform a Soft Reset on shutdown
mtd: spi-nor: core: disable Octal DTR mode on suspend.
mtd: spi-nor: core: expose spi_nor_default_setup() in core.h
mtd: spi-nor: spansion: add support for Cypress Semper flash
mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
drivers/mtd/spi-nor/core.c | 446 +++++++++++++++++++++++++++-----
drivers/mtd/spi-nor/core.h | 22 ++
drivers/mtd/spi-nor/micron-st.c | 112 +++++++-
drivers/mtd/spi-nor/sfdp.c | 143 +++++++++-
drivers/mtd/spi-nor/sfdp.h | 13 +-
drivers/mtd/spi-nor/spansion.c | 167 ++++++++++++
drivers/spi/atmel-quadspi.c | 6 +
drivers/spi/spi-mem.c | 16 +-
drivers/spi/spi-mtk-nor.c | 10 +-
drivers/spi/spi-mxic.c | 3 +-
drivers/spi/spi-zynq-qspi.c | 11 +-
include/linux/mtd/spi-nor.h | 53 +++-
include/linux/spi/spi-mem.h | 14 +-
13 files changed, 910 insertions(+), 106 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] net: provide a devres variant of register_netdev()
From: David Miller @ 2020-05-22 22:36 UTC (permalink / raw)
To: brgl
Cc: edwin.peer, devicetree, bgolaszewski, stephane.leprovost, arnd,
corbet, netdev, sean.wang, linux-kernel, fparent, pedro.tsai,
linux-mediatek, andrew.perepech, john, matthias.bgg, kuba,
Mark-MC.Lee, linux-arm-kernel, hkallweit1
In-Reply-To: <20200520114415.13041-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Wed, 20 May 2020 13:44:10 +0200
> net: ethernet: mtk_eth_mac: use devm_register_netdev()
This patch doesn't apply to net-next.
Neither the source file drivers/net/ethernet/mediatek/mtk_eth_mac.c,
nor the function mtk_mac_probe() even exist in the net-next GIT
tree.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 4/5] arm64: defconfig: add MEDIA_PLATFORM_SUPPORT
From: Li Yang @ 2020-05-22 22:03 UTC (permalink / raw)
To: Max Krummenacher
Cc: Arnd Bergmann, Anson Huang, Mauro Carvalho Chehab,
Catalin Marinas, lkml, Bjorn Andersson, Marcin Juszkiewicz, soc,
Max Krummenacher, Olof Johansson, Shawn Guo, Geert Uytterhoeven,
Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200427134003.45188-5-max.krummenacher@toradex.com>
On Mon, Apr 27, 2020 at 8:43 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
>
> Commit 06b93644f4d1 ("media: Kconfig: add an option to filter in/out
> platform drivers") adds a new Kconfig symbol which now hides drivers
> currently enabled in the arm64 defconfig. Enable it to get those
> drivers back.
>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
This is pretty important otherwise some of the drivers enabled in
defconfig will no longer build.
>
>
> ---
>
> Changes in v3:
> - new patch: added 'arm64: defconfig: add MEDIA_PLATFORM_SUPPORT' now
> needed for some enabled drivers or these drivers will silently not
> be built.
>
> Changes in v2: None
>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index b8259814065dc..472aa82b9feee 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -569,6 +569,7 @@ CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
> CONFIG_MEDIA_SDR_SUPPORT=y
> CONFIG_MEDIA_CONTROLLER=y
> CONFIG_VIDEO_V4L2_SUBDEV_API=y
> +CONFIG_MEDIA_PLATFORM_SUPPORT=y
> # CONFIG_DVB_NET is not set
> CONFIG_MEDIA_USB_SUPPORT=y
> CONFIG_USB_VIDEO_CLASS=m
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] soc: fsl: qbman: Remove unused inline function qm_eqcr_get_ci_stashing
From: Li Yang @ 2020-05-22 21:54 UTC (permalink / raw)
To: YueHaibing
Cc: Roy Pledge, linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200508140846.47608-1-yuehaibing@huawei.com>
On Fri, May 8, 2020 at 9:11 AM YueHaibing <yuehaibing@huawei.com> wrote:
>
> There's no callers in-tree anymore.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied for next. Thanks.
Regards,
Leo
> ---
> drivers/soc/fsl/qbman/qman.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
> index 1e164e03410a..9888a7061873 100644
> --- a/drivers/soc/fsl/qbman/qman.c
> +++ b/drivers/soc/fsl/qbman/qman.c
> @@ -449,11 +449,6 @@ static inline int qm_eqcr_init(struct qm_portal *portal,
> return 0;
> }
>
> -static inline unsigned int qm_eqcr_get_ci_stashing(struct qm_portal *portal)
> -{
> - return (qm_in(portal, QM_REG_CFG) >> 28) & 0x7;
> -}
> -
> static inline void qm_eqcr_finish(struct qm_portal *portal)
> {
> struct qm_eqcr *eqcr = &portal->eqcr;
> --
> 2.17.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: David Miller @ 2020-05-22 21:36 UTC (permalink / raw)
To: matthias.bgg
Cc: edwin.peer, devicetree, stephane.leprovost, arnd, bgolaszewski,
netdev, brgl, sean.wang, linux-kernel, pedro.tsai, fparent,
robh+dt, linux-mediatek, andrew.perepech, john, kuba, Mark-MC.Lee,
linux-arm-kernel, hkallweit1
In-Reply-To: <1f941213-7ca2-c138-3530-85c34ebf0d53@gmail.com>
From: Matthias Brugger <matthias.bgg@gmail.com>
Date: Fri, 22 May 2020 23:31:50 +0200
>
>
> On 22/05/2020 23:20, David Miller wrote:
>> From: Bartosz Golaszewski <brgl@bgdev.pl>
>> Date: Fri, 22 May 2020 14:06:49 +0200
>>
>>> This series adds support for the STAR Ethernet Controller present on MediaTeK
>>> SoCs from the MT8* family.
>>
>> Series applied to net-next, thank you.
>>
>
> If you say "series applied" do you mean you also applied the device tree parts?
> These should go through my branch, because there could be conflicts if there are
> other device tree patches from other series, not related with network, touching
> the same files.
It's starting to get rediculous and tedious to manage the DT changes
when they are tied to new networking drivers and such.
And in any event, it is the patch series submitter's responsibility to
sort these issues out, separate the patches based upon target tree, and
clearly indicate this in the introductory posting and Subject lines.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc/k3-dsp: Add support for C71x DSPs
From: Mathieu Poirier @ 2020-05-22 21:33 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
Bjorn Andersson, Rob Herring, linux-arm-kernel
In-Reply-To: <20200521151636.28260-3-s-anna@ti.com>
On Thu, May 21, 2020 at 10:16:36AM -0500, Suman Anna wrote:
> The Texas Instrument's K3 J721E SoCs have a newer next-generation
> C71x DSP Subsystem in the MAIN voltage domain in addition to the
> previous generation C66x DSP subsystems. The C71x DSP subsystem is
> based on the TMS320C71x DSP CorePac module. The C71x CPU is a true
> 64-bit machine including 64-bit memory addressing and single-cycle
> 64-bit base arithmetic operations and supports vector signal processing
> providing a significant lift in DSP processing power over C66x DSPs.
> J721E SoCs use a C711 (a one-core 512-bit vector width CPU core) DSP
> that is cache coherent with the A72 Arm cores.
>
> Each subsystem has one or more Fixed/Floating-Point DSP CPUs, with 32 KB
> of L1P Cache, 48 KB of L1D SRAM that can be configured and partitioned as
> either RAM and/or Cache, and 512 KB of L2 SRAM configurable as either RAM
> and/or Cache. The CorePac also includes a Matrix Multiplication Accelerator
> (MMA), a Stream Engine (SE) and a C71x Memory Management Unit (CMMU), an
> Interrupt Controller (INTC) and a Powerdown Management Unit (PMU) modules.
>
> Update the existing K3 DSP remoteproc driver to add support for this C71x
> DSP subsystem. The firmware loading support is provided by using the newly
> added 64-bit ELF loader support, and is limited to images using only
> external DDR memory at the moment. The L1D and L2 SRAMs are used as scratch
> memory when using as RAMs, and cannot be used for loadable segments. The
> CMMU is also not supported to begin with, and the driver is designed to
> treat the MMU as if it is in bypass mode.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - k3_dsp_rproc_prepare/unprepare plugged in dynamically based on local reset,
> C71x doesn't use local resets
> - Dropped the sanity_check ops override, not needed on latest codebase
> v1: https://patchwork.kernel.org/patch/11458595/
>
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 610fbbf85ee6..2dbed316b6ac 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -406,8 +406,6 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> }
>
> static const struct rproc_ops k3_dsp_rproc_ops = {
> - .prepare = k3_dsp_rproc_prepare,
> - .unprepare = k3_dsp_rproc_unprepare,
> .start = k3_dsp_rproc_start,
> .stop = k3_dsp_rproc_stop,
> .kick = k3_dsp_rproc_kick,
> @@ -617,6 +615,10 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
>
> rproc->has_iommu = false;
> rproc->recovery_disabled = true;
> + if (data->uses_lreset) {
> + rproc->ops->prepare = k3_dsp_rproc_prepare;
> + rproc->ops->unprepare = k3_dsp_rproc_unprepare;
> + }
Yes
> kproc = rproc->priv;
> kproc->rproc = rproc;
> kproc->dev = dev;
> @@ -744,6 +746,12 @@ static const struct k3_dsp_mem_data c66_mems[] = {
> { .name = "l1dram", .dev_addr = 0xf00000 },
> };
>
> +/* C71x cores only have a L1P Cache, there are no L1P SRAMs */
> +static const struct k3_dsp_mem_data c71_mems[] = {
> + { .name = "l2sram", .dev_addr = 0x800000 },
> + { .name = "l1dram", .dev_addr = 0xe00000 },
> +};
> +
> static const struct k3_dsp_dev_data c66_data = {
> .mems = c66_mems,
> .num_mems = ARRAY_SIZE(c66_mems),
> @@ -751,8 +759,16 @@ static const struct k3_dsp_dev_data c66_data = {
> .uses_lreset = true,
> };
>
> +static const struct k3_dsp_dev_data c71_data = {
> + .mems = c71_mems,
> + .num_mems = ARRAY_SIZE(c71_mems),
> + .boot_align_addr = SZ_2M,
> + .uses_lreset = false,
Right
> +};
> +
> static const struct of_device_id k3_dsp_of_match[] = {
> { .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
> + { .compatible = "ti,j721e-c71-dsp", .data = &c71_data, },
> { /* sentinel */ },
> };
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
> --
> 2.26.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: Matthias Brugger @ 2020-05-22 21:31 UTC (permalink / raw)
To: David Miller, brgl
Cc: edwin.peer, devicetree, stephane.leprovost, arnd, bgolaszewski,
netdev, sean.wang, linux-kernel, pedro.tsai, fparent, robh+dt,
linux-mediatek, andrew.perepech, john, kuba, Mark-MC.Lee,
linux-arm-kernel, hkallweit1
In-Reply-To: <20200522.142031.1631406151370247419.davem@davemloft.net>
On 22/05/2020 23:20, David Miller wrote:
> From: Bartosz Golaszewski <brgl@bgdev.pl>
> Date: Fri, 22 May 2020 14:06:49 +0200
>
>> This series adds support for the STAR Ethernet Controller present on MediaTeK
>> SoCs from the MT8* family.
>
> Series applied to net-next, thank you.
>
If you say "series applied" do you mean you also applied the device tree parts?
These should go through my branch, because there could be conflicts if there are
other device tree patches from other series, not related with network, touching
the same files.
Regards,
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] ahci: qoriq: Add platform dependencies
From: Li Yang @ 2020-05-22 21:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, Amit Kucheria, Arnd Bergmann, linux-pm, Stephen Boyd,
Viresh Kumar, Michael Turquette, Daniel Lezcano,
Rafael J . Wysocki, lkml, linux-ide, Zhang Rui, Shawn Guo,
linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200507112955.23520-2-geert+renesas@glider.be>
On Thu, May 7, 2020 at 6:30 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> The Freescale QorIQ AHCI SATA controller is only present on Freescale
> Layerscape SoCs. Add platform dependencies to the AHCI_QORIQ config
> symbol, to avoid asking the user about it when configuring a kernel
> without Layerscape support.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Hi Jens,
Are you applying this patches? I can also apply it with your ACK.
Regards,
Leo
> ---
> drivers/ata/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 05ecdce1b702cf8b..d9e66b37acd1862a 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -264,6 +264,7 @@ config AHCI_XGENE
> config AHCI_QORIQ
> tristate "Freescale QorIQ AHCI SATA support"
> depends on OF
> + depends on SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
> select SATA_HOST
> help
> This option enables support for the Freescale QorIQ AHCI SoC's
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] clk: qoriq: Add platform dependencies
From: Li Yang @ 2020-05-22 21:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, Amit Kucheria, Arnd Bergmann, linux-pm, Stephen Boyd,
Viresh Kumar, Michael Turquette, Daniel Lezcano,
Rafael J . Wysocki, lkml, linux-ide, Zhang Rui, Shawn Guo,
linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200507112955.23520-4-geert+renesas@glider.be>
On Thu, May 7, 2020 at 6:31 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> The Freescale QorIQ clock controller is only present on Freescale E500MC
> and Layerscape SoCs. Add platform dependencies to the CLK_QORIQ config
> symbol, to avoid asking the user about it when configuring a kernel
> without E500MC or Layerscape support.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Hi Michael/Stephen,
Are you applying this patch? If not I can apply it with your ACK.
Regards,
Leo
> ---
> drivers/clk/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index bcb257baed06daa0..22bf015610d1724c 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -232,7 +232,8 @@ config COMMON_CLK_AXI_CLKGEN
>
> config CLK_QORIQ
> bool "Clock driver for Freescale QorIQ platforms"
> - depends on (PPC_E500MC || ARM || ARM64 || COMPILE_TEST) && OF
> + depends on OF
> + depends on PPC_E500MC || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
> ---help---
> This adds the clock driver support for Freescale QorIQ platforms
> using common clock framework.
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] treewide: Replace zero-length array with flexible-array
From: Li Yang @ 2020-05-22 21:24 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200507185301.GA14333@embeddedor>
On Thu, May 7, 2020 at 1:49 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> sizeof(flexible-array-member) triggers a warning because flexible array
> members have incomplete type[1]. There are some instances of code in
> which the sizeof operator is being incorrectly/erroneously applied to
> zero-length arrays and the result is zero. Such instances may be hiding
> some bugs. So, this work (flexible-array member conversions) will also
> help to get completely rid of those sorts of issues.
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> include/linux/fsl/bestcomm/bestcomm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied for next. Thanks.
Regards,
Leo
>
> diff --git a/include/linux/fsl/bestcomm/bestcomm.h b/include/linux/fsl/bestcomm/bestcomm.h
> index a0e2e6b19b57..154e541ce57e 100644
> --- a/include/linux/fsl/bestcomm/bestcomm.h
> +++ b/include/linux/fsl/bestcomm/bestcomm.h
> @@ -27,7 +27,7 @@
> */
> struct bcom_bd {
> u32 status;
> - u32 data[0]; /* variable payload size */
> + u32 data[]; /* variable payload size */
> };
>
> /* ======================================================================== */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [soc:mediatek/dt] BUILD REGRESSION 189881af810d452b592ee958db43eb4c57df9803
From: Arnd Bergmann @ 2020-05-22 21:24 UTC (permalink / raw)
To: Matthias Brugger; +Cc: DTML, arm-soc, kbuild test robot, Linux ARM
In-Reply-To: <5c53e7b7-4caa-06b9-8a9f-b3a29f008bb7@gmail.com>
On Fri, May 22, 2020 at 10:54 PM Matthias Brugger
<matthias.bgg@gmail.com> wrote:
>
> Hi all,
> Hi Arnd and Olof,
>
> On 22/05/2020 13:28, kbuild test robot wrote:
> > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt
> > branch HEAD: 189881af810d452b592ee958db43eb4c57df9803 arm: dts: mt2701: Add usb2 device nodes
> >
> > Error/Warning in current branch:
> >
> > ERROR: Input tree has errors, aborting (use -f to force output)
> >
> > Error/Warning ids grouped by kconfigs:
> >
> > recent_errors
> > `-- arm-randconfig-r035-20200520
> > `-- ERROR:Input-tree-has-errors-aborting-(use-f-to-force-output)
>
> Can you please explain me how to reproduce this. I'm not able to deduce that
> form this email. I can then look into this and how to fix it. Although up to now
> I don't understand where the relation with my dts32 changes is.
I don't see it either here, adding the devicetree list, in case anyone has more
information.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper
From: Li Yang @ 2020-05-22 21:23 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Kees Cook, Gustavo A. R. Silva, lkml, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Qiang Zhao
In-Reply-To: <20200518221904.GA22274@embeddedor>
On Mon, May 18, 2020 at 5:16 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
>
> but the preferred mechanism to declare variable-length types such as
> these ones is a flexible array member[1][2], introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on. So, replace
> the one-element array with a flexible-array member.
>
> Also, make use of the new struct_size() helper to properly calculate the
> size of struct qe_firmware.
>
> This issue was found with the help of Coccinelle and, audited and fixed
> _manually_.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> drivers/soc/fsl/qe/qe.c | 4 ++--
> include/soc/fsl/qe/qe.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied for next. Thanks.
Regards,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper
From: Li Yang @ 2020-05-22 21:21 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, lkml, Gustavo A. R. Silva, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Qiang Zhao
In-Reply-To: <202005202022.588918E61@keescook>
On Wed, May 20, 2020 at 10:24 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, May 20, 2020 at 06:52:21PM -0500, Li Yang wrote:
> > On Mon, May 18, 2020 at 5:57 PM Kees Cook <keescook@chromium.org> wrote:
> > > Hm, looking at this code, I see a few other things that need to be
> > > fixed:
> > >
> > > 1) drivers/tty/serial/ucc_uart.c does not do a be32_to_cpu() conversion
> > > on the length test (understandably, a little-endian system has never run
> > > this code since it's ppc specific), but it's still wrong:
> > >
> > > if (firmware->header.length != fw->size) {
> > >
> > > compare to the firmware loader:
> > >
> > > length = be32_to_cpu(hdr->length);
> > >
> > > 2) drivers/soc/fsl/qe/qe.c does not perform bounds checking on the
> > > per-microcode offsets, so the uploader might send data outside the
> > > firmware buffer. Perhaps:
> >
> > We do validate the CRC for each microcode, it is unlikely the CRC
> > check can pass if the offset or length is not correct. But you are
> > probably right that it will be safer to check the boundary and fail
>
> Right, but a malicious firmware file could still match CRC but trick the
> kernel code.
>
> > quicker before we actually start the CRC check. Will you come up with
> > a formal patch or you want us to deal with it?
>
> It sounds like Gustavo will be sending one, though I don't think either
> of us have the hardware to test it with, so if you could do that part,
> that would be great! :)
That will be great. I think Zhao Qiang can help with the testing part.
Regards,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: David Miller @ 2020-05-22 21:20 UTC (permalink / raw)
To: brgl
Cc: edwin.peer, devicetree, stephane.leprovost, arnd, bgolaszewski,
netdev, sean.wang, linux-kernel, pedro.tsai, fparent, robh+dt,
linux-mediatek, andrew.perepech, john, matthias.bgg, kuba,
Mark-MC.Lee, linux-arm-kernel, hkallweit1
In-Reply-To: <20200522120700.838-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Fri, 22 May 2020 14:06:49 +0200
> This series adds support for the STAR Ethernet Controller present on MediaTeK
> SoCs from the MT8* family.
Series applied to net-next, thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [soc:mediatek/dt] BUILD REGRESSION 189881af810d452b592ee958db43eb4c57df9803
From: Matthias Brugger @ 2020-05-22 20:54 UTC (permalink / raw)
To: kbuild test robot, arm; +Cc: linux-arm-kernel
In-Reply-To: <5ec7b744.ZcxrA/L/3+XSTqYO%lkp@intel.com>
Hi all,
Hi Arnd and Olof,
On 22/05/2020 13:28, kbuild test robot wrote:
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt
> branch HEAD: 189881af810d452b592ee958db43eb4c57df9803 arm: dts: mt2701: Add usb2 device nodes
>
> Error/Warning in current branch:
>
> ERROR: Input tree has errors, aborting (use -f to force output)
>
> Error/Warning ids grouped by kconfigs:
>
> recent_errors
> `-- arm-randconfig-r035-20200520
> `-- ERROR:Input-tree-has-errors-aborting-(use-f-to-force-output)
Can you please explain me how to reproduce this. I'm not able to deduce that
form this email. I can then look into this and how to fix it. Although up to now
I don't understand where the relation with my dts32 changes is.
Regards,
Matthias
>
> elapsed time: 7969m
>
> configs tested: 274
> configs skipped: 59
>
> arm defconfig
> arm allyesconfig
> arm allmodconfig
> arm allnoconfig
> arm64 allyesconfig
> arm64 defconfig
> arm64 allmodconfig
> arm64 allnoconfig
> sparc allyesconfig
> mips allyesconfig
> m68k allyesconfig
> sh sh03_defconfig
> arm vf610m4_defconfig
> h8300 defconfig
> m68k hp300_defconfig
> powerpc pq2fads_defconfig
> parisc alldefconfig
> sh sh7770_generic_defconfig
> arm mvebu_v7_defconfig
> arm u300_defconfig
> mips cavium_octeon_defconfig
> microblaze defconfig
> powerpc64 alldefconfig
> arm integrator_defconfig
> arc nsimosci_hs_defconfig
> powerpc mpc5200_defconfig
> arm clps711x_defconfig
> mips xway_defconfig
> mips maltaup_defconfig
> arm hisi_defconfig
> um defconfig
> arm davinci_all_defconfig
> sh r7780mp_defconfig
> arm sunxi_defconfig
> arm mmp2_defconfig
> mips loongson1c_defconfig
> arm ep93xx_defconfig
> arc nsimosci_defconfig
> um allnoconfig
> sh secureedge5410_defconfig
> sh apsh4ad0a_defconfig
> powerpc allmodconfig
> s390 debug_defconfig
> sh ap325rxa_defconfig
> c6x defconfig
> h8300 h8300h-sim_defconfig
> arc axs103_smp_defconfig
> mips qi_lb60_defconfig
> ia64 bigsur_defconfig
> openrisc or1ksim_defconfig
> sh lboxre2_defconfig
> powerpc chrp32_defconfig
> sh polaris_defconfig
> c6x evmc6457_defconfig
> arm corgi_defconfig
> mips cu1000-neo_defconfig
> arm ixp4xx_defconfig
> arm mps2_defconfig
> sh microdev_defconfig
> mips allnoconfig
> arm exynos_defconfig
> mips db1xxx_defconfig
> arm64 alldefconfig
> sh sh2007_defconfig
> arm bcm2835_defconfig
> sparc sparc32_defconfig
> ia64 alldefconfig
> sh ecovec24_defconfig
> arm shannon_defconfig
> riscv nommu_k210_defconfig
> powerpc ppc64e_defconfig
> parisc generic-32bit_defconfig
> arc alldefconfig
> sh sh7710voipgw_defconfig
> arm pleb_defconfig
> h8300 alldefconfig
> microblaze mmu_defconfig
> powerpc ppc44x_defconfig
> mips tb0219_defconfig
> parisc defconfig
> s390 allyesconfig
> m68k m5307c3_defconfig
> mips mtx1_defconfig
> arm mv78xx0_defconfig
> arm oxnas_v6_defconfig
> arc vdk_hs38_defconfig
> sh se7751_defconfig
> arm netwinder_defconfig
> arm iop32x_defconfig
> mips ath25_defconfig
> arm pxa_defconfig
> arm mini2440_defconfig
> alpha defconfig
> mips malta_defconfig
> arm assabet_defconfig
> m68k defconfig
> arm h3600_defconfig
> ia64 allnoconfig
> mips loongson3_defconfig
> mips malta_kvm_guest_defconfig
> arc hsdk_defconfig
> arc tb10x_defconfig
> powerpc allnoconfig
> sh sdk7786_defconfig
> arm u8500_defconfig
> sparc64 allyesconfig
> mips lasat_defconfig
> mips tb0287_defconfig
> powerpc mgcoge_defconfig
> um x86_64_defconfig
> powerpc storcenter_defconfig
> sh shmin_defconfig
> powerpc ps3_defconfig
> sparc64 defconfig
> arm keystone_defconfig
> m68k m5272c3_defconfig
> parisc allyesconfig
> mips decstation_defconfig
> mips lemote2f_defconfig
> powerpc tqm8xx_defconfig
> arm shmobile_defconfig
> arm stm32_defconfig
> powerpc holly_defconfig
> mips tb0226_defconfig
> mips rt305x_defconfig
> sh se7750_defconfig
> arm s3c6400_defconfig
> arm pcm027_defconfig
> powerpc ppc64_defconfig
> h8300 h8s-sim_defconfig
> m68k m5208evb_defconfig
> sh se7721_defconfig
> mips sb1250_swarm_defconfig
> powerpc amigaone_defconfig
> parisc generic-64bit_defconfig
> c6x dsk6455_defconfig
> arm multi_v5_defconfig
> xtensa alldefconfig
> arm spear13xx_defconfig
> sh rts7751r2dplus_defconfig
> mips nlm_xlr_defconfig
> sh migor_defconfig
> powerpc mpc512x_defconfig
> nds32 defconfig
> arm moxart_defconfig
> um allyesconfig
> mips rb532_defconfig
> arm imote2_defconfig
> i386 allnoconfig
> i386 allyesconfig
> i386 defconfig
> i386 debian-10.3
> ia64 allmodconfig
> ia64 defconfig
> ia64 allyesconfig
> m68k allmodconfig
> m68k allnoconfig
> m68k sun3_defconfig
> nios2 defconfig
> nios2 allyesconfig
> openrisc defconfig
> c6x allyesconfig
> c6x allnoconfig
> openrisc allyesconfig
> nds32 allnoconfig
> csky allyesconfig
> csky defconfig
> alpha allyesconfig
> xtensa allyesconfig
> h8300 allyesconfig
> h8300 allmodconfig
> xtensa defconfig
> arc defconfig
> arc allyesconfig
> sh allmodconfig
> sh allnoconfig
> microblaze allnoconfig
> mips allmodconfig
> parisc allnoconfig
> parisc allmodconfig
> powerpc allyesconfig
> powerpc rhel-kconfig
> powerpc defconfig
> x86_64 randconfig-a005-20200517
> x86_64 randconfig-a003-20200517
> x86_64 randconfig-a006-20200517
> x86_64 randconfig-a004-20200517
> x86_64 randconfig-a001-20200517
> x86_64 randconfig-a002-20200517
> i386 randconfig-a006-20200518
> i386 randconfig-a005-20200518
> i386 randconfig-a001-20200518
> i386 randconfig-a003-20200518
> i386 randconfig-a004-20200518
> i386 randconfig-a002-20200518
> i386 randconfig-a006-20200519
> i386 randconfig-a005-20200519
> i386 randconfig-a001-20200519
> i386 randconfig-a003-20200519
> i386 randconfig-a004-20200519
> i386 randconfig-a002-20200519
> i386 randconfig-a006-20200517
> i386 randconfig-a005-20200517
> i386 randconfig-a003-20200517
> i386 randconfig-a001-20200517
> i386 randconfig-a004-20200517
> i386 randconfig-a002-20200517
> i386 randconfig-a001-20200520
> i386 randconfig-a004-20200520
> i386 randconfig-a006-20200520
> i386 randconfig-a003-20200520
> i386 randconfig-a002-20200520
> i386 randconfig-a005-20200520
> x86_64 randconfig-a003-20200519
> x86_64 randconfig-a005-20200519
> x86_64 randconfig-a004-20200519
> x86_64 randconfig-a006-20200519
> x86_64 randconfig-a002-20200519
> x86_64 randconfig-a001-20200519
> x86_64 randconfig-a016-20200518
> x86_64 randconfig-a012-20200518
> x86_64 randconfig-a015-20200518
> x86_64 randconfig-a013-20200518
> x86_64 randconfig-a011-20200518
> x86_64 randconfig-a014-20200518
> x86_64 randconfig-a013-20200520
> x86_64 randconfig-a015-20200520
> x86_64 randconfig-a016-20200520
> x86_64 randconfig-a012-20200520
> x86_64 randconfig-a014-20200520
> x86_64 randconfig-a011-20200520
> i386 randconfig-a012-20200518
> i386 randconfig-a014-20200518
> i386 randconfig-a016-20200518
> i386 randconfig-a011-20200518
> i386 randconfig-a015-20200518
> i386 randconfig-a013-20200518
> i386 randconfig-a012-20200517
> i386 randconfig-a016-20200517
> i386 randconfig-a014-20200517
> i386 randconfig-a011-20200517
> i386 randconfig-a013-20200517
> i386 randconfig-a015-20200517
> i386 randconfig-a012-20200519
> i386 randconfig-a014-20200519
> i386 randconfig-a016-20200519
> i386 randconfig-a011-20200519
> i386 randconfig-a015-20200519
> i386 randconfig-a013-20200519
> i386 randconfig-a013-20200520
> i386 randconfig-a012-20200520
> i386 randconfig-a015-20200520
> i386 randconfig-a011-20200520
> i386 randconfig-a016-20200520
> i386 randconfig-a014-20200520
> riscv allyesconfig
> riscv allnoconfig
> riscv defconfig
> riscv allmodconfig
> s390 allnoconfig
> s390 allmodconfig
> s390 defconfig
> x86_64 defconfig
> sparc defconfig
> sparc64 allnoconfig
> sparc64 allmodconfig
> um allmodconfig
> x86_64 rhel-7.6-kselftests
> x86_64 rhel
> x86_64 rhel-7.6
> x86_64 rhel-7.2-clear
> x86_64 lkp
> x86_64 fedora-25
> x86_64 kexec
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox