Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 2月, 2016 1 次提交
  3. 10 2月, 2016 1 次提交
  5. 08 2月, 2016 2 次提交
  7. 02 2月, 2016 2 次提交
  9. 21 1月, 2016 1 次提交
  11. 20 1月, 2016 1 次提交
  13. 19 1月, 2016 1 次提交
  15. 14 1月, 2016 6 次提交
  17. 13 1月, 2016 1 次提交
    • R
      mmc: sd: limit SD card power limit according to cards capabilities · d9812780
      由 Russell King 提交于 
      The SD card specification allows cards to error out a SWITCH command
where the requested function in a group is not supported.  The spec
provides for a set of capabilities which indicate which functions are
supported.

In the case of the power limit, requesting an unsupported power level
via the SWITCH command fails, resulting in the power level remaining at
the power-on default of 0.72W, even though the host and card may support
higher powers levels.

This has been seen with SanDisk 8GB cards, which support the default
0.72W and 1.44W (200mA and 400mA) in combination with an iMX6 host,
supporting up to 2.88W (800mA).  This currently causes us to try to set
a power limit function value of '3' (2.88W) which the card errors out
on, and thereby causes the power level to remain at 0.72W rather than
the desired 1.44W.

Arrange to limit the selected current limit by the capabilities reported
by the card to avoid the SWITCH command failing.  Select the highest
current limit that the host and card combination support.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Fixes: a39ca6ae ("mmc: core: Simplify and fix for SD switch processing")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d9812780
  19. 06 1月, 2016 5 次提交
  21. 28 12月, 2015 7 次提交
    • L
      mmc: tegra: implement UHS tuning · c3c2384c
      由 Lucas Stach 提交于 
      This implements the UHS tuning sequence in a similar way to the one
contained in the TRM. It deviates in the way how to check if the tap
value is passing, by using the common Linux MMC function, which does
not only check for data CRC errors, but also if the received block
pattern is correct.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c3c2384c
    • L
      mmc: tegra: disable SPI_MODE_CLKEN · 74cd42bc
      由 Lucas Stach 提交于 
      The Tegra30 and up TRM states that this bit should always be
programmed to 0 by driver software.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      74cd42bc
    • L
      mmc: tegra: implement module external clock change · a8e326a9
      由 Lucas Stach 提交于 
      Allow the the driver to change the clock supplied from the CAR directly,
minimizing the need to divide the clock inside the SDMMC module itself.

This allows for higher clock speeds than the default 48MHz supplied to
the module and is a prerequisite to support DDR signaling modes, where
the Tegra host needs to be run with a fixed internal divider of 2 for
data to be sampled correctly. (Tegra K1 TRM v03p chapter 29.7.1.1)

