The commit 9d9491a7da ("mmc: dw_mmc: Fix the DTO timeout calculation")
and commit 4c2357f57d ("mmc: dw_mmc: Fix the CTO timeout calculation")
made changes, which cause multiply overflow for 32-bit systems. The
broken
timeout calculations leads to unexpected ETIMEDOUT errors and causes
stacktrace splat (such as below) during normal data exchange with
SD-card.
| Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
| - Info: Finished target initialization.
| mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd
| response 0x900, card status 0x0
DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so
code gets compiled on all 32-bit platforms as opposed to usage of
DIV_ROUND_UP when we may only compile stuff on a very few arches.
Lets cast this multiply to u64 type to prevent the overflow.
Change-Id: I45462bac22f946c5129eab0e0d5b22b3ed7ca19d
Fixes: 9d9491a7da ("mmc: dw_mmc: Fix the DTO timeout calculation")
Fixes: 4c2357f57d ("mmc: dw_mmc: Fix the CTO timeout calculation")
Tested-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> # ARC STAR
9001306872 HSDK, sdio: board crashes when copying big files
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: <stable@vger.kernel.org> # 4.14
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from c715160225)
Per SD specification physical layer v4.0, section 3.9.4, it
says "UHS-I supports only 4-bit mode. Host shall select 4-bit
mode by ACMD6. However mmc_sd_init_uhs_card() still go ahead
to initialize the cards anyway, whether card or host won't
support 4-bit mode.
This breaks the platforms which only support 1-bit mode but
with a UHS-I card inserted, as all the tuning process is broken
due to this. Alternatively, we should check the return value from
mmc_set_bus_width to see if host could finish the request to switch
the bus with on its side. But that needs more thing to do than this
patch that just bails out early to try to use high speed mode if 4-bit
mode isn't available for whatever reason. And this patch could also
fix the same problem for sdio since R4_18V_PRESENT won't be set for
ocr when mmc_sdio_init_card() finds mmc_host_uhs() is false.
Note that This patch doesn't keep the checking of card->scr.sda_spec3
and comparing card->scr.bus_widths with SD_SCR_BUS_WIDTH_4 within
mmc_sd_init_uhs_card since if the sd cards response with SD_ROCR_S18A,
it definitely support UHS-I mode, which implicitly means these checks
are always true.
Change-Id: I2e91418b3216d9efac672af604014d7095bf4a1a
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10241773/)
Per SDIO Simplified Specification V3, section 3.1.2, A host that
supports UHS-I sets S18R to 1 in the argument of CMD5 to request a
change of the signal voltage to 1.8V. If the card supports UHS-I and
the current signal voltage is 3.3V, S18A is set to 1 in the R4 response.
If the signal voltage is already 1.8V, the card sets S18A to 0 so that
host maintains the current signal voltage. UHS-I is supported in SD mode
and S18A is always 0 in SPI mode.
For the current code, if the signalingvoltage is fixed 1.8v, so
the card will set S18A to 0 for rocr and thus we would clear the
R4_18V_PRESENT from ocr, which make core won't try to use uhs mode.
To fix it, we expect sdio_read_cccr would fail if the uhs mode won't
work at all. Note that it's interesting that some sdio cards still
response S18A even the voltage is fixed to 1.8v and the CMD11 will
also accepted and finish enabling UHS mode successfully.I guess this
is why folks didn't notice this problem. Anyway, fix it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Change-Id: I81305f076a663d04c3ff93e78492daf091bc6311
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from 5fc3d80ef4)
Add new helper function, mmc_sdio_resend_if_cond, to be
reused when trying to retry the init sequence.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Change-Id: I3eb7ffdc18ddb49f34e39198ac4a65cdb8cad586
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from 0eb51a58ad)
Just follow the convention of fixing for DTO timeout.
Change-Id: I753b5a6f2ab409e58c83a59212592f3b430b018a
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
LSK 18.02 v4.4-android
* tag 'lsk-v4.4-18.02-android': (131 commits)
Linux 4.4.114
nfsd: auth: Fix gid sorting when rootsquash enabled
net: tcp: close sock if net namespace is exiting
flow_dissector: properly cap thoff field
ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
net: Allow neigh contructor functions ability to modify the primary_key
vmxnet3: repair memory leak
sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
sctp: do not allow the v4 socket to bind a v4mapped v6 address
r8169: fix memory corruption on retrieval of hardware statistics.
pppoe: take ->needed_headroom of lower device into account on xmit
net: qdisc_pkt_len_init() should be more robust
tcp: __tcp_hdrlen() helper
net: igmp: fix source address check for IGMPv3 reports
lan78xx: Fix failure in USB Full Speed
ipv6: ip6_make_skb() needs to clear cork.base.dst
ipv6: fix udpv6 sendmsg crash caused by too small MTU
ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
hrtimer: Reset hrtimer cpu base proper on CPU hotplug
...
commit 1ef5e49e46 upstream.
A previous patch had removed esdhc_of_platform_init() by mistake.
static void esdhc_of_platform_init(struct sdhci_host *host)
{
u32 vvn;
vvn = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
if (vvn == VENDOR_V_22)
host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
if (vvn > VENDOR_V_22)
host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ;
}
This patch is used to fix it by add/remove some quirks according to
verdor version in probe.
Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
Fixes: f4932cfd22 ("mmc: sdhci-of-esdhc: support both BE and LE host controller")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current io_latency_state structure includes entries for read
and write requests. There are special types of write commands
such as sync and discard (trim) commands, and the current
implementation is not general enough if we want to separate
latency histogram for such special commands.
This change makes io_latency_state structure request-type neutral.
It also changes to print the latency average.
Signed-off-by: Hyojun Kim <hyojun@google.com>
[ Upstream commit 40ceda09c8 ]
This patch can fix two issues:
Issue 1:
In previous code, div may be overflow when setting clock frequency
as f_min. We can use DIV_ROUND_UP to fix this boundary related
issue.
Issue 2:
In previous code, we can not set the correct clock frequency when
div equals 0xff.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
According to the SDIO standard interrupts are normally signalled in a
very complicated way. They require the card clock to be running and
require the controller to be paying close attention to the signals
coming from the card. This simply can't happen with the clock stopped
or with the controller in a low power mode.
To that end, we'll disable runtime_pm when we detect that an SDIO card
was inserted. This is much like with what we do with the special
"SDMMC_CLKEN_LOW_PWR" bit that dw_mmc supports.
NOTE: we specifically do this Runtime PM disabling at card init time
rather than in the enable_sdio_irq() callback. This is _different_
than how SDHCI does it. Why do we do it differently?
- Unlike SDHCI, dw_mmc uses the standard sdio_irq code in Linux (AKA
dw_mmc doesn't set MMC_CAP2_SDIO_IRQ_NOTHREAD).
- Because we use the standard sdio_irq code:
- We see a constant stream of enable_sdio_irq(0) and
enable_sdio_irq(1) calls. This is because the standard code
disables interrupts while processing and re-enables them after.
- While interrupts are disabled, there's technically a period where
we could get runtime disabled while processing interrupts.
- If we are runtime disabled while processing interrupts, we'll
reset the controller at resume time (see dw_mci_runtime_resume),
which seems like a terrible idea because we could possibly have
another interrupt pending.
To fix the above isues we'd want to put something in the standard
sdio_irq code that makes sure to call pm_runtime get/put when
interrupts are being actively being processed. That's possible to do,
but it seems like a more complicated mechanism when we really just
want the runtime pm disabled always for SDIO cards given that all the
other bits needed to get Runtime PM vs. SDIO just aren't there.
NOTE: at some point in time someone might come up with a fancy way to
do SDIO interrupts and still allow (some) amount of runtime PM.
Technically we could turn off the card clock if we used an alternate
way of signaling SDIO interrupts (and out of band interrupt is one way
to do this). We probably wouldn't actually want to fully runtime
suspend in this case though--at least not with the current
dw_mci_runtime_resume() which basically fully resets the controller at
resume time.
Change-Id: I29a687b2342b9cb921aad133a538689a8f7d9262
Fixes: e9ed8835e9 ("mmc: dw_mmc: add runtime PM callback")
Cc: <stable@vger.kernel.org>
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-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>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
* linux-linaro-lsk-v4.4-android: (510 commits)
Linux 4.4.103
Revert "sctp: do not peel off an assoc from one netns to another one"
xen: xenbus driver must not accept invalid transaction ids
s390/kbuild: enable modversions for symbols exported from asm
ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data
btrfs: return the actual error value from from btrfs_uuid_tree_iterate
ASoC: rsnd: don't double free kctrl
netfilter: nf_tables: fix oob access
netfilter: nft_queue: use raw_smp_processor_id()
spi: SPI_FSL_DSPI should depend on HAS_DMA
staging: iio: cdc: fix improper return value
iio: light: fix improper return value
mac80211: Suppress NEW_PEER_CANDIDATE event if no room
mac80211: Remove invalid flag operations in mesh TSF synchronization
drm: Apply range restriction after color adjustment when allocation
ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE
ath10k: set CTS protection VDEV param only if VDEV is up
ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
ath10k: ignore configuring the incorrect board_id
ath10k: fix incorrect txpower set by P2P_DEVICE interface
...
Conflicts:
drivers/media/v4l2-core/v4l2-ctrls.c
kernel/sched/fair.c
Change-Id: I48152b2a0ab1f9f07e1da7823119b94f9b9e1751
Conflicts due to AOSP's backported commits:
fs/f2fs/crypto.c
fs/f2fs/crypto_fname.c
Deleted by AOSP commit c1286ff41c ("f2fs: backport from (4c1fad64 -
Merge tag 'for-f2fs-4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)")
fs/f2fs/crypto_key.c
fs/f2fs/data.c
fs/f2fs/file.c
AOSP commit 13f002354d ("f2fs: catch up to v4.14-rc1")
override most of stable 4.4.y changes.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[ Upstream commit e1c6ec26b8 ]
I got this new build error on today's linux-next
drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
struct tasklet_struct pio_tasklet;
drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]
While I haven't found out why this happened now and not earlier, the
solution is obvious, we should include the header that defines
the structure.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The recent CTO timer introduced in commit 03de19212e ("mmc: dw_mmc:
introduce timer for broken command transfer over scheme") was causing
observable problems due to race conditions. Previous patches have
fixed those race conditions.
It can be observed that these same race conditions ought to be
theoretically possible with the DTO timer too though they are
massively less likely to happen because the data timeout is always set
to 0xffffff right now. That means even at a 200 MHz card clock we
were arming the DTO timer for 94 ms:
>>> (0xffffff * 1000. / 200000000) + 10
93.886075
We always also were setting the DTO timer _after_ starting the
transfer, unlike how the old code was seting the CTO timer.
In any case, even though the DTO timer is much less likely to have
races, it still makes sense to add code to handle it _just in case_.
Change-Id: I87a1707399b64d43278239ddd830c3270402239a
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002771/)
Just like the CTO timeout calculation introduced recently, the DTO
timeout calculation was incorrect. It used "bus_hz" but, as far as I
can tell, it's supposed to use the card clock. Let's account for the
div value, which is documented as 2x the value stored in the register,
or 1 if the register is 0.
NOTE: This was likely not terribly important until commit 16a34574c6
("mmc: dw_mmc: remove the quirks flags") landed because "DIV" is
documented on Rockchip SoCs (the ones that used to define the quirk)
to always be 0 or 1. ...and, in fact, it's documented to only be 1
with EMMC in 8-bit DDR52 mode. Thus before the quirk was applied to
everyone it was mostly OK to ignore the DIV value.
I haven't personally observed any problems that are fixed by this
patch but I also haven't tested this anywhere with a DIV other an 0.
AKA: this problem was found simply by code inspection and I have no
failing test cases that are fixed by it. Presumably this could fix
real bugs for someone out there, though.
Change-Id: I0d81f991e10e60b8d03ee330b34d08af34a33fcb
Fixes: 16a34574c6 ("mmc: dw_mmc: remove the quirks flags")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002751/)
This attempts to instill a bit of paranoia to the code dealing with
the CTO timer. It's believed that this will make the CTO timer more
robust in the case that we're having very long interrupt latencies.
Note that I originally thought that perhaps this patch was being
overly paranoid and wasn't really needed, but then while I was running
mmc_test on an rk3399 board I saw one instance of the message:
dwmmc_rockchip fe320000.dwmmc: Unexpected interrupt latency
I had debug prints in the CTO timer code and I found that it was
running CMD 13 at the time.
...so even though this patch seems like it might be overly paranoid,
maybe it really isn't?
Presumably the bad interrupt latency experienced was due to the fact
that I had serial console enabled as serial console is typically where
I place blame when I see absurdly large interrupt latencies. In this
particular case there was an (unrelated) printout to the serial
console just before I saw the "Unexpected interrupt latency" printout.
...and actually, I managed to even reproduce the problems by running
"iw mlan0 scan > /dev/null" while mmc_test was running. That not only
does a bunch of PCIe traffic but it also (on my system) outputs some
SELinux log spam.
Change-Id: I56373c6740d38b5c45a078e835f594261bad78d2
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002767/)
In the commit 03de19212e ("mmc: dw_mmc: introduce timer for broken
command transfer over scheme") we tried to calculate the expected
hardware command timeout value. Unfortunately that calculation isn't
quite correct in all cases. It used "bus_hz" but, as far as I can
tell, it's supposed to use the card clock. Let's account for the div
value, which is documented as 2x the value stored in the register, or
1 if the register is 0.
NOTE: It's not expected that this will actually fix anything important
since the 10 ms margin added by the function will pretty much dwarf
any calculations. The card clock should be 100 kHz at minimum and:
1000 ms/s * (255 * 2) / 100000 Hz.
Gives us 5.1 ms.
...so really the point of this patch is just to make the code more
"correct" in case anyone ever tries to remove the 10 ms buffer.
Change-Id: Ie5d902edb3a5bdfb9dc9233eb46edbbee334994c
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002775/)
When running with the commit 03de19212e ("mmc: dw_mmc: introduce
timer for broken command transfer over scheme") I found this message
in the log:
Unexpected command timeout, state 7
It turns out that we weren't properly cancelling the new CTO timer in
the case that a voltage switch was done. Let's promote the cancel
into the dw_mci_cmd_interrupt() function to fix this.
Change-Id: I2ee3537eb7a756d64964cc49114011ad329409b8
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002779/)
[ Upstream commit 5ef1ecf060 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Helmut Klein <hgkr.klein@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LSK 17.06 v4.4-android
* tag 'lsk-v4.4-17.06-android': (134 commits)
ANDROID: sdcardfs: remove dead function open_flags_to_access_mode()
ANDROID: android-base.cfg: split out arm64-specific configs
usb: gadget: f_fs: Fix possibe deadlock
ANDROID: uid_sys_stats: check previous uid_entry before call find_or_register_uid
ANDROID: sdcardfs: d_splice_alias can return error values
android: base-cfg: disable CONFIG_NFS_FS and CONFIG_NFSD
schedstats/eas: guard properly to avoid breaking non-smp schedstats users
BACKPORT: f2fs: sanity check size of nat and sit cache
FROMLIST: f2fs: sanity check checkpoint segno and blkoff
sched/tune: don't use schedtune before it is ready
sched/fair: use SCHED_CAPACITY_SCALE for energy normalization
sched/{fair,tune}: use reciprocal_value to compute boost margin
sched/tune: Initialize raw_spin_lock in boosted_groups
sched/tune: report when SchedTune has not been initialized
sched/tune: fix sched_energy_diff tracepoint
sched/tune: increase group count to 5
cpufreq/schedutil: use boosted_cpu_util for PELT to match WALT
sched/fair: Fix sched_group_energy() to support per-cpu capacity states
sched/fair: discount task contribution to find CPU with lowest utilization
sched/fair: ensure utilization signals are synchronized before use
...
Per the databook of designware mmc controller 2.70a, table 3-2, cmd
done interrupt should be fired as soon as the the cmd is sent via
cmd line. And the response timeout interrupt should be generated
unconditioinally as well if the controller doesn't receive the resp.
However that doesn't seem to meet the fact of rockchip specified Soc
platforms using dwmmc. We have continuously found the the cmd done or
response timeout interrupt missed somehow which took us a long time to
understand what was happening. Finally we narrow down the root to
the reconstruction of sample circuit for dwmmc IP introduced by
rockchip and the buggy design sweeps over all the existing rockchip
Socs using dwmmc disastrously.
It seems no way to work around this bug without the proper break-out
mechanism so that we seek for a parallel pair the same as the handling
for missing data response timeout, namely dto timer. Adding this cto
timer seems easily to handle this bug but it's hard to restrict
the code under the rockchip specified context. So after merging this
patch, it sets up the cto timer for all the platforms using dwmmc IP
which isn't ideal but at least we don't advertise new quirk here.
Fortunately, no obvious performance regression was found by test and the
pre-existing similar catch-all timer for sdhci has proved it's an acceptant
way to make the code as robust as possible.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196321
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
[shawn.lin: rewrite the code and the commit msg throughout]
Change-Id: I47238c9758fe74b98a1dd3939f22e569261e696f
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/9834331/)
commit f5f968f237 upstream.
The stingray SDHCI hardware supports ACMD12 and automatically
issues after multi block transfer completed.
If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen
on multi block read command with below error message:
Got data interrupt 0x00000002 even though no data
operation was in progress.
This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable
ACM12 support in SDHCI hardware and suppress spurious interrupt.
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>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: b580c52d58 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* linux-linaro-lsk-v4.4-android: (521 commits)
Linux 4.4.66
ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram
ARCv2: save r30 on kernel entry as gcc uses it for code-gen
nfsd: check for oversized NFSv2/v3 arguments
Input: i8042 - add Clevo P650RS to the i8042 reset list
p9_client_readdir() fix
MIPS: Avoid BUG warning in arch_check_elf
MIPS: KGDB: Use kernel context for sleeping threads
ALSA: seq: Don't break snd_use_lock_sync() loop by timeout
ALSA: firewire-lib: fix inappropriate assignment between signed/unsigned type
ipv6: check raw payload size correctly in ioctl
ipv6: check skb->protocol before lookup for nexthop
macvlan: Fix device ref leak when purging bc_queue
ip6mr: fix notification device destruction
netpoll: Check for skb->queue_mapping
net: ipv6: RTF_PCPU should not be settable from userspace
dp83640: don't recieve time stamps twice
tcp: clear saved_syn in tcp_disconnect()
sctp: listen on the sock only when it's state is listening or closed
net: ipv4: fix multipath RTM_GETROUTE behavior when iif is given
...
Conflicts:
drivers/usb/dwc3/gadget.c
include/linux/usb/quirks.h
Change-Id: I490f766b9a530b10da3107e20709538e4536a99d
commit 9f32784535 upstream.
Currently for DDR50 card, it need tuning in default. We meet tuning fail
issue for DDR50 card and some data CRC error when DDR50 sd card works.
This is because the default pad I/O drive strength can't make sure DDR50
card work stable. So increase the pad I/O drive strength for DDR50 card,
and use pins_100mhz.
This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
commit 9faac7b95e ("mmc: sdhci: enable tuning for DDR50")
Tested-and-reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the eMMC 5.0 version of the spec, several EXT_CSD fields about
device lifetime are added.
- Two types of estimated indications reflected by averaged wear out of memory
- An indication reflected by average reserved blocks
Export the information through sysfs.
Signed-off-by: Jungseung Lee <js07.lee@samsung.com>
Reviewed-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>
commit e2ebfb2142 upstream.
Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when sdhci changes clock frequency because it
waits for the clock to become stable under a spin lock.
The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.
Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 181302dc72 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: 53f3a9e26e ("mmc: USB SD Host Controller (USHC) driver")
Cc: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need a luxury timeout once needing some extra time to
wait for flushing cache.
Change-Id: I8cd4015f30fa45cacdb984f0461b1ad8ee6cba7d
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
The "clock-freq-min-max" property was deprecated.
There is "max-frequency" property in drivers/mmc/core/host.c
"max-frequency" can be replaced with "clock-freq-min-max".
Minimum clock value might be set to 100K by default.
Then MMC core should try to find the correct value from 400K to 100K.
So it just needs to set Maximum clock value.
Change-Id: I1c72a891c8afd221b0c395c32c7adf8696cc46f1
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit b023030f10)
If there is no property "clock-freq-min-max", mmc->f_min should be set
to 400K by default. But Some SoC can be used 100K.
When 100K is used, MMC core will try to check from 400K to 100K.
Change-Id: I059c994f1654c212bcff9b85dbffd9697d800eaf
Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 72e83577bc)
HS400-ES devices fail to initialize with the following error messages.
mmc1: power class selection to bus width 8 ddr 0 failed
mmc1: error -110 whilst initialising MMC card
This was seen on Samsung Chromebook Plus. Code analysis points to
commit 3d4ef32975 ("mmc: core: fix multi-bit bus width without
high-speed mode"), which attempts to set the bus width for all but
HS200 devices unconditionally. However, for HS400-ES, the bus width
is already selected.
Change-Id: I877b225a2ab9da623061288b2f908e956754107a
Cc: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Fixes: 3d4ef32975 ("mmc: core: fix multi-bit bus width ...")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
commit 3d4ef32975 upstream.
Commit 577fb13199 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().
However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.
This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.
Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.
Tested with a Zynq-7000 PicoZed 7020 board.
Fixes: 577fb13199 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[anssi.hannula@bitwise.fi: backported for the different err variable
check on v4.4 and tested]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
