- 21 Nov, 2019 2 commits
-
-
Wolfram Sang authored
This reverts commit 7a7dab23. We found out that there is still a race with RuntimePM. This can lead to a hang when accessing the eMMC in some situations. Revert this change until the RPM issue is fixed. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
- 20 Nov, 2019 12 commits
-
-
Manish Narani authored
Apart from taps set by auto tuning, ZynqMP platform has feature to set the tap values manually. Add support to set tap delay values in HW via ZynqMP SoC framework. Signed-off-by:
Manish Narani <manish.narani@xilinx.com> Signed-off-by:
-
Manish Narani authored
Add documentation for 'xlnx,zynqmp-8.9a' SDHCI controller and optional properties followed by example. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Manish Narani authored
Add tap delay nodes for setting SDIO Tap Delays on ZynqMP platform. Signed-off-by:
-
Manish Narani authored
Add support to read Clock Phase Delays from the DT and set it via clk_set_phase() API from clock framework. Some of the controllers might have their own handling of setting clock delays, for this keep the set_clk_delays as function pointer which can be assigned controller specific handling of the same. Signed-off-by:
-
Manish Narani authored
Add optional properties for mmc hosts which are used to set clk delays for different speed modes in the controller. Signed-off-by:
-
Manish Narani authored
There are some operations like setting the clock delays may need to have two clocks, one for output path and one for input path. Adding input path clock for some phys to use. Signed-off-by:
-
Manish Narani authored
Add documentation for an optional input clock which is essentially used in sampling the input data coming from the card. Signed-off-by:
-
Manish Narani authored
To improve the code readability, use two different structs, one for clock provider data and one for mmc platform data. Signed-off-by:
-
Fabio Estevam authored
The correct form is "did not become", so fix it accordingly. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Ivan Mikhaylov authored
Add read_l callback in sdhci_ops with flipping of SDHCI_CARD_PRESENT bit in case of inverted card detection signal. Signed-off-by:
Ivan Mikhaylov <i.mikhaylov@yadro.com> Reviewed-by:
Andrew Jeffery <andrew@aj.id.au> Acked-by:
-
Ivan Mikhaylov authored
Enable CONFIG_MMC_SDHCI_IO_ACCESSORS for the ASPEED MMC driver. The read_l callback is used for inverted card detection. Signed-off-by:
-
Faiz Abbas authored
Add Support for CQHCI (Command Queuing Host Controller Interface) for each of the host controllers present in TI's J721E devices. Add cqhci_ops and a .irq() callback to handle cqhci specific interrupts. Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Acked-by:
-
- 18 Nov, 2019 2 commits
-
-
Bradley Bolen authored
With large eMMC cards, it is possible to create general purpose partitions that are bigger than 4GB. The size member of the mmc_part struct is only an unsigned int which overflows for gp partitions larger than 4GB. Change this to a u64 to handle the overflow. Signed-off-by:
Bradley Bolen <bradleybolen@gmail.com> Signed-off-by:
-
Eugeniu Rosca authored
Isolated initially to renesas_sdhi_internal_dmac [1], Ulf suggested adding MMC_CAP_ERASE to the TMIO mmc core: On Fri, Nov 15, 2019 at 10:27:25AM +0100, Ulf Hansson wrote: -- snip -- This test and due to the discussions with Wolfram and you in this thread, I would actually suggest that you enable MMC_CAP_ERASE for all tmio variants, rather than just for this particular one. In other words, set the cap in tmio_mmc_host_probe() should be fine, as it seems none of the tmio variants supports HW busy detection at this point. -- snip -- Testing on R-Car H3ULCB-KF doesn't reveal any issues (v5.4-rc7): root@rcar-gen3:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 59.2G 0 disk <--- eMMC mmcblk0boot0 179:8 0 4M 1 disk mmcblk0boot1 179:16 0 4M 1 disk mmcblk1 179:24 0 30G 0 disk <--- SD card root@rcar-gen3:~# time blkdiscard /dev/mmcblk0 real 0m8.659s user 0m0.001s sys 0m1.920s root@rcar-gen3:~# time blkdiscard /dev/mmcblk1 real 0m1.176s user 0m0.001s sys 0m0.124s [1] https://lore.kernel.org/linux-renesas-soc/20191112134808.23546-1-erosca@de.adit-jv.com/ Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com> Originally-by:
Harish Jenny K N <harish_kandiga@mentor.com> Suggested-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by:
-
- 15 Nov, 2019 12 commits
-
-
H. Nikolaus Schaller authored
They are already included from mmc/sdio_ids.h and do not need a local definition. Fixes: 884f3860 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Acked-by:
Kalle Valo <kvalo@codeaurora.org> Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by:
-
H. Nikolaus Schaller authored
SDIO_VENDOR_ID_TI_WL1251 is now defined in mmc/sdio_ids.h separately from SDIO_VENDOR_ID_TI for wl1271. Fixes: 884f3860 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by:
-
H. Nikolaus Schaller authored
wl1251 and wl1271 have different vendor id and device id. So we need to handle both with sdio quirks. Fixes: 884f3860 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by:
-
H. Nikolaus Schaller authored
v4.11-rc1 did introduce a patch series that rearranged the sdio quirks into a header file. Unfortunately this did forget to handle SDIO_VENDOR_ID_TI differently between wl1251 and wl1271 with the result that although the wl1251 was found on the sdio bus, the firmware did not load any more and there was no interface registration. This patch defines separate constants to be used by sdio quirks and drivers. Fixes: 884f3860 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by:
-
H. Nikolaus Schaller authored
Now as we have removed the last user (pandora_wl1251_init_card) of this callback, we can remove it from the hsmmc code. Suggested-by:
-
H. Nikolaus Schaller authored
There is a new driver in drivers/mmc/host/omap_hsmmc.c configured by CONFIG_MMC_OMAP_HS and the last user was the pdata-quirks for pandora. Suggested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
H. Nikolaus Schaller authored
With a wl1251 child node of mmc3 in the device tree decoded in omap_hsmmc.c to handle special wl1251 initialization, we do no longer need to instantiate the mmc3 through pdata quirks. We also can remove the wlan regulator and reset/interrupt definitions and do them through device tree. Fixes: 81eef6ca ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by:
-
H. Nikolaus Schaller authored
This partly reverts the commit efdfeb07 ("regulator: fixed: Convert to use GPIO descriptor only"). We must remove this from mainline first, so that the following patch to remove the openpandora quirks for mmc3 and wl1251 cleanly applies to stable v4.9, v4.14, v4.19 where the above mentioned patch is not yet present. Since the code affected is removed (no pandora gpios in pdata-quirks and more), there will be no matching revert-of-the-revert. Signed-off-by:
-
H. Nikolaus Schaller authored
Pandora_wl1251_init_card was used to do special pdata based setup of the sdio mmc interface. This does no longer work with v4.7 and later. A fix requires a device tree based mmc3 setup. Therefore we move the special setup to omap_hsmmc.c instead of calling some pdata supplied init_card function. The new code checks for a DT child node compatible to wl1251 so it will not affect other MMC3 use cases. Generally, this code was and still is a hack and should be moved to mmc core to e.g. read such properties from optional DT child nodes. Fixes: 81eef6ca ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by:
-
H. Nikolaus Schaller authored
Since v4.7 the dma initialization requires that there is a device tree property for "rx" and "tx" channels which is not provided by the pdata-quirks initialization. By conversion of the mmc3 setup to device tree this will finally allows to remove the OpenPandora wlan specific omap3 data-quirks. Fixes: 81eef6ca ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by:
-
H. Nikolaus Schaller authored
We will have the wl1251 defined as a child node of the mmc interface and can read setup for gpios, interrupts and the ti,use-eeprom property from there instead of pdata to be provided by pdata-quirks. Fixes: 81eef6ca ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by:
-
H. Nikolaus Schaller authored
The standard method for sdio devices connected to an sdio interface is to define them as a child node like we can see with wlcore. Signed-off-by:
-
- 14 Nov, 2019 9 commits
-
-
Ulf Hansson authored
-
Peter Ujfalusi authored
dma_request_slave_channel_reason() is: dma_request_chan(dev, name) Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel_reason() is: dma_request_chan(dev, name) Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by:
-
Thierry Reding authored
According to the comment, board files used to specify 1 ms for the debounce time. gpiod_set_debounce() needs the debounce time to be specified in units of microseconds, so make sure to multiply the value by 1000. Note that, according to the git log, the board files actually did specify 1 us for bounce times, but that seems really low. Device tree bindings for this type of GPIO typically specify the debounce times in milliseconds, so setting this default value to 1 ms seems like it would be somewhat safer. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Pavel Machek <pavel@denx.de> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Peng Fan authored
Add imx8mq/m/n compatible string Signed-off-by:
Peng Fan <peng.fan@nxp.com> Acked-by:
-
Ulf Hansson authored
It have turned out that it's not a good idea to unconditionally do a power cycle and then to re-initialize the SDIO card, as currently done through mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple SDIO func drivers probed, who also shares the same SDIO card. To address these scenarios, one may be tempted to use a notification mechanism, as to allow the core to inform each of the probed func drivers, about an ongoing HW reset. However, supporting such an operation from the func driver point of view, may not be entirely trivial. Therefore, let's use a more simplistic approach to solve the problem, by instead forcing the card to be removed and re-detected, via scheduling a rescan-work. In this way, we can rely on existing infrastructure, as the func driver's ->remove() and ->probe() callbacks, becomes invoked to deal with the cleanup and the re-initialization. This solution may be considered as rather heavy, especially if a func driver doesn't share its card with other func drivers. To address this, let's keep the current immediate HW reset option as well, but run it only when there is one func driver probed for the card. Finally, to allow the caller of mmc_hw_reset(), to understand if the reset is being asynchronously managed from a scheduled work, it returns 1 (propagated from mmc_sdio_hw_reset()). If the HW reset is executed successfully and synchronously it returns 0, which maintains the existing behaviour. Reviewed-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
-
Ulf Hansson authored
Upfront in mmc_rescan() we use the host->rescan_entered flag, to allow scanning only once for non-removable cards. Therefore, it's also not possible that we can have a corresponding card bus attached (host->bus_ops is NULL), when we are scanning non-removable cards. For this reason, let' drop the check for mmc_card_is_removable() as it's redundant. Reviewed-by:
-
Ulf Hansson authored
The SDIO HW reset procedure in mwifiex_sdio_card_reset_work() is broken, when the SDIO card is shared with another SDIO func driver. This is the case when the Bluetooth btmrvl driver is being used in combination with mwifiex. More precisely, when mwifiex_sdio_card_reset_work() runs to resets the SDIO card, the btmrvl driver doesn't get notified about it. Beyond that point, the btmrvl driver will fail to communicate with the SDIO card. This is a generic problem for SDIO func drivers sharing an SDIO card, which are about to be addressed in subsequent changes to the mmc core and the mmc_hw_reset() interface. In principle, these changes means the mmc_hw_reset() interface starts to return 1 if the are multiple drivers for the SDIO card, as to indicate to the caller that the reset needed to be scheduled asynchronously through a hotplug mechanism of the SDIO card. Let's prepare the mwifiex driver to support the upcoming new behaviour of mmc_hw_reset(), which means extending the mwifiex_sdio_card_reset_work() to support the asynchronous SDIO HW reset path. This also means, we need to allow the ->remove() callback to run, without waiting for the FW to be loaded. Additionally, during system suspend, mwifiex_sdio_suspend() may be called when a reset has been scheduled, but waiting to be executed. In this scenario let's simply return -EBUSY to abort the suspend process, as to allow the reset to be completed first. Reviewed-by:
-
Eugen Hristev authored
The quirks2 are parsed and set (e.g. from DT) before the quirk for broken HS200 is set in the driver. The driver needs to enable just this flag, not rewrite the whole quirk set. Fixes: 7871aa60 ("mmc: sdhci-of-at91: add quirk for broken HS200") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Acked-by:
-
- 13 Nov, 2019 3 commits
-
-
Ulf Hansson authored
Tony's email address from elandigitalsystems.com has bounced for a long time. Let's update MAINTAINERS to mark the driver as orphan as to reflect the situation. Signed-off-by: -
Ulf Hansson authored
The ->init_card() host ops is printing message to the log, without actually doing something useful. Let's just drop this code. Signed-off-by: -
Biju Das authored
This patch adds SDHI support for RZ/G2N (R8A774B1) SoC. Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
-
