05 Mar, 2021

1 commit


23 Feb, 2021

1 commit

  • In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
    circumstances, this may be done while the device is runtime suspended,
    triggering the below splat.

    Fix the problem by adding a pm_runtime_get_sync(), before reading the
    register, which will turn on clocks etc making the device accessible again.

    [ 1811.323148] mmc1: card aaaa removed
    [ 1811.347483] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
    [ 1811.354988] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core [last unloaded: mmc_core]
    [ 1811.365726] CPU: 0 PID: 3464 Comm: rmmod Not tainted 5.10.1-sd-99871-g53835a2e8186 #5
    [ 1811.373559] Hardware name: Freescale i.MX8DXL EVK (DT)
    [ 1811.378705] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
    [ 1811.384723] pc : sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx]
    [ 1811.391090] lr : platform_drv_remove+0x2c/0x50
    [ 1811.395536] sp : ffff800012c7bcb0
    [ 1811.398855] x29: ffff800012c7bcb0 x28: ffff00002c72b900
    [ 1811.404181] x27: 0000000000000000 x26: 0000000000000000
    [ 1811.409497] x25: 0000000000000000 x24: 0000000000000000
    [ 1811.414814] x23: ffff0000042b3890 x22: ffff800009127120
    [ 1811.420131] x21: ffff00002c4c9580 x20: ffff0000042d0810
    [ 1811.425456] x19: ffff0000042d0800 x18: 0000000000000020
    [ 1811.430773] x17: 0000000000000000 x16: 0000000000000000
    [ 1811.436089] x15: 0000000000000004 x14: ffff000004019c10
    [ 1811.441406] x13: 0000000000000000 x12: 0000000000000020
    [ 1811.446723] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
    [ 1811.452040] x9 : fefefeff6364626d x8 : 7f7f7f7f7f7f7f7f
    [ 1811.457356] x7 : 78725e6473607372 x6 : 0000000080808080
    [ 1811.462673] x5 : 0000000000000000 x4 : 0000000000000000
    [ 1811.467990] x3 : ffff800011ac1cb0 x2 : 0000000000000000
    [ 1811.473307] x1 : ffff8000091214d4 x0 : ffff8000133a0030
    [ 1811.478624] Call trace:
    [ 1811.481081] sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx]
    [ 1811.487098] platform_drv_remove+0x2c/0x50
    [ 1811.491198] __device_release_driver+0x188/0x230
    [ 1811.495818] driver_detach+0xc0/0x14c
    [ 1811.499487] bus_remove_driver+0x5c/0xb0
    [ 1811.503413] driver_unregister+0x30/0x60
    [ 1811.507341] platform_driver_unregister+0x14/0x20
    [ 1811.512048] sdhci_esdhc_imx_driver_exit+0x1c/0x3a8 [sdhci_esdhc_imx]
    [ 1811.518495] __arm64_sys_delete_module+0x19c/0x230
    [ 1811.523291] el0_svc_common.constprop.0+0x78/0x1a0
    [ 1811.528086] do_el0_svc+0x24/0x90
    [ 1811.531405] el0_svc+0x14/0x20
    [ 1811.534461] el0_sync_handler+0x1a4/0x1b0
    [ 1811.538474] el0_sync+0x174/0x180
    [ 1811.541801] Code: a9025bf5 f9403e95 f9400ea0 9100c000 (b9400000)
    [ 1811.547902] ---[ end trace 3fb1a3bd48ff7be5 ]---

    Signed-off-by: Frank Li
    Cc: stable@vger.kernel.org # v4.0+
    Link: https://lore.kernel.org/r/20210210181933.29263-1-Frank.Li@nxp.com
    [Ulf: Clarified the commit message a bit]
    Signed-off-by: Ulf Hansson

    Frank Li
     

29 Jan, 2021

1 commit


04 Jan, 2021

1 commit

  • This is the 5.10.4 stable release

    * tag 'v5.10.4': (717 commits)
    Linux 5.10.4
    x86/CPU/AMD: Save AMD NodeId as cpu_die_id
    drm/edid: fix objtool warning in drm_cvt_modes()
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/gpu/drm/imx/dcss/dcss-plane.c
    drivers/media/i2c/ov5640.c

    Jason Liu
     