Also enable the broken preset value quirk as the preset values need to
be adapted to the changed clocking. While Tegra114+ allows this through
vendor registers, there is no such way for Tegra30. Takes the easy way
out  and keep things consistent between the different SoC generations by
flagging the preset registers as unusable.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a8e326a9
    • J
      mmc: sdhci: restore behavior when setting VDD via external regulator · 918f4cbd
      由 Jisheng Zhang 提交于 
      After commit 52221610 ("mmc: sdhci: Improve external VDD regulator
support"), for the VDD is supplied via external regulators, we ignore
the code to convert a VDD voltage request into one of the standard
SDHCI voltage levels, then program it in the SDHCI_POWER_CONTROL. This
brings two issues:

1. SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk isn't handled properly any
more.

2. What's more, once SDHCI_POWER_ON bit is set, some controllers such
as the sdhci-pxav3 used in marvell berlin SoCs require the voltage
levels programming in the SDHCI_POWER_CONTROL register, even the VDD
is supplied by external regulator. So the host in marvell berlin SoCs
still works fine after the commit. However, commit 3cbc6123 ("mmc:
sdhci: Set SDHCI_POWER_ON with external vmmc") sets the SDHCI_POWER_ON
bit, this would make the host in marvell berlin SoCs won't work any
more with external vmmc.

This patch restores the behavior when setting VDD through external
regulator by moving the call of mmc_regulator_set_ocr() to the end
of sdhci_set_power() function.

After this patch, the sdcard on Marvell Berlin SoC boards work again.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Fixes: 52221610 ("mmc: sdhci: Improve external VDD ...")
Reviewed-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Tested-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      918f4cbd
    • A
      mmc: It is not an error for the card to be removed while suspended · 520322d9
      由 Adrian Hunter 提交于 
      A card can be removed while it is runtime suspended.
Do not print an error message.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      520322d9
    • C
      mmc: block: Allow more than 8 partitions per card · 382c55f8
      由 Colin Cross 提交于 
      It is quite common for Android devices to utilize more
then 8 partitions on internal eMMC storage.

The vanilla kernel can support this via
CONFIG_MMC_BLOCK_MINORS, however that solution caps the
system to 256 minors total, which limits the number of
mmc cards the system can support.

This patch, which has been carried for quite awhile in
the AOSP common tree, provides an alternative solution
that doesn't seem to limit the total card count. So I
wanted to submit it for consideration upstream.

This patch sets the GENHD_FL_EXT_DEVT flag, which will
allocate minor number in major 259 for partitions past
disk->minors.

It also removes the use of disk_devt to determine devidx
from md->disk. md->disk->first_minor is always initialized
from devidx and can always be used to recover it.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Android Kernel Team <kernel-team@android.com>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: NColin Cross <ccross@android.com>
[jstultz: Added context to commit message]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      382c55f8
    • U
      mmc: core: Optimize boot time by detecting cards simultaneously · 520bd7a8
      由 Ulf Hansson 提交于 
      The mmc workqueue is an ordered workqueue, allowing only one work to
execute per given time. As this workqueue is used for card detection, the
conseqeunce is that cards will be detected one by one waiting for each
other.

Moreover, most of the time spent during card initialization is waiting for
the card's internal firmware to be ready. From a CPU perspective this
typically means waiting for a completion variable to be kicked via an
IRQ-handler or waiting for a sleep timer to finish.

This behaviour of detecting/initializing cards is sub-optimal, especially
for SOCs having several controllers/cards.

Let's convert to use the system_freezable_wq for the mmc detect works.
This enables several works to be executed simultaneously and thus also
cards to be detected like so.

Tests on UX500, which holds two eMMC cards and an SD-card (actually also
an SDIO card, currently not detected), shows a significant improved
behaviour due to this change.

Before this change, both the eMMC cards waited for the SD card to be
initialized as its detect work entered the workqueue first. In some cases,
depending on the characteristic of the SD-card, they got delayed 1-1.5 s.

Additionally for the second eMMC, it needed to wait for the first eMMC to
be initialized which added another 120-190 ms.

Converting to the system_freezable_wq, removed these delays and made both
the eMMC cards available far earlier in the boot sequence.

Selecting the system_freezable_wq, in favour of for example the system_wq,
is because we need card detection mechanism to be disabled once userspace
are frozen during system PM. Currently the mmc core deal with this via PM
notifiers, but following patches may utilize the behaviour of the
system_freezable_wq, to simplify the use of the PM notifiers.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NAlan Cooper <alcooperx@gmail.com>
Tested-by: NShawn Lin <shawn.lin@rock-chips.com>
      520bd7a8
  23. 22 12月, 2015 12 次提交
    • A
      mmc: dw_mmc: use resource_size_t to store physical address · 260b3164
      由 Arnd Bergmann 提交于 
      The dw_mmc driver stores the physical address of the MMIO registers
in a pointer, which requires the use of type casts, and is actually
broken if anyone ever has this device on a 32-bit SoC in registers
above 4GB. Gcc warns about this possibility when the driver is built
with ARM LPAE enabled:

mmc/host/dw_mmc.c: In function 'dw_mci_edmac_start_dma':
mmc/host/dw_mmc.c:702:17: warning: cast from pointer to integer of different size
  cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);
                 ^
mmc/host/dw_mmc-pltfm.c: In function 'dw_mci_pltfm_register':
mmc/host/dw_mmc-pltfm.c:63:19: warning: cast to pointer from integer of different size
  host->phy_regs = (void *)(regs->start);

This changes the code to use resource_size_t, which gets rid of the
warning, the bug and the useless casts.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      260b3164
    • C
      mmc: core: fix __mmc_switch timeout caused by preempt · 3bbb0dee
      由 Chaotian Jing 提交于 
      there is a time window between __mmc_send_status() and time_afer(),
on some eMMC chip, the timeout_ms is only 10ms, if this thread was
scheduled out during this period, then, even card has already changes
to transfer state by the result of CMD13, this part of code also treat
it to timeout error.
So, need calculate timeout first, then call __mmc_send_status(), if
already timeout and card still in programing state, then treat it to
the real timeout error.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3bbb0dee
    • R
      mmc: usdhi6rol0: handle NULL data in timeout · 05caee93
      由 Rabin Vincent 提交于 
      Commit bb08a7d4 ("mmc: usdhi6rol0: fix NULL pointer deref in debug
print") fixed one NULL pointer dereference but unfortunately introduced
another.  "data" may be NULL if this is a command timeout for a command
without any data, so we should only use it if we're actually waiting for
data.

Fixes: bb08a7d4 ("mmc: usdhi6rol0: fix NULL pointer deref in debug print")
Cc: stable@vger.kernel.org # v4.3
Signed-off-by: NRabin Vincent <rabin.vincent@axis.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      05caee93
    • S
      mmc: of_mmc_spi: Add IRQF_ONESHOT to interrupt flags · 60b71f60
      由 saurabh 提交于 
      If no primary handler is specified for threaded_irq then a
default one is assigned which always returns IRQ_WAKE_THREAD.
This handler requires the IRQF_ONESHOT, because the source of
interrupt is not disabled
Signed-off-by: NSaurabh Sengar <saurabh.truth@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      60b71f60
    • C
      mmc: mediatek: change some dev_err to dev_dbg · 2066fd28
      由 Chaotian Jing 提交于 
      there are too many error logs shown when use CMD21/CMD19 to do tune,
and it will appear at each resume time, print out so many logs to the
uart console cost too mush time. so change it to dev_dbg.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2066fd28
    • F
      mmc: enable MMC/SD/SDIO device to suspend/resume asynchronously · ec076cd2
      由 Fu, Zhonghui 提交于 
      Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition dependency between devices. This patch
enables MMC/SD/SDIO card and SDIO function devices to suspend/resume
asynchronously. This will take advantage of multicore and improve
system suspend/resume speed. After applying this patch and enabling
all SDIO function's child devices to suspend/resume asynchronously
on ASUS T100TA, the system suspend-to-idle time is reduced from
1645ms to 1108ms, and the system resume time is reduced from 940ms
to 918ms.
Signed-off-by: NZhonghui Fu <zhonghui.fu@linux.intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ec076cd2
    • A
      mmc: sdhci: Fix sdhci_runtime_pm_bus_on/off() · 5c671c41
      由 Adrian Hunter 提交于 
      sdhci has a legacy facility to prevent runtime suspend if the
bus power is on.  This is needed in cases where the power to
the card is dependent on the bus power.  It is controlled by
a pair of functions: sdhci_runtime_pm_bus_on() and
sdhci_runtime_pm_bus_off().  These functions use a boolean
variable 'bus_on' to ensure changes are always paired.
There is an additional check for 'runtime_suspended' which is
the problem.  In fact, its use is ill-conceived as the only
requirement for the logic is that 'on' and 'off' are paired,
which is actually broken by the check, for example if the bus
power is turned on during runtime resume.  So remove  the check.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      5c671c41
    • A
      mmc: sdhci: 64-bit DMA actually has 4-byte alignment · 04a5ae6f
      由 Adrian Hunter 提交于 
      The version 3.00 SDHCI spec. was a bit unclear about the
required data alignment for 64-bit DMA, whereas the version
4.10 spec. uses different language and indicates that only
4-byte alignment is required rather than the 8-byte alignment
currently implemented.  That make no difference to SD and EMMC
which invariably transfer data in sector-aligned blocks.
However with SDIO, it results in using more DMA descriptors
than necessary.  Theoretically that slows DMA slightly although
DMA is not the limiting factor for throughput, so there is no
discernable impact on performance.  Nevertheless, the driver
should follw the spec unless there is good reason not to, so
this patch corrects the alignment criterion.

There is a more complicated criterion for the DMA descriptor
table itself.  However the table is allocated by dma_alloc_coherent()
which allocates pages (i.e. aligned to a page boundary).
For simplicity just check it is 8-byte aligned, but add a comment
that some Intel controllers actually require 8-byte alignment
even when using 32-bit DMA.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      04a5ae6f
    • A
      mmc: sdhci: Fix DMA descriptor with zero data length · 347ea32d
      由 Adrian Hunter 提交于 
      SDHCI has built-in DMA called ADMA2.  ADMA2 uses a descriptor
table to define DMA scatter-gather.  Each desciptor can specify
a data length up to 65536 bytes, however the length field is
only 16-bits so zero means 65536.  Consequently, putting zero
when the size is zero must not be allowed.  This patch fixes
one case where zero data length could be set inadvertently.

The problem happens because unaligned data gets split and the
code did not consider that the remaining aligned portion might
be zero length.  That case really only happens for SDIO because
SD and eMMC cards transfer blocks that are invariably sector-
aligned.  For SDIO, access to function registers is done by
data transfer (CMD53) when the register is bigger than 1 byte.
Generally registers are 4 bytes but 2-byte registers are possible.
So DMA of 4 bytes or less can happen.  When 32-bit DMA is used,
the data alignment must be 4, so 4-byte transfers won't casue a
problem, but a 2-byte transfer could.  However with the introduction
of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes,
so all 4-byte transfers not on 8-byte boundaries get "split" into
a 4-byte chunk and a 0-byte chunk, thereby hitting the bug.

In fact, a closer look at the SDHCI specs indicates that only the
descriptor table requires 8-byte alignment for 64-bit DMA.  That
will be dealt with in a separate patch, but the potential for a
2-byte access remains, so this fix is needed anyway.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      347ea32d
    • A
      mmc: sdio: Fix invalid vdd in voltage switch power cycle · d9bfbb95
      由 Adrian Hunter 提交于 
      The 'ocr' parameter passed to mmc_set_signal_voltage()
defines the power-on voltage used when power cycling
after a failure to set the voltage.  However, in the
case of mmc_sdio_init_card(), the value passed has the
R4_18V_PRESENT flag set which is not valid for power-on
and results in an invalid vdd.  Fix by passing the card's
ocr value which does not have the flag.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d9bfbb95
    • A
      mmc: sdhci: Do not BUG on invalid vdd · 9d5de93f
      由 Adrian Hunter 提交于 
      The driver may not be able to set the power correctly but that
is not a reason to BUG().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NVenu Byravarasu <vbyravarasu@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9d5de93f
    • A
      mmc: sdhci-pci: Do not default to 33 Ohm driver strength for Intel SPT · 1ca89685
      由 Adrian Hunter 提交于 
      In some cases, the stronger 33 Ohm driver strength must not be used
so it is not a suitable default.  Change it to the standard default
50 Ohm value.

The patch applies to v4.2+ except the file name changed.  It is
drivers/mmc/host/sdhci-pci.c prior to v.4.4.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      1ca89685