- 26 Apr, 2022 36 commits
-
-
Bean Huo authored
Occasionally, user-land applications initiate longer timeout values for certain commands through ioctl() system call. But so far we are still using a fixed timeout of 10 seconds in mmc_poll_for_busy() on the ioctl() path, even if a custom timeout is specified in the userspace application. This patch allows custom timeout values to override this default timeout values on the ioctl path. Cc: stable <stable@vger.kernel.org> Signed-off-by:
Bean Huo <beanhuo@micron.com> Acked-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220423221623.1074556-3-huobean@gmail.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Bean Huo authored
Only the device data is needed, not the entire struct of_device_id. Use of_device_get_match_data() instead of open coding of_match_device(). Signed-off-by:
-
Vignesh Raghavendra authored
The ARASAN MMC controller on Keystone 3 class of devices need the SDCD line to be connected for proper functioning. Similar to the issue pointed out in sdhci-of-arasan.c driver, commit 3794c542 ("mmc: sdhci-of-arasan: Set controller to test mode when no CD bit"). In cases where this can't be connected, add a quirk to force the controller into test mode and set the TESTCD bit. Use the flag "ti,fails-without-test-cd", to implement this above quirk when required. Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20220425063120.10135-3-a-govindraju@ti.comSigned-off-by:
-
Aswath Govindraju authored
The ARASAN MMC controller on Keystone 3 class of devices needs the SDCD line to be connected for proper functioning. Similar to the issue pointed out in sdhci-of-arasan.c driver, commit 3794c542 ("mmc: sdhci-of-arasan: Set controller to test mode when no CD bit"). In cases where SDCD line is not connected, adding "ti,fails-without-test-cd" in the DT node helps to indicate the controller, that the SDCD line has been pulled down, using the TESTCD bit. Signed-off-by:
-
Ulf Hansson authored
-
Abel Vesa authored
Add i.MX8DXL compatible string. It also needs "fsl,imx8qm-fec" compatible. Signed-off-by:
Abel Vesa <abel.vesa@nxp.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220419113516.1827863-10-abel.vesa@nxp.comSigned-off-by:
-
Chris Packham authored
Convert the sdhci-dove binding to JSON schema. The optional clocks property was not in the original binding document but has been in the dove.dtsi since commit 5b03df9a ("ARM: dove: switch to DT clock providers"). Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220419024611.1327525-5-chris.packham@alliedtelesis.co.nzSigned-off-by:
-
Chris Packham authored
Convert the orion-sdio binding to JSON schema. Signed-off-by:
-
Linus Walleij authored
The VQMMC is often provided by a level shifter, so drop a small note in the bindings that this can be the case and how that is done. It is helpful information since this is pretty common. Cc: devicetree@vger.kernel.org Signed-off-by:
-
Linus Walleij authored
We iterate an extra time through the IRQ status handling loop despite nothing had fired. Enabling the debug prints: mmci-pl18x 80005000.mmc: op 01 arg 00000000 flags 000000e1 mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000001 mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000000 mmci-pl18x 80005000.mmc: op 01 arg 40ff8080 flags 000000e1 mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000001 mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000000 It is pointless to loop through the function when status is zero. Just break the loop if the status is zero. Signed-off-by:
-
Heiner Kallweit authored
Using the device-managed version allows to simplify clean-up in probe() error path and remove(). Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/268b3cd5-2388-2553-bdba-c72853f91aa3@gmail.comSigned-off-by:
-
Ben Chuang authored
When GL9755 enters ASPM L1 sub-states, it will stay at L1.1 and will not enter L1.2. The workaround is to toggle PM state to allow GL9755 to enter ASPM L1.2. Signed-off-by:
Ben Chuang <ben.chuang@genesyslogic.com.tw> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20220414094945.457500-1-benchuanggli@gmail.comSigned-off-by:
-
Wolfram Sang authored
We have a dedicated directory for platform_data meanwhile, don't spoil the MMC directory with it. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20220412093102.3428-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Aidan MacDonald authored
Do what is done in other DMA-enabled MMC host drivers (cf. host/mmci.c) and limit the maximum segment size based on the DMA engine's capabilities. This is needed to avoid warnings like the following with CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]--- Signed-off-by:Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220411153753.50443-1-aidanmacdonald.0x0@gmail.comSigned-off-by:
-
Adam Ford authored
The SDHC controller in the imx8mn and imx8mp have the same controller as the imx8mm which is slightly different than that of the imx7d. Using the fallback of the imx8mm enables the controllers to support HS400-ES which is not available on the imx7d. After discussion with NXP, it turns out that the imx8qm should fall back to the imx8qxp, because those have some additional flags not present in the imx8mm. Mark the current state of the fallbacks as deprecated, and add the proper fallbacks so in the future, the deprecated combination can be removed and prevent any future devices from using the wrong fallback. Suggested-by: haibo.chen@nxp.com Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
-
Wolfram Sang authored
To make it unambiguous that the hw_reset callback is for cards and not for controllers, we add 'card' to the callback name and convert all users in one go. We keep the argument as mmc_host, though, because the callback is used very early when mmc_card is not yet populated. Signed-off-by:
-
Wolfram Sang authored
To make it unambiguous that mmc_sw_reset() is for cards and not for controllers, we make the function argument mmc_card instead of mmc_host. There are no users to convert currently. Suggested-by:
-
Lad Prabhakar authored
Add linux-renesas-soc@vger.kernel.org list entry for Renesas TMIO/SDHI driver. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
-
Wolfram Sang authored
We don't need to specify the Gen3 compatible entry for M3W because it will be provided by the generic Gen3 fallback. Signed-off-by:
-
Wolfram Sang authored
The hardware evolved, so we only need to disable HS400 support on ES1.* revisions. Update the code. Signed-off-by:
Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: refactored to top-of-tree] Signed-off-by:
-
Janusz Krzysztofik authored
The driver, OMAP specific, now omits clk_prepare/unprepare() steps, not supported by OMAP custom implementation of clock API. However, non-CCF stubs of those functions exist for use on such platforms until converted to CCF. Update the driver to be compatible with CCF implementation of clock API. Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Link: https://lore.kernel.org/r/20220402112004.129886-1-jmkrzyszt@gmail.comSigned-off-by:
-
Christian Löhle authored
Since SD and MMC Highspeed modes are also valid for SPI let's parse them too. Signed-off-by:
Christian Loehle <cloehle@hyperstone.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20c6efa9a4c7423bbfb9352705c4a53a@hyperstone.comSigned-off-by:
-
Sergey Shtylyov authored
Despite mmc_ioc_multi_cmd::num_of_cmds is a 64-bit field, its maximum value is limited to MMC_IOC_MAX_CMDS (only 255); using a 64-bit local variable to hold a copy of that field leads to gcc generating ineffective loop code: despite the source code using an *int* variable for the loop counters, the 32-bit object code uses 64-bit unsigned counters. Also, gcc has to drop the most significant word of that 64-bit variable when calling kcalloc() and assigning to mmc_queue_req::ioc_count anyway. Using the *unsigned int* variable instead results in a better code. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/eea3b0bd-6091-f005-7189-b5b7868abdb6@omp.ruSigned-off-by:
-
Tinghan Shen authored
MediaTek has a new version of mmc IP since mt8183. Some IO registers are moved to top to improve hardware design and named as "host top registers". Add host top register in the reg binding description for mt8183 and successors. Signed-off-by:
Wenbin Mei <wenbin.mei@mediatek.com> Signed-off-by:
Tinghan Shen <tinghan.shen@mediatek.com> Reviewed-by:
-
Chris Packham authored
Convert the marvell,xenon-sdhci binding to JSON schema. Currently the in-tree dts files don't validate because they use sdhci@ instead of mmc@ as required by the generic mmc-controller schema. The compatible "marvell,sdhci-xenon" was not documented in the old binding but it accompanies the of "marvell,armada-3700-sdhci" in the armada-37xx SoC dtsi so this combination is added to the new binding document. Signed-off-by:
-
Wolfram Sang authored
Further digging in the datasheets revealed that R-Car V3M also has no HS400 support. Reported-by:
-
Geert Uytterhoeven authored
When running on an system without any quirks (e.g. R-Car V3U), the kernel crashes with a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002 ... Hardware name: Renesas Falcon CPU and Breakout boards based on r8a779a0 (DT) Workqueue: events_freezable mmc_rescan ... Call trace: renesas_sdhi_internal_dmac_start_dma+0x54/0x12c tmio_process_mrq+0x124/0x274 Fix this by adding the missing checks for the validatity of the priv->quirks pointer. Signed-off-by: -
Yann Gautier authored
In SDIO mode, the sg list for requests can be unaligned with what the STM32 SDMMC internal DMA can support. In that case, instead of failing, use a temporary bounce buffer to copy from/to the sg list. This buffer is limited to 1MB. But for that we need to also limit max_req_size to 1MB. It has not shown any throughput penalties for SD-cards or eMMC. Signed-off-by:
Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20220328145114.334577-1-yann.gautier@foss.st.comSigned-off-by:
-
Wolfram Sang authored
Put the braces to the proper position to make reading the code easier. Signed-off-by:
-
Wolfram Sang authored
After Shimoda-san's much appreciated refactoring of the quirk handling, we can convert now 'dmac_only_one_rx' from an ugly global flag to a regular quirk. This makes quirk handling more consistent and easier to maintain. After this patch, soc_dma_quirks is completely gone, hooray! Signed-off-by:
-
Wolfram Sang authored
After Shimoda-san's much appreciated refactoring of the quirk handling, we can convert now the 'fixed_addr_mode' from an ugly global flag to a regular quirk. This makes quirk handling more consistent and easier to maintain. Signed-off-by:
-
Wolfram Sang authored
The whitelist has been refactored away with a0fb3fc8 ("mmc: renesas_sdhi: remove whitelist for internal DMAC") so the comment doesn't make any sense anymore. Signed-off-by:
-
Wolfram Sang authored
When I read 'no_fallback', I forgot what fallback even though I was the author of this change. Name it better to make the code easier to understand. Signed-off-by:
-
Wolfram Sang authored
It is not explicitly expressed in the docs, but the needed data strobe pin is indeed missing for D3. The BSP disables HS400 as well. This means a little refactoring to reuse an already existing setup. Signed-off-by:
-
Wolfram Sang authored
We moved quirk handling out of the SDHI core to the individual drivers. So, no need to include headers needed for soc_device_match et al. Signed-off-by:
-
Brian Norris authored
Way back in commit 4f25580f ("mmc: core: changes frequency to hs_max_dtr when selecting hs400es"), Rockchip engineers noticed that some eMMC don't respond to SEND_STATUS commands very reliably if they're still running at a low initial frequency. As mentioned in that commit, JESD84-B51 P49 suggests a sequence in which the host: 1. sets HS_TIMING 2. bumps the clock ("<= 52 MHz") 3. sends further commands It doesn't exactly require that we don't use a lower-than-52MHz frequency, but in practice, these eMMC don't like it. The aforementioned commit tried to get that right for HS400ES, although it's unclear whether this ever truly worked as committed into mainline, as other changes/refactoring adjusted the sequence in conflicting ways: 08573eaf ("mmc: mmc: do not use CMD13 to get status after speed mode switch") 53e60650 ("mmc: core: Allow CMD13 polling when switching to HS mode for mmc") In any case, today we do step 3 before step 2. Let's fix that, and also apply the same logic to HS200/400, where this eMMC has problems too. Resolves errors like this seen when booting some RK3399 Gru/Scarlet systems: [ 2.058881] mmc1: CQHCI version 5.10 [ 2.097545] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA [ 2.209804] mmc1: mmc_select_hs400es failed, error -84 [ 2.215597] mmc1: error -84 whilst initialising MMC card [ 2.417514] mmc1: mmc_select_hs400es failed, error -110 [ 2.423373] mmc1: error -110 whilst initialising MMC card [ 2.605052] mmc1: mmc_select_hs400es failed, error -110 [ 2.617944] mmc1: error -110 whilst initialising MMC card [ 2.835884] mmc1: mmc_select_hs400es failed, error -110 [ 2.841751] mmc1: error -110 whilst initialising MMC card Ealier versions of this patch bumped to 200MHz/HS200 speeds too early, which caused issues on, e.g., qcom-msm8974-fairphone-fp2. (Thanks for the report Luca!) After a second look, it appears that aligns with JESD84 / page 45 / table 28, so we need to keep to lower (HS / 52 MHz) rates first. Fixes: 08573eaf ("mmc: mmc: do not use CMD13 to get status after speed mode switch") Fixes: 53e60650 ("mmc: core: Allow CMD13 polling when switching to HS mode for mmc") Fixes: 4f25580f ("mmc: core: changes frequency to hs_max_dtr when selecting hs400es") Cc: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/linux-mmc/11962455.O9o76ZdvQC@g550jk/Reported-by:
Luca Weiss <luca@z3ntu.xyz> Signed-off-by:
Brian Norris <briannorris@chromium.org> Tested-by:
-
- 24 Apr, 2022 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fix from Borislav Petkov: - Fix a corner case when calculating sched runqueue variables That fix also removes a check for a zero divisor in the code, without mentioning it. Vincent clarified that it's ok after I whined about it: https://lore.kernel.org/all/CAKfTPtD2QEyZ6ADd5WrwETMOX0XOwJGnVddt7VHgfURdqgOS-Q@mail.gmail.com/ * tag 'sched_urgent_for_v5.18_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/pelt: Fix attach_entity_load_avg() corner case
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Partly revert a change to our timer_interrupt() that caused lockups with high res timers disabled. - Fix a bug in KVM TCE handling that could corrupt kernel memory. - Two commits fixing Power9/Power10 perf alternative event selection. Thanks to Alexey Kardashevskiy, Athira Rajeev, David Gibson, Frederic Barrat, Madhavan Srinivasan, Miguel Ojeda, and Nicholas Piggin. * tag 'powerpc-5.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/perf: Fix 32bit compile powerpc/perf: Fix power10 event alternatives powerpc/perf: Fix power9 event alternatives KVM: PPC: Fix TCE handling for VFIO powerpc/time: Always set decrementer in timer_interrupt()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Borislav Petkov: - Add Sapphire Rapids CPU support - Fix a perf vmalloc-ed buffer mapping error (PERF_USE_VMALLOC in use) * tag 'perf_urgent_for_v5.18_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/cstate: Add SAPPHIRERAPIDS_X CPU support perf/core: Fix perf_mmap fail when CONFIG_PERF_USE_VMALLOC enabled
-