30 Dec, 2020

2 commits

  • [ Upstream commit d7b819b5d33869d41bdaa427aeb98ae24c57a38b ]

    Fix to return the error code from devm_gpiod_get_optional() instaed
    of 0 in pxamci_probe().

    Fixes: f54005b508b9a9d9c ("mmc: pxa: Use GPIO descriptor for power")
    Reported-by: Hulk Robot
    Signed-off-by: Zhihao Cheng
    Link: https://lore.kernel.org/r/20201121021431.3168506-1-chengzhihao1@huawei.com
    Signed-off-by: Ulf Hansson
    Signed-off-by: Sasha Levin

    Zhihao Cheng
     
  • [ Upstream commit fcc541fea394d67ad607ee41acfa891e79fe17a2 ]

    'busy_timeout' is in msecs, not in jiffies. Use the correct factor.

    Fixes: 5e958e4aacf4 ("sdhci: tegra: Implement Tegra specific set_timeout callback")
    Signed-off-by: Wolfram Sang
    Acked-by: Sowjanya Komatineni
    Acked-by: Thierry Reding
    Link: https://lore.kernel.org/r/20201116132206.23518-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson
    Signed-off-by: Sasha Levin

    Wolfram Sang
     

14 Dec, 2020

14 commits

  • No handling for voltage parsing failure. This patch is to
    fix the issue.

    Fixes: de6c11d3a1a3 ("mmc: use generic device properties in mmc_of_parse_voltage")
    Signed-off-by: Yangbo Lu
    Reviewed-by: Haibo Chen

    Yangbo Lu
     
  • Add ACPI support for eSDHC driver.

    Signed-off-by: Meenakshi Aggarwal
    Signed-off-by: Yangbo Lu

    Yangbo Lu
     
  • Convert to generic device properties in mmc_of_parse_voltage().
    Rename the function to mmc_parse_voltage().

    Signed-off-by: Meenakshi Aggarwal
    Signed-off-by: Yangbo Lu

    Yangbo Lu
     
  • When imx_data->pinctrl is not a valid pointer, pinctrl_lookup_state
    will trigger kernel panic.

    When we boot Dual OS on Jailhouse hypervisor, we let the 1st Linux to
    configure pinmux ready for the 2nd OS, so the 2nd OS not have pinctrl
    settings.

    Reviewed-by: Bough Chen
    Reviewed-by: Alice Guo
    Signed-off-by: Peng Fan

    Peng Fan
     
  • Find this issue on i.MX7D-sdb board with broadcom sdio wifi.
    When system resume, sometimes this wifi meet the tuning fail issue.
    All tuning command get command timeout error. This is because
    sdio_irq_work on system_wq was executed before the broadcom
    wifi driver resume. Due to broadcom wifi driver set the wifi in
    Sleep sate in system suspend, need to set the wifi to Wake state
    first. So need to make sure wifi driver resume first, then do the
    sdio_irq_work.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • S32V234 uSDHC is compatible with the driver implemented for i.MX.
    Notes:
    - Errata ESDHC_FLAG_ERR004536 is not applicable for S32V234 uSDHC.
    - MMC driver is selected based on the SOC that is part of the Freescale S32
    family.

    Signed-off-by: Gilles Talis
    Signed-off-by: Mihaela Martinas
    Signed-off-by: Stoica Cosmin-Stefan
    Signed-off-by: Stefan-Gabriel Mirea
    Acked by: Haibo Chen

    Mihaela Martinas
     
  • Currently sdhci driver free irq in host suspend, and call
    request_threaded_irq() in host resume. But during host resume,
    Ctrl+C can impact sdhci host resume, see the error log:

    CPU1 is up
    PM: noirq resume of devices complete after 0.637 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.1
    PM: early resume of devices complete after 0.774 msecs
    dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
    PM: Device 30b40000.usdhc failed to resume: error -4
    dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
    PM: Device 30b50000.usdhc failed to resume: error -4
    dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
    PM: Device 30b60000.usdhc failed to resume: error -4 fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
    mmc0: Timeout waiting for hardware interrupt.
    mmc0: Timeout waiting for hardware interrupt.
    mmc0: Timeout waiting for hardware interrupt.
    mmc0: Timeout waiting for hardware interrupt.
    mmc0: Timeout waiting for hardware interrupt.
    mmc0: Timeout waiting for hardware interrupt.
    mmc0: error -110 during resume (card was removed?)
    mmc2: Timeout waiting for hardware interrupt.
    mmc2: Timeout waiting for hardware interrupt.
    mmc2: error -110 during resume (card was removed?)

    In request_threaded_irq-> __setup_irq-> kthread_create
    ->kthread_create_on_node, the comment shows that SIGKILLed will
    impact the kthread create, and return -EINTR.

    This patch replace them with disable|enable_irq(), that will prevent
    IRQs from being propagated to the sdhci driver.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • Request BUS_FREQ_HIGH when bus is busy and then release BUS_FREQ_HIGH
    when bus becomes idle.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • When suspend usdhc, it will access usdhc register. So usdhc clock
    should be enabled, otherwise the access usdhc register will return
    error or cause system.

    Take this into consideration, if system enable a usdhc and do not
    connect any SD/SDIO/MMC card, after system boot up, this usdhc
    will do runtime suspend, and close all usdhc clock. At this time,
    if suspend the system, due to no card persent, usdhc runtime resume
    will not be called. So usdhc clock still closed, then in suspend,
    once access usdhc register, system hung or bus error return.

    This patch make sure usdhc clock always enabled while doing usdhc
    suspend.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • With igore pm notify feature, MMC core will not re-detect card
    after system suspend/resume. This is needed for some special cards
    like Broadcom WiFi which can't work propertly on card re-detect
    after system resume.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • This will cause meaningless CPU overhead by polling the card at backgroud
    if the CD is broken.
    Most board does not intend to use this function, so remove it.
    Platform driver could add it for test if needed.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • We may meet the following errors with a SD3.0 DDR50 cards during reboot test.
    mmc0: new ultra high speed DDR50 SDHC card at address aaaa
    mmcblk0: mmc0:aaaa SU08G 7.40 GiB
    mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
    mmcblk0: retrying using single block read
    mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
    end_request: I/O error, dev mmcblk0, sector 0
    .....
    Buffer I/O error on device mmcblk0, logical block 0
    mmcblk0: unable to read partition table

    The root cause is still unknown.
    Since there's an errata of Sandisk eMMC card before that it requires delay for CMD6
    for eMMC DDR mode to work stable, we also suspect the SD3.0 DDR requires similar delay.
    (Still not confirmed by Sandisk)
    By adding the delay, the overnight reboot test(run 2000+ times) did not
    show the issue anymore. Originally it can easy show the error after about 20 times of
    reboot test.

    So this patch would be the temporary workaround for Sandisk SD3.0 DDR50 mode
    unstable issue.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • After adding mega fast support, the default enabled usdhc wakeup will block
    M/F to gate off power domain.

    To avoid this issue, we only claim wakeup capability and reply on user to enable
    it via sysfs according to real needs.
    The drawback of such change is that for SDIO WiFi Wakeup On Wireless feature,
    User has to enable both uSDHC and WiFi WoW wakeup mannually to make
    WoW work well.

    BTW, due to the wakeup feature is controller itself, so we do not need to reply
    on WiFi PM flags to enable it.

    Signed-off-by: Haibo Chen

    Haibo Chen
     
  • Some sandisk emmc cards need certain delay before sending cmd13 after cmd6.
    Original CR: ENGR174296 (commit: fd031f9)

    Signed-off-by: Haibo Chen

    Haibo Chen
     

