- 17 Dec, 2018 40 commits
-
-
Faiz Abbas authored
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/SPRACA9Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Faiz Abbas authored
The driver fetches a thermal zone using the string "cpu_thermal" for tuning operation. Add a note for the same. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Intel BYT-based controllers do not have a LED signal line. Nevertheless sdhci_led_control() takes more than twice as long as sdhci_send_command(), even though it does nothing. Use the new SDHCI_QUIRK_NO_LED quirk to disable LED control for Intel BYT-based controllers. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Intel BYT-based controllers do not have a LED signal line. Nevertheless sdhci_led_control() takes more than twice as long as sdhci_send_command(), even though it does nothing. Use the new SDHCI_QUIRK_NO_LED quirk to disable LED control for Intel BYT-based controllers. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Host controllers may not have a LED signal line, whereas the register updates to control the non-existent LED can be relatively time consuming. Add a quirk to disable LED control. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ludovic Barre authored
On cmd12 (STOP_TRANSMISSION), STM32 sdmmc variant needs to set cmdstop bit in command register. The CPSM ("Command Path State Machine") treats the command as a Stop Transmission command and signals abort to the DPSM ("Data Path State Machine"). Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Colin Ian King authored
There are spelling mistakes in a couple of dev_dbg messages, fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Jerome Brunet authored
With some eMMC devices, there is still issues with the new phase settings. Enabling signal resampling seems to solve the problem for these. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Jerome Brunet authored
Align the default Core and Tx phase with the SoC vendor tree. Even if the Tx phase is different from what the documentation recommends, it seems to provide better results. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Jerome Brunet authored
The spinlock is only used within the irq handler so it does not seem very useful. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Jerome Brunet authored
On errors, if we don't stop the descriptor chain, it may continue to run and raise IRQ after we have called mmc_request_done(). This is bad because we won't be able to get cmd anymore and properly deal with the IRQ. This patch makes sure the descriptor chain is stopped before calling mmc_request_done() Fixes: 79ed05e3 ("mmc: meson-gx: add support for descriptor chain mode") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Faiz Abbas authored
The host controllers on TI's AM654 SOCs are not compatible with the phy and consumer model of the sdhci-of-arasan driver. It turns out that for optimal operation at higher speeds, a special tuning procedure needs to be implemented which involves configuration of platform specific phy registers. Therefore, branch out to a new sdhci_am654 driver and add the phy register space with all phy configurations to it. Populate AM654 specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever applicable. Only add support for upto High Speed for SD card and upto DDR52 speed mode for eMMC. Higher speeds will be added in subsequent patches. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Faiz Abbas authored
Commit 26a4f38d ("dt-bindings: mmc: sdhci-of-arasan: Add new compatible for AM654 MMC PHY") added a new compatible for supporting controllers on TI's AM65x SOCs. It turns out that the controller is not compatible with the arasan driver's phy and consumer model as it requires some phy registers for core sdhci functionality. This calls for the binding to branch out to a new driver. Therefore, add a deprecated message for the ti,am654-sdhci-5.1 binding. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Faiz Abbas authored
Add binding documentation for mmc host controllers present on TI's AM654 SOCs. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Arnd Bergmann authored
The newly added sdhci_msm_restore_sdr_dll_config() function is only called if CONFIG_PM is enabled: drivers/mmc/host/sdhci-msm.c:1050:12: error: 'sdhci_msm_restore_sdr_dll_config' defined but not used [-Werror=unused-function] Better remove the incorrect #ifdef altogether and just use __maybe_unused, which is harder to get wrong. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Always check the wait condition before returning timeout. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Zhoujie Wu <zjwu@marvell.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Always check the wait condition before returning timeout. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Always check the wait condition before returning timeout. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/mmc/host/alcor.c: In function 'alcor_data_set_dma': drivers/mmc/host/alcor.c:124:12: warning: variable 'len' set but not used [-Wunused-but-set-variable] drivers/mmc/host/alcor.c:648:15: warning: variable 'clock_out' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Linus Walleij authored
I managed to put the ifdef/else statements wrong when registering the GPIO descriptor table for MMC CD/WP. Fixing it up! Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Fixes: babd0b238d11 ("mmc: host: tmio: Use GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Colin Ian King authored
There is a spelling mistake in a pr_warn message, fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kai-Heng Feng authored
In order to let host's parent device, rtsx_usb, to use USB remote wake up signaling to do card detection, it needs to be suspended. Hence it's necessary to add runtime PM support for the memstick host. To keep memstick host stays suspended when it's not in use, convert the card detection function from kthread to delayed_work, which can be scheduled when the host is resumed and can be canceled when the host is suspended. Put the device to suspend when there's no card and the power mode is MEMSTICK_POWER_OFF. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kai-Heng Feng authored
Use ms_dev() helper for consistency. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kai-Heng Feng authored
We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put} helpers to let memstick host support runtime pm. The rpm count may go down to zero before the memstick host powers on, so the host can be runtime suspended. So before doing card detection, increment the rpm count to avoid the host gets runtime suspended. Balance the rpm count after card detection is done. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kai-Heng Feng authored
Although rtsx_usb doesn't support card removal detection, card insertion will resume rtsx_usb by USB remote wakeup signaling. When rtsx_usb gets resumed, also resumes its child devices, rtsx_usb_sdmmc and rtsx_usb_ms, to notify them there's a card in its slot. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Kai-Heng Feng authored
If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). Add missing pm_runtime_disable() for rtsx_usb_ms. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ulf Hansson authored
The rtsx USB parent device, has logic to detect when a card is inserted into the card slot. Although, the logic can't detect when a card is removed. This makes things a bit tricky, which is why the current method is simply to turn on MMC_CAP_NEEDS_POLL during probe. Using MMC_CAP_NEEDS_POLL means lots of energy being wasted, as the mmc host becomes runtime resumed frequently by the mmc core, while it polls for new cards being inserted. To address this problem, let's start relying on that the rtsx USB driver runtime resumes its child device, which is the rtsx_usb_sdmmc device, when it detects that a new card being inserted. This means dropping MMC_CAP_NEEDS_POLL from being set during probe. Instead let's implement a ->runtime_resume() callback to schedule a detect work and to set MMC_CAP_NEEDS_POLL. In this way, polling is enabled as long as there is card inserted, thus we can rely on the mmc core to detect also when the card becomes removed. Furthermore, to avoid polling forever after a card has been removed, let's implement a ->runtime_suspend() callback and make it clear MMC_CAP_NEEDS_POLL. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
-
Ulf Hansson authored
The current implementation uses the runtime PM autosuspend feature with a default timeout set to 50ms. This really doesn't makes sense, as it's a USB driven host device, which needs it rtsx USB device (parent device) to be runtime resumed to provide power to the card. In practise, using the autosuspend or any async runtime PM suspend method, means unnecessary delaying the host device and thus the parent, to be runtime suspended when a card is removed/powered off. For this reasons, let's simply drop the support for runtime PM autosuspend and tell the mmc core to use synced runtime PM suspend methods, via setting MMC_CAP_SYNC_RUNTIME_PM during probe. Moreover, as the mmc core nowadays deploys runtime PM reference counting of the mmc host device, convert ->set_ios() to use the more lightweight pm_runtime_get_noresume() and pm_runtime_put_noidle() APIs. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
-
Ulf Hansson authored
In case the card has been powered off, it seems silly to continue to allow the led to be updated. Instead let's forbid that, as it enables us to prevent runtime resuming the device and thus avoids wasting energy. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
-
Ulf Hansson authored
To allow mmc host drivers to inform the mmc core about rather using pm_runtime_put_sync_suspend() instead of pm_runtime_put_autosuspend(), let's introduce MMC_CAP_SYNC_RUNTIME_PM. This is especially useful for those mmc host drivers that don't benefit from using the runtime PM autosuspend feature. Typically this is those that relies on parent devices to power the card via runtime PM, like some USB host drivers for example. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
-
Loic Poulain authored
The Clock Data Recovery (CDR) circuit allows to automatically adjust the RX sampling-point/phase for high frequency cards (SDR104, HS200...). CDR is automatically enabled during DLL configuration. However, according to the APQ8016 reference manual, this function must be disabled during TX and tuning phase in order to prevent any interferences during tuning challenges and unexpected phase alteration during TX transfers. This patch enables/disables CDR according to the current transfer mode. This fixes sporadic write transfer issues observed with some SDR104 and HS200 cards. Inspired by sdhci-msm downstream patch: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/432516/Reported-by: Leonid Segal <leonid.s@variscite.com> Reported-by: Manabu Igusa <migusa@arrowjapan.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Oleksij Rempel authored
This driver provides support for Alcor Micro AU6601 and AU6621 SD/MMC controller. Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Oleksij Rempel authored
This driver provides support for Alcor Micro AU6601 and AU6621 card readers. This is single LUN HW and it is expected to work with following standards: - Support SDR104 / SDR50 - MultiMedia Card (MMC) - Memory Stick (MS) - Memory Stick PRO (MS_Pro) Since it is a PCIe controller, it should work on any architecture supporting PCIe. For now, it was developed and tested only on x86_64. This driver is a result of RE work and was created without any documentation or real knowledge of HW internals. Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
YueHaibing authored
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Joey Pabalinas <joeypabalinas@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Evan Green authored
In sdhci-msm-v5 and beyond, the MCI registers are removed, so there is only one register region required. Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
Add support for the mmc max-frequency device property for Intel BYT-based host controllers. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Linus Walleij authored
All host drivers are converted to look up GPIO descriptors from device tree, ACPI or machine descriptor tables, so now we can delete the legacy GPIO handling using hardcoded GPIO numbers from the kernel. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Linus Walleij authored
After converting the PXA driver to use GPIO descriptors for card detect and write protect it is relatively simple to convert it to also use a descriptor for getting the optional power control GPIO. The polarity inversion flag can also go away from the platform data since this is indicated in the GPIO machine descriptor table. Cc: Daniel Mack <daniel@zonque.org> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Linus Walleij authored
This deletes the code dealing with handling card detect and write protect passed in as platform data and makes the host rely on just GPIO descriptors. The card read only inversion flag has to be kept around for now, as the core cannot handle the inversion flags on the descriptors yet. Since we can now rely on the descriptors to have the right polarity, we set the "override_active_level" to false in mmc_gpiod_request_cd() and mmc_gpiod_request_ro(). Cc: Daniel Mack <daniel@zonque.org> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-