- 15 Mar, 2018 14 commits
-
-
tianshuliang authored
Hisilicon hi3798cv200 SoC extends the dw-mshc controller for additional clock control. Add device tree bindings for hi3798cv200-dw-mshc. Signed-off-by:
tianshuliang <tianshuliang@hisilicon.com> Signed-off-by:
Jiancheng Xue <xuejiancheng@hisilicon.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Harish Jenny K N authored
This patch exports RCA register to sysfs which will help in reading the disk identification information. Reviewed-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by:
-
Wolfram Sang authored
Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI which incorrectly disabled WP altogether instead of only disabling the internal mechanism. Since the whole WP handling has been reworked, we can simply disable this capability to re-enable WP GPIOs. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Markus Elfring authored
Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
John Keeping authored
Following up the device tree fixed in commits e78c6371 ("ARM: dts: rockchip: Fix DWMMC clocks") and ca9eee95 ("arm64: dts: rockchip: Fix DWMMC clocks", 2018-02-15), avoid confusion by using the correct property name in the debug output if clocks are not found. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
-
Shawn Lin authored
Variable err would be firstly initialized by the return value of mmc_sd_switch(). Signed-off-by:
-
Shawn Lin authored
Since we could move card->host->caps & MMC_CAP_4_BIT_DATA ahead of mmc_sdio_init_uhs_card, in mmc_host_uhs(). So there we could save this bit to check that. Also, if the process of sdio_enable_4bit_bus goes wrong, we should bails out early. Signed-off-by:
-
Shawn Lin authored
Per SD specification physical layer v4.0, section 3.9.4, it says "UHS-I supports only 4-bit mode. Host shall select 4-bit mode by ACMD6. However mmc_sd_init_uhs_card() still go ahead to initialize the cards anyway, whether card or host won't support 4-bit mode. This breaks the platforms which could support UHS-I mode but on some certain boards only support 1-bit mode with a UHS-I card inserted, as all the tuning process is broken due to this. Alternatively, we should check the return value from mmc_set_bus_width() to see if host could finish the request to switch the bus width on its side. But that needs more thing to do than this patch that just bails out early to try high speed mode if 4-bit mode isn't available for whatever reason. And this patch could also fix the same problem for sdio since R4_18V_PRESENT won't be set for ocr when mmc_sdio_init_card() finds mmc_host_uhs() is false. Note that this patch doesn't keep the checking of card->scr.sda_spec3 and comparing card->scr.bus_widths with SD_SCR_BUS_WIDTH_4 within mmc_sd_init_uhs_card() since if the sd cards response with SD_ROCR_S18A, it definitely supports UHS-I mode, which implicitly means these checkings are always true. Signed-off-by:
-
Jaehoon Chung authored
Since 'num-slots' had already deprecated, remove the property in device-tree file. Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Jaehoon Chung authored
Since 'num-slots' had already deprecated, remove the property in device-tree file. Signed-off-by:
-
Jaehoon Chung authored
Since 'num-slots' had already deprecated, remove the property in device-tree file. Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
Jaehoon Chung authored
Since 'num-slots' had already deprecated, remove the property in device-tree file. Signed-off-by:
-
Jaehoon Chung authored
'num-slots' property had already deprecated. Remove the 'nom-slots' property that is kept to maintain the compatibility. Signed-off-by:
-
Jaehoon Chung authored
'clock-freq-min-max' property had already deprecated. Remove the 'clock-freq-min-max' property that is kept to maintain the compatibility. Signed-off-by:
-
- 05 Mar, 2018 26 commits
-
-
Ulf Hansson authored
-
Sean Wang authored
Just applying the existing logic and adding its own characteristics into the space pointed by an extra entry of struct of_device_id to have support of MT7622 SoC. Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Tested-by:
Jumin Li <jumin.li@mediatek.com> Signed-off-by:
-
Sean Wang authored
Add the devicetree binding for MT7622 SoC Signed-off-by:
-
Adrian Hunter authored
Commit 03dbaa04 ("mmc: slot-gpio: Add support to enable irq wake on cd_irq") enabled wakeup at initialization. However, users also want to control it from sysfs power/wakeup attribute. That means the driver needs to check the PM flags before enabling it in the suspend callback. Add support for that in sdhci-pci, which is the only driver presently using the MMC_CAP_CD_WAKE flag, and remove the enabling in mmc_gpiod_request_cd_irq() Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Adrian Hunter authored
Commit 03dbaa04 ("mmc: slot-gpio: Add support to enable irq wake on cd_irq") enabled wakeup at initialization. However drivers may wish to enable and disable based on different criteria. Add a helper function mmc_gpio_set_cd_wake() to make it easy for drivers to do that. Signed-off-by:
-
Adrian Hunter authored
Do not enable wakeup for SDIO card interrupt unless the SDIO function driver has requested it which is indicated by mmc_card_wake_sdio_irq(). Signed-off-by:
-
Adrian Hunter authored
Do not unnecessarily enable card detect wakeup in the cases that the card is not removable or a GPIO is used for card detect. Signed-off-by:
-
Adrian Hunter authored
Now that tuning no longer leaves the Buffer Read Enable bit set (refer intel_execute_tuning()), glk_cqe_enable() is no longer needed. Get rid of it. Signed-off-by:
-
Shawn Lin authored
Not sure why it was there in the first place, but it's obviously useless check, so let's remove it. Signed-off-by:
-
Alexey Roslyakov authored
cur_slot and num_slots has been removed from struct dw_mci in 42f989c0. Unfortunately, inline documentation was not updated so far. Fix @lock field documentation in Locking section. Move @mrq field of struct dw_mci_slot mention closer to it description, so no one could miss this slightest detail. Couple of code style fixes as a bonus. Signed-off-by:
Alexey Roslyakov <alexey.roslyakov@gmail.com> Reviewed-by:
-
Shawn Lin authored
Clang reports a compile warning: drivers/mmc/host/dw_mmc.c:2124:5: warning: Value stored to 'prev_state' is never read By checking the code, prev_state and state assignment for STATE_SENDING_CMD is indeed never used after jumping to unlock tag. So remove it. Signed-off-by:
-
Shawn Lin authored
Use the newly added macro to simply to the code. Signed-off-by:
-
Andy Shevchenko authored
...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Masahiro Yamada authored
TMIO_MASK_CMD is properly enabled in tmio_mmc_start_command(). We have no reason to set it up in tmio_mmc_host_probe(). (If we really wanted to set it in the probe, we would have to do likewise when resuming.) Even worse, the following code is extremely confusing: _host->sdcard_irq_mask &= ~irq_mask; The logic is opposite between "->sdcard_irq_mask" and "irq_mask". The intention is not clear at a glance. Signed-off-by:
-
Masahiro Yamada authored
Currently, force_pio is cleared when the driver exits. Then, it resulted in clearing it in multiple places since MMC drivers in general have multiple exit points. tmio_mmc_reset_work - bails out on timeout tmio_process_mrq - error out when it cannot send a command tmio_mmc_finish_request - successful exit This is error-prone since we may miss to cover all bail-out points. To simplify the code, the data structure should be initialized just before used since we have a single entrance. force_pio is only used for data transfer, so tmio_mmc_start_data() will be a suitable place to clear this flag. Signed-off-by:
-
Masahiro Yamada authored
As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ} are asserted for DMA mode as well as for PIO. I need to disable the those IRQs in dma_ops->start hook, otherwise the DMA transfer fails with the following error message: PIO IRQ in DMA mode! Renesas chips are the same cases since I see their dma_ops->start hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!). If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling should be entirely moved to the core. tmio_mmc_cmd_irq() will be a suitable place to disable them. The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd. /* Unmask the IRQs we want to know about */ if (!_host->chan_rx) irq_mask |= TMIO_MASK_READOP; if (!_host->chan_tx) irq_mask |= TMIO_MASK_WRITEOP; At this point, _host->{chan_rx,chan_tx} are _always_ NULL because tmio_mmc_request_dma() is called after this code. Consequently, TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not. Remove this pointless code. Signed-off-by: -
Masahiro Yamada authored
The TMIO mmc cannot detect the card insertion in native_hotplug mode if the driver is probed without a card inserted. The reason is obvious; all IRQs are disabled by tmio_mmc_host_probe(), as follows: tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL); The card event IRQs are first enabled by tmio_mmc_start_command() as follows: if (!host->native_hotplug) irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT); tmio_mmc_enable_mmc_irqs(host, irq_mask); If the driver is probed without a card, tmio_mmc_start_command() is never called in the first place. So, the card is never detected. The card event IRQs must be enabled in probe/resume functions. Signed-off-by: -
Masahiro Yamada authored
A card detect GPIO is set up only for platforms with "cd-gpios" DT property or TMIO_MMC_USE_GPIO_CD flag. However, the driver core always uses mmc_gpio_get_cd, which just fails with -ENOSYS if ctx->cd_gpio is unset. The bit 5 of the status register provides the current signal level of the CD line. Allow to use it if the GPIO is unused. Signed-off-by:
-
Evgeniy Didin authored
The commit 9d9491a7 ("mmc: dw_mmc: Fix the DTO timeout calculation") and commit 4c2357f5 ("mmc: dw_mmc: Fix the CTO timeout calculation") made changes, which cause multiply overflow for 32-bit systems. The broken timeout calculations leads to unexpected ETIMEDOUT errors and causes stacktrace splat (such as below) during normal data exchange with SD-card. | Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1 | - Info: Finished target initialization. | mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd | response 0x900, card status 0x0 DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so code gets compiled on all 32-bit platforms as opposed to usage of DIV_ROUND_UP when we may only compile stuff on a very few arches. Lets cast this multiply to u64 type to prevent the overflow. Fixes: 9d9491a7 ("mmc: dw_mmc: Fix the DTO timeout calculation") Fixes: 4c2357f5 ("mmc: dw_mmc: Fix the CTO timeout calculation") Tested-by:
Vineet Gupta <Vineet.Gupta1@synopsys.com> Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files Signed-off-by:
Evgeniy Didin <Evgeniy.Didin@synopsys.com> Cc: <stable@vger.kernel.org> # 4.14 Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Acked-by:
-
Masahiro Yamada authored
This property is equivalent to "disable-wp" defined in Documentation/devicetree/bindings/mmc/mmc.txt The TMIO MMC core calls mmc_of_parse(), and it sets MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present. We do not need a vendor-specific property to do the same thing. Let's remove the description from the dt-binding to prevent new boards from using it. I am keeping the driver code for existing DT files, but added comments that this is deprecated. Signed-off-by:
-
Masahiro Yamada authored
The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT. No platform defines this flag any more. Remove. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Reviewed-by:
-
Masahiro Yamada authored
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and "toshiba,mmc-wrprotect-disable" at the same time. I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe. Signed-off-by:
-
Masahiro Yamada authored
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. The flag is propagated as follows: tmio_mmc_data::capabilities2 -> mmc_host::caps2 Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves, so gpio_ro is obviously unused by legacy boards like this. So, this conversion should be safe. Signed-off-by: -
Masahiro Yamada authored
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. The flag is propagated as follows: renesas_sdhi_of_data::capabilities2 -> tmio_mmc_data::capabilities2 -> mmc_host::caps2 Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and TMIO_MMC_WRPROTECT_DISABLE at the same time. I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe. Signed-off-by: -
Stefan Wahren authored
According to the BCM2835 datasheet there are no preset value registers. This wasn't an issue before, because we didn't propagate 1.8V support. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Sergio Valverde authored
If the max_discard value is zero, the conditional branch that checks the trim capabilities will never update this value with max_trim. Change the condition statement to also check the max_discard value in order to avoid an unnecessary call to mmc_do_calc_max_discard. Signed-off-by:
Sergio Valverde <vlvrdv@gmail.com> Reviewed-by:
Shawn Lin <shawn.lin@rock-chip.com> Signed-off-by:
-