04 Dec, 2020

3 commits

  • The #ifdef check for the suspend/resume functions is wrong:

    drivers/mmc/host/mtk-sd.c:2765:12: error: unused function 'msdc_suspend' [-Werror,-Wunused-function]
    static int msdc_suspend(struct device *dev)
    drivers/mmc/host/mtk-sd.c:2779:12: error: unused function 'msdc_resume' [-Werror,-Wunused-function]
    static int msdc_resume(struct device *dev)

    Remove the #ifdef and mark all four as __maybe_unused to aovid the
    problem.

    Fixes: c0a2074ac575 ("mmc: mediatek: Fix system suspend/resume support for CQHCI")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann
    Link: https://lore.kernel.org/r/20201203222922.1067522-1-arnd@kernel.org
    Signed-off-by: Ulf Hansson

    Arnd Bergmann
     
  • The CMD13 polling is needed for commands with R1B responses. In commit
    a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B
    response"), the intent was to introduce this for requests targeted to the
    RPMB partition. However, the condition to trigger the polling loop became
    wrong, leading to unnecessary polling. Let's fix the condition to avoid
    this.

    Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response")
    Cc: stable@vger.kernel.org
    Reported-by: Zhan Liu
    Signed-off-by: Zhan Liu
    Signed-off-by: Bean Huo
    Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com
    Signed-off-by: Ulf Hansson

    Bean Huo
     
  • Further testing of error cases revealed that downgrade is not enough, so
    we need to reset the SCC which is done by calling the custom reset
    function. This reset function can distinguish between the various SDHI
    variants, so protecting the call with MIN_RCAR2 is enough here.

    Fixes: 24ce2d7b8bea ("mmc: tmio: bring tuning HW to a sane state with MMC_POWER_OFF")
    Reported-by: Yoshihiro Shimoda
    Signed-off-by: Wolfram Sang
    Reviewed-by: Yoshihiro Shimoda
    Tested-by: Yoshihiro Shimoda
    Link: https://lore.kernel.org/r/20201125204953.3344-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson

    Wolfram Sang
     

