- 17 Dec, 2018 40 commits
-
-
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 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 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:
-
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 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 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 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:
-
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:
-
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:
-
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:
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Signed-off-by:
-
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:
-
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:
-
Adrian Hunter authored
Add support for the mmc max-frequency device property for Intel BYT-based host controllers. Signed-off-by:
-
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 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:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
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 authored
This deletes the platform data passed for card detect and write protect from various PXA machines. Make sure to keep .gpio_card_ro_invert as this is still in use by some machines and needed to set the right flag to the MMC core (will be cleaned up later). 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 authored
This implements the code path for the PXAMCI hostso that it can retrieve GPIO descriptors rather than use the global GPIO numberspace for GPIO lines. If the GPIO descriptor is present, it will take precedence and get used in place of the platform data GPIO number. We move the code around a bit so we request the card detect first and the write protect second. We keep the code setting the host flag for the write protect polarity inversion semantics since the slot GPIO core needs to be refactored to deal with this before we can get rid of this. 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 authored
The Palm27x devices set up the MMC card detect and write protect lines with a special helper function. Augment this helper function to also accept an optional GPIO descriptor table and pass and register this for all the Palm27x devices in that family. 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> Acked-by:
-
Linus Walleij authored
This adds GPIO descriptor look-up tables for a whole bunch of PXA boards with MMC card detect (CD) and write protect (WP) GPIO lines, so we can move away from the hard-coded GPIO numberspace. In some cases the platforms were compulsively including the <linux/gpio.h> header even if they weren't actually using it, and in these cases I simply replaced that inclusion with the more appropriate <linux/gpio/machine.h> which is what board files should be including most of the time. 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 authored
Instead of using the name directly from the I2C client to name the gpio_chip, use dev_name() on the client->dev, so we get the sometimes more unique device name, as I2C has a mechanism for naming its devices explicitly in e.g. board data. This is a prerequisite for being able to reference uniquely any I2C GPIO expander defined in a board file when setting up GPIO descriptor tables. Reviewed-by:
-
Linus Walleij authored
Simplify things by making the S3CMCI driver just use slot GPIO with descriptors instead of passing around the global GPIO numbers that we want to get rid of. Getting the names of the GPIO chips into the machine descriptor tables was a bit of a challenge but I think I have them right. The platform data supports passing in inversion flags, but no platform is using them, and it is highly unlikely that we will add more, so drop them. The long term plan is to let the inversion flags on the GPIO machine descriptor do the job. The lines are flagged as GPIO_ACTIVE_[LOW|HIGH] as that is what they are, and 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: Jaehoon Chung <jh80.chung@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Sergio Prado <sergio.prado@e-labworks.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Linus Walleij authored
The TMIO MMC driver was passing global GPIO numbers around for card detect. It turns out only one single board in the kernel was actually making use of this feature so it is pretty easy to convert the driver to use only GPIO descriptors. The lines are flagged as GPIO_ACTIVE_[LOW|HIGH] as that is what they are, and 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(). Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Linus Walleij authored
Switch the SPI MMC driver to use GPIO descriptors internally and just look those up using the standard slot GPIO functions mmc_gpiod_request_cd() and mmc_gpiod_request_ro(). Make sure to request index 0 and 1 in accordance with the SPI MMC DT binding, and add the same GPIOs in machine descriptor tables on all boards that use SPI MMC in board files. The lines are flagged as GPIO_ACTIVE_[LOW|HIGH] as that is what they are, and 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: Hartley Sweeten <hsweeten@visionengravers.com> # Vision EP9307 Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by:
-
Nicholas Mc Guire authored
devm_kasprintf() may return NULL on failure of internal allocation thus the assignments to init.name are not safe if not checked. On error meson_mx_mmc_register_clks() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Yangbo Lu authored
This was a SoC issue on LX2160A Rev1.0. eSDHC_DLLCFG1[DLL_PD_PULSE_STRETCH_SEL] must be set to 0 to get 4 delay cells in the pulse width detection logic for eMMC HS400 mode. Otherwise it would cause unexpected HS400 issue. This patch is to clear this bit always for affected SoC when reset for all, since this bit doesn't affect other speed modes. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by:
-
Yangbo Lu authored
Currently only LX2160A eSDHC supports eMMC HS400. According to a large number of tests, eMMC HS400 failed to work at 150MHz, and for a few boards failed to work at 175MHz. But eMMC HS400 worked fine on 200MHz. We hadn't found the root cause but setting eSDHC_DLLCFG0[DLL_FREQ_SEL] = 0 using slow delay chain seemed to resovle this issue. Let's use this as fixup for now. Signed-off-by:
-
Yangbo Lu authored
There are timing violations in case of few division ratio options are selected for card clock frequency. prescaler*divisor options /3,/5,/6,/7,/9,/10,/11,/13,/14 and /15 are not available in LX2 Rev1.0. prescaler*divisor options /4,/8 and /12 only available in LX2 Rev1.0. Applicable only for HS400 mode. so by add the erratum A011334 support to limit the prescaler*divisor in LX2 REV1.0 Signed-off-by:
Yinbo Zhu <yinbo.zhu@nxp.com> Signed-off-by:
-
Yangbo Lu authored
1. Perform the Tuning Process at the HS400 target operating frequency. Latched the clock division value. 2. if read transaction, then set the SDTIMNGCTL[FLW_CTL_BG]. 3. Switch to High Speed mode and then set the card clock frequency to a value not greater than 52Mhz 4. Clear TBCTL[TB_EN],tuning block enable bit. 5. Change to 8 bit DDR Mode 6. Switch the card to HS400 mode. 7. Set TBCTL[TB_EN], tuning block enable bit. 8. Clear SYSCTL[SDCLKEN] 9. Wait for PRSSTAT[SDSTB] to be set 10. Change the clock division to latched value.Set TBCTL[HS 400 mode] and Set SDCLKCTL[CMD_CLK_CTRL] 11. Set SYSCTL[SDCLKEN] 12. Wait for PRSSTAT[SDSTB] to be set 13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL]. 14. Wait for delay chain to lock. 15. Set TBCTL[HS400_WNDW_ADJUST] 16. Again clear SYSCTL[SDCLKEN] 17. Wait for PRSSTAT[SDSTB] to be set 18. Set ESDHCCTL[FAF] 19. Wait for ESDHCCTL[FAF] to be cleared 20. Set SYSCTL[SDCLKEN] 21. Wait for PRSSTAT[SDSTB] to be set. Signed-off-by: -
Yinbo Zhu authored
Some eMMC controllers need specific settings for HS400 mode before the speed mode can be switched to DDR mode, during the HS400 initialization sequence. For that reason, let's introduce a new host callback, ->hs400_prepare_ddr() and invoked it just before switching to DDR mode. Signed-off-by:
-
Faiz Abbas authored
The sdhci_execute_tuning() function has assignment of private pointers multiple times. Remove the redundant assignment. Acked-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Acked-by:
-
Faiz Abbas authored
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:
-
Ezequiel Garcia authored
As reported by Aaro, the JZ4740 MMC driver throws a warning when the kernel is built without preemption (CONFIG_PREEMPT_NONE=y). [ 16.461094] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 567 host->next_data.cookie 568 [ 16.473120] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 568 host->next_data.cookie 569 [ 16.485144] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 569 host->next_data.cookie 570 [ 16.497170] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 570 host->next_data.cookie 571 The problem seems to be related to how pre_req/post_req is implemented. Currently, it seems the driver expects jz4740_mmc_prepare_dma_data() to be called with monotonically increasing host_cookie values, which is wrong. Moreover, the implementation is overly complicated, keeping track of unneeded "next cookie" state. So, instead of attempting to fix the current pre_req/post_req implementation, this commit refactors the driver, dropping the state, following other drivers such as dw_mmc and sdhci. Cc: Paul Cercueil <paul@crapouillou.net> Cc: Mathieu Malaterre <malat@debian.org> Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Tested-by:
-
Ludovic Barre authored
Refer to "4.15 set block count command" of sd specification: Host needs to issue CMD12 if any error is detected in the CMD18 and CMD25 operations. In sbc case, the data->stop is fill by framework. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Tested-by:
-
Wolfram Sang authored
If we use it this way, people should know about it. Also, replace true/false with nonzero/zero because the flag is not strictly a bool anymore. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Wolfram Sang authored
Some variants (namely Renesas SDHI) have bits in the STATS and IRQ_MASK registers which are 'always 1' and should be written as such. Introduce a seperate mask for this and apply it whenever such a register is written. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Niklas Söderlund authored
The Renesas BSP confirms that H3 ES1.x and M3-W ES1.[012] do not properly support HS400. Add a quirk to indicate this and disable HS400 in the MMC capabilities if the quirk is set. Signed-off-by:
-
Niklas Söderlund authored
It was though all ES revisions of H3 and M3-W SoCs required the TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us this is not true, only early ES revisions of the SoC do. Since quirk matching based on ES revisions is now used to handle the flag it's possible to align all Gen3 compatibility properties. This will allow later ES revisions of H3 and M3-W to use the correct 8-tap HS400 mode. Signed-off-by:
-
