#
3a1d0a8d |
|
27-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: dw_mmc: rockchip: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20230727070051.17778-41-frank.li@vivo.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
397605c2 |
|
10-Jun-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
mmc: dw_mmc: rockchip: Obviously always return success in remove callback dw_mci_pltfm_remove() returns 0 unconditionally and returning an error in a platform remove callback isn't very sensible. (The only effect of the latter is that the device core emits a generic warning and then removes the device anyhow.) So return 0 unconditionally to make it obvious there is no error forwarded to the upper layers. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220610211257.102071-3-u.kleine-koenig@pengutronix.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
52c92286 |
|
05-Mar-2022 |
Peter Geis <pgwipeout@gmail.com> |
mmc: dw-mmc-rockchip: Fix handling invalid clock rates The Rockchip rk356x ciu clock cannot be set as low as the dw-mmc hardware supports. This leads to a situation during card initialization where the clock is set lower than the clock driver can support. The dw-mmc-rockchip driver spews errors when this happens. For normal operation this only happens a few times during boot, but when cd-broken is enabled (in cases such as the SoQuartz module) this fires multiple times each poll cycle. Fix this by testing the lowest possible frequency that the clock driver can support which is within the mmc specification. Divide that rate by the internal divider and set f_min to this. Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20220305215835.2210388-3-pgwipeout@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
4bac670a |
|
24-Nov-2021 |
John Keeping <john@metanate.com> |
mmc: dw_mmc: rockchip: use common_caps The capabilities for all instances are the same, so use common_caps instead of caps/num_caps to remove the dependency on the mshcN device tree alias. Signed-off-by: John Keeping <john@metanate.com> Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Link: https://lore.kernel.org/r/20211124184603.3897245-4-john@metanate.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
df4e1372 |
|
15-Apr-2021 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: Just set default sample value for legacy mode .set_ios() is called from .resume() as well. For SDIO device which sets keep-power-in-suspend, nothing should be changed after resuming, as well as sample tuning value, since this value is tuned already. So we should not overwrite it with the default value. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://lore.kernel.org/r/1618539454-182170-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
21b2cec6 |
|
03-Sep-2020 |
Douglas Anderson <dianders@chromium.org> |
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4 This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous probe") but applied to a whole pile of drivers. This batch converts the drivers that appeared to be around in the v4.4 timeframe. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # SH_MMCIF Tested-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200903162412.1.Id501e96fa63224f77bb86b2135a5e8324ffb9c43@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
2874c5fd |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d39b1b2a |
|
05-Apr-2018 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc: fix misleading comment in dw_mci_rk3288_set_ios DDR52 with 8-bit mode should be handled in a different way when requesting ciu_clk. However DDR50 is used for SDMMC/SDIO and could never be possible with 8-bit mode. It's trival but misleading. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
e988867f |
|
01-Mar-2018 |
John Keeping <john@metanate.com> |
mmc: dw_mmc-rockchip: correct property names in debug Following up the device tree fixed in commits e78c637127ee ("ARM: dts: rockchip: Fix DWMMC clocks") and ca9eee95a2de ("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 <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
0d84b9e5 |
|
23-Feb-2018 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc: Fix out-of-bounds access for slot's caps Add num_caps field for dw_mci_drv_data to validate the controller id from DT alias and non-DT ways. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
1a12a70f |
|
16-May-2017 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: parse rockchip, desired-num-phases from DT Currently we unconditionally do tuning for each degree, which costs 900ms for each boot and resume. May someone argue that this is a question of accuracy VS time. But I would say it's a trick of how we need to do decision for our boards. If we don't care the time we spend at all, we could definitely do tuning for each degree. But when we need to improve the user experience, for instance, speed up resuming from S3, we should also have the right to do that. This patch add parsing "rockchip,desired-num-phases", for folks to specify the number of doing tuning. If not specified, 360 will be used as before. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
0f21c58c |
|
30-Dec-2016 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: dw_mmc: Remove the public dw_mmc header file There are currently no external users of the public dw_mmc header file, except the dw_mmc driver itself. Therefore let's move the definitions from the public dw_mmc header file into the existing private dw_mmc header file and then remove the public one. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1f5c51d7 |
|
11-Oct-2016 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc: disable biu clk if possible We could disable biu clk if gpio card detect available, or it is a non-removable device. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
f90142683 |
|
11-Oct-2016 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: add runtime PM support This patch adds runtime PM support for dw_mmc-rockchip. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
2c4c7146 |
|
14-Jul-2016 |
Jaehoon Chung <jh80.chung@samsung.com> |
mmc: dw_mmc: rockchip: unset the MMC_CAP_ERASE flag In dw_mmc.c, it's enabled by default. It doesn't need to set MMC_CAP_ERASE in rockchip anymore. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
16a34574 |
|
20-Jun-2016 |
Jaehoon Chung <jh80.chung@samsung.com> |
mmc: dw_mmc: remove the quirks flags Remove the quirks flag. (DW_MCI_QUIRK_BROKEN_DTO) For removing this, enabled the dto_timer by defaults. It doesn't see any I/O performance degression. In future, dwmmc controller should not use the quirks flag. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
d4aa908c |
|
12-May-2016 |
Douglas Anderson <dianders@chromium.org> |
mmc: dw_mmc: rockchip: Set the drive phase properly Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance where the power on default is wrong or where the firmware didn't configure this properly then we'll get a mysterious failure. In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") we actually started setting this explicitly in the kernel, but that commit wasn't quite right and also wasn't quite enough. See <https://patchwork.kernel.org/patch/9085311/> for some details. Let's explicitly set this phase in dw_mmc. The comments inside this patch try to explain the situation quite throughly, but the high level overview of this is: Before this patch on rk3288 devices tested (after revert of the clock patch described above): * eMMC: 180 degrees * SDMMC/SDIO0/SDIO1: 90 degrees After this patch: * Use 90 degree phase offset usually. * Use 180 degree phase offset for MMC_DDR52, SDR104, HS200. That means we are _changing_ behavior for those devices in this way: * If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90 degrees (vs 180) but otherwise have no change. * For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at 90 degrees (vs 180). It seems fairly unlikely that building modern hardware is using an eMMC that isn't using DDR52 or HS200, of course. * For SDR104 cards we'll now run with 180 degree phase offset (vs 90). It's expected that 90 degree phase offset would have worked OK, but this gives us extra margin. I have tested this by inserting my collection of uSD cards (mostly UHS, though a few not) into a veyron_minnie and confirmed that they still seem to enumerate properly. For a subset of them I tried putting a filesystem on them and also tried running mmc_test. Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
d57fe83e |
|
26-Apr-2016 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise failing to create rpmb partition. With it, we can get rpmb successfully: mmc1: new HS200 MMC card at address 0001 mmcblk0: mmc1:0001 DS2016 14.7 GiB mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
19756760 |
|
31-Mar-2016 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: remove setup_clock for rockchip We remove setup_clock hook and combine it into init hook to simplify the code Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
c6a9bf99 |
|
01-Mar-2016 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: fix failing to mount partition with "discard" Without MMC_CAP_ERASE support, we fail to mount partition with "discard" option since mmc_queue_setup_discard is limited for checking mmc_can_erase. Without doing mmc_queue_setup_discard, blk_queue_discard fails to test QUEUE_FLAG_DISCARD flag, so we get the following log from f2fs(actually similar to other file system): mounting with "discard" option, but the device does not support discard Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
31fa8353 |
|
02-Feb-2016 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: dw_mmc-rockchip: remove dw_mci_rockchip_pmops dw_mci_rockchip_pmops just copy-paste what dw_mci_pltfm_pmops have done. Let's remove it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
aaaaeb7a |
|
20-Jan-2016 |
Jaehoon Chung <jh80.chung@samsung.com> |
mmc: dw_mmc: remove the prepare_command hook This patch removes the prepare_command hook from entire dw_mmc driver. Now, almost all SoCs are using by default, except Exynos. It seems that dwmmc controller is using unnecessary hook. To know whether needs to set this bit or not, add the DW_MMC_CARD_NO_USE_HOLD bit. If some SoCs need to disable this in future, just set the DW_MMC_CARD_NO_USE_HOLD bit. set_bit(DW_MMC_CARD_NO_USE_HOLD, &slot->flags), Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
7b6471a9 |
|
05-Nov-2015 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Remove MMC_CAP_RUNTIME_RESUME as it's redundant Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
9979dbe5 |
|
27-Oct-2015 |
Chaotian Jing <chaotian.jing@mediatek.com> |
mmc: mmc: extend the mmc_send_tuning() The mmc_execute_tuning() has already prepared the opcode, there is no need to prepare it again at mmc_send_tuning(), and, there is a BUG of mmc_send_tuning() to determine the opcode by bus width, assume eMMC was running at HS200, 4bit mode, then the mmc_send_tuning() will overwrite the opcode from CMD21 to CMD19, then got error. in addition, extend an argument of "cmd_error" to allow getting if there was cmd error when tune response. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> [Ulf: Rebased patch] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
cbb79e43 |
|
12-Oct-2015 |
Alexandru M Stan <amstan@chromium.org> |
mmc: dw_mmc-rockchip: MMC tuning with the clock phase framework This algorithm will try 1 degree increments, since there's no way to tell what resolution the underlying phase code uses. As an added bonus, doing many tunings yields better results since some tests are run more than once (ex: if the underlying driver uses 45 degree increments, the tuning code will try the same angle more than once). It will then construct a list of good phase ranges (even ranges that cross 360/0), will pick the biggest range then it will set the sample_clk to the middle of that range. We do not touch ciu_drive (and by extension define default-drive-phase). Drive phase is mostly used to define minimum hold times, while one could write some code to determine what phase meets the minimum hold time (ex 10 degrees) this will not work with the current clock phase framework (which floors angles, so we'll get 0 deg, and there's no way to know what resolution the floors happen at). We assume that the default drive angles set by the hardware are good enough. If a device has device specific code (like exynos) then that will still take precedence, otherwise this new code will execute. If the device wants to tune, but has no sample_clk defined we'll return EIO with an error message. Signed-off-by: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
57e10486 |
|
10-Aug-2015 |
Addy Ke <addy.ke@rock-chips.com> |
mmc: dw_mmc: add quirk for broken data transfer over scheme This patch add a new quirk to add a s/w timer to notify the driver to terminate current transfer and report a data timeout to the core, if DTO interrupt does NOT come within the given time. dw_mmc call mmc_request_done func to finish transfer depends on DTO interrupt. If DTO interrupt does not come in sending data state, the current transfer will be blocked. We got the reply from synopsys: There are two counters but both use the same value of [31:8] bits. Data timeout counter doesn't wait for stop clock and you should get DRTO even when the clock is not stopped. Host Starvation timeout counter is triggered with stop clock condition. This means that host should get DRTO and DTO interrupt. But this case really exists, when driver reads tuning data from card on RK3288-pink2 board. I measured waveforms by oscilloscope and found that card clock was always on and data lines were always holded high level in sending data state. There are two possibility that data over interrupt doesn't come in reading data state on RK3X SoCs: - get command done interrupt, but doesn't get any data-related interrupt. - get data error interrupt, but doesn't get data over interrupt. Signed-off-by: Addy Ke <addy.ke@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
|
#
a7ca2b16 |
|
14-May-2015 |
Zhangfei Gao <zhangfei.gao@linaro.org> |
mmc: dw_mmc: rockchip: Fix modalias to make module auto-loading work Make the modalias match driver name, this is required to make module auto-loading work. Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> CC: Doug Anderson <dianders@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
6d53200b |
|
19-Feb-2015 |
addy ke <addy.ke@rock-chips.com> |
mmc: dw_mmc: rockchip: add support MMC_CAP_RUNTIME_RESUME capability To support HS200 and UHS mode, mmc core will call init_card() to execute tuning: - sdio: init_card can be executed at runtime resume. - sd and mmc: init_card can be executed at resume or runtime resume, which depends on MMC_CAP_RUNTIME_RESUME capability. On rk3288 SoC, host will get DRTO interrupt when host send command to read tuning data. This will spend more than 111ms: drto_ms = drto_clks * 1000 / bus_hz = 111ms. And the total tuning time will be more than 400ms. So we should add MMC_CAP_RUNTIME_RESUME capability to execute tuning at runtime resume. Only if we do so, can we pass resume test. Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Addy Ke <addy.ke@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
96083379 |
|
23-Jan-2015 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
mmc: dw_mmc: rockchip: remove incorrect __exit_p() dw_mci_pltfm_remove() is not (nor should it be) marked as __exit, so we should not be using __exit_p() wrapper with it. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
76756234 |
|
04-Nov-2014 |
Addy Ke <addy.ke@rock-chips.com> |
mmc: dw_mmc: add support for the other bit of sdio interrupt The bit of sdio interrupt is 16 in designware implementation, but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the number of slot0 in the SDIO interrupt registers. Signed-off-by: Addy Ke <addy.ke@rock-chips.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
e7791079 |
|
14-Oct-2014 |
Doug Anderson <dianders@chromium.org> |
mmc: dw_mmc: rockchip: Don't recalc the clock when it goes off The "set_ios" function is called with a clock of 0 when the clock is turning off. There's no reason to go through all the extra Rockchip logic (whose goal is to make sure DIV is 0 or 1) in that case. The Rockchip logic happened to work because the CCF will pick the lowest possible rate when you ask it for a clock of 0, but it's silly to go through all the remuxing and adjusting for no reason. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
4cdc2ec1 |
|
18-Aug-2014 |
addy ke <addy.ke@rock-chips.com> |
mmc: dw_mmc: move rockchip related code to a separate file To support HS200 and UHS-1, we need add a big hunk of code, as shown in the following patches. So a separate file for rockchip SOCs is suitable. Signed-off-by: Addy Ke <addy.ke@rock-chips.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|