24 Nov, 2020

2 commits

  • The commit 16ada730a759 ("mmc: sdhci-of-arasan: Modify clock operations
    handling") introduced support for platform specific clock operations.
    Around the same point in time the commit 36c6aadaae86 ("mmc:
    sdhci-of-arasan: Add support for Intel Keem Bay") was also merged.
    Unfortunate it was not really tested on top of the previously mentioned
    commit, which causes clock registration failures for Keem Bay SOC devices.

    Let's fix this, by properly declaring the clock operation for Keem Bay SOC
    devices.

    Fixes: 36c6aadaae86 ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay")
    Signed-off-by: Muhammad Husaini Zulkifli
    Reviewed-by: Adrian Hunter
    Link: https://lore.kernel.org/r/20201118120120.24908-2-muhammad.husaini.zulkifli@intel.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson

    Muhammad Husaini Zulkifli
     
  • The SDIO recheck fix is required for more of the supported variants. Let's
    add it to those that needs it.

    Reported-by: Fabien Parent
    Reported-by: Mattijs Korpershoek
    Signed-off-by: Yong Mao
    Link: https://lore.kernel.org/r/20201119030237.9414-1-yong.mao@mediatek.com
    Fixes: 9e2582e57407 ("mmc: mediatek: fix SDIO irq issue")
    Cc: stable@vger.kernel.org
    [Ulf: Clarified commitmsg ]
    Signed-off-by: Ulf Hansson

    yong mao
     

23 Nov, 2020

1 commit

  • Before we got these errors on MT8192 platform:
    [ 59.153891] Restarting tasks ...
    [ 59.154540] done.
    [ 59.159175] PM: suspend exit
    [ 59.218724] mtk-msdc 11f60000.mmc: phase: [map:fffffffe] [maxlen:31]
    [final:16]
    [ 119.776083] mmc0: cqhci: timeout for tag 9
    [ 119.780196] mmc0: cqhci: ============ CQHCI REGISTER DUMP ===========
    [ 119.786709] mmc0: cqhci: Caps: 0x100020b6 | Version: 0x00000510
    [ 119.793225] mmc0: cqhci: Config: 0x00000101 | Control: 0x00000000
    [ 119.799706] mmc0: cqhci: Int stat: 0x00000000 | Int enab: 0x00000000
    [ 119.806177] mmc0: cqhci: Int sig: 0x00000000 | Int Coal: 0x00000000
    [ 119.812670] mmc0: cqhci: TDL base: 0x00000000 | TDL up32: 0x00000000
    [ 119.819149] mmc0: cqhci: Doorbell: 0x003ffc00 | TCN: 0x00000200
    [ 119.825656] mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
    [ 119.832155] mmc0: cqhci: Task clr: 0x00000000 | SSC1: 0x00001000
    [ 119.838627] mmc0: cqhci: SSC2: 0x00000000 | DCMD rsp: 0x00000000
    [ 119.845174] mmc0: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x0000891c
    [ 119.851654] mmc0: cqhci: Resp idx: 0x00000000 | Resp arg: 0x00000000
    [ 119.865773] mmc0: cqhci: : ===========================================
    [ 119.872358] mmc0: running CQE recovery
    From these logs, we found TDL base was back to the default value.

    After suspend, the mmc host is powered off by HW, and bring CQE register
    to the default value, so we add system suspend/resume interface, then bring
    CQE to deactivated state before suspend, it will be enabled by CQE first
    request after resume.

    Signed-off-by: Wenbin Mei
    Link: https://lore.kernel.org/r/20201118063405.24906-1-wenbin.mei@mediatek.com
    Fixes: 88bd652b3c74 ("mmc: mediatek: command queue support")
    Cc: stable@vger.kernel.org
    [Ulf: Renamed functions]
    Signed-off-by: Ulf Hansson

    Wenbin Mei
     

17 Nov, 2020

4 commits

  • In the current implementation DLL reset will be issued for
    each ITAP and OTAP setting inside ATF, this is creating issues
    in some scenarios and this sequence is not inline with the TRM.
    To fix the issue, DLL reset should be removed from the ATF and
    host driver will request it explicitly.
    This patch update host driver to explicitly request for DLL reset
    before ITAP (assert DLL) and after OTAP (release DLL) settings.

    Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup")
    Signed-off-by: Sai Krishna Potthuri
    Signed-off-by: Manish Narani
    Acked-by: Michal Simek
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1605515565-117562-4-git-send-email-manish.narani@xilinx.com
    Signed-off-by: Ulf Hansson

    Manish Narani
     
  • Mask the ITAP and OTAP delay bits before updating with the new
    tap value for Versal platform.

    Fixes: 1a470721c8f5 ("sdhci: arasan: Add support for Versal Tap Delays")
    Signed-off-by: Sai Krishna Potthuri
    Signed-off-by: Manish Narani
    Acked-by: Michal Simek
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1605515565-117562-3-git-send-email-manish.narani@xilinx.com
    Signed-off-by: Ulf Hansson

    Manish Narani
     
  • Allow configuring the Output and Input tap values with zero to avoid
    failures in some cases (one of them is SD boot mode) where the output
    and input tap values may be already set to non-zero.

    Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup")
    Signed-off-by: Sai Krishna Potthuri
    Signed-off-by: Manish Narani
    Acked-by: Michal Simek
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1605515565-117562-2-git-send-email-manish.narani@xilinx.com
    Signed-off-by: Ulf Hansson

    Manish Narani
     
  • A UHS setting of SDR25 can give better results for High Speed mode.
    This is because there is no setting corresponding to high speed. Currently
    SDHCI sets no value, which means zero which is also the setting for SDR12.
    There was an attempt to change this in sdhci.c but it caused problems for
    some drivers, so it was reverted and the change was made to sdhci-brcmstb
    in commit 2fefc7c5f7d16e ("mmc: sdhci-brcmstb: Fix incorrect switch to HS
    mode"). Several other drivers also do this.

    Signed-off-by: Adrian Hunter
    Cc: stable@vger.kernel.org # v5.4+
    Link: https://lore.kernel.org/r/20201112133656.20317-1-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson

    Adrian Hunter
     

10 Nov, 2020

5 commits

  • This reverts commit db1af1e9712920f47b5dc6a995fca3eec05ea85e. It was
    only a workaround to hide a regression. We now have proper fixes.

    Signed-off-by: Wolfram Sang
    Tested-by: Niklas Söderlund
    Reviewed-by: Yoshihiro Shimoda
    Tested-by: Yoshihiro Shimoda
    Link: https://lore.kernel.org/r/20201106072549.1495-4-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson

    Wolfram Sang
     
  • When powering off a card, we need to disable the tuning HW (like SCC for
    the Renesas SDHI) to get to a sane state and allow for re-tuning new
    cards. This was hidden before because we wrongly did that in hw_reset()
    before which was an unintended use of hw_reset(). Now that we corrected
    the use of hw_reset() meanwhile, we revealed this shortcoming and need
    to fix it properly by explicitly calling the downgrade callback.

    Fixes: 6e7d4de10890 ("mmc: renesas_sdhi: move wrong 'hw_reset' to 'reset'")
    Suggested-by: Takeshi Saito
    Reviewed-by: Takeshi Saito
    Signed-off-by: Wolfram Sang
    Tested-by: Niklas Söderlund
    Reviewed-by: Yoshihiro Shimoda
    Tested-by: Yoshihiro Shimoda
    Link: https://lore.kernel.org/r/20201106072549.1495-3-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson

    Wolfram Sang
     
  • When applying a revert, the assumption that DMA only needs to be cleared
    in specific cases was wrong. We want to reset the DMA controller every
    time the rest of the HW gets reset, too.

    Fixes: 34e3211e5492 ("Revert "mmc: tmio: fix reset operation"")
    Reported-by: Yoshihiro Shimoda
    Signed-off-by: Wolfram Sang
    Tested-by: Niklas Söderlund
    Reviewed-by: Yoshihiro Shimoda
    Tested-by: Yoshihiro Shimoda
    Link: https://lore.kernel.org/r/20201106072549.1495-2-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson

    Wolfram Sang
     
  • Apply erratum workaround of unreliable pulse width detection to
    more affected platforms (LX2160A Rev2.0 and LS1028A Rev1.0).

    Signed-off-by: Yangbo Lu
    Fixes: 48e304cc1970 ("mmc: sdhci-of-esdhc: workaround for unreliable pulse width detection")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201110071314.3868-1-yangbo.lu@nxp.com
    Signed-off-by: Ulf Hansson

    Yangbo Lu
     
  • The commit 94b110aff867 ("mmc: tmio: add tmio_mmc_host_alloc/free()")
    added tmio_mmc_host_free(), but missed the function calling in
    the sh_mobile_sdhi_remove() at that time. So, fix it. Otherwise,
    we cannot rebind the sdhi/mmc devices when we use aliases of mmc.

    Fixes: 94b110aff867 ("mmc: tmio: add tmio_mmc_host_alloc/free()")
    Signed-off-by: Yoshihiro Shimoda
    Reviewed-by: Wolfram Sang
    Tested-by: Wolfram Sang
    Reviewed-by: Niklas Söderlund
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1604654730-29914-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Ulf Hansson

    Yoshihiro Shimoda
     

31 Oct, 2020

1 commit

  • Pull MMC host fixes from Ulf Hansson:

    - sdhci: Fix performance regression with auto CMD auto select

    - sdhci-of-esdhc: Fix initialization for eMMC HS400 mode

    - sdhci-of-esdhc: Fix timeout bug for tuning commands

    * tag 'mmc-v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
    mmc: sdhci-of-esdhc: make sure delay chain locked for HS400
    mmc: sdhci-of-esdhc: set timeout to max before tuning
    mmc: sdhci: Use Auto CMD Auto Select only when v4_mode is true

    Linus Torvalds
     

28 Oct, 2020

1 commit

  • For eMMC HS400 mode initialization, the DLL reset is a required step
    if DLL is enabled to use previously, like in bootloader.
    This step has not been documented in reference manual, but the RM will
    be fixed sooner or later.

    This patch is to add the step of DLL reset, and make sure delay chain
    locked for HS400.

    Signed-off-by: Yangbo Lu
    Acked-by: Adrian Hunter
    Link: https://lore.kernel.org/r/20201020081116.20918-1-yangbo.lu@nxp.com
    Fixes: 54e08d9a95ca ("mmc: sdhci-of-esdhc: add hs400 mode support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson

    Yangbo Lu
     

25 Oct, 2020

1 commit

  • Pull ARM SoC platform updates from Olof Johansson:
    "SoC changes, a substantial part of this is cleanup of some of the
    older platforms that used to have a bunch of board files.

    In particular:

    - Remove non-DT i.MX platforms that haven't seen activity in years,
    it's time to remove them.

    - A bunch of cleanup and removal of platform data for TI/OMAP
    platforms, moving over to genpd for power/reset control (yay!)

    - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
    closer to multiplatform support (not quite there yet, but getting
    close).

    There are a few other changes too, smaller fixlets, etc. For new
    platform support, the primary ones are:

    - New SoC: Hisilicon SD5203, ARM926EJ-S platform.

    - Cpufreq support for i.MX7ULP"

    * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits)
    ARM: mstar: Select MStar intc
    ARM: stm32: Replace HTTP links with HTTPS ones
    ARM: debug: add UART early console support for SD5203
    ARM: hisi: add support for SD5203 SoC
    ARM: omap3: enable off mode automatically
    clk: imx: imx35: Remove mx35_clocks_init()
    clk: imx: imx31: Remove mx31_clocks_init()
    clk: imx: imx27: Remove mx27_clocks_init()
    ARM: imx: Remove unused definitions
    ARM: imx35: Retrieve the IIM base address from devicetree
    ARM: imx3: Retrieve the AVIC base address from devicetree
    ARM: imx3: Retrieve the CCM base address from devicetree
    ARM: imx31: Retrieve the IIM base address from devicetree
    ARM: imx27: Retrieve the CCM base address from devicetree
    ARM: imx27: Retrieve the SYSCTRL base address from devicetree
    ARM: s3c64xx: bring back notes from removed debug-macro.S
    ARM: s3c24xx: fix Wunused-variable warning on !MMU
    ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
    MAINTAINERS: mark linux-samsung-soc list non-moderated
    ARM: imx: Remove remnant board file support pieces
    ...

    Linus Torvalds
     

23 Oct, 2020

1 commit

  • On rare occations there is the following error:

    mmc0: Tuning timeout, falling back to fixed sampling clock

    There are SD cards which takes a significant longer time to reply to the
    first CMD19 command. The eSDHC takes the data timeout value into account
    during the tuning period. The SDHCI core doesn't explicitly set this
    timeout for the tuning procedure. Thus on the slow cards, there might be
    a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong
    sequence of events. In the end this will lead to an unsuccessful tuning
    procedure and to the above error.

    To workaround this, set the timeout to the maximum value (which is the
    best we can do) and the SDHCI core will take care of the proper timeout
    handling.

    Fixes: ba49cbd0936e ("mmc: sdhci-of-esdhc: add tuning support")
    Signed-off-by: Michael Walle
    Acked-by: Adrian Hunter
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201022222337.19857-1-michael@walle.cc
    Signed-off-by: Ulf Hansson

    Michael Walle
     

15 Oct, 2020

1 commit

  • sdhci-of-dwcmshc meets an eMMC read performance regression with below
    command after commit 427b6514d095 ("mmc: sdhci: Add Auto CMD Auto
    Select support"):

    dd if=/dev/mmcblk0 of=/dev/null bs=8192 count=100000

    Before the commit, the above command gives 120MB/s
    After the commit, the above command gives 51.3 MB/s

    So it looks like sdhci-of-dwcmshc expects Version 4 Mode for Auto
    CMD Auto Select. Fix the performance degradation by ensuring v4_mode
    is true to use Auto CMD Auto Select.

    Fixes: 427b6514d095 ("mmc: sdhci: Add Auto CMD Auto Select support")
    Signed-off-by: Jisheng Zhang
    Acked-by: Adrian Hunter
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201015174115.4cf2c19a@xhacker.debian
    Signed-off-by: Ulf Hansson

    Jisheng Zhang