* [PATCH v5 05/21] mtd: rawnand: Return an enum from of_get_nand_ecc_algo()
From: Miquel Raynal @ 2020-05-14 17:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus
Cc: Tudor Ambarus, Julien Su, Schrempf Frieder, Paul Cercueil,
linux-mtd, Thomas Petazzoni, Miquel Raynal, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200514171651.24851-1-miquel.raynal@bootlin.com>
There is an enumeration to list ECC algorithm, let's use it instead of
returning an int.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/raw/nand_base.c | 35 +++++++++++++++++---------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index deb8c21a3cf1..e4296b67adbc 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4997,17 +4997,20 @@ static const char * const nand_ecc_algos[] = {
[NAND_ECC_RS] = "rs",
};
-static int of_get_nand_ecc_algo(struct device_node *np)
+static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
{
+ enum nand_ecc_algo ecc_algo;
const char *pm;
- int err, i;
+ int err;
err = of_property_read_string(np, "nand-ecc-algo", &pm);
if (!err) {
- for (i = NAND_ECC_HAMMING; i < ARRAY_SIZE(nand_ecc_algos); i++)
- if (!strcasecmp(pm, nand_ecc_algos[i]))
- return i;
- return -ENODEV;
+ for (ecc_algo = NAND_ECC_HAMMING;
+ ecc_algo < ARRAY_SIZE(nand_ecc_algos);
+ ecc_algo++) {
+ if (!strcasecmp(pm, nand_ecc_algos[ecc_algo]))
+ return ecc_algo;
+ }
}
/*
@@ -5015,15 +5018,14 @@ static int of_get_nand_ecc_algo(struct device_node *np)
* for some obsoleted values that were specifying ECC algorithm.
*/
err = of_property_read_string(np, "nand-ecc-mode", &pm);
- if (err < 0)
- return err;
+ if (!err) {
+ if (!strcasecmp(pm, "soft"))
+ return NAND_ECC_HAMMING;
+ else if (!strcasecmp(pm, "soft_bch"))
+ return NAND_ECC_BCH;
+ }
- if (!strcasecmp(pm, "soft"))
- return NAND_ECC_HAMMING;
- else if (!strcasecmp(pm, "soft_bch"))
- return NAND_ECC_BCH;
-
- return -ENODEV;
+ return NAND_ECC_UNKNOWN;
}
static int of_get_nand_ecc_step_size(struct device_node *np)
@@ -5068,7 +5070,8 @@ static bool of_get_nand_on_flash_bbt(struct device_node *np)
static int nand_dt_init(struct nand_chip *chip)
{
struct device_node *dn = nand_get_flash_node(chip);
- int ecc_mode, ecc_algo, ecc_strength, ecc_step;
+ enum nand_ecc_algo ecc_algo;
+ int ecc_mode, ecc_strength, ecc_step;
if (!dn)
return 0;
@@ -5090,7 +5093,7 @@ static int nand_dt_init(struct nand_chip *chip)
if (ecc_mode >= 0)
chip->ecc.mode = ecc_mode;
- if (ecc_algo >= 0)
+ if (ecc_algo != NAND_ECC_UNKNOWN)
chip->ecc.algo = ecc_algo;
if (ecc_strength >= 0)
--
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 related
* [PATCH v5 04/21] dt-bindings: mtd: Deprecate OOB_FIRST mode
From: Miquel Raynal @ 2020-05-14 17:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus
Cc: Tudor Ambarus, Julien Su, Schrempf Frieder, Paul Cercueil,
linux-mtd, Thomas Petazzoni, Miquel Raynal, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200514171651.24851-1-miquel.raynal@bootlin.com>
This mode has never actually been used, it was introduced for a single
driver and even this driver did not use it in the DT but only in the
code. Now that this mode has been removed, let's trim the bindings
definition to avoid carrying useless properties.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Documentation/devicetree/bindings/mtd/atmel-nand.txt | 3 +--
Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 3aa297c97ab6..ead1826d0d51 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -143,8 +143,7 @@ Required properties:
Optional properties:
- atmel,nand-has-dma : boolean to support dma transfer for nand read/write.
- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
- Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
- "soft_bch".
+ Supported values are: "none", "soft", "hw", "hw_syndrome", "soft_bch".
- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware,
capable of BCH encoding and decoding, on devices where it is present.
- atmel,pmecc-cap : error correct capability for Programmable Multibit ECC
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index d261b7096c69..d529f8587ba6 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -49,7 +49,7 @@ patternProperties:
nand-ecc-mode:
allOf:
- $ref: /schemas/types.yaml#/definitions/string
- - enum: [ none, soft, hw, hw_syndrome, hw_oob_first, on-die ]
+ - enum: [ none, soft, hw, hw_syndrome, on-die ]
description:
Desired ECC engine, either hardware (most of the time
embedded in the NAND controller) or software correction
--
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 related
* [PATCH v5 03/21] mtd: rawnand: Drop OOB_FIRST placement scheme
From: Miquel Raynal @ 2020-05-14 17:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus
Cc: Tudor Ambarus, Julien Su, Schrempf Frieder, Paul Cercueil,
linux-mtd, Thomas Petazzoni, Miquel Raynal, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200514171651.24851-1-miquel.raynal@bootlin.com>
This scheme has been introduced for the Davinci controller and means
that the OOB area must be read *before* the rest of the data. This has
nothing to do with the ECC in OOB placement as it could be understood
and most importantly, there is no point in having this function out of
the Davinci NAND controller driver. A DT property for this scheme has
been added but never used, even by the Davinci driver which only uses
this scheme to change the default nand_read_page().
Move the main read_page() helper into the Davinci driver and remove
the remaining boilerplate.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/raw/davinci_nand.c | 126 +++++++++++++++++++++-------
drivers/mtd/nand/raw/nand_base.c | 81 ------------------
include/linux/mtd/rawnand.h | 1 -
3 files changed, 98 insertions(+), 110 deletions(-)
diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
index 25c185bea50c..5ea562098c8c 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -410,6 +410,77 @@ static int nand_davinci_correct_4bit(struct nand_chip *chip, u_char *data,
return corrected;
}
+/**
+ * nand_read_page_hwecc_oob_first - hw ecc, read oob first
+ * @chip: nand chip info structure
+ * @buf: buffer to store read data
+ * @oob_required: caller requires OOB data read to chip->oob_poi
+ * @page: page number to read
+ *
+ * Hardware ECC for large page chips, require OOB to be read first. For this
+ * ECC mode, the write_page method is re-used from ECC_HW. These methods
+ * read/write ECC from the OOB area, unlike the ECC_HW_SYNDROME support with
+ * multiple ECC steps, follows the "infix ECC" scheme and reads/writes ECC from
+ * the data area, by overwriting the NAND manufacturer bad block markings.
+ */
+static int nand_davinci_read_page_hwecc_oob_first(struct nand_chip *chip,
+ uint8_t *buf,
+ int oob_required, int page)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ int i, eccsize = chip->ecc.size, ret;
+ int eccbytes = chip->ecc.bytes;
+ int eccsteps = chip->ecc.steps;
+ uint8_t *p = buf;
+ uint8_t *ecc_code = chip->ecc.code_buf;
+ uint8_t *ecc_calc = chip->ecc.calc_buf;
+ unsigned int max_bitflips = 0;
+
+ /* Read the OOB area first */
+ ret = nand_read_oob_op(chip, page, 0, chip->oob_poi, mtd->oobsize);
+ if (ret)
+ return ret;
+
+ ret = nand_read_page_op(chip, page, 0, NULL, 0);
+ if (ret)
+ return ret;
+
+ ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+ chip->ecc.total);
+ if (ret)
+ return ret;
+
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
+ int stat;
+
+ chip->ecc.hwctl(chip, NAND_ECC_READ);
+
+ ret = nand_read_data_op(chip, p, eccsize, false, false);
+ if (ret)
+ return ret;
+
+ chip->ecc.calculate(chip, p, &ecc_calc[i]);
+
+ stat = chip->ecc.correct(chip, p, &ecc_code[i], NULL);
+ if (stat == -EBADMSG &&
+ (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
+ /* check for empty pages with bitflips */
+ stat = nand_check_erased_ecc_chunk(p, eccsize,
+ &ecc_code[i],
+ eccbytes, NULL, 0,
+ chip->ecc.strength);
+ }
+
+ if (stat < 0) {
+ mtd->ecc_stats.failed++;
+ } else {
+ mtd->ecc_stats.corrected += stat;
+ max_bitflips = max_t(unsigned int, max_bitflips, stat);
+ }
+ }
+ return max_bitflips;
+}
+
/*----------------------------------------------------------------------*/
/*
@@ -613,6 +684,13 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
break;
case NAND_ECC_HW:
if (pdata->ecc_bits == 4) {
+ int chunks = mtd->writesize / 512;
+
+ if (!chunks || mtd->oobsize < 16) {
+ dev_dbg(&info->pdev->dev, "too small\n");
+ return -EINVAL;
+ }
+
/*
* No sanity checks: CPUs must support this,
* and the chips may not use NAND_BUSWIDTH_16.
@@ -635,6 +713,26 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
info->chip.ecc.bytes = 10;
info->chip.ecc.options = NAND_ECC_GENERIC_ERASED_CHECK;
info->chip.ecc.algo = NAND_ECC_BCH;
+
+ /*
+ * Update ECC layout if needed ... for 1-bit HW ECC, the
+ * default is OK, but it allocates 6 bytes when only 3
+ * are needed (for each 512 bytes). For 4-bit HW ECC,
+ * the default is not usable: 10 bytes needed, not 6.
+ *
+ * For small page chips, preserve the manufacturer's
+ * badblock marking data ... and make sure a flash BBT
+ * table marker fits in the free bytes.
+ */
+ if (chunks == 1) {
+ mtd_set_ooblayout(mtd,
+ &hwecc4_small_ooblayout_ops);
+ } else if (chunks == 4 || chunks == 8) {
+ mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ info->chip.ecc.read_page = nand_davinci_read_page_hwecc_oob_first;
+ } else {
+ return -EIO;
+ }
} else {
/* 1bit ecc hamming */
info->chip.ecc.calculate = nand_davinci_calculate_1bit;
@@ -650,34 +748,6 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
return -EINVAL;
}
- /*
- * Update ECC layout if needed ... for 1-bit HW ECC, the default
- * is OK, but it allocates 6 bytes when only 3 are needed (for
- * each 512 bytes). For the 4-bit HW ECC, that default is not
- * usable: 10 bytes are needed, not 6.
- */
- if (pdata->ecc_bits == 4) {
- int chunks = mtd->writesize / 512;
-
- if (!chunks || mtd->oobsize < 16) {
- dev_dbg(&info->pdev->dev, "too small\n");
- return -EINVAL;
- }
-
- /* For small page chips, preserve the manufacturer's
- * badblock marking data ... and make sure a flash BBT
- * table marker fits in the free bytes.
- */
- if (chunks == 1) {
- mtd_set_ooblayout(mtd, &hwecc4_small_ooblayout_ops);
- } else if (chunks == 4 || chunks == 8) {
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
- info->chip.ecc.mode = NAND_ECC_HW_OOB_FIRST;
- } else {
- return -EIO;
- }
- }
-
return ret;
}
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 097650be7e0d..deb8c21a3cf1 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -3024,76 +3024,6 @@ static int nand_read_page_hwecc(struct nand_chip *chip, uint8_t *buf,
return max_bitflips;
}
-/**
- * nand_read_page_hwecc_oob_first - [REPLACEABLE] hw ecc, read oob first
- * @chip: nand chip info structure
- * @buf: buffer to store read data
- * @oob_required: caller requires OOB data read to chip->oob_poi
- * @page: page number to read
- *
- * Hardware ECC for large page chips, require OOB to be read first. For this
- * ECC mode, the write_page method is re-used from ECC_HW. These methods
- * read/write ECC from the OOB area, unlike the ECC_HW_SYNDROME support with
- * multiple ECC steps, follows the "infix ECC" scheme and reads/writes ECC from
- * the data area, by overwriting the NAND manufacturer bad block markings.
- */
-static int nand_read_page_hwecc_oob_first(struct nand_chip *chip, uint8_t *buf,
- int oob_required, int page)
-{
- struct mtd_info *mtd = nand_to_mtd(chip);
- int i, eccsize = chip->ecc.size, ret;
- int eccbytes = chip->ecc.bytes;
- int eccsteps = chip->ecc.steps;
- uint8_t *p = buf;
- uint8_t *ecc_code = chip->ecc.code_buf;
- uint8_t *ecc_calc = chip->ecc.calc_buf;
- unsigned int max_bitflips = 0;
-
- /* Read the OOB area first */
- ret = nand_read_oob_op(chip, page, 0, chip->oob_poi, mtd->oobsize);
- if (ret)
- return ret;
-
- ret = nand_read_page_op(chip, page, 0, NULL, 0);
- if (ret)
- return ret;
-
- ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
- chip->ecc.total);
- if (ret)
- return ret;
-
- for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
- int stat;
-
- chip->ecc.hwctl(chip, NAND_ECC_READ);
-
- ret = nand_read_data_op(chip, p, eccsize, false, false);
- if (ret)
- return ret;
-
- chip->ecc.calculate(chip, p, &ecc_calc[i]);
-
- stat = chip->ecc.correct(chip, p, &ecc_code[i], NULL);
- if (stat == -EBADMSG &&
- (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
- /* check for empty pages with bitflips */
- stat = nand_check_erased_ecc_chunk(p, eccsize,
- &ecc_code[i], eccbytes,
- NULL, 0,
- chip->ecc.strength);
- }
-
- if (stat < 0) {
- mtd->ecc_stats.failed++;
- } else {
- mtd->ecc_stats.corrected += stat;
- max_bitflips = max_t(unsigned int, max_bitflips, stat);
- }
- }
- return max_bitflips;
-}
-
/**
* nand_read_page_syndrome - [REPLACEABLE] hardware ECC syndrome based page read
* @chip: nand chip info structure
@@ -5034,7 +4964,6 @@ static const char * const nand_ecc_modes[] = {
[NAND_ECC_SOFT] = "soft",
[NAND_ECC_HW] = "hw",
[NAND_ECC_HW_SYNDROME] = "hw_syndrome",
- [NAND_ECC_HW_OOB_FIRST] = "hw_oob_first",
[NAND_ECC_ON_DIE] = "on-die",
};
@@ -5783,16 +5712,6 @@ static int nand_scan_tail(struct nand_chip *chip)
*/
switch (ecc->mode) {
- case NAND_ECC_HW_OOB_FIRST:
- /* Similar to NAND_ECC_HW, but a separate read_page handle */
- if (!ecc->calculate || !ecc->correct || !ecc->hwctl) {
- WARN(1, "No ECC functions supplied; hardware ECC not possible\n");
- ret = -EINVAL;
- goto err_nand_manuf_cleanup;
- }
- if (!ecc->read_page)
- ecc->read_page = nand_read_page_hwecc_oob_first;
- fallthrough;
case NAND_ECC_HW:
/* Use standard hwecc read page function? */
if (!ecc->read_page)
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 85eb1a3b8edd..bc7c7d9adae9 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -88,7 +88,6 @@ enum nand_ecc_mode {
NAND_ECC_SOFT,
NAND_ECC_HW,
NAND_ECC_HW_SYNDROME,
- NAND_ECC_HW_OOB_FIRST,
NAND_ECC_ON_DIE,
};
--
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 related
* [PATCH v5 01/21] mtd: Fix typo in mtd_ooblayout_set_databytes() description
From: Miquel Raynal @ 2020-05-14 17:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus
Cc: Tudor Ambarus, Julien Su, Schrempf Frieder, Paul Cercueil,
Boris Brezillon, linux-mtd, Thomas Petazzoni, Miquel Raynal,
Mason Yang, Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200514171651.24851-1-miquel.raynal@bootlin.com>
Fix a probable copy/paste error: the function works like
mtd_ooblayout_set_bytes(), not *_get_bytes().
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/mtdcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 50437b4ffe76..8c4dcfa49e35 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1800,7 +1800,7 @@ EXPORT_SYMBOL_GPL(mtd_ooblayout_get_databytes);
* @start: first ECC byte to set
* @nbytes: number of ECC bytes to set
*
- * Works like mtd_ooblayout_get_bytes(), except it acts on free bytes.
+ * Works like mtd_ooblayout_set_bytes(), except it acts on free bytes.
*
* Returns zero on success, a negative error code otherwise.
*/
--
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 related
* [PATCH v5 00/21] Prepare the introduction of generic ECC engines
From: Miquel Raynal @ 2020-05-14 17:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus
Cc: Tudor Ambarus, Julien Su, Schrempf Frieder, Paul Cercueil,
linux-mtd, Thomas Petazzoni, Miquel Raynal, Mason Yang,
Chuanhong Guo, linux-arm-kernel
Already 3 series have been sent on this topic but as they grow over
time, I decided to split it arbitrary and take only the preparation
patches that are here. The actual ECC machinery will be contributed
later when this preparation series will be merged.
Thanks,
Miquèl
Changes in v5
=============
* Rebased on top of nand/next
* Avoided a fallthrough situation in commit:
mtd: rawnand: Separate the ECC engine type and the OOB placement
* Fixed an of_dev_put() build issue due to a missing dummy helper.
* Extracted a patch that deserved to be merged quickly.
* Fixed a few issues reported by robots.
Changes in v4
=============
* Rebased on top of a recent kernel version.
* Added Boris' reviewed-by.
* Added Maxime's Acked-by tag.
* Added the missing of_device.h header to ecc.c.
* Corrected a 'minimum' comparison by using min_t.
* Updated the new Macronix raw NAND controller driver by using the new
(ECC related) function names.
* Fixed a function call in ndfc.c.
* Update brcmnand.c file to fit new enumerations and structures (due
to recent Kamal's changes).
* Force sm_ftl to depends on the Hamming engine, because by just
selecting it the ECC code would be embedded in the NAND core and the
NAND core might not be compiled in with sm_ftl.
* Fixed a structure field name that I previously added in davinci
platform data.
* Moved the oob_first placement scheme to Davinci driver. Removed any
occurence of it out of the driver (unused).
* Simplify structure names as proposed by Boris.
* Change enumeration/string names about ECC engine
providers/placements.
* Change the logic in the of_get_nand_ecc_* helpers to ensure backward
compatibility.
* Use enums intead of unsigned integers in the core when referring to
ECC engine type, placement and algorithm.
* Add nand-ecc-placement DT property.
* Deprecate hw_syndrome.
* Deprecate nand-ecc-mode in favor of nand-ecc-provider.
* Fixed a typo in the Macronix ECC driver, where I made a copy/paste
error which I haven't spotted because it is located in a macro only
compiled when building the driver as a module (name of the of_ids
was prefixed marvell_nfc instead of mxic_ecc).
* Simplified the ECC engine API by dropping the useless oobbuf
parameter. Instead, ECC engine drivers are supposed to provide a
spare OOB buffer if none is provided. Updated the three existing
engines.
* Fixed BCH software engine with the help of Mason from Macronix.
* Added a mechanism called "tweaking req" to change the SPI-NAND
requests and ensure they always contain the right amount of data/OOB
needed for the ECC engine to work properly.
Changes in v3
=============
* Added Boris' Reviewed-by tags.
* Added a kernel doc header on the nand_page_io_req enumeration.
* Added support for HW engines.
* Droped the patch clarifying the value of the first entry in
enumerations (which is always 0).
* Rename the nand_ecc_conf structure as nand_ecc_props because the
_conf suffix implies that it is possible to edit it, while in some
cases (eg. on-die ECC) there is nothing to tweak.
* Smoother introduction of the ECC engine abstraction.
* Renamed the ECC engine module nand_ecc_engine.ko.
* Moved all the ECC files into drivers/mtd/nand/. Forgot the ecc/
subdirectory.
* Added a new series to drop the ECC mode enumeration wich mixes the
provider (none, hw, sw, on-die) and the OOB placement (first,
syndrome).
* Various typos fixed.
* Added a few patches to fix bugs found in SPI-NAND/mtdchar.c.
* Introduced the external hardware ECC engine boilerplate.
Changes in v2
=============
* SPDX license identifiers for soft BCH and Hamming: the license macro
was right, "GPL" means "GPLv2 or higher", so do not change this
portion. Also update the commit messages to fit the actual change.
* Do not compile-in the NAND core by default, do it only for raw
NAND. Remove the dependencies on CONFIG_MTD in a different
patch. Also, keep an extra level of hierarchy in Kconfig for the
NAND bits by adding a menu instead of a config.
* Moved the standard OOB layouts in the ecc/engine.c driver instead of
in the NAND core.
* Used the nand_ecc_ prefix in most of the engines functions instead
of just ecc_, which is now reserved for bare helpers. Get rid of the
__ecc prefix.
* In the sunxi NAND controller driver: moved the ECC structure from
sunxi_nfc to sunxi_nand_chip as the ECC engine is per-chip and not
per controller.
* Software Hamming ECC engine is only enabled by default if raw NAND
is also enabled. NDFC now selects the software Hamming ECC engine
(instead of depending on it).
* Mention in software BCH and Hamming Kconfig entries that booting
from NAND is very likely to fail if the user selects these symbols
as modules.
* Added Boris Reviewed-by tag on the SPI-NAND typo fixing patch.
* Renamed the "mode" into a "provider" entry in the ECC configuration
structures.
* Moved the "total" entry of the ECC configuration directly in the
context structure (should probably not be public but let's keep it
as is for now).
* Split the generic ECC engine introduction into smaller patches to do
some renaming aside.
* Drop the "maximize" entry in the ECC engine configuration structure,
keep using a flag like before.
* Canceled the move of the SPI-NAND specific ECC engine out of the
core file.
* Amended the root ECC structures to have three nand_ecc_conf
structures: one for the defaults, one for the chip requirements, one
for the user desires.
* Created a *ondie_engine pointer in the nand_ecc structure to save
the on-die ECC engine, if any. For instance, saving a reference to
this engine is done by the SPI-NAND core.
* Dropped the SPI-NAND flag that was used to distinguish between NAND
flavors from the NAND core, it should not be needed anymore.
* Added an helper in the NAND core to put a reference on an ECC
engine. This will be used by the hardware engines only.
* Renamed the files ecc/sw-{bch,hamming}.c and their headers
include/linux/mtd/nand-ecc-sw-{bch,hamming}-engine.h.
* Created a MTD_NAND_ECC invisible Kconfig symbol.
* Added plenty of missing EXPORT_SYMBOL{,_GPL}().
* Minor modifications so that everything still compiles even when
modules and built-in drivers are mixed in Kconfig in the whole NAND
directory.
Miquel Raynal (21):
mtd: Fix typo in mtd_ooblayout_set_databytes() description
mtd: rawnand: Avoid a typedef
mtd: rawnand: Drop OOB_FIRST placement scheme
dt-bindings: mtd: Deprecate OOB_FIRST mode
mtd: rawnand: Return an enum from of_get_nand_ecc_algo()
mtd: rawnand: Add an invalid ECC mode to discriminate with valid ones
mtd: rawnand: Create a new enumeration to describe OOB placement
mtd: rawnand: Separate the ECC engine type and the OOB placement
mtd: rawnand: Create a new enumeration to describe properly ECC types
mtd: rawnand: Create a helper to retrieve the ECC placement
mtd: rawnand: Use the new ECC engine type enumeration
mtd: rawnand: Deprecate nand-ecc-mode in favor of nand-ecc-provider
mtd: rawnand: Drop the legacy ECC type enumeration
dt-bindings: mtd: Add the nand-ecc-placement property
dt-bindings: mtd: Deprecate hw_syndrome from the ECC modes
dt-bindings: mtd: Deprecate the nand-ecc-mode property
mtd: nand: Move nand_device forward declaration to the top
mtd: nand: Add an extra level in the Kconfig hierarchy
mtd: nand: Drop useless 'depends on' in Kconfig
mtd: nand: Add a NAND page I/O request type
mtd: nand: Rename a core structure
.../devicetree/bindings/mtd/atmel-nand.txt | 3 +-
.../bindings/mtd/nand-controller.yaml | 27 +-
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-da850-evm.c | 2 +-
arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
arch/arm/mach-davinci/board-dm355-leopard.c | 3 +-
arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/board-mityomapl138.c | 2 +-
arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
arch/arm/mach-s3c24xx/common-smdk.c | 2 +-
arch/arm/mach-s3c24xx/mach-anubis.c | 2 +-
arch/arm/mach-s3c24xx/mach-at2440evb.c | 2 +-
arch/arm/mach-s3c24xx/mach-bast.c | 2 +-
arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
arch/arm/mach-s3c24xx/mach-mini2440.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
arch/arm/mach-s3c24xx/mach-qt2410.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx1950.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx3715.c | 2 +-
arch/arm/mach-s3c24xx/mach-vstms.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-real6410.c | 2 +-
drivers/mtd/mtdcore.c | 2 +-
drivers/mtd/nand/Kconfig | 5 +
drivers/mtd/nand/onenand/Kconfig | 1 -
drivers/mtd/nand/raw/Kconfig | 1 -
drivers/mtd/nand/raw/ams-delta.c | 2 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 14 +-
drivers/mtd/nand/raw/au1550nd.c | 2 +-
.../mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c | 3 +-
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 8 +-
.../mtd/nand/raw/cadence-nand-controller.c | 4 +-
drivers/mtd/nand/raw/cafe_nand.c | 3 +-
drivers/mtd/nand/raw/cmx270_nand.c | 2 +-
drivers/mtd/nand/raw/cs553x_nand.c | 2 +-
drivers/mtd/nand/raw/davinci_nand.c | 153 +++++---
drivers/mtd/nand/raw/denali.c | 3 +-
drivers/mtd/nand/raw/diskonchip.c | 3 +-
drivers/mtd/nand/raw/fsl_elbc_nand.c | 18 +-
drivers/mtd/nand/raw/fsl_ifc_nand.c | 10 +-
drivers/mtd/nand/raw/fsl_upm.c | 2 +-
drivers/mtd/nand/raw/fsmc_nand.c | 12 +-
drivers/mtd/nand/raw/gpio.c | 2 +-
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 2 +-
drivers/mtd/nand/raw/hisi504_nand.c | 6 +-
.../mtd/nand/raw/ingenic/ingenic_nand_drv.c | 14 +-
drivers/mtd/nand/raw/lpc32xx_mlc.c | 2 +-
drivers/mtd/nand/raw/lpc32xx_slc.c | 3 +-
drivers/mtd/nand/raw/marvell_nand.c | 17 +-
drivers/mtd/nand/raw/meson_nand.c | 2 +-
drivers/mtd/nand/raw/mpc5121_nfc.c | 2 +-
drivers/mtd/nand/raw/mtk_nand.c | 6 +-
drivers/mtd/nand/raw/mxc_nand.c | 23 +-
drivers/mtd/nand/raw/nand_base.c | 336 ++++++++----------
drivers/mtd/nand/raw/nand_micron.c | 4 +-
drivers/mtd/nand/raw/nand_toshiba.c | 3 +-
drivers/mtd/nand/raw/nandsim.c | 4 +-
drivers/mtd/nand/raw/ndfc.c | 2 +-
drivers/mtd/nand/raw/omap2.c | 20 +-
drivers/mtd/nand/raw/orion_nand.c | 2 +-
drivers/mtd/nand/raw/pasemi_nand.c | 2 +-
drivers/mtd/nand/raw/plat_nand.c | 2 +-
drivers/mtd/nand/raw/qcom_nandc.c | 2 +-
drivers/mtd/nand/raw/r852.c | 3 +-
drivers/mtd/nand/raw/s3c2410.c | 16 +-
drivers/mtd/nand/raw/sh_flctl.c | 4 +-
drivers/mtd/nand/raw/sharpsl.c | 2 +-
drivers/mtd/nand/raw/socrates_nand.c | 3 +-
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 9 +-
drivers/mtd/nand/raw/sunxi_nand.c | 18 +-
drivers/mtd/nand/raw/tango_nand.c | 2 +-
drivers/mtd/nand/raw/tegra_nand.c | 2 +-
drivers/mtd/nand/raw/tmio_nand.c | 2 +-
drivers/mtd/nand/raw/txx9ndfmc.c | 2 +-
drivers/mtd/nand/raw/vf610_nfc.c | 4 +-
drivers/mtd/nand/raw/xway_nand.c | 2 +-
drivers/mtd/nand/spi/core.c | 4 +-
include/linux/mtd/nand.h | 30 +-
include/linux/mtd/rawnand.h | 46 ++-
include/linux/mtd/spinand.h | 2 +-
include/linux/platform_data/mtd-davinci.h | 9 +-
.../linux/platform_data/mtd-nand-s3c2410.h | 2 +-
87 files changed, 529 insertions(+), 420 deletions(-)
--
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
* [PATCH v5 02/21] mtd: rawnand: Avoid a typedef
From: Miquel Raynal @ 2020-05-14 17:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus
Cc: Tudor Ambarus, Julien Su, Schrempf Frieder, Paul Cercueil,
Boris Brezillon, linux-mtd, Thomas Petazzoni, Miquel Raynal,
Mason Yang, Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200514171651.24851-1-miquel.raynal@bootlin.com>
In new code, the use of typedef is discouraged. Turn this one in the
raw NAND core into a regular enumeration.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/nand/raw/nand_base.c | 4 ++--
include/linux/mtd/rawnand.h | 6 +++---
include/linux/platform_data/mtd-davinci.h | 2 +-
include/linux/platform_data/mtd-nand-s3c2410.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 7fab932694f5..097650be7e0d 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5053,8 +5053,8 @@ static int of_get_nand_ecc_mode(struct device_node *np)
/*
* For backward compatibility we support few obsoleted values that don't
- * have their mappings into nand_ecc_modes_t anymore (they were merged
- * with other enums).
+ * have their mappings into the nand_ecc_mode enum anymore (they were
+ * merged with other enums).
*/
if (!strcasecmp(pm, "soft_bch"))
return NAND_ECC_SOFT;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 0f45b6984ad1..85eb1a3b8edd 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -83,14 +83,14 @@ struct nand_chip;
/*
* Constants for ECC_MODES
*/
-typedef enum {
+enum nand_ecc_mode {
NAND_ECC_NONE,
NAND_ECC_SOFT,
NAND_ECC_HW,
NAND_ECC_HW_SYNDROME,
NAND_ECC_HW_OOB_FIRST,
NAND_ECC_ON_DIE,
-} nand_ecc_modes_t;
+};
enum nand_ecc_algo {
NAND_ECC_UNKNOWN,
@@ -362,7 +362,7 @@ static const struct nand_ecc_caps __name = { \
* @write_oob: function to write chip OOB data
*/
struct nand_ecc_ctrl {
- nand_ecc_modes_t mode;
+ enum nand_ecc_mode mode;
enum nand_ecc_algo algo;
int steps;
int size;
diff --git a/include/linux/platform_data/mtd-davinci.h b/include/linux/platform_data/mtd-davinci.h
index 08e639e047e5..03e92c71b3fa 100644
--- a/include/linux/platform_data/mtd-davinci.h
+++ b/include/linux/platform_data/mtd-davinci.h
@@ -68,7 +68,7 @@ struct davinci_nand_pdata { /* platform_data */
* Newer ones also support 4-bit ECC, but are awkward
* using it with large page chips.
*/
- nand_ecc_modes_t ecc_mode;
+ enum nand_ecc_mode ecc_mode;
u8 ecc_bits;
/* e.g. NAND_BUSWIDTH_16 */
diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
index deb849bcf0ec..08675b16f9e1 100644
--- a/include/linux/platform_data/mtd-nand-s3c2410.h
+++ b/include/linux/platform_data/mtd-nand-s3c2410.h
@@ -49,7 +49,7 @@ struct s3c2410_platform_nand {
unsigned int ignore_unset_ecc:1;
- nand_ecc_modes_t ecc_mode;
+ enum nand_ecc_mode ecc_mode;
int nr_sets;
struct s3c2410_nand_set *sets;
--
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 related
* Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
From: Enric Balletbo i Serra @ 2020-05-14 17:12 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Nicolas Boichat, Daniel Vetter, Enric Balletbo Serra,
linux-kernel, dri-devel, David Airlie,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
Philipp Zabel, Hsin-Yi Wang, Matthias Brugger,
Collabora Kernel ML, Sam Ravnborg, Linux ARM
In-Reply-To: <CAAOTY__b6V12fS2xTKGjB1fQTfRjX7AQyBqDPXzshfhkjjSkeQ@mail.gmail.com>
Hi Chun-Kuang,
On 14/5/20 18:44, Chun-Kuang Hu wrote:
> Hi, Enric:
>
> Enric Balletbo i Serra <enric.balletbo@collabora.com> 於 2020年5月14日 週四 下午11:42寫道：
>>
>> Hi Chun-Kuang,
>>
>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
>>> Hi, Enric:
>>>
>>> Enric Balletbo Serra <eballetbo@gmail.com> 於 2020年5月14日 週四 上午12:41寫道：
>>>>
>>>> Hi Chun-Kuang,
>>>>
>>>> Missatge de Enric Balletbo i Serra <enric.balletbo@collabora.com> del
>>>> dia dv., 1 de maig 2020 a les 17:25:
>>>>>
>>>>> Use the drm_bridge_connector helper to create a connector for pipelines
>>>>> that use drm_bridge. This allows splitting connector operations across
>>>>> multiple bridges when necessary, instead of having the last bridge in
>>>>> the chain creating the connector and handling all connector operations
>>>>> internally.
>>>>>
>>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>>>>
>>>> A gentle ping on this, I think that this one is the only one that
>>>> still needs a review in the series.
>>>
>>> This is what I reply in patch v3:
>>>
>>
>> Sorry for missing this.
>>
>>> I think the panel is wrapped into next_bridge here,
>>>
>>
>> Yes, you can have for example:
>>
>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> drm_panel_bridge
>> (edp panel)
>>
>> or a
>>
>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
>>
>> The _first_ one is my use case
>>
>>> if (panel) {
>>
>> This handles the second case, where you attach a dsi panel.
>>
>>> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
>>>
>>> so the next_bridge is a panel_bridge, in its attach function
>>> panel_bridge_attach(),
>>> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
>>> it would create connector and attach connector to panel.
>>>
>>> I'm not sure this flag would exist or not, but for both case, it's strange.
>>> If exist, you create connector in this patch but no where to attach
>>> connector to panel.
>>
>> Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi,
>> mtk_dsi and mtk_hdmi to the new drm_bridge API the drm_bridge_connector_init()
>> will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init for
>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
>> graphic controller driver should create connectors and CRTCs, as example you can
>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
>>
>
> I have such question because I've reviewed omap's driver. In omap's
> driver, after it call drm_bridge_connector_init(), it does this:
>
> if (pipe->output->panel) {
> ret = drm_panel_attach(pipe->output->panel,
> pipe->connector);
> if (ret < 0)
> return ret;
> }
>
> In this patch, you does not do this.
>
I see, so yes, I am probably missing call drm_panel_attach in case there is a
direct panel attached. Thanks for pointing it.
I'll send a new version adding the drm_panel_attach call.
>>> If not exist, the next_brige would create one connector and this brige
>>> would create another connector.
>>>
>>> I think in your case, mtk_dsi does not directly connect to a panel, so
>>
>> Exactly
>>
>>> I need a exact explain. Or someone could test this on a
>>> directly-connect-panel platform.
>>
>> I don't think I am breaking this use case but AFAICS there is no users in
>> mainline that directly connect a panel using the mediatek driver. As I said my
>> use case is the other so I can't really test. Do you know anyone that can test this?
>
> I'm not sure who can test this, but [1], which is sent by YT Shen in a
> series, is a patch to support dsi command mode so dsi could directly
> connect to panel.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.7-rc5&id=21898816831fc60c92dd634ab4316a24da7eb4af
>
> It's better that someone could test this case, but if no one would
> test this, I could also accept a good-look patch.
>
> Regards,
> Chun-Kuang.
>
>>
>> Thanks,
>> Enric
>>
>>>
>>> Regards,
>>> Chun-Kuang.
>>>
>>>>
>>>> Thanks,
>>>> Enric
>>>>
>>>>> ---
>>>>>
>>>>> Changes in v4: None
>>>>> Changes in v3:
>>>>> - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart)
>>>>>
>>>>> Changes in v2: None
>>>>>
>>>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++++++++++++-
>>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>>>> index 4f3bd095c1ee..471fcafdf348 100644
>>>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>>>> @@ -17,6 +17,7 @@
>>>>>
>>>>> #include <drm/drm_atomic_helper.h>
>>>>> #include <drm/drm_bridge.h>
>>>>> +#include <drm/drm_bridge_connector.h>
>>>>> #include <drm/drm_mipi_dsi.h>
>>>>> #include <drm/drm_of.h>
>>>>> #include <drm/drm_panel.h>
>>>>> @@ -183,6 +184,7 @@ struct mtk_dsi {
>>>>> struct drm_encoder encoder;
>>>>> struct drm_bridge bridge;
>>>>> struct drm_bridge *next_bridge;
>>>>> + struct drm_connector *connector;
>>>>> struct phy *phy;
>>>>>
>>>>> void __iomem *regs;
>>>>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>>>>> */
>>>>> dsi->encoder.possible_crtcs = 1;
>>>>>
>>>>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
>>>>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
>>>>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>>>>> if (ret)
>>>>> goto err_cleanup_encoder;
>>>>>
>>>>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
>>>>> + if (IS_ERR(dsi->connector)) {
>>>>> + DRM_ERROR("Unable to create bridge connector\n");
>>>>> + ret = PTR_ERR(dsi->connector);
>>>>> + goto err_cleanup_encoder;
>>>>> + }
>>>>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>>>>> +
>>>>> return 0;
>>>>>
>>>>> err_cleanup_encoder:
>>>>> --
>>>>> 2.26.2
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-mediatek mailing list
>>>>> Linux-mediatek@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
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 0/2] Add CPU power management for CPU bound CTI devices.
From: Mathieu Poirier @ 2020-05-14 17:12 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, tglx, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20200511204836.27870-1-mike.leach@linaro.org>
On Mon, May 11, 2020 at 09:48:34PM +0100, Mike Leach wrote:
> Adds in power management for CPU bound CTI devices:
> i) CPU Hotplug - registers a new notifier for CPU start and stop events.
> ii) CPU idle PM event notifier to handle PM_ENTER, PM_ENTER_FAILED and
> PM_EXIT events.
>
> Tested with DB410c on coresight/next tree (Linux 5.7-rc1)
>
> Changes since v2:
> 1) removed helper functions filtering on CONFIG_CPU_PM to call cpu_pm
> fns directly.
> 2) add check for return value from cpuhp_remove_state_nocalls().
>
> Changes since V1: (requested by Mathieu).
> 1) Split into separate patches for CPU pm and CPU hotplug handling.
> 2) Enable on hotplug has a specific function to enable the hardware,
> while leaving the enable reference counts unchanged.
>
> Mike Leach (2):
> coresight: cti: Add CPU Hotplug handling to CTI driver.
> coresight: cti: Add CPU idle pm notifer to CTI devices.
I have applied this set.
Thanks,
Mathieu
>
> drivers/hwtracing/coresight/coresight-cti.c | 160 ++++++++++++++++++++
> include/linux/cpuhotplug.h | 1 +
> 2 files changed, 161 insertions(+)
>
> --
> 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 v2 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend
From: Asutosh Das (asd) @ 2020-05-14 17:06 UTC (permalink / raw)
To: Stanley Chu, linux-scsi, martin.petersen, avri.altman,
alim.akhtar, jejb
Cc: bvanassche, andy.teng, chun-hung.wu, kuohong.wang, linux-kernel,
cang, linux-mediatek, peter.wang, matthias.bgg, linux-arm-kernel,
beanhuo
In-Reply-To: <20200514150122.32110-5-stanley.chu@mediatek.com>
On 5/14/2020 8:01 AM, Stanley Chu wrote:
> Currently UFS host driver promises VCC supply if UFS device
> needs to do WriteBooster flush during runtime suspend.
>
> However the UFS specification mentions,
>
> "While the flushing operation is in progress, the device is
> in Active power mode."
>
> Therefore UFS host driver needs to promise more: Keep UFS
> device as "Active power mode", otherwise UFS device shall not
> do any flush if device enters Sleep or PowerDown power mode.
>
> Fix this by not changing device power mode if WriteBooster
> flush is required in ufshcd_suspend().
>
> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
> ---
> drivers/scsi/ufs/ufs.h | 1 -
> drivers/scsi/ufs/ufshcd.c | 42 ++++++++++++++++++++-------------------
> 2 files changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> index b3135344ab3f..9e4bc2e97ada 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -577,7 +577,6 @@ struct ufs_dev_info {
> u32 d_ext_ufs_feature_sup;
> u8 b_wb_buffer_type;
> u32 d_wb_alloc_units;
> - bool keep_vcc_on;
> u8 b_presrv_uspc_en;
> };
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 169a3379e468..b9f7744ca2b4 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
> !hba->dev_info.is_lu_power_on_wp) {
> ufshcd_setup_vreg(hba, false);
> } else if (!ufshcd_is_ufs_dev_active(hba)) {
> - if (!hba->dev_info.keep_vcc_on)
> - ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
> + ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
> if (!ufshcd_is_link_active(hba)) {
> ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
> ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
> @@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
> enum ufs_pm_level pm_lvl;
> enum ufs_dev_pwr_mode req_dev_pwr_mode;
> enum uic_link_state req_link_state;
> + bool keep_curr_dev_pwr_mode = false;
>
> hba->pm_op_in_progress = 1;
> if (!ufshcd_is_shutdown_pm(pm_op)) {
> @@ -8227,27 +8227,29 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
> ufshcd_disable_auto_bkops(hba);
> }
> /*
> - * With wb enabled, if the bkops is enabled or if the
> - * configured WB type is 70% full, keep vcc ON
> - * for the device to flush the wb buffer
> + * If device needs to do BKOP or WB buffer flush during
> + * Hibern8, keep device power mode as "active power mode"
> + * and VCC supply.
> */
> - if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
> - ufshcd_wb_keep_vcc_on(hba))
> - hba->dev_info.keep_vcc_on = true;
> - else
> - hba->dev_info.keep_vcc_on = false;
> - } else {
> - hba->dev_info.keep_vcc_on = false;
> + keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
> + (((req_link_state == UIC_LINK_HIBERN8_STATE) ||
> + ((req_link_state == UIC_LINK_ACTIVE_STATE) &&
> + ufshcd_is_auto_hibern8_enabled(hba))) &&
> + ufshcd_wb_keep_vcc_on(hba));
> }
>
This looks fine.
But I still think the delayed check of flush status should be done to
turn-off Vcc when flush is complete.
> - if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&
> - ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
> - !ufshcd_is_runtime_pm(pm_op))) {
> - /* ensure that bkops is disabled */
> - ufshcd_disable_auto_bkops(hba);
> - ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
> - if (ret)
> - goto enable_gating;
> + if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
> + if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
> + !ufshcd_is_runtime_pm(pm_op)) {
> + /* ensure that bkops is disabled */
> + ufshcd_disable_auto_bkops(hba);
> + }
> +
> + if (!keep_curr_dev_pwr_mode) {
> + ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
> + if (ret)
> + goto enable_gating;
> + }
> }
>
> flush_work(&hba->eeh_work);
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
_______________________________________________
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 v1 2/9] dmaengine: Actions: Add support for S700 DMA engine
From: André Przywara @ 2020-05-14 17:02 UTC (permalink / raw)
To: Amit Singh Tomar, vkoul, afaerber, manivannan.sadhasivam
Cc: dmaengine, dan.j.williams, linux-actions, linux-arm-kernel,
cristian.ciocaltea
In-Reply-To: <1589472657-3930-3-git-send-email-amittomer25@gmail.com>
On 14/05/2020 17:10, Amit Singh Tomar wrote:
Hi,
> DMA controller present on S700 SoC is compatible with the one on S900
> (as most of registers are same), but it has different DMA descriptor
> structure where registers "fcnt" and "ctrlb" uses different encoding.
>
> For instance, on S900 "fcnt" starts at offset 0x0c and uses upper 12
> bits whereas on S700, it starts at offset 0x1c and uses lower 12 bits.
>
> This commit adds support for DMA controller present on S700.
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> Changes since RFC:
> * Added accessor function to get the frame lenght.
> * Removed the SoC specific check in IRQ routine.
> ---
> drivers/dma/owl-dma.c | 50 +++++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
> index b0d80a2fa383..afa6c6f43d26 100644
> --- a/drivers/dma/owl-dma.c
> +++ b/drivers/dma/owl-dma.c
> @@ -134,6 +134,11 @@ enum owl_dmadesc_offsets {
> OWL_DMADESC_SIZE
> };
>
> +enum owl_dma_id {
> + S900_DMA,
> + S700_DMA,
> +};
> +
> /**
> * struct owl_dma_lli - Link list for dma transfer
> * @hw: hardware link list
> @@ -200,6 +205,7 @@ struct owl_dma_vchan {
> * @pchans: array of data for the physical channels
> * @nr_vchans: the number of physical channels
> * @vchans: array of data for the physical channels
> + * @devid: device id based on OWL SoC
> */
> struct owl_dma {
> struct dma_device dma;
> @@ -214,6 +220,7 @@ struct owl_dma {
>
> unsigned int nr_vchans;
> struct owl_dma_vchan *vchans;
> + enum owl_dma_id devid;
> };
>
> static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,
> @@ -308,6 +315,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
> return ctl;
> }
>
> +static inline u32 llc_hw_flen(struct owl_dma_lli *lli)
Drop the inline, that's not needed. The compiler knows better.
> +{
> + return lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
> +}
Please introduce this function in the previous patch already. Otherwise
you replace code here that you introduced only there.
> +
> static void owl_dma_free_lli(struct owl_dma *od,
> struct owl_dma_lli *lli)
> {
> @@ -354,6 +366,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> struct dma_slave_config *sconfig,
> bool is_cyclic)
> {
> + struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
> u32 mode, ctrlb;
>
> mode = OWL_DMA_MODE_PW(0);
> @@ -409,8 +422,14 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> lli->hw[OWL_DMADESC_DADDR] = dst;
> lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
> lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> - lli->hw[OWL_DMADESC_FLEN] = len | 1 << 20;
> - lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> +
> + if (od->devid == S700_DMA) {
> + lli->hw[OWL_DMADESC_FLEN] = len;
> + lli->hw[OWL_DMADESC_CTRLB] = 1 | ctrlb;
> + } else {
> + lli->hw[OWL_DMADESC_FLEN] = len | 1 << 20;
> + lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
Can you either add comments or use macros to explain what's going on
here? What is the "1" about?
> + }
>
> return 0;
> }
> @@ -572,7 +591,7 @@ static irqreturn_t owl_dma_interrupt(int irq, void *dev_id)
>
> global_irq_pending = dma_readl(od, OWL_DMA_IRQ_PD0);
>
> - if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
> + if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
> dev_dbg(od->dma.dev,
> "global and channel IRQ pending match err\n");
>
> @@ -741,9 +760,9 @@ static u32 owl_dma_getbytes_chan(struct owl_dma_vchan *vchan)
> list_for_each_entry(lli, &txd->lli_list, node) {
> /* Start from the next active node */
> if (lli->phys == next_lli_phy) {
> - list_for_each_entry(lli, &txd->lli_list, node)
> - bytes += lli->hw[OWL_DMADESC_FLEN] &
> - GENMASK(19, 0);
> + list_for_each_entry(lli, &txd->lli_list,
> + node)
Not needed line break?
Cheers,
Andre.
> + bytes += llc_hw_flen(lli);
> break;
> }
> }
> @@ -774,7 +793,7 @@ static enum dma_status owl_dma_tx_status(struct dma_chan *chan,
> if (vd) {
> txd = to_owl_txd(&vd->tx);
> list_for_each_entry(lli, &txd->lli_list, node)
> - bytes += lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
> + bytes += llc_hw_flen(lli);
> } else {
> bytes = owl_dma_getbytes_chan(vchan);
> }
> @@ -1031,11 +1050,20 @@ static struct dma_chan *owl_dma_of_xlate(struct of_phandle_args *dma_spec,
> return chan;
> }
>
> +static const struct of_device_id owl_dma_match[] = {
> + { .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
> + { .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, owl_dma_match);
> +
> static int owl_dma_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct owl_dma *od;
> int ret, i, nr_channels, nr_requests;
> + const struct of_device_id *of_id =
> + of_match_device(owl_dma_match, &pdev->dev);
>
> od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
> if (!od)
> @@ -1060,6 +1088,8 @@ static int owl_dma_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
> nr_channels, nr_requests);
>
> + od->devid = (enum owl_dma_id)of_id->data;
> +
> od->nr_pchans = nr_channels;
> od->nr_vchans = nr_requests;
>
> @@ -1192,12 +1222,6 @@ static int owl_dma_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id owl_dma_match[] = {
> - { .compatible = "actions,s900-dma", },
> - { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(of, owl_dma_match);
> -
> static struct platform_driver owl_dma_driver = {
> .probe = owl_dma_probe,
> .remove = owl_dma_remove,
>
_______________________________________________
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 v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend
From: Asutosh Das (asd) @ 2020-05-14 16:59 UTC (permalink / raw)
To: Stanley Chu
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
Andy Teng ($B{}G!9((B), jejb@linux.ibm.com,
Chun-Hung Wu (巫駿宏),
Kuohong Wang (王國鴻),
linux-kernel@vger.kernel.org, avri.altman@wdc.com,
cang@codeaurora.org, linux-mediatek@lists.infradead.org,
Peter Wang (王信友), alim.akhtar@samsung.com,
matthias.bgg@gmail.com, beanhuo@micron.com,
linux-arm-kernel@lists.infradead.org, bvanassche@acm.org
In-Reply-To: <1589467766.3197.100.camel@mtkswgap22>
On 5/14/2020 7:49 AM, Stanley Chu wrote:
> Hi Asutosh,
>
> On Thu, 2020-05-14 at 10:23 +0800, Stanley Chu wrote:
>> Hi Asutosh,
>>
>> On Wed, 2020-05-13 at 12:31 -0700, Asutosh Das (asd) wrote:
>>> On 5/12/2020 3:47 AM, Stanley Chu wrote:
>>>> Currently UFS host driver promises VCC supply if UFS device
>>>> needs to do WriteBooster flush during runtime suspend.
>>>>
>>>> However the UFS specification mentions,
>>>>
>>>> "While the flushing operation is in progress, the device is
>>>> in Active power mode."
>>>>
>>>> Therefore UFS host driver needs to promise more: Keep UFS
>>>> device as "Active power mode", otherwise UFS device shall not
>>>> do any flush if device enters Sleep or PowerDown power mode.
>>>>
>>>> Fix this by not changing device power mode if WriteBooster
>>>> flush is required in ufshcd_suspend().
>>>>
>>>> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
>>>> ---
>>>> drivers/scsi/ufs/ufs.h | 1 -
>>>> drivers/scsi/ufs/ufshcd.c | 39 +++++++++++++++++++--------------------
>>>> 2 files changed, 19 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
>>>> index b3135344ab3f..9e4bc2e97ada 100644
>>>> --- a/drivers/scsi/ufs/ufs.h
>>>> +++ b/drivers/scsi/ufs/ufs.h
>>>> @@ -577,7 +577,6 @@ struct ufs_dev_info {
>>>> u32 d_ext_ufs_feature_sup;
>>>> u8 b_wb_buffer_type;
>>>> u32 d_wb_alloc_units;
>>>> - bool keep_vcc_on;
>>>> u8 b_presrv_uspc_en;
>>>> };
>>>>
>>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>>> index 169a3379e468..2d0aff8ac260 100644
>>>> --- a/drivers/scsi/ufs/ufshcd.c
>>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>>> @@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
>>>> !hba->dev_info.is_lu_power_on_wp) {
>>>> ufshcd_setup_vreg(hba, false);
>>>> } else if (!ufshcd_is_ufs_dev_active(hba)) {
>>>> - if (!hba->dev_info.keep_vcc_on)
>>>> - ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
>>>> + ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
>>>> if (!ufshcd_is_link_active(hba)) {
>>>> ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
>>>> ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
>>>> @@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>>>> enum ufs_pm_level pm_lvl;
>>>> enum ufs_dev_pwr_mode req_dev_pwr_mode;
>>>> enum uic_link_state req_link_state;
>>>> + bool keep_curr_dev_pwr_mode = false;
>>>>
>>>> hba->pm_op_in_progress = 1;
>>>> if (!ufshcd_is_shutdown_pm(pm_op)) {
>>>> @@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>>>> /* make sure that auto bkops is disabled */
>>>> ufshcd_disable_auto_bkops(hba);
>>>> }
>>>> +
>>> Unnecessary newline, perhaps?
>>
>> Yap, I will remove it in next version.
>>
>>>> /*
>>>> - * With wb enabled, if the bkops is enabled or if the
>>>> - * configured WB type is 70% full, keep vcc ON
>>>> - * for the device to flush the wb buffer
>>>> + * If device needs to do BKOP or WB buffer flush, keep device
>>>> + * power mode as "active power mode" and its VCC supply.
>>>> */
>>>> - if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
>>>> - ufshcd_wb_keep_vcc_on(hba))
>>>> - hba->dev_info.keep_vcc_on = true;
>>>> - else
>>>> - hba->dev_info.keep_vcc_on = false;
>>>> - } else {
>>>> - hba->dev_info.keep_vcc_on = false;
>>>> + keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
>>>> + ufshcd_wb_keep_vcc_on(hba);
>>> Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops?
>>>
>>> Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush
>>> on hibern8 is enabled and the link is being put to hibern8 mode during
>>> runtime-suspend? Perhaps that should also be factored in here?
>>
>> Both auto-bkops and WriteBooster flush during Hibern8 need device power
>> mode to be "Active Power Mode".
>>
>> For auto-bkops, the spec mentions,
>>
>> "If the background operations enable bit is set and the device is in
>> Active power mode or Idle power mode, then the device is allowed to
>> execute any internal operations."
>>
>> For WriteBooster flush during Hibern8, the spec mentions,
>>
>> "While the flushing operation is in progress, the device is in Active
>> power mode."
>>
>> Therefore here we can use an unified "keep_curr_dev_pwr_mode" to
>> indicate the same requirements of above both features.
>>
>> Besides, both operations may access flash array inside UFS device thus
>> VCC supply shall be also kept.
>>
>> Before this patch, the original code will keep device power mode (stay
>> in Active Power Mode) if hba->auto_bkops_enabled is set as true during
>> runtime-suspend with UFSHCD_CAP_AUTO_BKOPS_SUSPEND capability is
>> enabled. This patch will not change this decision, just add
>> "WriteBooster flush during Hibern8" feature as another condition to do
>> so.
>>
>> Thank you so much to remind me that "Link shall be put in Hibern8" is a
>> necessary condition for "WriteBooster flush during Hibern8". I will add
>> more checking for keep_curr_dev_pwr_mode to prevent unnecessary power
>> drain.
>>
>>>> }
>>>>
>>>> - if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&
>>>> - ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
>>>> - !ufshcd_is_runtime_pm(pm_op))) {
>>>> - /* ensure that bkops is disabled */
>>>> - ufshcd_disable_auto_bkops(hba);
>>>> - ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
>>>> - if (ret)
>>>> - goto enable_gating;
>>>> + if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
>>>> + if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
>>>> + !ufshcd_is_runtime_pm(pm_op)) {
>>>> + /* ensure that bkops is disabled */
>>>> + ufshcd_disable_auto_bkops(hba);
>>>> + }
>>>> +
>>>> + if (!keep_curr_dev_pwr_mode) {
>>>> + ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
>>>
>>> Now, when the WB buffer is completely flushed out, the device should be
>>> put back into UFS_SLEEP_PWR_MODE or UFS_POWERDOWN_PWR_MODE. Say, the
>>> device buffer has to be flushed and during runtime-suspend, the device
>>> is put to UFS_ACTIVE_PWR_MODE and Vcc is kept ON; the device doesn't
>>> resume nor does the system enters suspend for a very long time, and with
>>> AH8 and hibern8 disabled, there will be an unnecessary power drain for
>>> that much time.
>
> Another thought is that if keep_curr_dev_pwr_mode will be set as true
> only if link is put in Hibern8 or Auto-Hibern8 is enabled. By this way,
> the power consumption shall be very small after flush or auto-bkop is
> finished.
>
> Then the checking of flush status during runtime-suspend may be not
> necessary.
>
>>>
>>> How about a periodic interval checking of flush status if
>>> keep_curr_dev_pwr_mode evaluates to be true?
>>
>> This is a good point!
>>
>> The same thing also happens for auto-bkops. How about add a timer to
>> leave runtime suspend if keep_curr_dev_pwr_mode is set as true? This is
>> simple and also favors power. The timeout value could be adjustable
>> according to the available WriteBooster buffer size.
>>
>> A periodic interval checking of flush status needs to re-activate link
>> to communicate with the device. This would be tricky and the
>> re-activation flow is just like runtime-resume.
>>
>> What would you think?
>>
>> Thanks.
>> Stanley Chu
>>
>>
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
Hi Stanley,
I think that'd work, but there's definitely a penalty of keeping Vcc ON.
And if we do want to keep it ON, then we'd have to measure how much
excess power is being used - after the flush is done.
I think setting keep_curr_dev_pwr_mode to true iff h8 and ah8 are
enabled is a good idea. In addition to that, adding a timer to check
flush status if keep_curr_dev_pwr_mode is set to true would keep the
power consumption to a minimum. So I suggest to have the delayed check
of flush status as well.
Thanks,
-asd
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
_______________________________________________
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 v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
From: Chun-Kuang Hu @ 2020-05-14 16:44 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Chun-Kuang Hu, Nicolas Boichat, Daniel Vetter,
Enric Balletbo Serra, linux-kernel, dri-devel, David Airlie,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
Philipp Zabel, Hsin-Yi Wang, Matthias Brugger,
Collabora Kernel ML, Sam Ravnborg, Linux ARM
In-Reply-To: <53683f2d-23c7-57ab-2056-520c50795ffe@collabora.com>
Hi, Enric:
Enric Balletbo i Serra <enric.balletbo@collabora.com> 於 2020年5月14日 週四 下午11:42寫道：
>
> Hi Chun-Kuang,
>
> On 14/5/20 16:28, Chun-Kuang Hu wrote:
> > Hi, Enric:
> >
> > Enric Balletbo Serra <eballetbo@gmail.com> 於 2020年5月14日 週四 上午12:41寫道：
> >>
> >> Hi Chun-Kuang,
> >>
> >> Missatge de Enric Balletbo i Serra <enric.balletbo@collabora.com> del
> >> dia dv., 1 de maig 2020 a les 17:25:
> >>>
> >>> Use the drm_bridge_connector helper to create a connector for pipelines
> >>> that use drm_bridge. This allows splitting connector operations across
> >>> multiple bridges when necessary, instead of having the last bridge in
> >>> the chain creating the connector and handling all connector operations
> >>> internally.
> >>>
> >>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> >>
> >> A gentle ping on this, I think that this one is the only one that
> >> still needs a review in the series.
> >
> > This is what I reply in patch v3:
> >
>
> Sorry for missing this.
>
> > I think the panel is wrapped into next_bridge here,
> >
>
> Yes, you can have for example:
>
> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> drm_panel_bridge
> (edp panel)
>
> or a
>
> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
>
> The _first_ one is my use case
>
> > if (panel) {
>
> This handles the second case, where you attach a dsi panel.
>
> > dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
> >
> > so the next_bridge is a panel_bridge, in its attach function
> > panel_bridge_attach(),
> > according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> > it would create connector and attach connector to panel.
> >
> > I'm not sure this flag would exist or not, but for both case, it's strange.
> > If exist, you create connector in this patch but no where to attach
> > connector to panel.
>
> Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi,
> mtk_dsi and mtk_hdmi to the new drm_bridge API the drm_bridge_connector_init()
> will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init for
> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
> graphic controller driver should create connectors and CRTCs, as example you can
> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
>
I have such question because I've reviewed omap's driver. In omap's
driver, after it call drm_bridge_connector_init(), it does this:
if (pipe->output->panel) {
ret = drm_panel_attach(pipe->output->panel,
pipe->connector);
if (ret < 0)
return ret;
}
In this patch, you does not do this.
> > If not exist, the next_brige would create one connector and this brige
> > would create another connector.
> >
> > I think in your case, mtk_dsi does not directly connect to a panel, so
>
> Exactly
>
> > I need a exact explain. Or someone could test this on a
> > directly-connect-panel platform.
>
> I don't think I am breaking this use case but AFAICS there is no users in
> mainline that directly connect a panel using the mediatek driver. As I said my
> use case is the other so I can't really test. Do you know anyone that can test this?
I'm not sure who can test this, but [1], which is sent by YT Shen in a
series, is a patch to support dsi command mode so dsi could directly
connect to panel.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.7-rc5&id=21898816831fc60c92dd634ab4316a24da7eb4af
It's better that someone could test this case, but if no one would
test this, I could also accept a good-look patch.
Regards,
Chun-Kuang.
>
> Thanks,
> Enric
>
> >
> > Regards,
> > Chun-Kuang.
> >
> >>
> >> Thanks,
> >> Enric
> >>
> >>> ---
> >>>
> >>> Changes in v4: None
> >>> Changes in v3:
> >>> - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart)
> >>>
> >>> Changes in v2: None
> >>>
> >>> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++++++++++++-
> >>> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> index 4f3bd095c1ee..471fcafdf348 100644
> >>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> @@ -17,6 +17,7 @@
> >>>
> >>> #include <drm/drm_atomic_helper.h>
> >>> #include <drm/drm_bridge.h>
> >>> +#include <drm/drm_bridge_connector.h>
> >>> #include <drm/drm_mipi_dsi.h>
> >>> #include <drm/drm_of.h>
> >>> #include <drm/drm_panel.h>
> >>> @@ -183,6 +184,7 @@ struct mtk_dsi {
> >>> struct drm_encoder encoder;
> >>> struct drm_bridge bridge;
> >>> struct drm_bridge *next_bridge;
> >>> + struct drm_connector *connector;
> >>> struct phy *phy;
> >>>
> >>> void __iomem *regs;
> >>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> >>> */
> >>> dsi->encoder.possible_crtcs = 1;
> >>>
> >>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> >>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> >>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >>> if (ret)
> >>> goto err_cleanup_encoder;
> >>>
> >>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> >>> + if (IS_ERR(dsi->connector)) {
> >>> + DRM_ERROR("Unable to create bridge connector\n");
> >>> + ret = PTR_ERR(dsi->connector);
> >>> + goto err_cleanup_encoder;
> >>> + }
> >>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> >>> +
> >>> return 0;
> >>>
> >>> err_cleanup_encoder:
> >>> --
> >>> 2.26.2
> >>>
> >>>
> >>> _______________________________________________
> >>> Linux-mediatek mailing list
> >>> Linux-mediatek@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
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 v4 00/12] kgdb: Support late serial drivers; enable early debug w/ boot consoles
From: Greg Kroah-Hartman @ 2020-05-14 16:36 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, linux-doc, Catalin Marinas, Bjorn Andersson,
H. Peter Anvin, Mauro Carvalho Chehab, Frank Rowand,
Daniel Thompson, Jonathan Corbet, Will Deacon, x86, Russell King,
Krzysztof Kozlowski, jinho lim, Andy Gross, Pawan Gupta,
Linux ARM, linux-serial, kgdb-bugreport, Dave Martin,
Masami Hiramatsu, linux-arm-msm, Jiri Slaby, Alexios Zavras, bp,
Thomas Gleixner, Ingo Molnar, Allison Randal, Juergen Gross,
Sumit Garg, LKML, James Morse, Eric W. Biederman, Jason Wessel,
Andrew Morton, Enrico Weigelt
In-Reply-To: <CAD=FV=X+t_Wg5KadZBTGHMSEXY3c-t6DZAtdaLXys31QJJpGGA@mail.gmail.com>
On Thu, May 14, 2020 at 09:34:26AM -0700, Doug Anderson wrote:
> > (though we must keep
> > changes to drivers/tty/serial/kgdboc alongside the kgdb changes).
> >
> > I can hoover them up but I'd need a solid set of acks and
> > I don't think we've got that yet.
>
> It would be nice for it to be explicit, but "get_maintainer" says that
> Greg KH is the maintainer of serial drivers. Git log confirms that he
> also has been the one landing changes to these files. Early-on he
> provided his Reviewed-by for the series as a whole, so he's aware of
> it and maybe would be fine w/ the serial changes landing through the
> kgdb tree?
>
> Greg: is that correct?
I have no objection for all of these to go through any other tree that
wants to take them :)
But if you want me to take them in the serial tree, to make it easier
for you or any other serial driver issues, I will be glad to do that,
just send them my way. It's your call.
thanks,
greg k-h
_______________________________________________
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 v4 00/12] kgdb: Support late serial drivers; enable early debug w/ boot consoles
From: Doug Anderson @ 2020-05-14 16:34 UTC (permalink / raw)
To: Daniel Thompson, Greg Kroah-Hartman, Will Deacon, Catalin Marinas
Cc: Mark Rutland, linux-doc, kgdb-bugreport, Bjorn Andersson,
H. Peter Anvin, Mauro Carvalho Chehab, Frank Rowand,
Jonathan Corbet, x86, Russell King, Krzysztof Kozlowski,
jinho lim, Andy Gross, Pawan Gupta, Linux ARM, linux-serial,
Jiri Slaby, Dave Martin, Masami Hiramatsu, linux-arm-msm,
Alexios Zavras, bp, Thomas Gleixner, Ingo Molnar, Allison Randal,
Juergen Gross, Sumit Garg, LKML, James Morse, Eric W. Biederman,
Jason Wessel, Andrew Morton, Enrico Weigelt
In-Reply-To: <20200514162109.6qt5drd27hpilijh@holly.lan>
Hi,
On Thu, May 14, 2020 at 9:21 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Thu, May 07, 2020 at 01:08:38PM -0700, Douglas Anderson wrote:
> > <snip>
> >
> > My first attempt was to try to get the existing "ekgdboc" to work
> > earlier. I tried that for a bit until I realized that it needed to
> > work at the tty layer and I couldn't find any serial drivers that
> > managed to register themselves to the tty layer super early at boot.
> > The only documented use of "ekgdboc" is "ekgdboc=kbd" and that's a bit
> > of a special snowflake. Trying to get my serial driver and all its
> > dependencies to probe normally and register the tty driver super early
> > at boot seemed like a bad way to go. In fact, all the complexity
> > needed to do something like this is why the system already has a
> > special concept of a "boot console" that lives only long enough to
> > transition to the normal console.
> >
> > <snip>
> >
> > The devices I had for testing were:
> > - arm32: rk3288-veyron-jerry
> > - arm64: rk3399-gru-kevin
> > - arm64: qcom-sc7180-trogdor (not mainline yet)
> >
> > These are the devices I tested this series on. I tried to test
> > various combinations of enabling/disabling various options and I
> > hopefully caught the corner cases, but I'd appreciate any extra
> > testing people can do. Notably I didn't test on x86, but (I think) I
> > didn't touch much there so I shouldn't have broken anything.
>
> I have tested a slightly earlier version using qemu and will test this
> set before it moves forwards.
>
>
> > .../admin-guide/kernel-parameters.txt | 20 ++
> > Documentation/dev-tools/kgdb.rst | 24 ++
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/include/asm/debug-monitors.h | 2 +
> > arch/arm64/kernel/debug-monitors.c | 2 +-
> > arch/arm64/kernel/traps.c | 3 +
> > arch/x86/Kconfig | 1 +
> > drivers/tty/serial/8250/8250_early.c | 23 ++
> > drivers/tty/serial/amba-pl011.c | 32 +++
> > drivers/tty/serial/kgdboc.c | 268 ++++++++++++++++--
> > drivers/tty/serial/qcom_geni_serial.c | 32 +++
> > include/linux/kgdb.h | 4 +
> > kernel/debug/debug_core.c | 52 +++-
> > lib/Kconfig.kgdb | 18 ++
> > 14 files changed, 436 insertions(+), 46 deletions(-)
>
> Any thoughts on how best to land these changes?
>
> AFAICT the arm64
I was hoping to get an Ack from Will or Catalin for my most recent
arm64 patch [1] and then it could land in your tree. However, it
wouldn't be the end of the world if that landed later. "kgdbwait"
would be broken if you used it together with "kgdb_earlycon" but
overall we'd still be in a better place than we were.
> and 8250/amba-pl011/qcom_geni_serial code
> could be applied independently of the kgdb changes
Right, that would be OK. Nobody would actually be able to use
"kgdb_earlycon" until those landed but there would be no problem with
those two landing separately.
> (though we must keep
> changes to drivers/tty/serial/kgdboc alongside the kgdb changes).
>
> I can hoover them up but I'd need a solid set of acks and
> I don't think we've got that yet.
It would be nice for it to be explicit, but "get_maintainer" says that
Greg KH is the maintainer of serial drivers. Git log confirms that he
also has been the one landing changes to these files. Early-on he
provided his Reviewed-by for the series as a whole, so he's aware of
it and maybe would be fine w/ the serial changes landing through the
kgdb tree?
Greg: is that correct?
> I'd also be happy to ack where needed and let someone else pick it up
> (the other changes queued for kgdb this cycle are pretty small so we
> shouldn't see much conflict in kernel/debug/ ).
It feels to me that the kgdb tree is the best destination for all
these patches if possible.
[1] https://lore.kernel.org/r/20200513160501.1.I0b5edf030cc6ebef6ab4829f8867cdaea42485d8@changeid
-Doug
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ARM: static kernel in vmalloc space
From: Russell King - ARM Linux admin @ 2020-05-14 16:25 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: afzal mohammed, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <CAK8P3a2PNZY-9L9+SFDLtrp731ZGo6Nbs-7jY6E2PwWXa0kfKw@mail.gmail.com>
On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> > On Tue, May 12, 2020 at 09:49:59PM +0200, Arnd Bergmann wrote:
> >
> > > Any idea which bit you want to try next?
> >
> > My plan has been to next post patches for the static kernel migration
> > to vmalloc space (currently the code is rigid, taking easy route
> > wherever possible & not of high quality) as that feature has an
> > independent existence & adds value by itself. And then start working
> > on other steps towards VMSPLIT_4G_4G.
> >
> > Now that you mentioned about other things, i will slowly start those
> > as well.
>
> Sounds good.
>
> > > Creating a raw_copy_{from,to}_user()
> > > based on get_user_pages()/kmap_atomic()/memcpy() is probably a good
> > > next thing to do. I think it can be done one page at a time with only
> > > checking for
> > > get_fs(), access_ok(), and page permissions, while get_user()/put_user()
> > > need to handle a few more corner cases.
> >
> > Before starting w/ other things, i would like to align on the high
> > level design,
> >
> > My understanding (mostly based on your comments) as follows,
> > (i currently do not have a firm grip over these things, hope to have
> > it once started w/ the implementation)
> >
> > 1. SoC w/ LPAE
> > 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc,
> > kmap, fixmap & vectors
>
> Right, these kind of go together because pre-LPAE cannot do the
> same TTBR1 split, and they more frequently have conflicting
> static mappings.
>
> It's clearly possible to do something very similar for older chips
> (v6 or v7 without LPAE, possibly even v5), it just gets harder
> while providing less benefit.
Forget about doing this for anything without a PIPT cache - or you're
going to end up having to flush the data cache each time you enter or
exit the kernel.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
_______________________________________________
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 v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Maxime Ripard @ 2020-05-14 16:22 UTC (permalink / raw)
To: Joerg Roedel
Cc: Mark Rutland, devicetree, iommu, Chen-Yu Tsai, Rob Herring,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20200514131647.GK18353@8bytes.org>
[-- Attachment #1.1: Type: text/plain, Size: 1737 bytes --]
Hi,
On Thu, May 14, 2020 at 03:16:47PM +0200, Joerg Roedel wrote:
> On Thu, May 14, 2020 at 03:09:00PM +0200, Maxime Ripard wrote:
> > On Thu, May 14, 2020 at 02:38:55PM +0200, Joerg Roedel wrote:
> > > On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> > > > Maxime Ripard (5):
> > > > dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> > > > dt-bindings: display: sun8i-mixer: Allow for an iommu property
> > > > iommu: Add Allwinner H6 IOMMU driver
> > > > arm64: dts: allwinner: h6: Add IOMMU
> > > > drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
> > >
> > > Applied all to the IOMMU tree, thanks. The code lives in the
> > > arm/allwinner branch.
> >
> > Did you also merge the DTS and DRM patches?
> >
> > Ideally, they should be merged through other trees to avoid the conflicts as
> > much as possible (arm-soc and drm-misc respectively).
> >
> > If it's an option, could you drop all of them but "dt-bindings: iommu: Add
> > Allwinner H6 IOMMU bindings" and "iommu: Add Allwinner H6 IOMMU driver"?
>
> Okay, just to be on the safe side, I am going to drop:
>
> dt-bindings: display: sun8i-mixer: Allow for an iommu property
> arm64: dts: allwinner: h6: Add IOMMU
> drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
>
> from the iommu-tree?
Yep, please :)
> I took them because you are also maintaining the DRM driver, which
> counted as an implicit ACK for me :)
I also maintain the DTS patches for that matter, but we have a good number of
patches queued up for those files in those trees usually, so it's easier for
everyone to avoid the conflicts and just merge them into separate trees when we
can.
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v4 00/12] kgdb: Support late serial drivers; enable early debug w/ boot consoles
From: Daniel Thompson @ 2020-05-14 16:21 UTC (permalink / raw)
To: Douglas Anderson
Cc: Mark Rutland, linux-doc, catalin.marinas, bjorn.andersson, hpa,
Mauro Carvalho Chehab, will, corbet, frowand.list, x86,
Russell King, Krzysztof Kozlowski, jinho lim, agross, Pawan Gupta,
linux-arm-kernel, linux-serial, kgdb-bugreport, Dave Martin,
Masami Hiramatsu, linux-arm-msm, jslaby, Alexios Zavras, bp, tglx,
mingo, Allison Randal, Juergen Gross, sumit.garg, gregkh,
linux-kernel, James Morse, Eric W. Biederman, jason.wessel,
Andrew Morton, Enrico Weigelt
In-Reply-To: <20200507200850.60646-1-dianders@chromium.org>
On Thu, May 07, 2020 at 01:08:38PM -0700, Douglas Anderson wrote:
> <snip>
>
> My first attempt was to try to get the existing "ekgdboc" to work
> earlier. I tried that for a bit until I realized that it needed to
> work at the tty layer and I couldn't find any serial drivers that
> managed to register themselves to the tty layer super early at boot.
> The only documented use of "ekgdboc" is "ekgdboc=kbd" and that's a bit
> of a special snowflake. Trying to get my serial driver and all its
> dependencies to probe normally and register the tty driver super early
> at boot seemed like a bad way to go. In fact, all the complexity
> needed to do something like this is why the system already has a
> special concept of a "boot console" that lives only long enough to
> transition to the normal console.
>
> <snip>
>
> The devices I had for testing were:
> - arm32: rk3288-veyron-jerry
> - arm64: rk3399-gru-kevin
> - arm64: qcom-sc7180-trogdor (not mainline yet)
>
> These are the devices I tested this series on. I tried to test
> various combinations of enabling/disabling various options and I
> hopefully caught the corner cases, but I'd appreciate any extra
> testing people can do. Notably I didn't test on x86, but (I think) I
> didn't touch much there so I shouldn't have broken anything.
I have tested a slightly earlier version using qemu and will test this
set before it moves forwards.
> .../admin-guide/kernel-parameters.txt | 20 ++
> Documentation/dev-tools/kgdb.rst | 24 ++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/debug-monitors.h | 2 +
> arch/arm64/kernel/debug-monitors.c | 2 +-
> arch/arm64/kernel/traps.c | 3 +
> arch/x86/Kconfig | 1 +
> drivers/tty/serial/8250/8250_early.c | 23 ++
> drivers/tty/serial/amba-pl011.c | 32 +++
> drivers/tty/serial/kgdboc.c | 268 ++++++++++++++++--
> drivers/tty/serial/qcom_geni_serial.c | 32 +++
> include/linux/kgdb.h | 4 +
> kernel/debug/debug_core.c | 52 +++-
> lib/Kconfig.kgdb | 18 ++
> 14 files changed, 436 insertions(+), 46 deletions(-)
Any thoughts on how best to land these changes?
AFAICT the arm64 and 8250/amba-pl011/qcom_geni_serial code
could be applied independently of the kgdb changes (though we must keep
changes to drivers/tty/serial/kgdboc alongside the kgdb changes).
I can hoover them up but I'd need a solid set of acks and
I don't think we've got that yet.
I'd also be happy to ack where needed and let someone else pick it up
(the other changes queued for kgdb this cycle are pretty small so we
shouldn't see much conflict in kernel/debug/ ).
Daniel.
_______________________________________________
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 10/15] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-14 16:19 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <20200514075942.10136-11-brgl@bgdev.pl>
On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> family. For now we only support full-duplex.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Looks very nice overall. Just a few things I noticed, and some ideas
that may or may not make sense:
> +/* This is defined to 0 on arm64 in arch/arm64/include/asm/processor.h but
> + * this IP doesn't work without this alignment being equal to 2.
> + */
> +#ifdef NET_IP_ALIGN
> +#undef NET_IP_ALIGN
> +#endif
> +#define NET_IP_ALIGN 2
Maybe you should just define your own macro instead of replacing
the normal one then?
> +static void mtk_mac_lock(struct mtk_mac_priv *priv)
> +{
> + spin_lock_irqsave(&priv->lock, priv->lock_flags);
> +}
> +
> +static void mtk_mac_unlock(struct mtk_mac_priv *priv)
> +{
> + spin_unlock_irqrestore(&priv->lock, priv->lock_flags);
> +}
This looks wrong: you should not have shared 'flags' passed into
spin_lock_irqsave(), and I don't even see a need to use the
irqsave variant of the lock in the first place.
Maybe start by open-coding the lock and remove the wrappers
above.
Then see if you can use a cheaper spin_lock_bh() or plain spin_lock()
instead of irqsave.
Finally, see if this can be done in a lockless way by relying on
appropriate barriers and separating the writers into separate
cache lines. From a brief look at the driver I think it can be done
without too much trouble.
> +static unsigned int mtk_mac_intr_read_and_clear(struct mtk_mac_priv *priv)
> +{
> + unsigned int val;
> +
> + regmap_read(priv->regs, MTK_MAC_REG_INT_STS, &val);
> + regmap_write(priv->regs, MTK_MAC_REG_INT_STS, val);
> +
> + return val;
> +}
Do you actually need to read the register? That is usually a relatively
expensive operation, so if possible try to use clear the bits when
you don't care which bits were set.
> +/* All processing for TX and RX happens in the napi poll callback. */
> +static irqreturn_t mtk_mac_handle_irq(int irq, void *data)
> +{
> + struct mtk_mac_priv *priv;
> + struct net_device *ndev;
> +
> + ndev = data;
> + priv = netdev_priv(ndev);
> +
> + if (netif_running(ndev)) {
> + mtk_mac_intr_mask_all(priv);
> + napi_schedule(&priv->napi);
> + }
> +
> + return IRQ_HANDLED;
> +static int mtk_mac_netdev_start_xmit(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + struct mtk_mac_priv *priv = netdev_priv(ndev);
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct device *dev = mtk_mac_get_dev(priv);
> + struct mtk_mac_ring_desc_data desc_data;
> +
> + desc_data.dma_addr = mtk_mac_dma_map_tx(priv, skb);
> + if (dma_mapping_error(dev, desc_data.dma_addr))
> + goto err_drop_packet;
> +
> + desc_data.skb = skb;
> + desc_data.len = skb->len;
> +
> + mtk_mac_lock(priv);
> + mtk_mac_ring_push_head_tx(ring, &desc_data);
> +
> + if (mtk_mac_ring_full(ring))
> + netif_stop_queue(ndev);
> + mtk_mac_unlock(priv);
> +
> + mtk_mac_dma_resume_tx(priv);
> +
> + return NETDEV_TX_OK;
> +
> +err_drop_packet:
> + dev_kfree_skb(skb);
> + ndev->stats.tx_dropped++;
> + return NETDEV_TX_BUSY;
> +}
I would always add BQL flow control in new drivers, using
netdev_sent_queue here...
> +static int mtk_mac_tx_complete_one(struct mtk_mac_priv *priv)
> +{
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct mtk_mac_ring_desc_data desc_data;
> + int ret;
> +
> + ret = mtk_mac_ring_pop_tail(ring, &desc_data);
> + if (ret)
> + return ret;
> +
> + mtk_mac_dma_unmap_tx(priv, &desc_data);
> + dev_kfree_skb_irq(desc_data.skb);
> +
> + return 0;
> +}
... and netdev_completed_queue() here.
> +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> +{
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct net_device *ndev = priv->ndev;
> + int ret;
> +
> + for (;;) {
> + mtk_mac_lock(priv);
> +
> + if (!mtk_mac_ring_descs_available(ring)) {
> + mtk_mac_unlock(priv);
> + break;
> + }
> +
> + ret = mtk_mac_tx_complete_one(priv);
> + if (ret) {
> + mtk_mac_unlock(priv);
> + break;
> + }
> +
> + if (netif_queue_stopped(ndev))
> + netif_wake_queue(ndev);
> +
> + mtk_mac_unlock(priv);
> + }
> +}
It looks like most of the stuff inside of the loop can be pulled out
and only done once here.
> +static int mtk_mac_poll(struct napi_struct *napi, int budget)
> +{
> + struct mtk_mac_priv *priv;
> + unsigned int status;
> + int received = 0;
> +
> + priv = container_of(napi, struct mtk_mac_priv, napi);
> +
> + status = mtk_mac_intr_read_and_clear(priv);
> +
> + /* Clean up TX */
> + if (status & MTK_MAC_BIT_INT_STS_TNTC)
> + mtk_mac_tx_complete_all(priv);
> +
> + /* Receive up to $budget packets */
> + if (status & MTK_MAC_BIT_INT_STS_FNRC)
> + received = mtk_mac_process_rx(priv, budget);
> +
> + /* One of the counter reached 0x8000000 - update stats and reset all
> + * counters.
> + */
> + if (status & MTK_MAC_REG_INT_STS_MIB_CNT_TH) {
> + mtk_mac_update_stats(priv);
> + mtk_mac_reset_counters(priv);
> + }
> +
> + if (received < budget)
> + napi_complete_done(napi, received);
> +
> + mtk_mac_intr_unmask_all(priv);
> +
> + return received;
> +}
I think you want to leave (at least some of) the interrupts masked
if your budget is exhausted, to avoid generating unnecessary
irqs.
It may also be faster to not mask/unmask at all but just
clear the interrupts that you have finished processing
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: [Question] Hardware management of stage2 page dirty state
From: Catalin Marinas @ 2020-05-14 16:14 UTC (permalink / raw)
To: zhukeqian
Cc: Marc Zyngier, Zengtao (B), yuzenghui, wanghaibin.wang, kvmarm,
linux-arm-kernel
In-Reply-To: <0767678d-d580-eb02-c2f0-423b16526736@huawei.com>
Hi Keqian,
On Thu, May 14, 2020 at 05:16:52PM +0800, zhukeqian wrote:
> I have some questions after deep reading your patch
> https://patchwork.kernel.org/patch/8824261/ which enables hardware updates
> of the Access Flag for Stage 2 page tables.
>
> I notice that at the bottom of commit message, you said the following words:
> "After some digging through the KVM code, I concluded that hardware DBM
> (dirty bit management) support is not feasible for Stage 2. A potential
> user would be dirty logging but this requires a different bitmap exposed
> to Qemu and, to avoid races, the stage 2 mappings need to be mapped
> read-only on clean, writable on fault. This assumption simplifies the
> hardware Stage 2 AF support."
>
> I have three questions here.
>
> 1. I do not understand the reason well about "not feasible". Does the main reason
> for this is the "races" you referred?
IIRC, dirty logging works by having a bitmap populated by the host
kernel when the guest writes a page. Such write triggers a stage 2 fault
and the kernel populates the bitmap. With S2 DBM, you wouldn't get a
fault when the guest writes the page, so the host kernel would have to
periodically check which S2 entries became writable to update the qemu
bitmap.
I think the race I had in mind was that the bitmap still reports the
page as clean while the guest already updated it.
Looking at this again, it may not matter much as qemu can copy those
pages again when migrating and before control is handed over to the new
host.
> 2. What does the "races" refer to? Do you mean the races between [hardware S2 DBM]
> and [dirty information collection that executed by KVM]?
Yes.
> During VM live migration, Qemu will send dirty page iteratively and finally stop
> VM when dirty pages is not too much. We may miss dirty pages during each iteration
> before VM stop, but there are no races after VM stop, so we won't miss dirty pages
> finally. It seems that "races" is not a convinced reason for "not feasible".
You are probably right. But you'd have to change the dirty tracking from
a fault mechanism to a polling one checking the S2 page tables
periodically. Or, can you check then only once after VM stop?
> 3. You said that disable hardware S2 DBM support can simplify the hardware S2 AF support.
> Could you please explain the reason in detail?
I probably meant that it simplifies the patch rather than something
specific to the AF support. If you add DBM, you'd need to make sure that
making a pte read-only doesn't lose the dirty information (see
ptep_set_wrprotect(), not sure whether KVM uses the same macro).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 9/9] arm64: dts: actions: Add uSD support for Cubieboard7
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds uSD support for Cubieboard7 board based on Actions Semi
S700 SoC. SD0 is connected to uSD slot. Since there is no PMIC support
added yet, fixed regulator has been used as a regulator node.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++++++++++++++++++++
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index 63e375cd9eb4..ec117eb12f3a 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -13,6 +13,7 @@
aliases {
serial3 = &uart3;
+ mmc0 = &mmc0;
};
chosen {
@@ -28,6 +29,23 @@
device_type = "memory";
reg = <0x1 0xe0000000 0x0 0x0>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-always-on;
+ };
};
&i2c0 {
@@ -81,6 +99,14 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+ "sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
};
&timer {
@@ -90,3 +116,18 @@
&uart3 {
status = "okay";
};
+
+/* uSD */
+&mmc0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_default>;
+ cd-gpios = <&pinctrl 120 GPIO_ACTIVE_LOW>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ bus-width = <4>;
+ vmmc-supply = <&sd_vcc>;
+ vqmmc-supply = <&sd_vcc>;
+};
+
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 3f1fc3e48415..8a541dd48f61 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/clock/actions,s700-cmu.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/actions,s700-reset.h>
--
2.7.4
_______________________________________________
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 v1 8/9] arm64: dts: actions: Add MMC controller support for S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commits adds support for MMC controllers present on Actions S700 SoC,
there are 3 MMC controllers in this SoC which can be used for accessing
SD/EMMC/SDIO cards.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 56f2f84812cb..3f1fc3e48415 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -258,5 +258,38 @@
dma-requests = <44>;
clocks = <&cmu CLK_DMAC>;
};
+
+ mmc0: mmc@e0210000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0210000 0x0 0x4000>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD0>;
+ resets = <&cmu RESET_SD0>;
+ dmas = <&dma 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0214000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0214000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD1>;
+ resets = <&cmu RESET_SD1>;
+ dmas = <&dma 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0218000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0218000 0x0 0x4000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD2>;
+ resets = <&cmu RESET_SD2>;
+ dmas = <&dma 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.7.4
_______________________________________________
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 v1 7/9] dt-bindings: reset: s700: Add binding constants for mmc
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds device tree binding reset constants for mmc controller
present on Actions S700 Soc.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* added Rob's acked-by tag
---
include/dt-bindings/reset/actions,s700-reset.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h
index 5e3b16b8ef53..a3118de6d7aa 100644
--- a/include/dt-bindings/reset/actions,s700-reset.h
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -30,5 +30,8 @@
#define RESET_UART4 20
#define RESET_UART5 21
#define RESET_UART6 22
+#define RESET_SD0 23
+#define RESET_SD1 24
+#define RESET_SD2 25
#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
--
2.7.4
_______________________________________________
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 v1 6/9] arm64: dts: actions: Add DMA Controller for S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds DAM controller present on Actions S700, it differs from
S900 in terms of number of dma channels and requests.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No Change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 0397c5dd3dec..56f2f84812cb 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -245,5 +245,18 @@
<GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ dma: dma-controller@e0230000 {
+ compatible = "actions,s700-dma";
+ reg = <0x0 0xe0230000 0x0 0x1000>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ dma-channels = <10>;
+ dma-requests = <44>;
+ clocks = <&cmu CLK_DMAC>;
+ };
};
};
--
2.7.4
_______________________________________________
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 v1 5/9] dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
Converts the device tree bindings for the Actions Semi Owl SoCs DMA
Controller over to YAML schemas.
It also adds new compatible string "actions,s700-dma" to match
the driver.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
New patch, was not there in RFC.
---
Documentation/devicetree/bindings/dma/owl-dma.txt | 47 ------------
Documentation/devicetree/bindings/dma/owl-dma.yaml | 84 ++++++++++++++++++++++
2 files changed, 84 insertions(+), 47 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt
deleted file mode 100644
index 03e9bb12b75f..000000000000
--- a/Documentation/devicetree/bindings/dma/owl-dma.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Actions Semi Owl SoCs DMA controller
-
-This binding follows the generic DMA bindings defined in dma.txt.
-
-Required properties:
-- compatible: Should be "actions,s900-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain 4 interrupts shared by all channel.
-- #dma-cells: Must be <1>. Used to represent the number of integer
- cells in the dmas property of client device.
-- dma-channels: Physical channels supported.
-- dma-requests: Number of DMA request signals supported by the controller.
- Refer to Documentation/devicetree/bindings/dma/dma.txt
-- clocks: Phandle and Specifier of the clock feeding the DMA controller.
-
-Example:
-
-Controller:
- dma: dma-controller@e0260000 {
- compatible = "actions,s900-dma";
- reg = <0x0 0xe0260000 0x0 0x1000>;
- interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
- #dma-cells = <1>;
- dma-channels = <12>;
- dma-requests = <46>;
- clocks = <&clock CLK_DMAC>;
- };
-
-Client:
-
-DMA clients connected to the Actions Semi Owl SoCs DMA controller must
-use the format described in the dma.txt file, using a two-cell specifier
-for each channel.
-
-The two cells in order are:
-1. A phandle pointing to the DMA controller.
-2. The channel id.
-
-uart5: serial@e012a000 {
- ...
- dma-names = "tx", "rx";
- dmas = <&dma 26>, <&dma 27>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
new file mode 100644
index 000000000000..12e68c0ece67
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl SoCs DMA controller
+
+description: |
+ The OWL DMA is a general-purpose direct memory access controller capable of
+ supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
+ respectively.
+ DMA clients connected to the Actions Semi Owl SoCs DMA controller must
+ use the format described in the owl-dma.yaml file, using a two-cell specifier
+ for each channel.
+
+ The two cells in order are:
+ 1. A phandle pointing to the DMA controller.
+ 2. The channel id.
+
+ uart5: serial@e012a000 {
+ ...
+ dma-names = "tx", "rx";
+ dmas = <&dma 26>, <&dma 27>;
+ ...
+ };
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - actions,s900-dma
+ - actions,s700-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 4
+
+ "#dma-cells":
+ const: 1
+
+ dma-channels:
+ maxItems: 1
+
+ dma-requests:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - dma-channels
+ - dma-requests
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/actions,s700-cmu.h>
+ dma: dma-controller@e0260000 {
+ compatible = "actions,s900-dma";
+ reg = <0x0 0xe0260000 0x0 0x1000>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ dma-channels = <12>;
+ dma-requests = <46>;
+ clocks = <&clock CLK_DMAC>;
+ };
+
+...
--
2.7.4
_______________________________________________
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 v1 4/9] arm64: dts: actions: do not merge disable sps node from S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for
Actions Semi S700") following error has been observed while booting
Linux on Cubieboard7-lite(based on S700 SoC).
[ 0.257415] pinctrl-s700 e01b0000.pinctrl: can't request region for
resource [mem 0xe01b0000-0xe01b0fff]
[ 0.266902] pinctrl-s700: probe of e01b0000.pinctrl failed with error -16
This is due to the fact that memory range for "sps" power domain controller
clashes with pinctrl.
This commit disable "sps" to avoid this conflict and let us test DMA and MMC
related changes.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* kept as do not merge.
---
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 2006ad5424fa..0397c5dd3dec 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -220,6 +220,7 @@
compatible = "actions,s700-sps";
reg = <0x0 0xe01b0100 0x0 0x100>;
#power-domain-cells = <1>;
+ status = "disabled";
};
timer: timer@e024c000 {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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