- 04 May, 2016 8 commits
-
-
Peter Ujfalusi authored
With the new dma_request_chan() the client driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the driver can now support deferred probing against DMA. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Ulf Hansson <ulf.hansson@linaro.org> CC: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
CMD0 or hardware reset may invalidate the cache, so it needs to be flushed before reset. In the case of recovery, we can't expect flushing the cache to work always, but have a go and ignore errors. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Wolfram Sang authored
And return the old clock rate if something went wrong. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Wolfram Sang authored
We had a regression on r8a7740 where the SDHI clock was a generic peripheral clock, so changing its rate was not desired. This should be fixed in the clock driver. However, it also shows that the new clock calculation should only be used on tested systems. Add a check for that. Signed-off-by:
-
Wolfram Sang authored
RCar Gen2 and later implementations of TMIO/SDHI have their own set of features and additions. FAST_CLK_CHG is just one of them and I see a few others being added soon. Some may work on older chipsets but this needs to be tested case by case. Instead of adding a bunch of flags for each feature, add a global RCar2+ one for now. We can still break out features if the need arises. Signed-off-by:
-
Wolfram Sang authored
Save a few lines, the codebase is large enough. Signed-off-by:
-
Peter Ujfalusi authored
With the new dma_request_chan() the client driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the driver can now support deferred probing against DMA. Signed-off-by:
-
Ludovic Desroches authored
The controller claims to support SDR104. In fact, it only supports a degraded SDR104 since the maximum frequency of the SD clock is 120 MHz instead of 208 MHz. The sdhci core is unaware of it and will compute a wrong clock divider. We can deal with this specific case by using presets. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
-
- 02 May, 2016 32 commits
-
-
Lars Persson authored
Some boards need different pin drive strength for the UHS mode. Add an optional pinctrl setting with two pin states covering UHS speeds and other speeds. Signed-off-by:
Lars Persson <larper@axis.com> Signed-off-by:
-
Lars Persson authored
Add a start_signal_voltage_switch() operation to support enabling of UHS modes. Signed-off-by:
-
Lars Persson authored
The driver in its current form does not support UHS at all due to a missing start_signal_voltage_switch callback. Also when this callback is added we should let the device tree control UHS capabilities using the standard mmc bindings. Signed-off-by:
-
Lars Persson authored
Add a pinctrl binding to specify different pin settings for high speed modes and UHS modes. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Wolfram Sang authored
A few SH boards include the file but don't make use of it (no named interrupts). The SDHI code removed support for this feature as well. So, drop the references and ultimately remove the unneeded file. Signed-off-by:
Rich Felker <dalias@libc.org> Acked-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
-
Wolfram Sang authored
Now that reading CTL_STATUS is consistent, we can remove CTL_STATUS2 and document how this is handled internally. Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Wolfram Sang authored
This bit has a different meaning in SDHI and original TMIO. Document that and use the proper naming. Reviewed-by:
-
Wolfram Sang authored
To prevent confusion, use the virtual u32 CTL_STATUS in card_busy() the same way as in other parts of this driver. Reviewed-by:
-
Wolfram Sang authored
BIT() makes it easier to match the bits to the datasheet. This is especially important here, since some variants have different names in their datasheets (like with Renesas R-Car). Reviewed-by:
-
Wolfram Sang authored
Looking at the backlogs, I am not the only one who missed that the above functions do not read u32 from one register, but create a virtual u32 from reading to adjacent u16 registers (which depending on 'bus_shift' can be up to 8 byte apart). Because this driver supports old hardware for which we don't have documentation, I first wrongly assumed there was a variant which had a few u32 registers. Let's give the functions more descriptive names to make it more obvious what is happening. Reviewed-by:
-
Tony Lindgren authored
The legacy user space for n900 relies on the MMC slot names. Let's check if those are passed in pdata and use them. As this makes the DT booting compatible with legacy booting, we should be able to start dropping omap3 legacy booting support in v4.8. Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: linux-mmc@vger.kernel.org Signed-off-by:
Tony Lindgren <tony@atomide.com> Tested-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by:
-
Wolfram Sang authored
There is no support for this platform in the kernel anymore. Reported-by:
-
Wolfram Sang authored
There is no support for this platform in the kernel anymore. Make the Kconfig text more generic, so it won't get stale anymore. Reported-by:
-
Wolfram Sang authored
A last minute fix applied by Ulf made room for some simplification. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Wolfram Sang authored
There is no reason to have a public and private header file. Merge them into a private one, so looking up symbols is less confusing. Signed-off-by:
-
Wolfram Sang authored
Having just one irq handler again, let's include the 'card_status' function in the main handler which is way more readable. Drop a useless debug output while here. It should be a dev_dbg in case we ever need it again. Signed-off-by:
-
Wolfram Sang authored
We removed installation of separate handlers previously, so we can also remove the separate handlers. Signed-off-by:
-
Wolfram Sang authored
There is no user left in the kernel, so this code can be removed. (Legacy, non-DT sh_mobile boards have been removed a while ago.) The diff looks more complicated than it is: The if-block for multiplexed isr is now the main code path, the rest is removed. Signed-off-by:
-
Wolfram Sang authored
We won't access an index based array to get our DT config, but create separate structs instead. So, remove the array which only wastes memory. Signed-off-by:
-
Ulf Hansson authored
Instead of using an mmc specific implementation to deal with indexes through a BITMAP, let's convert to use the IDA library. Signed-off-by: -
Ulf Hansson authored
If the allocation of a new partition fails, let's make sure to also release the previously picked device index. Signed-off-by: -
Ulf Hansson authored
As IDA is more lightweight than IDR, let's convert to use that instead. Signed-off-by: -
Masahiro Yamada authored
defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) is equivalent to: IS_ENABLED(CONFIG_LEDS_CLASS) Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
-
Masahiro Yamada authored
defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ defined(CONFIG_MMC_SDHCI_MODULE)) is equivalent to: defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \ defined(MODULE)) and it can also be written shortly as: IS_REACHABLE(CONFIG_LEDS_CLASS) Signed-off-by: -
Adrian Hunter authored
SDHCI_SDR104_NEEDS_TUNING was originally named SDHCI_HS200_NEEDS_TUNING and was added in commit 069c9f14 ("mmc: host: Adds support for eMMC 4.5 HS200 mode"). That commit conflated SDHCI_SDR50_NEEDS_TUNING and SDHCI_HS200_NEEDS_TUNING due to what appears to be misplaced parentheses. Commit 156e14b1 ("mmc: sdhci: fix caps2 for HS200") made HS200 configuration equivalent to SDR104 configuration, renaming SDHCI_HS200_NEEDS_TUNING to SDHCI_SDR104_NEEDS_TUNING despite tuning for HS200 now being non-optional. The mix-up with SDHCI_SDR50_NEEDS_TUNING remained and became more obvious after commit 4b6f37d3 ("mmc: sdhci: clean up sdhci_execute_tuning() decision") where the author noted the patch was "reflecting what the original code was doing, it shows that it may not be what the author actually intended." The way the code is currently written, SDHCI_SDR104_NEEDS_TUNING causes tuning to be done always for SDR50 mode if SDR104 mode is also supported by the host controller. That makes no sense because we already have capabilities bit SDHCI_USE_SDR50_TUNING and corresponding flag SDHCI_SDR50_NEEDS_TUNING for that purpose. Given the dubious origins of SDHCI_SDR104_NEEDS_TUNING, it seems reasonable to remove it. The benefit being SDR50 mode will now not un-nessessarily do tuning. Signed-off-by:
-
Masahiro Yamada authored
Swap the call order of sdhci_alloc_host() and platform_get_irq(). It makes sdhci_alloc_host() the last function that can fail in the sdhci_pltfm_init(). So, we can drop the sdhci_free_host() call from the failure path. Signed-off-by:
-
Masahiro Yamada authored
Call devm_ioremap_resource() right after platform_get_resource(). This saves the error check of platform_get_resource() because devm_ioremap_resource() checks if the given resource is NULL. Signed-off-by:
-
Masahiro Yamada authored
The chain of devm_request_mem_region() and devm_ioremap() can be replaced with devm_ioremap_resource(). Also, we can drop the error messages because devm_ioremap_resource() displays similar messages on error. Signed-off-by:
-
Masahiro Yamada authored
Use the managed variant of ioremap(). Signed-off-by:
-
Masahiro Yamada authored
Use the managed variant of request_mem_region(). Signed-off-by:
-
Masahiro Yamada authored
The function platform_get_irq() can fail; it returns a negative error code on failure. A negative IRQ number will make sdhci_add_host() fail to request IRQ anyway, but it makes sense to let it fail earlier here. Signed-off-by:
-
Masahiro Yamada authored
The requirement resource_size >= 0x100 may not necessarily be reasonable; for example, sdhci-dove appears to sidestep some registers in sdhci_dove_readw(). Moreover, current code displays an error message for too small resource size, but still moves forward. Every DT should be responsible for describing its properties correctly, so lets's remove this error message from the common framework. Signed-off-by:
-
