From: Sasha Levin Date: Wed, 18 Mar 2020 19:27:18 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v4.4.217~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ddeb00019e21fa3c215453ef920641ea0ee2012d;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/mmc-core-allow-host-controllers-to-require-r1b-for-c.patch b/queue-4.19/mmc-core-allow-host-controllers-to-require-r1b-for-c.patch new file mode 100644 index 00000000000..1675d37f4da --- /dev/null +++ b/queue-4.19/mmc-core-allow-host-controllers-to-require-r1b-for-c.patch @@ -0,0 +1,63 @@ +From 8c7862e6466ce4b928a721fd0b700cfb45ccfc12 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Mar 2020 12:49:43 +0100 +Subject: mmc: core: Allow host controllers to require R1B for CMD6 + +From: Ulf Hansson + +[ Upstream commit 1292e3efb149ee21d8d33d725eeed4e6b1ade963 ] + +It has turned out that some host controllers can't use R1B for CMD6 and +other commands that have R1B associated with them. Therefore invent a new +host cap, MMC_CAP_NEED_RSP_BUSY to let them specify this. + +In __mmc_switch(), let's check the flag and use it to prevent R1B responses +from being converted into R1. Note that, this also means that the host are +on its own, when it comes to manage the busy timeout. + +Suggested-by: Sowjanya Komatineni +Cc: +Tested-by: Anders Roxell +Tested-by: Sowjanya Komatineni +Tested-by: Faiz Abbas +Tested-By: Peter Geis +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/core/mmc_ops.c | 6 ++++-- + include/linux/mmc/host.h | 1 + + 2 files changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c +index 76de8d441cce4..9ae41fbe009bd 100644 +--- a/drivers/mmc/core/mmc_ops.c ++++ b/drivers/mmc/core/mmc_ops.c +@@ -538,9 +538,11 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, + * If the max_busy_timeout of the host is specified, make sure it's + * enough to fit the used timeout_ms. In case it's not, let's instruct + * the host to avoid HW busy detection, by converting to a R1 response +- * instead of a R1B. ++ * instead of a R1B. Note, some hosts requires R1B, which also means ++ * they are on their own when it comes to deal with the busy timeout. + */ +- if (host->max_busy_timeout && (timeout_ms > host->max_busy_timeout)) ++ if (!(host->caps & MMC_CAP_NEED_RSP_BUSY) && host->max_busy_timeout && ++ (timeout_ms > host->max_busy_timeout)) + use_r1b_resp = false; + + cmd.opcode = MMC_SWITCH; +diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h +index 840462ed1ec7e..7e8e5b20e82b0 100644 +--- a/include/linux/mmc/host.h ++++ b/include/linux/mmc/host.h +@@ -332,6 +332,7 @@ struct mmc_host { + MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 | \ + MMC_CAP_UHS_DDR50) + /* (1 << 21) is free for reuse */ ++#define MMC_CAP_NEED_RSP_BUSY (1 << 22) /* Commands with R1B can't use R1. */ + #define MMC_CAP_DRIVER_TYPE_A (1 << 23) /* Host supports Driver Type A */ + #define MMC_CAP_DRIVER_TYPE_C (1 << 24) /* Host supports Driver Type C */ + #define MMC_CAP_DRIVER_TYPE_D (1 << 25) /* Host supports Driver Type D */ +-- +2.20.1 + diff --git a/queue-4.19/mmc-core-default-to-generic_cmd6_time-as-timeout-in-.patch b/queue-4.19/mmc-core-default-to-generic_cmd6_time-as-timeout-in-.patch new file mode 100644 index 00000000000..55a7ee8e9b8 --- /dev/null +++ b/queue-4.19/mmc-core-default-to-generic_cmd6_time-as-timeout-in-.patch @@ -0,0 +1,79 @@ +From 19edf2bea7f4d5d754095603316ded76fb126b83 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Jan 2020 15:27:47 +0100 +Subject: mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch() + +From: Ulf Hansson + +[ Upstream commit 533a6cfe08f96a7b5c65e06d20916d552c11b256 ] + +All callers of __mmc_switch() should now be specifying a valid timeout for +the CMD6 command. However, just to be sure, let's print a warning and +default to use the generic_cmd6_time in case the provided timeout_ms +argument is zero. + +In this context, let's also simplify some of the corresponding code and +clarify some related comments. + +Signed-off-by: Ulf Hansson +Link: https://lore.kernel.org/r/20200122142747.5690-4-ulf.hansson@linaro.org +Signed-off-by: Sasha Levin +--- + drivers/mmc/core/mmc_ops.c | 25 +++++++++++-------------- + 1 file changed, 11 insertions(+), 14 deletions(-) + +diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c +index 873b2aa0c1556..76de8d441cce4 100644 +--- a/drivers/mmc/core/mmc_ops.c ++++ b/drivers/mmc/core/mmc_ops.c +@@ -456,10 +456,6 @@ static int mmc_poll_for_busy(struct mmc_card *card, unsigned int timeout_ms, + bool expired = false; + bool busy = false; + +- /* We have an unspecified cmd timeout, use the fallback value. */ +- if (!timeout_ms) +- timeout_ms = MMC_OPS_TIMEOUT_MS; +- + /* + * In cases when not allowed to poll by using CMD13 or because we aren't + * capable of polling by using ->card_busy(), then rely on waiting the +@@ -532,14 +528,19 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, + + mmc_retune_hold(host); + ++ if (!timeout_ms) { ++ pr_warn("%s: unspecified timeout for CMD6 - use generic\n", ++ mmc_hostname(host)); ++ timeout_ms = card->ext_csd.generic_cmd6_time; ++ } ++ + /* +- * If the cmd timeout and the max_busy_timeout of the host are both +- * specified, let's validate them. A failure means we need to prevent +- * the host from doing hw busy detection, which is done by converting +- * to a R1 response instead of a R1B. ++ * If the max_busy_timeout of the host is specified, make sure it's ++ * enough to fit the used timeout_ms. In case it's not, let's instruct ++ * the host to avoid HW busy detection, by converting to a R1 response ++ * instead of a R1B. + */ +- if (timeout_ms && host->max_busy_timeout && +- (timeout_ms > host->max_busy_timeout)) ++ if (host->max_busy_timeout && (timeout_ms > host->max_busy_timeout)) + use_r1b_resp = false; + + cmd.opcode = MMC_SWITCH; +@@ -550,10 +551,6 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, + cmd.flags = MMC_CMD_AC; + if (use_r1b_resp) { + cmd.flags |= MMC_RSP_SPI_R1B | MMC_RSP_R1B; +- /* +- * A busy_timeout of zero means the host can decide to use +- * whatever value it finds suitable. +- */ + cmd.busy_timeout = timeout_ms; + } else { + cmd.flags |= MMC_RSP_SPI_R1 | MMC_RSP_R1; +-- +2.20.1 + diff --git a/queue-4.19/mmc-core-respect-mmc_cap_need_rsp_busy-for-emmc-slee.patch b/queue-4.19/mmc-core-respect-mmc_cap_need_rsp_busy-for-emmc-slee.patch new file mode 100644 index 00000000000..3cb46cdcbef --- /dev/null +++ b/queue-4.19/mmc-core-respect-mmc_cap_need_rsp_busy-for-emmc-slee.patch @@ -0,0 +1,50 @@ +From d50c3dd17725d72444f0b9920c181bcd50acf2eb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 11 Mar 2020 10:20:36 +0100 +Subject: mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command + +From: Ulf Hansson + +[ Upstream commit 18d200460cd73636d4f20674085c39e32b4e0097 ] + +The busy timeout for the CMD5 to put the eMMC into sleep state, is specific +to the card. Potentially the timeout may exceed the host->max_busy_timeout. +If that becomes the case, mmc_sleep() converts from using an R1B response +to an R1 response, as to prevent the host from doing HW busy detection. + +However, it has turned out that some hosts requires an R1B response no +matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note +that, if the R1B gets enforced, the host becomes fully responsible of +managing the needed busy timeout, in one way or the other. + +Suggested-by: Sowjanya Komatineni +Cc: +Link: https://lore.kernel.org/r/20200311092036.16084-1-ulf.hansson@linaro.org +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/core/mmc.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c +index f1fe446eee666..5ca53e225382d 100644 +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -1901,9 +1901,12 @@ static int mmc_sleep(struct mmc_host *host) + * If the max_busy_timeout of the host is specified, validate it against + * the sleep cmd timeout. A failure means we need to prevent the host + * from doing hw busy detection, which is done by converting to a R1 +- * response instead of a R1B. ++ * response instead of a R1B. Note, some hosts requires R1B, which also ++ * means they are on their own when it comes to deal with the busy ++ * timeout. + */ +- if (host->max_busy_timeout && (timeout_ms > host->max_busy_timeout)) { ++ if (!(host->caps & MMC_CAP_NEED_RSP_BUSY) && host->max_busy_timeout && ++ (timeout_ms > host->max_busy_timeout)) { + cmd.flags = MMC_RSP_R1 | MMC_CMD_AC; + } else { + cmd.flags = MMC_RSP_R1B | MMC_CMD_AC; +-- +2.20.1 + diff --git a/queue-4.19/mmc-core-respect-mmc_cap_need_rsp_busy-for-erase-tri.patch b/queue-4.19/mmc-core-respect-mmc_cap_need_rsp_busy-for-erase-tri.patch new file mode 100644 index 00000000000..899f5ed46f0 --- /dev/null +++ b/queue-4.19/mmc-core-respect-mmc_cap_need_rsp_busy-for-erase-tri.patch @@ -0,0 +1,51 @@ +From 21560a8e38f26028e1fbf2ab3cdce79581c439bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Mar 2020 14:43:00 +0100 +Subject: mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard + +From: Ulf Hansson + +[ Upstream commit 43cc64e5221cc6741252b64bc4531dd1eefb733d ] + +The busy timeout that is computed for each erase/trim/discard operation, +can become quite long and may thus exceed the host->max_busy_timeout. If +that becomes the case, mmc_do_erase() converts from using an R1B response +to an R1 response, as to prevent the host from doing HW busy detection. + +However, it has turned out that some hosts requires an R1B response no +matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note +that, if the R1B gets enforced, the host becomes fully responsible of +managing the needed busy timeout, in one way or the other. + +Suggested-by: Sowjanya Komatineni +Cc: +Tested-by: Anders Roxell +Tested-by: Sowjanya Komatineni +Tested-by: Faiz Abbas +Tested-By: Peter Geis +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/core/core.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c +index 0a74785e575ba..56f7f3600469a 100644 +--- a/drivers/mmc/core/core.c ++++ b/drivers/mmc/core/core.c +@@ -2043,8 +2043,11 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from, + * the erase operation does not exceed the max_busy_timeout, we should + * use R1B response. Or we need to prevent the host from doing hw busy + * detection, which is done by converting to a R1 response instead. ++ * Note, some hosts requires R1B, which also means they are on their own ++ * when it comes to deal with the busy timeout. + */ +- if (card->host->max_busy_timeout && ++ if (!(card->host->caps & MMC_CAP_NEED_RSP_BUSY) && ++ card->host->max_busy_timeout && + busy_timeout > card->host->max_busy_timeout) { + cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC; + } else { +-- +2.20.1 + diff --git a/queue-4.19/mmc-host-fix-kconfig-warnings-on-keystone_defconfig.patch b/queue-4.19/mmc-host-fix-kconfig-warnings-on-keystone_defconfig.patch new file mode 100644 index 00000000000..603c96fc1fe --- /dev/null +++ b/queue-4.19/mmc-host-fix-kconfig-warnings-on-keystone_defconfig.patch @@ -0,0 +1,47 @@ +From 3bc5539728e8f31adf7d7c6703eaf9f85b25bbfe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 9 Jan 2019 18:13:12 +0530 +Subject: mmc: host: Fix Kconfig warnings on keystone_defconfig + +From: Faiz Abbas + +[ Upstream commit 287b1da6a458a30da2e5be745498d31092ebb001 ] + +Commit 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding +SDR104/HS200 tuning failures (i929)") added a select on TI_SOC_THERMAL +for the driver to get temperature for tuning. + +However, this causes the following warning on keystone_defconfig because +keystone does not support TI_SOC_THERMAL: + +"WARNING: unmet direct dependencies detected for TI_SOC_THERMAL" + +Fix this by changing the select to imply. + +Fixes: 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding +SDR104/HS200 tuning failures (i929)") +Signed-off-by: Faiz Abbas +Tested-by: Borislav Petkov +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig +index 79b8ac9cdc744..b7f809aa40c2c 100644 +--- a/drivers/mmc/host/Kconfig ++++ b/drivers/mmc/host/Kconfig +@@ -936,7 +936,7 @@ config MMC_SDHCI_OMAP + tristate "TI SDHCI Controller Support" + depends on MMC_SDHCI_PLTFM && OF + select THERMAL +- select TI_SOC_THERMAL ++ imply TI_SOC_THERMAL + help + This selects the Secure Digital Host Controller Interface (SDHCI) + support present in TI's DRA7 SOCs. The controller supports +-- +2.20.1 + diff --git a/queue-4.19/mmc-sdhci-omap-add-platform-specific-reset-callback.patch b/queue-4.19/mmc-sdhci-omap-add-platform-specific-reset-callback.patch new file mode 100644 index 00000000000..efae075ec4b --- /dev/null +++ b/queue-4.19/mmc-sdhci-omap-add-platform-specific-reset-callback.patch @@ -0,0 +1,89 @@ +From f35f476872152b0854387625fe871c46e2b765c2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Nov 2018 16:03:56 +0530 +Subject: mmc: sdhci-omap: Add platform specific reset callback + +From: Faiz Abbas + +[ Upstream commit 5b0d62108b468b13410533c0ceea3821942bf592 ] + +The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids +assertion of data reset while tuning is happening. Implement a +platform specific callback that takes care of this condition. + +[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4 + +Acked-by: Kishon Vijay Abraham I +Signed-off-by: Faiz Abbas +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/sdhci-omap.c | 20 +++++++++++++++++++- + 1 file changed, 19 insertions(+), 1 deletion(-) + +diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c +index d02f5cf76b3d1..8a172575bb64f 100644 +--- a/drivers/mmc/host/sdhci-omap.c ++++ b/drivers/mmc/host/sdhci-omap.c +@@ -115,6 +115,7 @@ struct sdhci_omap_host { + + struct pinctrl *pinctrl; + struct pinctrl_state **pinctrl_state; ++ bool is_tuning; + }; + + static void sdhci_omap_start_clock(struct sdhci_omap_host *omap_host); +@@ -326,6 +327,8 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + dcrc_was_enabled = true; + } + ++ omap_host->is_tuning = true; ++ + while (phase_delay <= MAX_PHASE_DELAY) { + sdhci_omap_set_dll(omap_host, phase_delay); + +@@ -363,9 +366,12 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + phase_delay = max_window + 4 * (max_len >> 1); + sdhci_omap_set_dll(omap_host, phase_delay); + ++ omap_host->is_tuning = false; ++ + goto ret; + + tuning_error: ++ omap_host->is_tuning = false; + dev_err(dev, "Tuning failed\n"); + sdhci_omap_disable_tuning(omap_host); + +@@ -695,6 +701,18 @@ static void sdhci_omap_set_uhs_signaling(struct sdhci_host *host, + sdhci_omap_start_clock(omap_host); + } + ++void sdhci_omap_reset(struct sdhci_host *host, u8 mask) ++{ ++ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); ++ struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host); ++ ++ /* Don't reset data lines during tuning operation */ ++ if (omap_host->is_tuning) ++ mask &= ~SDHCI_RESET_DATA; ++ ++ sdhci_reset(host, mask); ++} ++ + static struct sdhci_ops sdhci_omap_ops = { + .set_clock = sdhci_omap_set_clock, + .set_power = sdhci_omap_set_power, +@@ -703,7 +721,7 @@ static struct sdhci_ops sdhci_omap_ops = { + .get_min_clock = sdhci_omap_get_min_clock, + .set_bus_width = sdhci_omap_set_bus_width, + .platform_send_init_74_clocks = sdhci_omap_init_74_clocks, +- .reset = sdhci_reset, ++ .reset = sdhci_omap_reset, + .set_uhs_signaling = sdhci_omap_set_uhs_signaling, + }; + +-- +2.20.1 + diff --git a/queue-4.19/mmc-sdhci-omap-fix-busy-detection-by-enabling-mmc_ca.patch b/queue-4.19/mmc-sdhci-omap-fix-busy-detection-by-enabling-mmc_ca.patch new file mode 100644 index 00000000000..bb248204591 --- /dev/null +++ b/queue-4.19/mmc-sdhci-omap-fix-busy-detection-by-enabling-mmc_ca.patch @@ -0,0 +1,46 @@ +From c37abc6411777705461a67821ec7bad61a1056b3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Mar 2020 15:05:02 +0100 +Subject: mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY + +From: Ulf Hansson + +[ Upstream commit 055e04830d4544c57f2a5192a26c9e25915c29c0 ] + +It has turned out that the sdhci-omap controller requires the R1B response, +for commands that has this response associated with them. So, converting +from an R1B to an R1 response for a CMD6 for example, leads to problems +with the HW busy detection support. + +Fix this by informing the mmc core about the requirement, via setting the +host cap, MMC_CAP_NEED_RSP_BUSY. + +Reported-by: Naresh Kamboju +Reported-by: Anders Roxell +Reported-by: Faiz Abbas +Cc: +Tested-by: Anders Roxell +Tested-by: Faiz Abbas +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/sdhci-omap.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c +index 5698af25caef6..79ee5fc5a2013 100644 +--- a/drivers/mmc/host/sdhci-omap.c ++++ b/drivers/mmc/host/sdhci-omap.c +@@ -1109,6 +1109,9 @@ static int sdhci_omap_probe(struct platform_device *pdev) + host->mmc_host_ops.execute_tuning = sdhci_omap_execute_tuning; + host->mmc_host_ops.enable_sdio_irq = sdhci_omap_enable_sdio_irq; + ++ /* R1B responses is required to properly manage HW busy detection. */ ++ mmc->caps |= MMC_CAP_NEED_RSP_BUSY; ++ + ret = sdhci_setup_host(host); + if (ret) + goto err_put_sync; +-- +2.20.1 + diff --git a/queue-4.19/mmc-sdhci-omap-workaround-errata-regarding-sdr104-hs.patch b/queue-4.19/mmc-sdhci-omap-workaround-errata-regarding-sdr104-hs.patch new file mode 100644 index 00000000000..90c55f029ce --- /dev/null +++ b/queue-4.19/mmc-sdhci-omap-workaround-errata-regarding-sdr104-hs.patch @@ -0,0 +1,207 @@ +From c6b61ab47d9e4ca4422531d9d7cc54ef59ede2c6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Dec 2018 19:52:53 +0530 +Subject: mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning + failures (i929) + +From: Faiz Abbas + +[ Upstream commit 961de0a856e3a30c0238d1269c0b17f9b179b6c3 ] + +Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions +(SPRZ426D - November 2014 - Revised February 2018 [1]) mentions +unexpected tuning pattern errors. A small failure band may be present +in the tuning range which may be missed by the current algorithm. +Furthermore, the failure bands vary with temperature leading to +different optimum tuning values for different temperatures. + +As suggested in the related Application Report (SPRACA9B - October 2017 +- Revised July 2018 [2]), tuning should be done in two stages. +In stage 1, assign the optimum ratio in the maximum pass window for the +current temperature. In stage 2, if the chosen value is close to the +small failure band, move away from it in the appropriate direction. + +References: +[1] http://www.ti.com/lit/pdf/sprz426 +[2] http://www.ti.com/lit/pdf/SPRACA9 + +Signed-off-by: Faiz Abbas +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/Kconfig | 2 + + drivers/mmc/host/sdhci-omap.c | 90 ++++++++++++++++++++++++++++++++++- + 2 files changed, 91 insertions(+), 1 deletion(-) + +diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig +index 694d0828215d2..79b8ac9cdc744 100644 +--- a/drivers/mmc/host/Kconfig ++++ b/drivers/mmc/host/Kconfig +@@ -935,6 +935,8 @@ config MMC_SDHCI_XENON + config MMC_SDHCI_OMAP + tristate "TI SDHCI Controller Support" + depends on MMC_SDHCI_PLTFM && OF ++ select THERMAL ++ select TI_SOC_THERMAL + help + This selects the Secure Digital Host Controller Interface (SDHCI) + support present in TI's DRA7 SOCs. The controller supports +diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c +index 8a172575bb64f..5698af25caef6 100644 +--- a/drivers/mmc/host/sdhci-omap.c ++++ b/drivers/mmc/host/sdhci-omap.c +@@ -27,6 +27,7 @@ + #include + #include + #include ++#include + + #include "sdhci-pltfm.h" + +@@ -290,15 +291,19 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + struct sdhci_host *host = mmc_priv(mmc); + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); + struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host); ++ struct thermal_zone_device *thermal_dev; + struct device *dev = omap_host->dev; + struct mmc_ios *ios = &mmc->ios; + u32 start_window = 0, max_window = 0; ++ bool single_point_failure = false; + bool dcrc_was_enabled = false; + u8 cur_match, prev_match = 0; + u32 length = 0, max_len = 0; + u32 phase_delay = 0; ++ int temperature; + int ret = 0; + u32 reg; ++ int i; + + pltfm_host = sdhci_priv(host); + omap_host = sdhci_pltfm_priv(pltfm_host); +@@ -312,6 +317,16 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + if (ios->timing == MMC_TIMING_UHS_SDR50 && !(reg & CAPA2_TSDR50)) + return 0; + ++ thermal_dev = thermal_zone_get_zone_by_name("cpu_thermal"); ++ if (IS_ERR(thermal_dev)) { ++ dev_err(dev, "Unable to get thermal zone for tuning\n"); ++ return PTR_ERR(thermal_dev); ++ } ++ ++ ret = thermal_zone_get_temp(thermal_dev, &temperature); ++ if (ret) ++ return ret; ++ + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_DLL); + reg |= DLL_SWT; + sdhci_omap_writel(omap_host, SDHCI_OMAP_DLL, reg); +@@ -329,6 +344,11 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + + omap_host->is_tuning = true; + ++ /* ++ * Stage 1: Search for a maximum pass window ignoring any ++ * any single point failures. If the tuning value ends up ++ * near it, move away from it in stage 2 below ++ */ + while (phase_delay <= MAX_PHASE_DELAY) { + sdhci_omap_set_dll(omap_host, phase_delay); + +@@ -336,10 +356,15 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + if (cur_match) { + if (prev_match) { + length++; ++ } else if (single_point_failure) { ++ /* ignore single point failure */ ++ length++; + } else { + start_window = phase_delay; + length = 1; + } ++ } else { ++ single_point_failure = prev_match; + } + + if (length > max_len) { +@@ -357,13 +382,76 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) + goto tuning_error; + } + ++ /* ++ * Assign tuning value as a ratio of maximum pass window based ++ * on temperature ++ */ ++ if (temperature < -20000) ++ phase_delay = min(max_window + 4 * max_len - 24, ++ max_window + ++ DIV_ROUND_UP(13 * max_len, 16) * 4); ++ else if (temperature < 20000) ++ phase_delay = max_window + DIV_ROUND_UP(9 * max_len, 16) * 4; ++ else if (temperature < 40000) ++ phase_delay = max_window + DIV_ROUND_UP(8 * max_len, 16) * 4; ++ else if (temperature < 70000) ++ phase_delay = max_window + DIV_ROUND_UP(7 * max_len, 16) * 4; ++ else if (temperature < 90000) ++ phase_delay = max_window + DIV_ROUND_UP(5 * max_len, 16) * 4; ++ else if (temperature < 120000) ++ phase_delay = max_window + DIV_ROUND_UP(4 * max_len, 16) * 4; ++ else ++ phase_delay = max_window + DIV_ROUND_UP(3 * max_len, 16) * 4; ++ ++ /* ++ * Stage 2: Search for a single point failure near the chosen tuning ++ * value in two steps. First in the +3 to +10 range and then in the ++ * +2 to -10 range. If found, move away from it in the appropriate ++ * direction by the appropriate amount depending on the temperature. ++ */ ++ for (i = 3; i <= 10; i++) { ++ sdhci_omap_set_dll(omap_host, phase_delay + i); ++ ++ if (mmc_send_tuning(mmc, opcode, NULL)) { ++ if (temperature < 10000) ++ phase_delay += i + 6; ++ else if (temperature < 20000) ++ phase_delay += i - 12; ++ else if (temperature < 70000) ++ phase_delay += i - 8; ++ else ++ phase_delay += i - 6; ++ ++ goto single_failure_found; ++ } ++ } ++ ++ for (i = 2; i >= -10; i--) { ++ sdhci_omap_set_dll(omap_host, phase_delay + i); ++ ++ if (mmc_send_tuning(mmc, opcode, NULL)) { ++ if (temperature < 10000) ++ phase_delay += i + 12; ++ else if (temperature < 20000) ++ phase_delay += i + 8; ++ else if (temperature < 70000) ++ phase_delay += i + 8; ++ else if (temperature < 90000) ++ phase_delay += i + 10; ++ else ++ phase_delay += i + 12; ++ ++ goto single_failure_found; ++ } ++ } ++ ++single_failure_found: + reg = sdhci_omap_readl(omap_host, SDHCI_OMAP_AC12); + if (!(reg & AC12_SCLK_SEL)) { + ret = -EIO; + goto tuning_error; + } + +- phase_delay = max_window + 4 * (max_len >> 1); + sdhci_omap_set_dll(omap_host, phase_delay); + + omap_host->is_tuning = false; +-- +2.20.1 + diff --git a/queue-4.19/perf-amd-uncore-replace-manual-sampling-check-with-c.patch b/queue-4.19/perf-amd-uncore-replace-manual-sampling-check-with-c.patch new file mode 100644 index 00000000000..44c7fa307df --- /dev/null +++ b/queue-4.19/perf-amd-uncore-replace-manual-sampling-check-with-c.patch @@ -0,0 +1,88 @@ +From fb80e122428ee93ae2f7287d74a00b8a7de98642 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 11 Mar 2020 14:13:21 -0500 +Subject: perf/amd/uncore: Replace manual sampling check with CAP_NO_INTERRUPT + flag + +From: Kim Phillips + +[ Upstream commit f967140dfb7442e2db0868b03b961f9c59418a1b ] + +Enable the sampling check in kernel/events/core.c::perf_event_open(), +which returns the more appropriate -EOPNOTSUPP. + +BEFORE: + + $ sudo perf record -a -e instructions,l3_request_g1.caching_l3_cache_accesses true + Error: + The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (l3_request_g1.caching_l3_cache_accesses). + /bin/dmesg | grep -i perf may provide additional information. + +With nothing relevant in dmesg. + +AFTER: + + $ sudo perf record -a -e instructions,l3_request_g1.caching_l3_cache_accesses true + Error: + l3_request_g1.caching_l3_cache_accesses: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat' + +Fixes: c43ca5091a37 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters") +Signed-off-by: Kim Phillips +Signed-off-by: Borislav Petkov +Acked-by: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200311191323.13124-1-kim.phillips@amd.com +Signed-off-by: Sasha Levin +--- + arch/x86/events/amd/uncore.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c +index baa7e36073f90..604a8558752d1 100644 +--- a/arch/x86/events/amd/uncore.c ++++ b/arch/x86/events/amd/uncore.c +@@ -193,20 +193,18 @@ static int amd_uncore_event_init(struct perf_event *event) + + /* + * NB and Last level cache counters (MSRs) are shared across all cores +- * that share the same NB / Last level cache. Interrupts can be directed +- * to a single target core, however, event counts generated by processes +- * running on other cores cannot be masked out. So we do not support +- * sampling and per-thread events. ++ * that share the same NB / Last level cache. On family 16h and below, ++ * Interrupts can be directed to a single target core, however, event ++ * counts generated by processes running on other cores cannot be masked ++ * out. So we do not support sampling and per-thread events via ++ * CAP_NO_INTERRUPT, and we do not enable counter overflow interrupts: + */ +- if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK) +- return -EINVAL; + + /* NB and Last level cache counters do not have usr/os/guest/host bits */ + if (event->attr.exclude_user || event->attr.exclude_kernel || + event->attr.exclude_host || event->attr.exclude_guest) + return -EINVAL; + +- /* and we do not enable counter overflow interrupts */ + hwc->config = event->attr.config & AMD64_RAW_EVENT_MASK_NB; + hwc->idx = -1; + +@@ -314,6 +312,7 @@ static struct pmu amd_nb_pmu = { + .start = amd_uncore_start, + .stop = amd_uncore_stop, + .read = amd_uncore_read, ++ .capabilities = PERF_PMU_CAP_NO_INTERRUPT, + }; + + static struct pmu amd_llc_pmu = { +@@ -324,6 +323,7 @@ static struct pmu amd_llc_pmu = { + .start = amd_uncore_start, + .stop = amd_uncore_stop, + .read = amd_uncore_read, ++ .capabilities = PERF_PMU_CAP_NO_INTERRUPT, + }; + + static struct amd_uncore *amd_uncore_alloc(unsigned int cpu) +-- +2.20.1 + diff --git a/queue-4.19/series b/queue-4.19/series new file mode 100644 index 00000000000..6e2bc206b15 --- /dev/null +++ b/queue-4.19/series @@ -0,0 +1,9 @@ +perf-amd-uncore-replace-manual-sampling-check-with-c.patch +mmc-core-default-to-generic_cmd6_time-as-timeout-in-.patch +mmc-sdhci-omap-add-platform-specific-reset-callback.patch +mmc-sdhci-omap-workaround-errata-regarding-sdr104-hs.patch +mmc-host-fix-kconfig-warnings-on-keystone_defconfig.patch +mmc-sdhci-omap-fix-busy-detection-by-enabling-mmc_ca.patch +mmc-core-respect-mmc_cap_need_rsp_busy-for-emmc-slee.patch +mmc-core-respect-mmc_cap_need_rsp_busy-for-erase-tri.patch +mmc-core-allow-host-controllers-to-require-r1b-for-c.patch