After host requests RESET_FOR_ALL action, the hardware output an
interrupt for OS and waiting for the OS to approve.
Before writing this fix, ACPI GED has handled the interrupt. But
the ACPI GED belongs to a slow process, and sometimes the handling
process time is more than 100ms(Mutex wait more than 100ms). So
drop the GED solution and add this quirk fix.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The device specific resource can be free in free_slot after
removing host controller.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In tuning mode of operation, when TBCTL[TB_EN] is set, eSDHC may report
one of the following errors :
1)Tuning error while running tuning operation where SYSCTL2[SAMPCLKSEL]
will not get set even when SYSCTL2[EXTN] is reset. OR
2)Data transaction error (e.g. IRQSTAT[DCE], IRQSTAT[DEBE]) during data
transaction errors.
This issue occurs when the data window sampled within eSDHC is in full
cycle. So, in that case, eSDHC is not able to find out the start and
end points of the data window and sets the sampling pointer at default
location (which is middle of the internal SD clock). If this sampling
point coincides with the data eye boundary, then it can result in the
above mentioned errors. Impact: Tuning mode of operation for SDR50,
SDR104 or HS200 speed modes may not work properly
Workaround: In case eSDHC reports tuning error or data errors in tuning
mode of operation, by add the erratum A008171 support to fix the issue.
Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch is to add tuning error codes to
judge tuning state
Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Here is another TMIO MMC variant found in Socionext UniPhier SoCs.
As commit b6147490e6 ("mmc: tmio: split core functionality, DMA and
MFD glue") said, these MMC controllers use the IP from Panasonic.
However, the MMC controller in the TMIO (Toshiba Mobile IO) MFD chip
was the first upstreamed user of this IP. The common driver code
for this IP is now called 'tmio-mmc-core' in Linux although it is a
historical misnomer.
Anyway, this driver select's MMC_TMIO_CORE to borrow the common code
from tmio-mmc-core.c
Older UniPhier SoCs (LD4, Pro4, sLD8) support the external DMA engine
like renesas_sdhi_sys_dmac.c. The difference is UniPhier SoCs use a
single DMA channel whereas Renesas chips request separate channels for
RX and TX.
Newer UniPhier SoCs (Pro5 and later) support the internal DMA engine
like renesas_sdhi_internal_dmac.c The register map is almost the same,
so I guess Renesas and Socionext use the same internal DMA hardware.
The main difference is, the register offsets are doubled for Renesas.
Renesas Socionext
SDHI UniPhier
DM_CM_DTRAN_MODE 0x820 0x410
DM_CM_DTRAN_CTRL 0x828 0x414
DM_CM_RST 0x830 0x418
DM_CM_INFO1 0x840 0x420
DM_CM_INFO1_MASK 0x848 0x424
DM_CM_INFO2 0x850 0x428
DM_CM_INFO2_MASK 0x858 0x42c
DM_DTRAN_ADDR 0x880 0x440
DM_DTRAN_ADDREX --- 0x444
This comes from the difference of host->bus_shift; 2 for Renesas SoCs,
and 1 for UniPhier SoCs. Also, the datasheet for UniPhier SoCs defines
DM_DTRAN_ADDR and DM_DTRAN_ADDREX as two separate registers.
It could be possible to factor out the DMA common code by introducing
some hooks to cope with platform quirks, but this patch does not touch
that for now.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
tmio_mmc_set_clock() is full of quirks because different SoC vendors
extended this in different ways.
The original IP defines the divisor range 1/2 ... 1/512.
bit 7 is set: 1/512
bit 6 is set: 1/256
...
bit 0 is set: 1/4
all bits clear: 1/2
It is platform-dependent how to achieve the 1/1 clock.
I guess the TMIO-MFD variant uses the clock selector outside of this IP,
as far as I see tmio_core_mmc_clk_div() in drivers/mfd/tmio_core.c
I guess bit[7:0]=0xff is Renesas-specific extension.
Socionext (and Panasonic) uses bit 10 (CLKSEL) for 1/1. Also, newer
versions of UniPhier SoC variants use bit 16 for 1/1024.
host->clk_update() is only used by the Renesas variants, whereas
host->set_clk_div() is only used by the TMIO-MFD variants.
To cope with this mess, promote tmio_mmc_set_clock() to a new
platform hook ->set_clock(), and melt the old two hooks into it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
tmio_mmc_clk_stop(host) is equivalent to tmio_mmc_set_clock(host, 0).
This replacement is needed for the next commit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The JZ4725B is the first JZ SoC version that introduced a 32-bit IMASK
register, not the JZ4750.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
I've successfully tested eMMC on the V3H Starter Kit board and since the
R8A77970 SoC has a single SDHI core, it can't be a subject to the known RX
DMA errata.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Remove the stray underscore in the DM_CM_DTRAN_MODE.BUS_WIDTH register
field name and fix the typo in the comment of the #define
DTRAN_MODE_CH_NUM_CH1.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Depending on MACH_JZ4740 | MACH_JZ4780 prevent us from creating a generic
kernel that works on more than one MIPS board. Instead, we just depend on
MIPS being set.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enable access to the RPMB on the on-board eMMC of the
Poplar board.
Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We need r8a774a1 to be whitelisted for SDHI to work on the RZ/G2M,
but we don't care about the revision of the SoC, so just whitelist
the generic part number.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add ACPI support to all IPROC SDHCI variants.
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Convert DT properties to generic device properties
so that drivers can get properties from DT or ACPI.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Srinath Mannam <srinath.mannam@broadcom.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Going primarily by:
https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors
with additional information gleaned from other related pages; notably:
- Bonnell shrink was called Saltwell
- Moorefield is the Merriefield refresh which makes it Airmont
The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
for i in `git grep -l FAM6_ATOM` ; do
sed -i -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g' \
-e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/' \
-e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g' \
-e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g' \
-e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g' \
-e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g' \
-e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g' \
-e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g' \
-e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g' \
-e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g' \
-e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i}
done
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: dave.hansen@linux.intel.com
Cc: len.brown@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Use the new of_get_compatible_child() helper to lookup the slot child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.
This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the node of the device being probed).
While at it, also fix up the related slot-node reference leak.
Fixes: ed80a13bb4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Cc: stable <stable@vger.kernel.org> # 4.15
Cc: Carlo Caione <carlo@endlessm.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
after unbinding mmc I get things like this:
[ 185.294067] mmc1: card 0001 removed
[ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
The wakeirq stays in /proc-interrupts
rebinding shows this:
[ 289.795959] genirq: Flags mismatch irq 112. 0000200a (480b4000.mmc:wakeup) vs. 0000200a (480b4000.mmc:wakeup)
[ 289.808959] omap_hsmmc 480b4000.mmc: Unable to request wake IRQ
[ 289.815338] omap_hsmmc 480b4000.mmc: no SDIO IRQ support, falling back to polling
That bug seems to be introduced by switching from devm_request_irq()
to generic wakeirq handling.
So let us cleanup at removal.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Fixes: 5b83b2234b ("mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It turned out that U-Boot left
the SDHI DMA interrupts enabled while the Linux driver didn't use those.
Masking those interrupts in renesas_sdhi_internal_dmac_request_dma() gets
rid of both issues...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Fixes: 2a68ea7896 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits
32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Fixes: 2a68ea7896 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The conversion to sg_copy_{from,to}_buffer has been done in the wrong
way. sg_copy_to_buffer is a copy from an SG list to a linear buffer so
it can't replace memcpy(dest, host->virt_base, data->sg->length) where
dest is the virtual address of the SG. Same for sg_copy_from_buffer
but in the opposite way.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Suggested-by: Douglas Gilbert <dgilbert@interlog.com>
Fixes: 53d7e098ba ("mmc: android-goldfish: use sg_copy_{from,to}_buffer")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The conversion to sg_copy_{from,to}_buffer has been done in the wrong
way. sg_copy_to_buffer is a copy from an SG list to a linear buffer so
it can't replace memcpy(buf + offset, &value, remaining) where buf is
the virtual address of the SG. Same for sg_copy_to_buffer but in the
opposite way.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Suggested-by: Douglas Gilbert <dgilbert@interlog.com>
Fixes: 5b4277814e ("mmc: atmel-mci: use sg_copy_{from,to}_buffer")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When tuning each tap is issued CMD19 twice and the result of both runs
recorded in host->taps. If the result is different between the two runs
the wrong sampling clock position was selected. Fix this by merging the
two runs and only keep the result for each tap if it was good in both
sets.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If the return value of mmc_send_tuning() is error other than -EILSEQ,
the tuning fails and process goes out of for_loop. The correct
processing is to judge their TAP as not good (NG) and continue.
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
[Niklas: update commit message]
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Recent Linux versions refuse to print actual virtual kernel addresses,
to not give a hint about the location of the kernel in a randomized virtual
address space. This affects the output of the sunxi MMC controller
driver, which now produces the rather uninformative line:
[ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
Since the virtual base address is not really interesting in the first
place, let's just drop this value. The same applies to Linux' notion of
the interrupt number, which is independent from the GIC SPI number.
We have the physical address as part of the DT node name, which is way
more useful for debugging purposes.
To keep a success message in the driver, we make this purpose explicit
with the word "initialized", plus print some information that is not too
obvious and that we learned while probing the device:
the maximum request size and whether it uses the new timing mode.
So the output turns into:
[ 1.750626] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[ 1.786699] sunxi-mmc 1c11000.mmc: initialized, max. request size: 2048 KB
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some Allwinner boards feature an on-board eMMC with fixed 3.3V voltage
(e.g. Banana Pi M2+), and in this case both the eMMC and the SoC are
capable of doing 3.3V DDR transmission.
Add capability of 3.3V DDR when DDR is available (extra clock or new
timing).
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As a first step to improve the variant specific code for mmci, add a
->dma_setup() callback to the struct mmci_host_ops.
To show its use, let's deploy the callback for the qcom dml, which involves
also to the assign the mmci_host_ops pointer from the variant ->init()
callback.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Ludovic Barre <ludovic.barre@st.com>
To be able to better support different mmci variants, we need to be able to
use variant specific callbacks, rather than continue to sprinkle the code
with additional variant data. To move in this direction, let's add an
optional ->init() callback to the variant data struct, which variants shall
use to assign the mmci_host_ops pointer.
Using an ->init() callback enables us to partition the code between
different files. To allow separate mmci variant files to implement the
variant specifics, let's also move the definition of the struct
variant_data to the common mmci header file.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Ludovic Barre <ludovic.barre@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tegra SDHCI controllers require the SDHCI clock divider to be configured
to divide the clock by two in DDR50/52 modes. Incorrectly configured
clock divider results in corrupted data.
Prevent the possibility of incorrectly calculating the divider value due
to clock rate rounding or low parent clock frequency by not assigning
host->max_clk to clk_get_rate() on tegra_sdhci_set_clock().
See the comments for further details.
Fixes: a8e326a ("mmc: tegra: implement module external clock change")
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add MSI interrupt support if the SD host device can support MSI interrupt.
Signed-off-by: ernest.zhang <ernest.zhang@bayhubtech.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Export sdhci tuning function symbols which are used by other SD Host
controller driver modules.
Signed-off-by: ernest.zhang <ernest.zhang@bayhubtech.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
O2 SD Host HS200 mode clock frequency current is 208MHz, should be changed
to 200MHz to meet specification.
Signed-off-by: ernest.zhang <ernest.zhang@bayhubtech.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When use eMMC as boot device, the eMMC signaling voltage is tied to 1.8v
fixed output voltage, bios can set o2 sd host controller PCI configuration
register 0x308 bit4 to 1 to let driver skip 3.3v signaling voltage and
direct use 1.8v singling voltage in eMMC initialize process.
Signed-off-by: ernest.zhang <ernest.zhang@bayhubtech.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Implement and use tegra_sdhci_get_max_clock() which returns the true
maximum host clock rate. The issue with tegra_sdhci_get_max_clock() is
that it returns the current clock rate of the host instead of the
maximum one, which can lead to unnecessarily small clock rates.
This differs from the previous implementation of
tegra_sdhci_get_max_clock() in that it doesn't divide the result by two.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the uSDHC case (e.g. i.MX 6) clocks only get disabled if frequency
is set to 0. However, it could be that the stack asks for a frequency
change while clocks are on. In that case the function clears the
divider registers (by clearing ESDHC_CLOCK_MASK) while the clock is
enabled! This causes a short period of time where the clock is
undivided (on a i.MX 6DL a clock of 196MHz has been measured).
For older IP variants the driver disables clock by clearing some bits
in ESDHC_SYSTEM_CONTROL.
Make sure to disable card clock before changing frequency for uSDHC
IP variants too.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for all controller instances, even
for those not supporting UHS-I mode...
When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra
SD/MMC instance which is connected to a eMMC device, the stack
enables SD3.0. However, enabling it has consequences: If SDHCI 3.0
support is advertised the stack enables Auto-CMD23. Unfortunately
Auto-CMD23 seems not to work well with Tegra 3 currently. It leads
to regular warnings:
mmc2: Got command interrupt 0x00010000 even though no command operation was in progress.
It is not entirely clear why those errors happens. It seems that
a Linux 3.1 based downstream kernel which has Auto-CMD23 support
does not show those warnings.
Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being
used for now. With this the eMMC works stable on high-speed mode
while still announcing SD3.0.
This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52
mode read speed improves from about 42MiB/s to 72MiB/s on an
Apalis T30.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Make sure the clock is doubled when using eMMC DDR52 mode.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The stack assumes that SDHC controller which support SD3.0 (SDR104) do
support HS200. This is not the case for Tegra 3, which does support SD
3.0
but only supports eMMC spec 4.41.
Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not
support HS200.
Note that commit 156e14b126 ("mmc: sdhci: fix caps2 for HS200") added
the tie between SD3.0 (SDR104) and HS200. I don't think that this is
necessarly true. It is fully legitimate to support SD3.0 and not support
HS200. The quirk naming suggests something is broken in the controller,
but this is not the case: The controller simply does not support HS200.
Fixes: 7ad2ed1dfc ("mmc: tegra: enable UHS-I modes")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Synopsys has DWC MSHC controller on HPAS-DX platform connected using PCIe
interface with SD card slot and eMMC device slots. This patch is to
enable SD cards connected on this platform. As Clock generation logic
is implemented using MMCM module of HAPS-DX platform, we have separate
functions to control the MMCM to generate required clocks with respect
to speed mode.
Signed-off-by: Prabu Thangamuthu <prabu.t@synopsys.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add a driver for SDHCI OF Synopsys DesignWare Cores Mobile Storage
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
For eMMC devices it is valid to only support 1.8V signaling. When
vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V
initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed
Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is
not available. This prevents the stack from even trying to use
3.3V signaling and avoids the above warning.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses
when doing DMA. Make sure that the corresponding dma mask is correctly
configured.
Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings
for sdhci end up 48-bit wide. However, on these chips sdhci only use
40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device
generates transactions with clipped 40-bit addresses, thus smmu context
faults are triggered. Setting up the correct dma mask fixes this
situation.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
A recent commit introduced a call to mmc_of_parse() and removed the
explicit assignment of GPIOs in the pdata structure. This will leave
them set to 0, which is a valid GPIO per se, so the code that looks
at these members will try to allocate them and fail.
To fix this properly, make the following changes:
a) Refrain from allocating and assiging a pdata struct from
pxamci_of_init(). It's a hack to do it this way anyway.
Instead, move the only remaining member of interest in
'struct pxamci_host' and assign the value from either
the passed in pdata pointer or with the value read from DT.
b) Let the only user of 'detect_delay_ms' look at the member of
'struct pxamci_host', not the pdata.
c) Make more code in pxamci_probe() dependent on the presence of
actual pdata.
This will also ease the removal of pdata one day.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Strip some code by letting the mmc core handle the regulators. The old
.gpio_power pdata handling is kept around for now.
This also set the voltage on the regulator and handles -EPROBE_DEFER
correctly.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Devicetree-enabled boards should use proper regulators to control the
power of cards, not GPIOs, so let's remove this property. The regulator
properties are supported by the MMC core and are described in the
generic MMC document:
Documentation/devicetree/bindings/mmc/mmc.txt
Note that devicetree support for PXA platforms hasn't fully landed yet,
so this binding does not have any users at this point.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Call into mmc_of_parse() from pxamci_of_init(). As it needs a pointer to a
struct mmc_host, refactor the code a bit.
This allows all generic MMC properties to be set that are described in
Documentation/devicetree/bindings/mmc/mmc.txt. Reword the documentation
a bit to make that clear.
The "cd" and "wp" gpio lookups are removed as the lookup will now be
done by mmc_of_parse().
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
pxamci_of_init() had some weird indenting.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
These gpio assignments don't make sense, as they are not used anywhere.
Remove the dead code.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
These members are no longer in use, so let's remove them.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This seems to be a left-over from times before the IRQ was handled by devm
functions. Remove it.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The field support_vsel is currently only used in the device tree
case. Get rid of it. No change in behavior.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The uSDHC supports DDR modes for eMMC devices running at 3.3V. This
allows to run eMMC with 3.3V signaling voltage at DDR52 mode:
# cat /sys/kernel/debug/mmc1/ios
clock: 52000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 8 (mmc DDR52)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Convert to use of_match_node method to fix up eSDHC clock for
ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a
according to its datasheet. The maxmum speed for ls1021a eSDHC
high speed mode is 46.5MHz.
Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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: Helmut Grohne <h.grohne@intenta.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support to use the new compatible string "qcom,sdhci-msm-v5".
Based on the msm variant, pick the relevant variant data and
use it for register read/write to msm specific registers.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In addition to offsets of certain registers changing, the registers in
core_mem have been shifted to HC mem as well. To access these
registers, define msm version specific functions. These functions can
be loaded into the function pointers at the time of probe based on
the msm version detected.
Also defind new data structure to hold version specific Ops and
register addresses.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For SDCC version 5.0.0, MCI registers are removed from SDCC
interface and some registers are moved to HC.
Define a new data structure where we can statically define
the address offsets for the registers in different SDCC versions.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
dw_mci_exynos_resume_noirq() performs DWMMC register access without
ensuring that respective clocks are enabled. This might cause external
abort on some systems (observed on Exynos5433 based boards). Fix this
by forcing a PM runtime active state before register access. Using
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS allows also to cleanup conditional code
a bit.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The sdhci get_max_clock callback is set to sdhci_pltfm_clk_get_max_clock
and tegra_sdhci_get_max_clock is removed. It appears that the
shdci-tegra specific callback was originally introduced due to the
requirement that the host clock has to be twice the bus clock on DDR50
mode. As far as I can tell the only effect the removal has on DDR50 mode
is in cases where the parent clock is unable to supply the requested
clock rate, causing the DDR50 mode to run at a lower frequency.
Currently the DDR50 mode isn't enabled on any of the SoCs and would also
require configuring the SDHCI clock divider register to function
properly.
The problem with tegra_sdhci_get_max_clock is that it divides the clock
rate by two and thus artificially limits the maximum frequency of faster
signaling modes which don't have the host-bus frequency ratio requirement
of DDR50 such as SDR104 and HS200. Furthermore, the call to
clk_round_rate() may return an error which isn't handled by
tegra_sdhci_get_max_clock.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If pinctrl nodes for 100/200MHz are missing, the controller should
not select any mode which need signal frequencies 100MHz or higher.
To prevent such speed modes the driver currently uses the quirk flag
SDHCI_QUIRK2_NO_1_8_V. This works nicely for SD cards since 1.8V
signaling is required for all faster modes and slower modes use 3.3V
signaling only.
However, there are eMMC modes which use 1.8V signaling and run below
100MHz, e.g. DDR52 at 1.8V. With using SDHCI_QUIRK2_NO_1_8_V this
mode is prevented. When using a fixed 1.8V regulator as vqmmc-supply
the stack has no valid mode to use. In this tenuous situation the
kernel continuously prints voltage switching errors:
mmc1: Switching to 3.3V signalling voltage failed
Avoid using SDHCI_QUIRK2_NO_1_8_V and prevent faster modes by
altering the SDHCI capability register. With that the stack is able
to select 1.8V modes even if no faster pinctrl states are available:
# cat /sys/kernel/debug/mmc1/ios
...
timing spec: 8 (mmc DDR52)
signal voltage: 1 (1.80 V)
...
Link: http://lkml.kernel.org/r/20180628081331.13051-1-stefan@agner.ch
Signed-off-by: Stefan Agner <stefan@agner.ch>
Fixes: ad93220de7 ("mmc: sdhci-esdhc-imx: change pinctrl state according
to uhs mode")
Cc: <stable@vger.kernel.org> # v4.13+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When mmc host controller enters suspend state, the clocks are
disabled, but irqs are not. For some reason the irqchip emits
false interrupts, which causes system lock loop.
Debug log is:
...
sunxi-mmc 1c11000.mmc: setting clk to 52000000, rounded 51200000
sunxi-mmc 1c11000.mmc: enabling the clock
sunxi-mmc 1c11000.mmc: cmd 13(8000014d) arg 10000 ie 0x0000bbc6 len 0
sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 00000004 idi 00000000
sunxi-mmc 1c11000.mmc: cmd 6(80000146) arg 3210101 ie 0x0000bbc6 len 0
sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 00000004 idi 00000000
sunxi-mmc 1c11000.mmc: cmd 13(8000014d) arg 10000 ie 0x0000bbc6 len 0
sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 00000004 idi 00000000
mmc1: new DDR MMC card at address 0001
mmcblk1: mmc1:0001 AGND3R 14.6 GiB
mmcblk1boot0: mmc1:0001 AGND3R partition 1 4.00 MiB
mmcblk1boot1: mmc1:0001 AGND3R partition 2 4.00 MiB
sunxi-mmc 1c11000.mmc: cmd 18(80003352) arg 0 ie 0x0000fbc2 len 409
sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 00004000 idi 00000002
mmcblk1: p1
sunxi-mmc 1c11000.mmc: irq: rq (null) mi 00000000 idi 00000000
sunxi-mmc 1c11000.mmc: irq: rq (null) mi 00000000 idi 00000000
sunxi-mmc 1c11000.mmc: irq: rq (null) mi 00000000 idi 00000000
sunxi-mmc 1c11000.mmc: irq: rq (null) mi 00000000 idi 00000000
and so on...
This issue apears on eMMC cards, routed on MMC2 slot. The patch is
tested with A20-OLinuXino-MICRO/LIME/LIME2 boards.
Fixes: 9a8e1e8cc2 ("mmc: sunxi: Add runtime_pm support")
Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Card write threshold control is supposed to be set since controller
version 2.80a for data write in HS400 mode and data read in
HS200/HS400/SDR104 mode. However the current code returns without
configuring it in the case of data writing in HS400 mode.
Meanwhile the patch fixes that the current code goes to
'disable' when doing data reading in HS400 mode.
Fixes: 7e4bf1bc95 ("mmc: dw_mmc: add the card write threshold for HS400 mode")
Signed-off-by: Qing Xia <xiaqing17@hisilicon.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
flag cannot be cleared because tmio_mmc_core sets the host->data
to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't
cause any side effects.
Fixes: 0cbc94daa5 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs")
Cc: <stable@vger.kernel.org> # v4.17+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch fixes an issue that lacks the dma_unmap_sg() calling in
the error patch of renesas_sdhi_internal_dmac_start_dma().
Fixes: 0cbc94daa5 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs")
Cc: <stable@vger.kernel.org> # v4.17+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit e060d376cc ("mmc: renesas_sdhi: fix WP detection")
and adds some code to really fix the regressions.
It was missed so far that Renesas R-Car instantiations of SDHI chose to
disable internal WP and used the existence of "wp-gpios" to en/disable
WP at all.
With the first refactoring by Yamada-san with commit 2ad1db059b ("mmc:
renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag"),
WP was always disabled even when GPIOs were present. With Wolfram's
first fix which gets now reverted, GPIOs were honored. But when not
available, the fallback was to internal WP and not to disabled WP. This
caused wrong WP status on uSD card slots.
Restore the old behaviour now. By default, WP is disabled. When a GPIO
is found, the GPIO re-enables WP. We will think about possible better
ways to handle this in the future.
Tested on a previously regressing Renesas Lager board (H2) and a still
working Renesas Salvator-X board (M3-W).
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is no obvious reasons to why mvsdio shouldn't be able to support
erase/trim/discard operations, hence let's set MMC_CAP_ERASE for it.
Cc: Damien Thebault <damien.thebault@vitec.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Damien Thebault <damien.thebault@vitec.com>
Instead of using a hardcoded timeout of 5 * HZ jiffies, let's respect the
command busy timeout provided by the mmc core. This make the used timeout
more reliable.
Cc: Damien Thebault <damien.thebault@vitec.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Damien Thebault <damien.thebault@vitec.com>
Now we have a proper implementation for the power irq handling and this
quirk is not needed anymore. In fact, it is causing card detection delays
on apq8096 platforms and the following error is displayed:
sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for req: (4) timed out
The quirk is forcing the controller to retain 1.8V signalling on the slot
even when a new card is inserted, which is not correct. The proper behavior
would be to reset the controller in order to start with 3.3V signaling.
Fixes: c0309b3803 ("mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq")
Suggested-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To be consistent with code in other mmc host drivers, convert to check the
correct PM config #ifdef in favor of using __maybe_unused.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To be consistent with code in other mmc host drivers, convert to check the
correct PM config #ifdef in favor of using __maybe_unused.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The highmem conversion caused a build error in some configurations:
drivers/mmc/host/mxcmmc.c: In function 'mxcmci_transfer_data':
drivers/mmc/host/mxcmmc.c:622:10: error: implicit declaration of function 'kmap_atomic'; did you mean 'in_atomic'? [-Werror=implicit-function-declaration]
This includes the correct header file.
Fixes: b189e7589f ("mmc: mxcmmc: handle highmem pages")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The newly added runtime-pm functions cause a harmless warning
when CONFIG_PM is disabled:
drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend' defined but not used [-Werror=unused-function]
static int sunxi_mmc_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume' defined but not used [-Werror=unused-function]
static int sunxi_mmc_runtime_resume(struct device *dev)
This marks them as __maybe_unused to shut up the warning.
Fixes: 9a8e1e8cc2 ("mmc: sunxi: Add runtime_pm support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use kmap_atomic to map the scatterlist entry before using it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
I noticed below error msg with sdhci-pxav3 on some berlin platforms:
[.....] sdhci-pxav3 f7ab0000.sdhci failed to add host
It is due to getting related vmmc or vqmmc regulator returns
-EPROBE_DEFER. It doesn't matter at all but it's confusing.
>From another side, if driver probing fails and the error number isn't
-EPROBE_DEFER, the core will tell us something as below:
[.....] sdhci-pxav3: probe of f7ab0000.sdhci failed with error -EXX
So it's not necessary to emit error msg if sdhci_add_host() fails. And
some other sdhci host drivers also have this issue, let's fix them
together.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
match_string() returns the index of an array for a matching string,
which can be used intead of open coded variant.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Hu Ziji <huziji@marvell.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use sg_copy_{from,to}_buffer to bounce buffer and kmap_atomic to map the
scatterlist entry before using it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Pass the scatterlist on to the USB subsystem instead of expecting a
kernel virtual address.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use kmap_atomic to map the scatterlist entry before using it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This handles highmem pages, and also cleans up the code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This handles highmem pages, and also cleans up the code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to
properly reset the host controller (reset all) on initialization
after exiting deep sleep.
Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com>
Fixes: c833e92bbb ("mmc: sdhci-iproc: support standard byte register accesses")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When the host controller accepts only 32bit writes, the value of the
16bit TRANSFER_MODE register, that has the same 32bit address as the
16bit COMMAND register, needs to be saved and it will be written
in a 32bit write together with the command as this will trigger the
host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then
sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
write it again resulting in wrong value to be written because the
initial write value was saved in a shadow and the read-back returned
a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
saved for a different reason, although a scenario that will cause the
mentioned problem on this registers is not probable.
Fixes: b580c52d58 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Remove hard coded mmc cap 1.8v from platform data as it is board specific.
The 1.8v DDR mmc caps can be enabled using DTS property for those
boards that support it.
Fixes: b17b4ab8ce ("mmc: sdhci-iproc: define MMC caps in platform data")
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Trigger the reset line of the mmc controller while probing, if available.
The reset should be optional for now, at least until all related DT nodes
have the reset property.
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This commit adds extension to the dw_mmc driver for Mellanox BlueField
SoC. It updates the UHS_REG_EXT register to bring up the eMMC card on
this SoC.
Signed-off-by: Liming Sun <lsun@mellanox.com>
Reviewed-by: David Woods <dwoods@mellanox.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
A redundant return statement is removed from
tegra_sdhci_set_uhs_signaling(). The function returns void and the
return does not affect the control flow of the function.
Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Instead of using a fixed 3s timeout for commands with R1B responses,
convert to use the per request calculated busy timeout from the mmc core.
This is needed to cope with requests that requires longer timeout, for
example erase/discard commands.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Michał Pecio <michal.pecio@gmail.com>
Instead of having to return -EINVAL when requested to send SDIO specific
commands, let's set MMC_CAP2_NO_SDIO as it completely prevents them.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Michał Pecio <michal.pecio@gmail.com>
commit 8d20b2eae6 ("mmc: sdhci_omap: Add support to set
IODELAY values") stored IODelay values for all MM/SD modes
in pinctrl_state structure member of sdhci_omap_host. However for
DDR mode it gets IODelay values only for 1.8v DDR mode. Since some of
the platforms which uses sdhci-omap has IO lines connected to 3.3v,
get IODelay values for 3.3v DDR mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add sdhci_omap_enable_sdio_irq to set CTPL and CLKEXTFREE bits in
MMCHS_CON register required to detect asynchronous card interrupt
on DAT[1].
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support for the new compatible added specifically to support
k2g's MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Errata i834 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
(SPRZ429K July 2014–Revised March 2017 [1]) mentions the maximum
obtainable timeout through MMC host controller is 700ms. And for
commands taking longer than 700ms, hardware timeout should be
disabled and software timeout should be used.
The workaround for Errata i834 can be achieved by adding
SDHCI_QUIRK2_DISABLE_HW_TIMEOUT quirk in sdhci-omap.
[1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdf
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci has a 10 second timeout to catch devices that stop responding.
In the case of quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, instead of
programming 10 second arbitrary value, calculate the total time it would
take for the entire transfer to happen and program the timeout value
accordingly.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Factor out the target_timeout calculation so it can be re-used.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add quirk to disable HW timeout if the requested timeout is more than the
maximum obtainable timeout.
Also, if the quirk is set and ->get_max_timeout_count() is not implemented,
max_busy_timeout is set to zero.
Based-on-patch-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SDHCI controller in a SoC might support HS200/HS400 (indicated
using mmc-hs200-1_8v/mmc-hs400-1_8v dt property), but if the board is
modeled such that the IO lines are not connected to 1.8v then
HS200/HS400 cannot be supported. Disable HS200/HS400 if the board
does not have 1.8v connected to the IO lines. Also Disable DDR/UHS in 1.8v
if the IO lines are not connected to 1.8v.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Invoke sdhci_get_of_property defined in sdhci-pltfm.c to read
sdhci specific properties from dt node.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Errata i843 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
(SPRZ429K July 2014–Revised March 2017 [1]) mentions
PG 1.0/1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3
can operate.
Use soc_device_match() to identify rev 1.0/1.1 silicon and
override mmc->f_max according to the errata workaround.
"max-frequency" dt property cannot be used since the device
tree is added for rev 2.0 silicon.
soc_device_match() is also used in order to get the IODelay values
for rev 1.0/1.1 silicon.
[1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdf
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci can directly get ADMA capability from MMCHS_CAPA register.
Remove explicitly setting ADMA here as some instances might not have
ADMA enabled. (sdhci_read_caps() is also removed from here since
sdhci_setup_host() invokes it).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci_omap_config_iodelay_pinctrl_state() requires caps and caps2 to be
initialized (speed mode capabilities like UHS/HS200) before it is
invoked. While mmc_of_parse() initializes caps/caps2 if capabilities is
populated in device tree, it will remain uninitialized for capabilities
obtained from SDHCI_CAPABILITIES register.
Fix sdhci_omap_config_iodelay_pinctrl_state() to be used even while
getting the capabilities from SDHCI_CAPABILITIES register by invoking
sdhci_setup_host() before sdhci_omap_config_iodelay_pinctrl_state().
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On !RT interrupt runs with interrupts disabled. On RT it's in a
thread, so no need to disable interrupts at all.
Remove the local_irq_save() invocation.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
While performing R/W access in PIO mode, the common SDHCI driver checks
the buffer ready status once per whole block processing. That is, after
getting an appropriate interrupt, or checking an appropriate status bit,
the driver makes buffer accesses for the whole block size (e.g. 128 reads
for 512 bytes block). This is done in accordance with SD Host Controller
Specification.
At the same time, the Ultra Secured Digital Host Controller (uSDHC), used
in i.MX6 (and, probably, earlier i.MX series too), uses a separate
Watermark Levels register, controlling the amount of data or space
available when raising status bit or interrupt. For default watermark
setting of 16 words, the controller expects (and guarantees) no more
than 16 buffer accesses after raising buffer ready status bit and
generating an appropriate interrupt. If the driver tries to access the
whole block size, it will get incorrect data at the end, and a new
interrupt will appear later, when the driver already doesn't expect it.
This happens sometimes, more likely on low frequencies, e.g. when
reading EXT_CSD at MMC card initialization phase
(which makes that initialization fail).
Such behavior of i.MX uSDHC seems to be non-compliant
to SDHCI Specification, but this is the way it works now.
In order not to rewrite the SDHCI driver PIO mode access logic,
the IMX specific driver can just set the watermark level to default
block size (128 words or 512 bytes), so that the controller behavior
will be consistent to generic specification. This patch does this
for PIO mode accesses only, restoring default values for DMA accesses
to avoid any possible side effects from performance point of view.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs
have a control signal (io_pad_pwr_switch/mode18 ) that indicates
whether the PAD works in 3v or 1.8v.
SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset
based on actual voltage used for IO lines. So when power irq is
triggered for io high or io low, the driver should check the voltages
supported and set the pad accordingly.
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
During probe check whether the vdd-io regulator of sdhc platform device
can support 1.8V and 3V and store this information as a capability of
platform device.
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single
SDHI core anyway, so can't be a subject of the known RX DMA errata...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently, the code block inside the for loop will never execute more than
once, because the function returns immediately after the first iteration,
hence the execution of the code at the second iteration is structurally
dead and, code at line 281: return 0; is never reached.
Fix this by checking _ret_ before return.
Addresses-Coverity-ID: 1468009 ("Logically dead code")
Addresses-Coverity-ID: 1468002 ("Structurally dead code")
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The usage of of_device_get_match_data() reduce the code size a bit.
Also, the only way to call msdc_drv_probe() is to match an entry in
msdc_of_ids[], so of_id cannot be NULL.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fix 3.3V voltage switch for some BYT-based Intel controllers by making use
of the ACPI DSM.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The WARN can never trigger because we limited the max_seg number in
renesas_sdhi_of_data already. Remove it and update the comment.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Whitelisting every ES version does not scale. So, we whitelist whole
SoCs independent of ES version. If we need specific handling for an ES
version, we put it to the front, so it will be matched first.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj@renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Sometimes sg->offset is not used for buffer addresses allocated by
dma_map_sg(), so alignment checks should be done on the allocated buffer
addresses. Delete the alignment check for sg->offset that is done before
dma_map_sg(). Instead, it performs the alignment check for
sg->dma_address after dma_map_sg().
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
[Niklas: broke this commit in two and tidied small style issue]
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[rebased to mmc/next]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Instead of directly accessing the members of struct scatterlist use the
helpers mmc_get_dma_dir() and sg_dma_address() in
renesas_sdhi_internal_dmac_start_dma(). Based on previous work by
Masaharu Hayakawa.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[rebased to mmc/next]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On some NI 904x devices, using 3.3V signaling for extended periods of
time will physically damage the pads connected to the SDHC, eventually
causing complete failure of the controller. To work around this,
require that we avoid 3.3V signaling.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Our set_ios hook is, when the card is power up or down, either doing a full
init or put our controller back into a reset mode.
Since we're also doing that in our runtime_pm hooks, and at possibly much
more often, we can drop it from the set_ios, and either rely on our
runtime_pm hooks or our probe to do it.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
So far, even if our card was not in use, we didn't shut down our MMC
controller, which meant that it was still active and clocking the bus.
While this obviously means that we could save some power there, it also
creates issues when it comes to EMC control since we'll have a perfect peak
at the card clock rate.
Let's implement runtime_pm with autosuspend so that we will shut down the
controller when it's not been in use for quite some time.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to improve readibility and reusability, let's move the card setup
to a small function called by our .set_ios hook.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to improve readibility and reusability, let's move the clock setup
to a small function called by our .set_ios hook.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In order to improve readibility and reusability, let's move the bus width
setup to a small function called by our .set_ios hook.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
All the other functions in the driver take a struct sunxi_mmc_host pointer.
Let's make it consistent.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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>
Cadence sent out an errata report to their customers of this IP.
This errata is not so severe, but the tune request should be sent
twice to avoid the potential issue.
Quote from the report:
Problem Summary
---------------
The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
This issue may lead to an incorrect values of read/write pointers of
the synchronization FIFO. Such a situation can happen at the SDR104
and HS200 tuning procedure when the PHY is requested to change a phase
of sampling clock when moving to the next tuning iteration.
Workarounds
-----------
The following are valid workarounds to resolve the issue:
1. In eMMC mode, software sends tune request twice instead of once at
each iteration. This means that the clock phase is not changed on
the second request so there is no potential for clock instability.
2. In SD mode, software must not use the hardware tuning and instead
perform an almost identical procedure to eMMC, using the HRS34 Tune
Force register.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Explicitly update the docomentation to support the Meson-AXG platform.
Signed-off-by: Nan Li <nan.li@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Introduce the compatible data to cover the register offset & mask
change of the eMMC controller in Amlogic's Meson-AXG SoC.
Signed-off-by: Nan Li <nan.li@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Replace dma_request_channel() with dma_request_chan(),
which also supports probing from the devicetree.
Tested-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
