- 01 Jun, 2020 1 commit
-
-
Veerabhadrarao Badiganti authored
Clear tuning_done flag while executing tuning to ensure vendor specific HS400 settings are applied properly when the controller is re-initialized in HS400 mode. Without this, re-initialization of the qcom SDHC in HS400 mode fails while resuming the driver from runtime-suspend or system-suspend. Fixes: ff06ce41 ("mmc: sdhci-msm: Add HS400 platform support") Cc: stable@vger.kernel.org Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1590678838-18099-1-git-send-email-vbadigan@codeaurora.orgSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
- 29 May, 2020 21 commits
-
-
Pali Rohár authored
Device/vendor ids from Common CIS (Card Information Structure) may be different as device/vendor ids from CIS on particular SDIO function. Kernel currently exports only device/vendor ids from SDIO functions and not "main" device/vendor ids from Common CIS. This patch exports "main" device/vendor ids for SDIO and SD combo cards at top level mmc device in sysfs hierarchy. Userspace can use e.g. udev rules to correctly match whole SDIO card based on Common CIS device/vendor id and not only one particular SDIO function. Having this information in userspace also helps developers to debug whole SDIO card as e.g. kernel mmc quirks use device/vendor ids from Common CIS and not from particular SDIO function. Also it allows to write userspace applications which list all connected SDIO cards based on CIS ids. Signed-off-by:
Pali Rohár <pali@kernel.org> Reviewed-by:
Marek Behún <marek.behun@nic.cz> Link: https://lore.kernel.org/r/20200527110858.17504-2-pali@kernel.orgSigned-off-by:
-
Pali Rohár authored
SDIO non-combo cards are not handled by mmc_block driver and do not have accessible CID register which is used for MMC_NAME= construction. Signed-off-by:
-
Eugen Hristev authored
When enabling calibration at reset, the CALCR register was completely rewritten. This may cause certain bits being deleted unintentedly. Fix by issuing a read-modify-write operation. Fixes: 727d836a ("mmc: sdhci-of-at91: add DT property to enable calibration on full reset") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Link: https://lore.kernel.org/r/20200527105659.142560-1-eugen.hristev@microchip.com Cc: stable@vger.kernel.org Signed-off-by:
-
Haibo Chen authored
In current code, we add 1ms dealy after each tuning command for standard tuning method. Adding this 1ms dealy is because USDHC default check the CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning IC logic do not wait for the tuning data sending out by the card, trigger the buffer read ready interrupt immediately, and step to next cycle. So when next time the new tuning command send out by USDHC, card may still not send out the tuning data of the upper command，then some eMMC cards may stuck, can't response to any command, block the whole tuning procedure. If do not check the CMD CRC for tuning, then do not has this issue. USDHC will wait for the tuning data of each tuning command and check them. If the tuning data pass the check, it also means the CMD line also okay for tuning. So this patch disable the CMD CRC check for tuning, save some time for the whole tuning procedure. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/1590488522-9292-2-git-send-email-haibo.chen@nxp.comSigned-off-by:
-
Haibo Chen authored
According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is TUNING_START_TAP, bit[7] of this register is to disable the command CRC check for standard tuning. So fix it here. Fixes: d87fc966 ("mmc: sdhci-esdhc-imx: support setting tuning start point") Signed-off-by:
-
Haibo Chen authored
When use the specific GPIO to detect the card insert/remove, we can also add the GPIO as a wakeup source. When system suspend, insert or remove the card can wakeup the system. Signed-off-by:
-
Ludovic Barre authored
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: WARNING: CPU: 1 PID: 85 at kernel/dma/debug.c:1302 debug_dma_map_sg+0x2a0/0x3cc mmci-pl18x 58005000.sdmmc: DMA-API: mapping sg segment longer than device claims to support [len=126976] [max=65536] dma api debug checks and compares the segment size to dma_get_max_seg_size (dev->dma_parms->max_segment_size), the sdmmc variant has an internal DMA and should define its max_segment_size constraint to avoid this warning. This Patch defines the dev->dma_parms->max_segment_size with the constraint already set for mmc core (host->mmc->max_seg_size). Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200526155103.12514-3-ludovic.barre@st.comSigned-off-by:
-
Ludovic Barre authored
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: WARNING: CPU: 1 PID: 20 at kernel/dma/debug.c:500 add_dma_entry+0x16c/0x17c DMA-API: exceeded 7 overlapping mappings of cacheline 0x031d2645 Modules linked in: CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.5.0-rc2-00021-gdeda30999c2b-dirty #49 Hardware name: STM32 (Device Tree Support) Workqueue: events_freezable mmc_rescan [<c03138c0>] (unwind_backtrace) from [<c030d760>] (show_stack+0x10/0x14) [<c030d760>] (show_stack) from [<c0f2eb28>] (dump_stack+0xc0/0xd4) [<c0f2eb28>] (dump_stack) from [<c034a14c>] (__warn+0xd0/0xf8) [<c034a14c>] (__warn) from [<c034a530>] (warn_slowpath_fmt+0x94/0xb8) [<c034a530>] (warn_slowpath_fmt) from [<c03bca0c>] (add_dma_entry+0x16c/0x17c) [<c03bca0c>] (add_dma_entry) from [<c03bdf54>] (debug_dma_map_sg+0xe4/0x3d4) [<c03bdf54>] (debug_dma_map_sg) from [<c0d09244>] (sdmmc_idma_prep_data+0x94/0xf8) [<c0d09244>] (sdmmc_idma_prep_data) from [<c0d05a2c>] (mmci_prep_data+0x2c/0xb0) [<c0d05a2c>] (mmci_prep_data) from [<c0d073ec>] (mmci_start_data+0x134/0x2f0) [<c0d073ec>] (mmci_start_data) from [<c0d078d0>] (mmci_request+0xe8/0x154) [<c0d078d0>] (mmci_request) from [<c0cecb44>] (mmc_start_request+0x94/0xbc) DMA api debug brings to light leaking dma-mappings, dma_map_sg and dma_unmap_sg are not correctly balanced. If a request is prepared, the dma_map/unmap are done in asynchronous call pre_req (prep_data) and post_req (unprep_data). In this case the dma-mapping is right balanced. But if the request was not prepared, the data->host_cookie is define to zero and the dma_map/unmap must be done in the request. The dma_map is called by mmci_dma_start (prep_data), but there is no dma_unmap in this case. This patch adds dma_unmap_sg when the dma is finalized and the data cookie is zero (request not prepared). Signed-off-by:
-
Wan Ahmad Zainie authored
Intel Keem Bay SoC eMMC/SD/SDIO controller is based on Arasan SD 3.0 / eMMC 5.1 host controller IP. However, it does not support 64-bit access as its AXI interface has 32-bit address ports. Signed-off-by:
Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Reviewed-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200526062758.17642-3-wan.ahmad.zainie.wan.mohamad@intel.comSigned-off-by:
-
Wan Ahmad Zainie authored
Add new compatible strings in sdhci-of-arasan.c to support Intel Keem Bay eMMC/SD/SDIO controller, based on Arasan SDHCI 5.1. Signed-off-by:
-
Vladimir Kondratiev authored
Accordingly to Cadence documentation, PHY write procedure is: 1. Software sets the PHY Register Address (HRS04[5:0]) and the PHY Write Data (HRS04[15:8]) fields. 2. Software sets the PHY Write Transaction Request (HRS04[24]) field to 1. 3. Software waits as the PHY Write Transaction Acknowledge (HRS04[26]) field is equal to 0. 4. Hardware performs the write transaction to PHY register where HRS04[15:8] is a data written to register under HRS04[5:0] address. 5. Hardware sets the PHY Transaction Acknowledge (HRS04[26]) to 1 when transaction is completed. 6. Software clears the PHY Write Transaction Request (HRS04[24]) to 1 after noticing that the PHY Write Transaction Acknowledge (HRS04[26]) field is equal to 1. 7. Software waits for the PHY Acknowledge Register (HRS04[26]) field is equal to 0. Add missing steps 3 and 7. Lack of these steps causes integrity errors detested by hardware. Signed-off-by:
Vladimir Kondratiev <vladimir.kondratiev@intel.com> Link: https://lore.kernel.org/r/20200525074053.7309-1-vladimir.kondratiev@intel.comSigned-off-by:
-
Pali Rohár authored
Fix ordering of SDIO IDs to conform to the comment above, which says vendor first, device next. Signed-off-by:
-
Pali Rohár authored
All macro names for SDIO device IDs are prefixed by vendor name to which device ID belongs. So for consistency add Broadcom string vendor prefix to all Cypress macro names as they belong to SDIO Broadcom vendor ID. Change also Cypress 43012 value from decimal do hexadecimal notation to be consistent with all other values. Signed-off-by:
-
Pali Rohár authored
Define appropriate macro names for consistency with other macros. Signed-off-by:
-
Pali Rohár authored
Also replace generic MANUFACTURER macros by proper SDIO IDs macros. Checks for device IDs are slightly modified to use SDIO device IDs. This allows removal of all custom MANUFACTURER macros from ath10k. Signed-off-by:
-
Pali Rohár authored
Also replace generic MANUFACTURER macros by proper SDIO IDs macros. Check for "AR6003 or later" is slightly modified to use SDIO device IDs. This allows removal of all custom MANUFACTURER macros from ath6kl. Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200522144412.19712-8-pali@kernel.orgSigned-off-by:
-
Pali Rohár authored
Define appropriate macro names for consistency with other Siano macros. Signed-off-by:
-
Pali Rohár authored
Define appropriate macro names for consistency with other macros. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200522144412.19712-6-pali@kernel.orgSigned-off-by:
Ganapathi Bhat <ganapathi.bhat@nxp.com>
-
Pali Rohár authored
Define appropriate macro names for consistency with other Marvell macros. Signed-off-by:
-
Pali Rohár authored
Add _WLAN suffix to macro names for consistency with other Marvell macros. These IDs represents wlan function of combo bt/wlan cards. Other functions of these cards have different IDs. Signed-off-by:
-
Pali Rohár authored
Add underscore as separator in Marvell 8688 macro names for better readability and consistency. Signed-off-by:
-
- 28 May, 2020 18 commits
-
-
Pali Rohár authored
Marvell SDIO device ID 0x9134 is used in SDIO Common CIS (Card Information Structure) and not in SDIO wlan function (with ID 1). SDIO Common CIS is accessed by function ID 0. So change this misleading macro name to SDIO_DEVICE_ID_MARVELL_8887_F0 as it does not refer to wlan function. It refers to function 0. Wlan module on this SDIO card is available at function ID 1 and is identified by different SDIO device ID 0x9135. Kernel quirks for SDIO devices are matched against device ID from SDIO Common CIS. Therefore device ID used in quirk is correct, just has misleading name. Signed-off-by:
-
Ulf Hansson authored
-
Angelo Dureghello authored
Moving specific m5441x clk-related code in more appropriate location, since breaking compilation for other targets. Signed-off-by:
Angelo Dureghello <angelo.dureghello@timesys.com> Link: https://lore.kernel.org/r/20200525102324.2723438-1-angelo.dureghello@timesys.comSigned-off-by:
-
Yangbo Lu authored
The eSDHC HS400 timing requires many specific registers setting, unlike other speed modes which need to set only host controller 2 register. When driver needs to downgrade HS400 mode to other speed mode, the controller have to exit HS400 timing properly first. This patch is to support the procedure of HS400 exiting at the beginning of esdhc_set_uhs_signaling. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Acked-by:
-
Sarthak Garg authored
Implement dump_vendor_registers host operation to print the vendor specific registers in addition to standard SDHC register during error conditions. Signed-off-by:
Sahitya Tummala <stummala@codeaurora.org> Signed-off-by:
Sarthak Garg <sartgarg@codeaurora.org> Acked-by:
-
Sarthak Garg authored
Introduce new sdhci ops to dump vendor specific registers in the sdhci_dumpregs during error. Signed-off-by:
-
Sarthak Garg authored
Certain platforms require different settings in the SDCC_HC_REG_DLL_CONFIG register. This setting can change from platform to platform. So the driver should check whether a particular platform require a different setting by reading the DT file and use it. Also use msm_cm_dll_set_freq only when DLL not supplied. Signed-off-by:
Bao D. Nguyen <nguyenb@codeaurora.org> Signed-off-by:
-
Sarthak Garg authored
Certain platforms require different settings in the SDCC_HC_REG_DDR_CONFIG register. This setting can change from platform to platform. So the driver should check whether a particular platform require a different setting by reading the device tree file and use it. Signed-off-by:
-
Sarthak Garg authored
Update dll_config_3 as per the host clock frequency as specified in the DLL Hardware Reference Guide. Signed-off-by:
-
Veerabhadrarao Badiganti authored
With SDCC v5.1.0, additional setting needed for enabling DLL output. The dll-user-control register need to be configured during dll initialization for getting proper dll output. Without this configuration, we don't get the DLL lock status properly. Also update the DLL register settings according to the SDCC Hardware Programming Guide. Signed-off-by:
-
Sarthak Garg authored
Add information regarding DLL register properties for getting board specific configurations. These DLL register settings may vary from board to board. Signed-off-by:
-
Sarthak Garg authored
Add new compatible string for sm8250 target. Signed-off-by:
-
Sowjanya Komatineni authored
When auto calibration timeouts, calibration is disabled and fail-safe drive strength values are programmed based on the signal voltage. Different fail-safe drive strength values based on voltage are applicable only for SoCs supporting 3V3 and 1V8 pad controls. So, this patch avoids reading these properties from the device tree for SoCs not using pad controls and the warning of missing properties will not show up on these SoC platforms. Signed-off-by:
Sowjanya Komatineni <skomatineni@nvidia.com> Tested-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Wolfram Sang authored
The SDHI driver en-/disabled its main clock on its own, e.g. during probe() and remove(). Now, we leave all handling to RPM. clk_summary before: sd0 1 1 0 12480000 0 0 50000 sdif0 2 2 0 12480000 0 0 50000 clk_summary after: sd0 1 1 0 12480000 0 0 50000 sdif0 1 1 0 12480000 0 0 50000 Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20200519164251.5430-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Ulf Hansson authored
If the tmio device is attached to a genpd (PM domain), that genpd may have ->start|stop() callback assigned to it. To make sure the device is accessible during ->probe(), genpd's ->start() callback must be invoked, which is currently managed by tmio_mmc_host_probe(). However, it's likely that may be too late for some cases, as registers may be read and written way before that point. To fix the behaviour, let's move the call to dev_pm_domain_start() from tmio_mmc_host_probe() into those clients that needs it. From discussions at linux-mmc mailing list, it turned out that it should be sufficient to do this for the SDHI renesas variants, hence the call is move to renesas_sdhi_probe(). Signed-off-by:
-
Ulf Hansson authored
Before calling tmio_mmc_host_probe(), the caller is required to enable clocks for its device, as to make it accessible when reading/writing registers during probe. Therefore, the responsibility to disable these clocks, in the error path of ->probe() and during ->remove(), is better managed outside tmio_mmc_host_remove(). As a matter of fact, callers of tmio_mmc_host_remove() already expects this to be the behaviour. However, there's a problem with tmio_mmc_host_remove() when the Kconfig option, CONFIG_PM, is set. More precisely, tmio_mmc_host_remove() may then disable the clock via runtime PM, which leads to clock enable/disable imbalance problems, when the caller of tmio_mmc_host_remove() also tries to disable the same clocks. To solve the problem, let's make sure tmio_mmc_host_remove() leaves the device with clocks enabled, but also make sure to disable the IRQs, as we normally do at ->runtime_suspend(). Reported-by:
-
Angelo Dureghello authored
Since actively working on Freescale ColdFire M5441X, adding myself as a maintainer of this driver. Signed-off-by:
-
Angelo Dureghello authored
This driver has been developed as a separate module starting from the similar sdhci-esdhc-imx.c. Reasons for a separate sdchi-esdhc-mcf driver: - m68K architecture does not support devicetrees, so modifying sdhci-of-esdhc.c that is devicetree-related adding platform data seems not appropriate, - clock-related part, has to be implemented specifically for mcf5441x family (see esdhc_mcf_pltfm_set_clock()), - this is a big endian cpu accessing a big endian controller, but about sdma, this controller does not support hw swap, which needs to be handled with specific code, - some other minor differences but mainly to avoid risks on tweaking inside largely used imx driver. Adding just a small size ColdFire-specific driver, with benefits in a further less risky maintenance. Signed-off-by:
-
