- 28 May, 2020 40 commits
-
-
Jisheng Zhang authored
We need a different set_uhs_signaling implementation for MMC_TIMING_MMC_HS and MMC_TIMING_MMC_HS400. Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200513182602.3636a551@xhacker.debianSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Martin Blumenstingl authored
The SDHC MMC host controller on Amlogic SoCs provides an eMMC and MMC card interface with 1/4/8-bit bus width. It supports eMMC spec 4.4x/4.5x including HS200 (up to 100MHz clock). The public S805 datasheet [0] contains a short documentation about the registers. Unfortunately it does not describe how to use the registers to make the hardware work. Thus this driver is based on reading (and understanding) the Amlogic 3.10 GPL kernel code. Some hardware details are not easy to see. Jianxin Pan was kind enough to answer my questions: The hardware has built-in busy timeout support. The maximum timeout is 30 seconds. This is only documented in Amlogic's internal documentation. The controller only works with very specific clock configurations. The details are not part of the public datasheet. In my own words the supported configurations are: - 399.812kHz: clkin = 850MHz div = 2126 sd_rx_phase = 63 - 1MHz: clkin = 850MHz div = 850 sd_rx_phase = 55 - 5.986MHz: clkin = 850MHz div = 142 sd_rx_phase = 24 - 25MHz: clkin = 850MHz div = 34 sd_rx_phase = 15 - 47.222MHz: clkin = 850MHz div = 18 sd_rx_phase = 11/15 (SDR50/HS) - 53.125MHz: clkin = 850MHz div = 16 sd_rx_phase = (tuning) - 70.833MHz: clkin = 850MHz div = 12 sd_rx_phase = (tuning) - 85MHz: clkin = 850MHz div = 10 sd_rx_phase = (tuning) - 94.44MHz: clkin = 850MHz div = 9 sd_rx_phase = (tuning) - 106.25MHz: clkin = 850MHz div = 8 sd_rx_phase = (tuning) - 127.5MHz: clkin = 1275MHz div = 10 sd_rx_phase = (tuning) - 141.667MHz: clkin = 850MHz div = 6 sd_rx_phase = (tuning) - 159.375MHz: clkin = 1275MHz div = 8 sd_rx_phase = (tuning) - 212.5MHz: clkin = 1275MHz div = 6 sd_rx_phase = (tuning) - (sd_tx_phase is always 1, 94.44MHz is not listed in the datasheet but this is what the 3.10 BSP kernel on Odroid-C1 actually uses) NOTE: CMD23 support is disabled for now because it results in command timeouts and thus decreases read performance. Tested-by:
Wei Wang <lnykww@gmail.com> Tested-by:
Xin Yin <yinxin_1989@aliyun.com> Reviewed-by:
Anand Moon <linux.amoon@gmail.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200512204147.504087-3-martin.blumenstingl@googlemail.comSigned-off-by:
-
Martin Blumenstingl authored
This documents the devicetree bindings for the SDHC MMC host controller found in Meson6, Meson8, Meson8b and Meson8m2 SoCs. It can use a bus-width of 1/4/8-bit and it supports eMMC spec 4.4x/4.5x including HS200 mode (up to 100MHz clock). It embeds an internal clock controller which outputs four clocks (mod_clk, sd_clk, tx_clk and rx_clk) and is fed by four external input clocks (clkin[0-3]). "pclk" is the module register clock, it has to be enabled to access the registers. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200512204147.504087-2-martin.blumenstingl@googlemail.comSigned-off-by:
-
Jérôme Pouiller authored
The definitions of MMC_IOC_CMD and of MMC_IOC_MULTI_CMD rely on MMC_BLOCK_MAJOR: #define MMC_IOC_CMD _IOWR(MMC_BLOCK_MAJOR, 0, struct mmc_ioc_cmd) #define MMC_IOC_MULTI_CMD _IOWR(MMC_BLOCK_MAJOR, 1, struct mmc_ioc_multi_cmd) However, MMC_BLOCK_MAJOR is defined in linux/major.h and linux/mmc/ioctl.h did not include it. Signed-off-by:Jérôme Pouiller <jerome.pouiller@silabs.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200511161902.191405-1-Jerome.Pouiller@silabs.comSigned-off-by:
-
Masahiro Yamada authored
Use FIELD_GET and FIELD_PREP to get access to the register fields. Delete the shift macros and use GENMASK() for the touched macros. Note that, this has the side-effect of changing the constants to 64-bit on 64-bit platforms. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20200511062828.1791484-1-yamada.masahiro@socionext.comSigned-off-by:
-
Masahiro Yamada authored
Currently, tmio_mmc_irq() handler is registered before the host is fully initialized by tmio_mmc_host_probe(). I did not previously notice this problem. The boot ROM of a new Socionext SoC unmasks interrupts (CTL_IRQ_MASK) somehow. The handler is invoked before tmio_mmc_host_probe(), then emits noisy call trace. Move devm_request_irq() below tmio_mmc_host_probe(). Fixes: 3fd784f7 ("mmc: uniphier-sd: add UniPhier SD/eMMC controller driver") Signed-off-by:
-
Ben Chuang authored
GL9763E supports High Speed SDR, High Speed DDR, HS200, HS400, Enhanced Strobe in HS400 mode, 1/4/8 bits data bus and 3.3/1.8V. Signed-off-by:
Ben Chuang <ben.chuang@genesyslogic.com.tw> Link: https://lore.kernel.org/r/20200508064154.13473-1-benchuanggli@gmail.comSigned-off-by:
-
Ulf Hansson authored
The MMC_CAP_ERASE bit is no longer used by the mmc core as erase, discard and trim operations are now always supported. Therefore, drop the bit and move all mmc hosts away from using it. Signed-off-by:
Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20200508112902.23575-1-ulf.hansson@linaro.orgReviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
Ulf Hansson authored
Step by step, mmc host drivers and the mmc core have been improved in regards to support erase/discard/trim operations. We have now reached a point when it no longer seems reasonable to use an opt-in approach to enable the functionality. Therefore, let's switch to make the operations always supported. Signed-off-by:
-
Ulf Hansson authored
Using a fixed 1s polling timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Note that, even if the sdricoh_cs driver may currently not support HW busy detection on DAT0, some comments in the code refer to that the HW may support it. Therefore, it seems better to be proactive in this case. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Rather than to poll in a busy-loop, let's convert into using read_poll_timeout() and insert a small delay between each polling attempts. In particular, this avoids hogging the CPU. Additionally, to convert to read_poll_timeout() we also need to switch from using a specific number of polling attempts, into a specific timeout in us instead. The previous 100000 attempts, is translated into a total timeout of total 1s, as that seemed like reasonable value to pick. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Rather than to poll in a busy-loop, let's convert into using read_poll_timeout() and insert a small delay between each polling attempts. In particular, this avoids hogging the CPU. Additionally, to convert to read_poll_timeout() we also need to switch from using a specific number of polling attempts, into a specific timeout in us instead. The previous 100000 attempts, is translated into a total timeout of total 1s, as that seemed like reasonable value to pick. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 2s, like erase (CMD38) for example. Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192218.GA16315@embeddedorSigned-off-by:
-
Martin Blumenstingl authored
The vendor driver (from the 3.10 kernel) triggers a soft reset every time before starting a new command. While this fixes a problem where SDIO cards are not detected at all (because all commands simply timed out) this hurts SD card read performance a bit (in my tests between 10% to 20%). Trigger a soft reset after we got a CRC error or if the previous command timed out (just like the vendor driver from the same 3.10 kernel for the newer SDHC controller IP does). This fixes detection of SDIO cards and doesn't hurt SD card read performance at the same time. With this patch the initialization of an RTL8723BS SDIO card looks like this: req done (CMD52): -110: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 1 timing 0 starting CMD0 arg 00000000 flags 000000c0 req done (CMD0): 0: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 0 starting CMD8 arg 000001aa flags 000002f5 req done (CMD8): -110: 00000000 00000000 00000000 00000000 starting CMD5 arg 00000000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD5 arg 00200000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD3 arg 00000000 flags 00000075 req done (CMD3): 0: 00010000 00000000 00000000 00000000 starting CMD7 arg 00010000 flags 00000015 req done (CMD7): 0: 00001e00 00000000 00000000 00000000 starting CMD52 arg 00000000 flags 00000195 req done (CMD52): 0: 00001032 00000000 00000000 00000000 [... more CMD52 omitted ...] clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 starting CMD52 arg 00000e00 flags 00000195 req done (CMD52): 0: 00001000 00000000 00000000 00000000 starting CMD52 arg 80000e02 flags 00000195 req done (CMD52): 0: 00001002 00000000 00000000 00000000 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 4 timing 2 starting CMD52 arg 00020000 flags 00000195 req done (CMD52): 0: 00001007 00000000 00000000 00000000 [... more CMD52 omitted ...] new high speed SDIO card at address 0001 Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by:
Tobias Baumann <017623705678@o2online.de> Signed-off-by:
-
Lad Prabhakar authored
Add support for r8a7742 SoC. Renesas RZ/G1H (R8A7742) MMCIF is identical to the R-Car Gen2 family. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1588794695-27852-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Wolfram Sang authored
The 'pengutronix' address is defunct for years. Use the proper contact address. Signed-off-by:
Wolfram Sang <wsa@kernel.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200502142840.19418-1-wsa@kernel.orgSigned-off-by:
-
Krishna Konda authored
Following eMMC JEDEC JESD84-B51 standard, an enhanced form of rpmb is supported. What this enhanced mode supports is in addition to be able to write one rpmb or two rpmb frames at a time, 32 frames can be written at a time. Expose this information present in ext csd field so that the user space application that wants to make use of this can do so. Signed-off-by:
Krishna Konda <kkonda@codeaurora.org> Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1588341189-4371-1-git-send-email-vbadigan@codeaurora.orgSigned-off-by:
-
Ulf Hansson authored
According to the comment in mmc_sdio_reinit_card(), some SDIO cards may require a "[CMD5,5,3,7] init sequence", which isn't always obeyed in mmc_sdio_init_card(). Especially, when we end up retrying the UHS-I specific initialization, there is a missing CMD5. Let's update the code to make the behaviour consistent and let's also take the opportunity to clean up the code a bit, to avoid open coding. Signed-off-by:
-
Ulf Hansson authored
While initializing an SDIO card in mmc_sdio_init_card(), we may need to retry the UHS-I specific initialization, in case the first attempt fails. This leads to resending a CMD8, but also to restart from scratch with the so called OCR mask negotiations. This is unnecessary as we already have a negotiated OCR mask, so let's use that instead. In this way, the behaviour also becomes more consistent with other similar paths. Signed-off-by:
-
Ulf Hansson authored
Over the years, the code in mmc_sdio_init_card() has grown to become quite messy. Unfortunate this has also lead to that several paths are leaking memory in form of an allocated struct mmc_card, which includes additional data, such as initialized struct device for example. Unfortunate, it's a too complex task find each offending commit. Therefore, this change fixes all memory leaks at once. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ulf Hansson authored
During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I specific initialization, which leads to removal of the previously allocated card. A new card is then re-allocated while retrying. However, in one of the corresponding error paths we may end up to remove an already removed card, which likely leads to a NULL pointer exception. So, let's fix this. Fixes: 5fc3d80e ("mmc: sdio: don't use rocr to check if the card could support UHS mode") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Rajendra Nayak authored
Even though specifying OPP's in device tree is optional, ignoring all errors reported by dev_pm_opp_of_add_table() means we can't distinguish between a missing OPP table and a wrong/buggy OPP table. While missing OPP table (dev_pm_opp_of_add_table() returns a -ENODEV in such case) can be ignored, a wrong/buggy OPP table in device tree should make the driver error out. while we fix that, lets also fix the variable names for opp/opp_table to avoid confusion and name them opp_table/has_opp_table instead. Suggested-by:
Matthias Kaehlcke <matthias@chromium.org> Signed-off-by:
Rajendra Nayak <rnayak@codeaurora.org> Link: https://lore.kernel.org/r/1588080785-6812-10-git-send-email-rnayak@codeaurora.orgSigned-off-by:
-
Takeshi Saito authored
With R-Car Gen3, CRC error occue at the following TAPs. H3, M3W 1.3, M3N... TAP=2,3,6,7 M3W 3.0 ... TAP=1,3,5,7 (Note: for 4tap SoCs, the numbers get divided by 2) Do not use these TAPs in HS400, and also don't use auto correction but manual correction. We check for bad taps in two places: 1) After tuning HS400: Then, we select a neighbouring TAP. One of them must be good, because there are never three bad taps in a row. Retuning won't help because we just finished tuning. 2) After a manual correction request: Here, we can't switch to the requested TAP. But we can retune (if the HS200 tuning was good) because the environment might have changed since the last tuning. If not, we stay on the same TAP. Signed-off-by:
Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: refactored to match upstream driver, reworded commit msg] Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200423130432.9990-3-wsa+renesas@sang-engineering.comSigned-off-by:
-
Wolfram Sang authored
For ES1.2, add a comment explaining the situation. For ES1.3 (and later, although unlikely), add a new entry defining it as 4tap. Signed-off-by:
-
Ulf Hansson authored
Using a fixed 3s polling timeout for all commands with R1B responses is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38), may require longer timeouts than 3s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Clarify the use of r1b_timeout, by renaming it to MMC_SPI_R1B_TIMEOUT_MS and by dropping the corresponding confusing comment about it. Additionally, let's also add a new define, MMC_SPI_INIT_TIMEOUT_MS and use it during the initialization. Even if these two defines are given the same value, the split makes it easier to understand them. Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Using a fixed 1s timeout for all commands (and data transfers) is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Bruce Chang <brucechang@via.com.tw> Cc: Harald Welte <HaraldWelte@viatech.com> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 1s timeout used by tifm_sd. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 1s, like erase (CMD38) for example. Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
-
Ulf Hansson authored
The in-parameter timeout is always set to TRANSFER_TIMEOUT by the callers of sdricoh_query_status(), hence let's drop it. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Move MMC_APP_CMD specific handling to be managed by sdricoh_mmc_cmd(), as this makes the code a bit cleaner. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
For commands that doesn't involve to prepare a data transfer, owl-mmc is using a fixed 30s response timeout. This is a bit problematic. For some commands it means waiting longer than needed for the completion to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 30s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 5s timeout used by jz4740. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 5s, like erase (CMD38) for example. Cc: Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Zou Wei authored
Fix the following sparse warning: drivers/mmc/host/sdhci-pci-o2micro.c:497:6: warning: symbol 'sdhci_pci_o2_set_clock' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:512:5: warning: symbol 'sdhci_pci_o2_probe_slot' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:581:5: warning: symbol 'sdhci_pci_o2_probe' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:786:5: warning: symbol 'sdhci_pci_o2_resume' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Acked-by:
-
Zou Wei authored
Fixes coccicheck warning: drivers/mmc/core/debugfs.c:222:0-23: WARNING: mmc_clock_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for debugfs files Fixes: 703aae3d ("mmc: add a file to debugfs for changing host clock at runtime") Fixes: a04c50aa ("mmc: core: no need to check return value of debugfs_create functions") Reported-by:
-
Masahiro Yamada authored
If sdhci-of-at91.c is compiled without CONFIG_HAVE_CLK, the line caps1 |= FIELD_PREP(SDHCI_CLOCK_MUL_MASK, clk_mul); ... emits "FIELD_PREP: value too large for the field" warning. The compiler seems to decide clk_mul is constant (unsigned int)-1, because clk_get_rate() returns 0 when CONFIG_HAVE_CLK is disabled. Add HAVE_CLK to the depenency since this driver does not work without the clock APIs anyway. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by:
-
Wolfram Sang authored
After TAP refactorization, we can use 'unsigned int' for two more variables because all the calculations work on this type now. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200420170230.9091-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Ludovic Barre authored
This patch fix a power-on issue, and avoid to retry the power sequence. In power off sequence: sdmmc must set pwr_reg in "power-cycle" state (value 0x2), to prevent the card from being supplied through the signal lines (all the lines are driven low). In power on sequence: when the power is stable, sdmmc must set pwr_reg in "power-off" state (value 0x0) to drive all signal to high before to set "power-on". To avoid writing the same value to the power register several times, this register is cached by the pwr_reg variable. At probe pwr_reg is initialized to 0 by kzalloc of mmc_alloc_host. Like pwr_reg value is 0 at probing, the power on sequence fail because the "power-off" state is not writes (value 0x0) and the lines remain drive to low. This patch initializes "pwr_reg" variable with power register value. This it done in sdmmc variant init to not disturb default mmci behavior. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200420161831.5043-1-ludovic.barre@st.comSigned-off-by:
-
