- 08 10月, 2018 1 次提交
-
-
由 Michal Simek 提交于
When mmc-pwrseq property is passed mmc_pwrseq_alloc() can return -EPROBE_DEFER because driver for power sequence provider is not probed yet. Do not show error message when this situation happens. Signed-off-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 16 7月, 2018 1 次提交
-
-
由 Helmut Grohne 提交于
Some controllers immediately report SDHCI_CLOCK_INT_STABLE after enabling the clock even when the clock is not stable. When used in conjunction with older/slower cards, this can result in: mmc0: error -84 whilst initialising SD card When the stable reporting is known to be broken, we simply wait for the maximum stabilization period. Signed-off-by: NHelmut Grohne <h.grohne@intenta.de> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 02 5月, 2018 2 次提交
-
-
由 Wolfram Sang 提交于
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Phil Edworthy 提交于
On SD 2.00 cards we get lots of these messages: "mmc0: Got data interrupt 0x00000002 even though no data operation was in progress" By applying the SDHCI_QUIRK2_STOP_WITH_TC quirk, the messages no longer happen. A single card claiming to be SD 3.00 compliant also generates the interrupts, but since the card's manfacturing date is 2002 mar, it's unlikely to really be SD 3.00. This card is a 8GB SanDisk 'SU08G' 8.0 (SDHC class 4). This has been reported on Xilinx devices that also use the Arasan IP. See https://patchwork.kernel.org/patch/8062871/ This has been tested on the Renesas RZ/ND-DB board with the RZ/N1 SoC. The Arasan IP in this device is version 1.39a and uses a max SD clock of 50MHz and does not support DDR modes. Signed-off-by: NPhil Edworthy <phil.edworthy@renesas.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 16 1月, 2018 1 次提交
-
-
由 Shawn Lin 提交于
Add CQHCI initialization and implement CQHCI operations for Arasan SDHCI variant host, namely arasan,sdhci-5.1, which is used by Rockchip RK3399 platform. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 11 12月, 2017 1 次提交
-
-
由 Milan Stevanovic 提交于
The power register needs to have a valid voltage set even when the power supply is managed by an external regulator. Signed-off-by: NMilan Stevanovic <milan.o.stevanovic@gmail.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 30 8月, 2017 2 次提交
-
-
由 Julia Lawall 提交于
The sdhci_pltfm_data structure is only passed as the second argument of sdhci_pltfm_init, which is const, while the sdhci_ops structure is only stored in the ops field of a sdhci_pltfm_data structure, which is also const. Thus both kinds of structures can be const as well. Done with the help of Coccinelle. Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Acked-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Jean-Francois Dagenais 提交于
This increases consistency of the code across the sdhci family. Signed-off-by: NJean-Francois Dagenais <jeff.dagenais@gmail.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Tested-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 20 6月, 2017 1 次提交
-
-
由 Shubhrajyoti Datta 提交于
ret is signed however is printed as unsigned fix the same. If printed as a negative number the result is easier to read. No functional change. Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 25 4月, 2017 3 次提交
-
-
由 Shawn Lin 提交于
Currently the get_timeout_clock callback doesn't clearly have a statement that it needs the variant drivers to return the timeout clock rate in kHz if the SDHCI_TIMEOUT_CLK_UNIT isn't present, otherwise the variant drivers should return it in MHz. It's also very likely that further variant drivers which are going to use this callback will be confused by this situation. Given the fact that moderm sdhci variant hosts are very prone to get the timeout clock from common clock framework (actually the only three users did that), it's more natural to return the value in Hz and we make an explicit comment there. Then we put the unit conversion inside the sdhci core. Thus will improve the code and prevent further misuses. Reported-by: NAnssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
The spin lock is not necessary in set_ios. Anything that is racing with changes to the I/O state is already broken. The mmc core already provides synchronization via "claiming" the host. So remove spin_lock and friends from sdhci_set_ios and related callbacks. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>
-
由 Adrian Hunter 提交于
Devices might save and restore tuning values so that re-tuning might not be needed after a pm transition. Let drivers decide by pushing the mmc_retune_needed() logic down to them. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NLudovic Desroches <ludovic.desroches@microchip.com>
-
- 14 3月, 2017 1 次提交
-
-
由 Anssi Hannula 提交于
sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 << (13 + divisor)). However, the divisor is not some Arasan-specific value, but instead is just the Data Timeout Counter Value from the SDHCI Timeout Control Register. Applying it here like this is wrong as the sdhci driver already takes that value into account when calculating timeouts, and in fact it *sets* that register value based on how long a timeout is wanted. Additionally, sdhci core interprets the .get_timeout_clock callback return value as if it were read from hardware registers, i.e. the unit should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit. This bit is set at least on the tested Zynq-7000 SoC. With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in too high a timeout clock rate being reported, causing the core to use longer-than-needed timeouts. Additionally, on a partitioned MMC (therefore having erase_group_def bit set) mmc_calc_max_discard() disables discard support as it looks like controller does not support the long timeouts needed for that. Do not apply the extra divisor and return the timeout clock in the expected unit. Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR eMMC card. Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi> Fixes: e3ec3a3d ("mmc: arasan: Add driver for Arasan SDHCI") Cc: <stable@vger.kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 10 10月, 2016 2 次提交
-
-
由 Shawn Lin 提交于
Per the vendor's requirement, we shouldn't do any setting for 1.8V Signaling Enable, otherwise the interaction/behaviour between phy and controller will be undefined. Mostly it works fine if we do that, but we still see failures. Anyway, let's fix it to meet the vendor's requirement. The error log looks like: [ 93.405085] mmc1: unexpected status 0x800900 after switch [ 93.408474] mmc1: switch to bus width 1 failed [ 93.408482] mmc1: mmc_select_hs200 failed, error -110 [ 93.408492] mmc1: error -110 during resume (card was removed?) [ 93.408705] PM: resume of devices complete after 213.453 msecs Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wei Yongjun 提交于
Fixes the following sparse warning: drivers/mmc/host/sdhci-of-arasan.c:253:6: warning: symbol 'sdhci_arasan_reset' was not declared. Should it be static? Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Acked-by: NSören Brinkmann <soren.brinkmann@xilinx.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 27 9月, 2016 3 次提交
-
-
由 Zach Brown 提交于
The sdhci controller on xilinx zynq devices will not function unless the CD bit is provided. http://www.xilinx.com/support/answers/61064.html In cases where it is impossible to provide the CD bit in hardware, setting the controller to test mode and then setting inserted to true will get the controller to function without the CD bit. When the device has the property xlnx,fails-without-test-cd the driver changes the controller to test mode and sets test inserted to true to make the controller function. Signed-off-by: NZach Brown <zach.brown@ni.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
corecfg_clockmultiplier indicates clock multiplier value of programmable clock generator which should be the same value of SDHCI_CAPABILITIES_1. The default value of the register, corecfg_clockmultiplier, is 0x10. But actually it is a mistake by designer as our intention was to set it to be zero which means we don't support programmable clock generator. So we have to make it to be zero on bootloader which seems work fine until now. But now we find an issue that when deploying genpd support for it, the remove callback will trigger the genpd to poweroff the power domain for sdhci-of-arasan which manage the controller, phy and corecfg_* stuff. So when we do bind/unbind the driver, we have already reinit the controller and phy, but without doing that for corecfg_*. Regarding to only the corecfg_clockmultipler is wrong, let's fix it by explicitly marking it to be zero when probing. With this change, we could do bind/unbind successfully. Reported-by: NZiyuan Xu <xzy.xu@rock-chips.com> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Reviewed-by: NZiyuan Xu <xzy.xu@rock-chips.com> Tested-by: NZiyuan Xu <xzy.xu@rock-chips.com> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Douglas Anderson 提交于
PHY intended to be used with the Arasan SDHCI 5.1 controller has trouble turning on when the card clock is slow or off. Strangely these problems appear to show up consistently on some boards while other boards work fine, but on the boards where it shows up the problem reproduces 100% of the time and is quite consistent in its behavior. These problems can be fixed by always making sure that we power on the PHY (and turn on its DLL) when the card clock is faster than about 50 MHz. Once on, we need to make sure that we never power down the PHY / turn off its DLL until the clock is faster again. We'll add logic for handling this into the sdhci-of-arasan driver. Note that right now the only user of a PHY in the sdhci-of-arasan driver is arasan,sdhci-5.1. It's presumed that all arasan,sdhci-5.1 PHY implementations need this workaround, so the logic is only contingent on having a PHY to control. If future Arasan controllers don't have this problem we can add code to decide if we want this flow or not. Also note that we check for slow clocks by checking for <= 400 kHz rather than checking for 50 MHz. This keeps things the most consistent and also means we can power the PHY on at max speed (where the DLL will lock fastest). Presumably anyone who intends to run with a card clock of < 50 MHz and > 400 kHz will be running on a device where this problem is fixed anyway. I believe this brings some resolution to the problems reported before. See the commit 6fc09244 ("mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes"). Signed-off-by: NDouglas Anderson <dianders@chromium.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 25 7月, 2016 5 次提交
-
-
由 Douglas Anderson 提交于
This reverts commit 4ac0d5f245e1 ("mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes"), resolving conflicts with other patches that have come after. It appears that on some boards / with some eMMC devices that the patch is causing problems. Presumably turning the phy off and on again at the wrong time while initially setting up the card is confusing the card, the host, or the PHY. We have lots of power cycles while initially setting up the card because the main sdhci driver often turns off the clock by clearing SDHCI_CLOCK_CARD_EN and then calls host->ops->set_clock() to set the clock again. With all of those, we ended up with lots of power cycles. Presumably the arguments made in the original patch still hold. That is, whenever the card clock is turned off and on again (or changed) we really should wait for the DLL to lock again. However, perhaps it's really not that critical for the lower speeds. It's possible that the right answer here is: * Whenever set_clock() is called we should double-check that the DLL is locked. * Whenever set_clock() is called and we're actually changing clocks we should do a power cycle around that. * When we're doing a power cycle just because the clock changed, we probably shouldn't do quite as many things (maybe don't need to recalibarate, etc). Unfortunately the interaction between SDHCI and the PHY is extremely limited because of the limited PHY API. The PHY does have a reference to the card clock and could theoretically register for notifications, except that our clock is query only (it uses CLK_GET_RATE_NOCACHE) and so can't really be notified about updates. I believe we would need a major redesign of clock handling in SDHCI core to do better than that, or we would need to make our one fake notifications. :( Let's hope that we can eventually get more information from Arasan on how all this should be handled before doing tons more work. Until then, let's get back to a known working state. Note that the rest of the patches in the 150 MHz series should still work fine even without this one. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Douglas Anderson 提交于
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the moment we register a CLK_GET_RATE_NOCACHE clock that simply allows querying the clock. This allows us to be less intrusive with regards to the main SDHCI driver, which has complex logic for adjusting the SD clock. Right now we always fully power cycle the PHY when the clock changes and that gives the PHY a good chance to query our clock. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Tested-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Douglas Anderson 提交于
In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399. >From [1] the corecfg_baseclkfreq is supposed to be set to: Base Clock Frequency for SD Clock. This is the frequency of the xin_clk. This is a relatively easy thing to do. Note that we assume that xin_clk is not dynamic and we can check the clock at probe time. If any real devices have a dynamic xin_clk future patches could register for notifiers for the clock. At the moment, setting corecfg_baseclkfreq is only supported for rk3399 since we need a specific map for each implementation. The code is written in a generic way that should make this easy to extend to other SoCs. Note that a specific compatible string for rk3399 is already in use and so we add that to the table to match rk3399. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdfSigned-off-by: NDouglas Anderson <dianders@chromium.org> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Tested-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Douglas Anderson 提交于
In commit 802ac39a ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for power cycling the PHY when the clock changes, one of the main reasons is that we need to give the DLL a chance to re-lock with the new clock. One of the things that the DLL is for is tuning the Receive Clock in HS200 mode and STRB in HS400 mode. Thus it is clear that we should make sure we power cycle the PHY (and wait for the DLL to lock) when we know we'll be in one of these two speed modes. That's what the original code did, though it used the clock rate rather than the speed mode. However, even in speed modes other than HS200,/HS400 the DLL is used for something since it can be clearly observed that the PHY doesn't function properly if you leave the DLL off. Although it appears less important to power cycle the PHY and wait for the DLL to lock when not in HS200/HS400 modes (no bugs were reported), it still seems wise to let the locking always happen nevertheless. Note: as part of this, we make sure that we never try to turn the PHY on when the clock is off (when the clock rate is 0). The PHY cannot work when the clock is off since its DLL can't lock. This change requires ("phy: rockchip-emmc: Increase lock time allowance") and will cause problems if picked without that change. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Tested-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
Currently sdhci-arasan 5.1 can support enhanced strobe function, and we now limit it just for "arasan,sdhci-5.1". Add mmc-hs400-enhanced-strobe in DT to enable the function if we're sure our controller can support it. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Reviewed-by: NDoug Anderson <dianders@chromium.org> Tested-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 04 5月, 2016 1 次提交
-
-
由 Shawn Lin 提交于
commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan") introduce phy support for arasan. According to the vendor's databook, we should make sure the phy is in poweroff status before we configure the clk stuff. Otherwise it may cause some IO sample timing issues from the test. And we don't need this extra operation while running in low performance mode since phy doesn't trigger sampling block. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 17 3月, 2016 3 次提交
-
-
由 Shawn Lin 提交于
This patch adds Generic PHY access for sdhci-of-arasan. Driver can get PHY handler from dt-binding, and power-on/init the PHY. Currently, it's just mandatory for arasan,sdhci-5.1. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
Currently, some err handling of sdhci_arasan_probe return directly without calling sdhci_pltfm_free. This patch fixes them. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Shawn Lin 提交于
We don't really need disable clk_ahb when failing to resume. Otherwise we may take risk of bus error for accessing register without clk_ahb. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 29 2月, 2016 3 次提交
-
-
由 Jisheng Zhang 提交于
Commit 0e748234 ("mmc: sdhci: Add size for caller in init+register") allows users of sdhci_pltfm to allocate private space in calls to sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the sdhci-of-arasan driver to this allocation. Signed-off-by: NJisheng Zhang <jszhang@marvell.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Jisheng Zhang 提交于
sdhci_pltfm_unregister() could operate host's registers, it will cause problems if the clk is already disabled and unprepared. Fix this issue by moving the clk_disable_unprepare() call to the end of remove function. Signed-off-by: NJisheng Zhang <jszhang@marvell.com> Acked-by: NSören Brinkmann <soren.brinkmann@xilinx.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Rameshwar Prasad Sahu 提交于
The Arason SD host controller supports set block count command (cmd23) and high speed mode. This patch re-enable both of these features that was disabled. For device that doesn't support high speed, it should configure its capability register accordingly instead disables it explicitly. Signed-off-by: NRameshwar Prasad Sahu <rsahu@apm.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 27 8月, 2015 1 次提交
-
-
由 Shawn Lin 提交于
This patch adds the compatible string in sdhci-of-arasan.c to support sdhci-arasan5.1 version of controller. No documented controller IP version is found in the TRM, so we use ths version of command queueing engine integrated into this controller by arasan to specify our controller. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Acked-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 17 8月, 2015 1 次提交
-
-
由 Suneel Garapati 提交于
adding SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,SDHCI_QUIRK2_PRESET_VALUE_BROKEN flags for arasan sdhc. Signed-off-by: NSuneel Garapati <suneel.garapati@xilinx.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 01 6月, 2015 1 次提交
-
-
由 Suman Tripathi 提交于
This patch adds the quirks and compatible string in sdhci-of-arasan.c to support sdhci-arasan4.9a version of controller. Signed-off-by: NSuman Tripathi <stripathi@apm.com> Reviewed-by: NMichal Simek <michal.simek@xilinx.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 08 4月, 2015 1 次提交
-
-
由 Michal Simek 提交于
Also check MMC OF properties. The controller supports MMC too. Signed-off-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 23 3月, 2015 1 次提交
-
-
由 Kevin Hao 提交于
So we can avoid to sprinkle the clk_disable_unprepare() in many drivers. Signed-off-by: NKevin Hao <haokexin@gmail.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 10 11月, 2014 2 次提交
-
-
由 Mike Looijmans 提交于
sdhci_add_host and sdhci_platfm_init already report failure, so don't emit error messages when a failure occurs. This prevents occurences of "deferred" messages when required power supplies are not ready for operation yet. Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Mike Looijmans 提交于
"ret" is a signed int, so use "%d" in format strings instead of "%u". This prevents cryptic codes in error messages like this: sdhci-arasan e0101000.sdhci: platform register failed (4294966779) Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl> Reviewed-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 09 9月, 2014 1 次提交
-
-
由 Peter Griffin 提交于
This patch removes the superflous .owner field for drivers which use the module_platform_driver API, as this is overriden in platform_driver_register anyway. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 22 5月, 2014 2 次提交
-
-
由 Russell King 提交于
Add sdhci_set_uhs_signaling() and always call the set_uhs_signaling method. This avoids quirks being added into sdhci_set_uhs_signaling(). Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> [Ulf Hansson] Resolved conflict Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-