- 27 Oct, 2015 2 commits
-
-
Chaotian Jing authored
Add 400Mhz clock source for HS400 mode Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Chaotian Jing authored
Sometime only need set MMC_CAP_HW_RESET for one of MMC hosts, So set it in device tree is better. Signed-off-by:
-
- 26 Oct, 2015 38 commits
-
-
Lokesh Vutla authored
Enable omap_hsmmc for Keystone 2 architecture which reuses the HSMMC IP found on OMAP platforms. Signed-off-by:
Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by:
-
Adrian Hunter authored
Add ACPI HIDs for Intel host controllers including one supporting HS400. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Adrian Hunter authored
Add PCI IDs for Intel host controllers Signed-off-by:
-
Shawn Lin authored
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Acked-by:
Joachim Eastwood <manabian@gmail.com> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Shawn Lin authored
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
Shawn Lin authored
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Shawn Lin authored
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Shawn Lin authored
DesignWare MMC Controller's transfer mode should be decided at runtime instead of compile-time. So we remove this config option and read dw_mmc's register to select DMA master. Signed-off-by:
Govindraj Raja <govindraj.raja@imgtec.com> Acked-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Shawn Lin authored
synopsys-dw-mshc supports three types of transfer mode. We add bindings and description for how to use them at runtime. Signed-off-by:
-
Shawn Lin authored
This patch add some macros for HCON register operations to make code more readable. Signed-off-by:
-
Shawn Lin authored
DesignWare MMC Controller can supports two types of DMA mode: external dma and internal dma. We get a RK312x platform integrated dw_mmc and ARM pl330 dma controller. This patch add edmac ops to support these platforms. I've tested it on RK31xx platform with edmac mode and RK3288 platform with idmac mode. Signed-off-by:
-
yangbo lu authored
The eSDHC doesn't have a standard power control register, so when writing this register in stack we should do nothing to avoid incorrect operation. Signed-off-by:
Yangbo Lu <yangbo.lu@freescale.com> Signed-off-by:
-
Sergei Shtylyov authored
Renesas R8A7794 SoC also has the MMCIF controller. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Sergei Shtylyov authored
The "compatible" property text contradicts even the example given in the MMCIF binding document itself; moreover, the Renesas MMCIF driver only matches on the generic "compatible" string and doesn't look for the SoC specific strings at all. Thus describe "renesas,sh-mmcif" as a fallback value. Fixes: b4c27763 ("mmc: sh_mmcif: Document DT bindings") Signed-off-by:
-
Sergei Shtylyov authored
There's little sense in releasing the host on mmc_add_card() error immediately after reclaiming it, so reclaim the host only in case of success. Signed-off-by:
-
Luis de Bethencourt authored
The driver depends on GOLDFISH but there isn't a build dependency so it's a good idea to allow the driver to always be built when the COMPILE_TEST option is enabled. That way, the driver can be built with a config generated by make allyesconfig and check if a patch would break the build. Signed-off-by:
Luis de Bethencourt <luisbg@osg.samsung.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Heiko Stuebner authored
This allows the tuning code to run and use higher speeds on capable cards. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Alexandru M Stan authored
The drive/sample clocks can be phase shifted. The drive clock could be used in a future patch to adjust hold times. The sample clock is used for tuning. Signed-off-by:
Alexandru M Stan <amstan@chromium.org> Signed-off-by:
-
Alexandru M Stan authored
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 authored
Add ciu_drive, ciu_sample clocks and default-sample-phase. This will later be used by tuning code. 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. Signed-off-by:
-
Douglas Anderson authored
We've introduced a new helper in the MMC core: mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new helper has some advantages: 1. We get the mmc_regulator_set_vqmmc() behavior of trying to match VQMMC and VMMC when the signal voltage is 3.3V. This ensures max compatibility. 2. We get rid of a few more warnings when probing unsupported voltages. 3. We get rid of some non-dw_mmc specific code in dw_mmc. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Douglas Anderson authored
This adds logic to the MMC core to set VQMMC. This is expected to be called by MMC drivers like dw_mmc as part of (or instead of) their start_signal_voltage_switch() callback. A few notes: * When setting the signal voltage to 3.3V we do our best to make VQMMC and VMMC match. It's been reported that this makes some old cards happy since they were tested back in the day before UHS when VQMMC and VMMC were provided by the same regulator. A nice side effect of this is that we don't end up on the hairy edge of VQMMC (2.7V), which some EEs claim is a little too close to the minimum for comfort. This is done in two steps. At first we try to find a VQMMC within a 0.3V tolerance of VMMC and if this is not supported by the supplying regulator we try to find a suitable voltage within the whole 2.7V-3.6V area of the spec. * The two step approach is currently necessary, as the used regulator_set_voltage_triplet(min, target, max) uses a simple implementation that just tries two basic steps: regulator_set_voltage(target, max); regulator_set_voltage(min, target); So with only one step with 2.7-3.6V borders, if a suitable voltage is a bit below VMMC, we would directly get the lowest 2.7V which some boards (like Rockchips) don't like at all. * When setting the signal voltage to 1.8V or 1.2V we aim for that specific voltage instead of picking the lowest one in the range. * We very purposely don't print errors in mmc_regulator_set_vqmmc(). There are cases where the MMC core will try several different voltages and we don't want to pollute the logs. Signed-off-by:
-
Heiko Stuebner authored
We will shortly need the calculation of an ocr-bit to the actual voltage in a second place too, so move it from mmc_regulator_set_ocr to a common function mmc_ocrbitnum_to_vdd to make that possible. Signed-off-by:
-
Ulf Hansson authored
MMC_CLKGATE was once invented to save power by gating the bus clock at request inactivity. At that time it served its purpose. The modern way to deal with power saving for these scenarios, is by using runtime PM. Nowadays, several host drivers have deployed runtime PM, but for those that haven't and which still cares power saving at request inactivity, it's certainly time to deploy runtime PM as it has been around for several years now. To simplify code to mmc core and thus decrease maintenance efforts, this patch removes all code related to MMC_CLKGATE. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
yangbo lu authored
Signed-off-by:
-
yangbo lu authored
Freescale eSDHC driver now supports both little-endian and big-endian mode eSDHC IPs for ARM and PPC. So, MMC_SDHCI_OF_ESDHC option needs to be reconfigured. Signed-off-by:
-
yangbo lu authored
To support little endian eSDHC controller, we redefine both BE and LE IO accessors. In the new accessors, use ioread*/iowrite* instead of in_be32/out_be32 and will select accessors according to endian mode in probe function. Signed-off-by:
-
yangbo lu authored
Signed-off-by:
-
Adrian Hunter authored
Add another PCI ID for an Intel eMMC host controller. Signed-off-by:
-
Douglas Anderson authored
Let's use DIV_ROUND_CLOSEST for rounding, not just truncating division. This lets us get closer to the right rate. Before this: set_phase(86) delay_nums=26 reg[0xf000420c]=0x468 actual_degrees=83 set_phase(89) delay_nums=27 reg[0xf000420c]=0x46c actual_degrees=86 After this: set_phase(86) delay_nums=27 reg[0xf000420c]=0x46c actual_degrees=86 set_phase(89) delay_nums=28 reg[0xf000420c]=0x470 actual_degrees=90 Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Douglas Anderson authored
Because of the inexact nature of the extra MMC delay elements (it's not possible to keep the phase monotonic and to also make phases (mod 90) > 70), we previously only allowed phases (mod 90) of 22.5, 45, and 67.5. But it's not the end of the world if the MMC clock phase goes non-monotonic. At most we'll be 25 degrees off. It's way better to test more phases to look for bad ones than to be 25 degrees off, because in the case of MMC really the point is to find bad phases and get as far asway from the as possible. If we get to test extra phases by going slightly non-monotonic then that might be fine. Worst case we would end up at a phases that's slight differnt than the one we wanted, but at least we'd still be quite far away from the a bad phase. Signed-off-by:
-
kbuild test robot authored
drivers/mmc/host/sdhci-pci-core.c:447:1-4: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci CC: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Ben Hutchings authored
It has no external callers. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
sdhci-pci-o2micro.c contains no initialisation and its functions are only called from shdci-pci.c, so there is no reason for it to be a separate module, let alone or for it to always be built-in. - Rename sdhci-pci.c to sdhci-pci-core.c so that the sdhci-pci module can be built from multiple source files - Add sdhci-pci-o2micro.c to it - Remove redundant exports Signed-off-by:
-
Weijun Yang authored
According to hardware spec, validate DDR50 mode for SDXC. Signed-off-by:
Weijun Yang <york.yang@csr.com> Signed-off-by:
Barry Song <Baohua.Song@csr.com> Signed-off-by:
-
Weijun Yang authored
CMD19 tuning is also available for DDR50 mode. Signed-off-by:
-
Weijun Yang authored
As SD Specifications Part1 Physical Layer Specification Version 3.01 says, CMD19 tuning is available for unlocked cards in transfer state of 1.8V signaling mode. The small difference between v3.00 and 3.01 spec means that CMD19 tuning is also available for DDR50 mode. Signed-off-by:
-
Grant Grundler authored
MMC_IOC_CMD and MMC_IOC_MULTI_CMD ioctl() code currently bails on any eMMC errors. However, in case there is any resp[] data, we should attempt to copy resp[] back to user space. The user app can then determine which command(s) failed in the MMC_IOC_MULTI_CMD case AND/OR report better diagnostics in both cases. Gwendal Grignou provided the idea and it was previously implemented and tested on v3.18 ChromeOS kernel: https://chromium-review.googlesource.com/#/c/299956Signed-off-by:Grant Grundler <grundler@chromium.org> Reviewed-by:
Hyung Taek Ryoo <hryoo@nvidia.com> Reviewed-by:
Gwendal Grignou <gwendal@chromium.org> Tested-by:
David Riley <davidriley@chromium.org> Signed-off-by:
-
