Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 5月, 2016 8 次提交
  3. 29 3月, 2016 1 次提交
    • A
      mmc: sdhci: Fix regression setting power on Trats2 board · 1dceb041
      由 Adrian Hunter 提交于 
      Several commits relating to setting power have been introducing
problems by putting driver-specific rules into generic SDHCI code.

Krzysztof Kozlowski reported that after commit 918f4cbd ("mmc:
sdhci: restore behavior when setting VDD via external regulator")
on Trats2 board there are warnings for invalid VDD  value (2.8V):

[    3.119656] ------------[ cut here ]------------
[    3.119666] WARNING: CPU: 3 PID: 90 at
../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
[    3.119669] mmc0: Invalid vdd 0x10
[    3.119673] Modules linked in:
[    3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G        W
   4.5.0-next-20160324 #23
[    3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    3.119690] Workqueue: events_freezable mmc_rescan
[    3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
(show_stack+0x10/0x14)
[    3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
(dump_stack+0x88/0x9c)
[    3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
[    3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
(warn_slowpath_fmt+0x38/0x48)
[    3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
(sdhci_do_set_ios+0x4cc/0x5e0)
[    3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
(sdhci_runtime_resume_host+0x60/0x114)
[    3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
[<c0402570>] (__rpm_callback+0x2c/0x60)
[    3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
(rpm_callback+0x20/0x80)
[    3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
(rpm_resume+0x36c/0x558)
[    3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
(__pm_runtime_resume+0x4c/0x64)
[    3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
(__mmc_claim_host+0x170/0x1b0)
[    3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
(mmc_rescan+0x54/0x348)
[    3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
(process_one_work+0x120/0x3f4)
[    3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
(worker_thread+0x38/0x554)
[    3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
(kthread+0xdc/0xf4)
[    3.119831] [<c01365a4>] (kthread) from [<c0107878>]
(ret_from_fork+0x14/0x3c)
[    3.119834] ---[ end trace a22d652aa3276886 ]---

Fix by adding a 'set_power' callback and restoring the default
behaviour prior to commit 918f4cbd ("mmc: sdhci: restore
behavior when setting VDD via external regulator").  The desired
behaviour of that commit is gotten by having sdhci-pxav3 provide
its own set_power callback.
Reported-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
Fixes: 918f4cbd ("mmc: sdhci: restore behavior when setting VDD...)
Tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: NJisheng Zhang <jszhang@marvell.com>
Tested-by: NJisheng Zhang <jszhang@marvell.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NAnand Moon <linux.amoon@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      1dceb041
  5. 18 3月, 2016 1 次提交
  7. 17 3月, 2016 1 次提交
    • A
      mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout · 99513624
      由 Adrian Hunter 提交于 
      Normally the timeout clock frequency is read from the capabilities
register.  It is also possible to set the value prior to calling
sdhci_add_host() in which case that value will override the
capabilities register value.  However that was being done after
calculating max_busy_timeout so that max_busy_timeout was being
calculated using the wrong value of timeout_clk.

Fix that by moving the override before max_busy_timeout is
calculated.

The result is that the max_busy_timeout and max_discard
increase for BSW devices so that, for example, the time for
mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds
to about 20 seconds.

Note, in the future, the capabilities setting will be tidied up
and this override won't be used anymore.  However this fix is
needed for stable.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      99513624
  9. 29 2月, 2016 22 次提交
  11. 11 2月, 2016 2 次提交
    • A
      mmc: sdhci: Allow override of get_cd() called from sdhci_request() · 8d28b7a7
      由 Adrian Hunter 提交于 
      Drivers may need to provide their own get_cd() mmc host op, but
currently the internals of the current op (sdhci_get_cd()) are
provided by sdhci_do_get_cd() which is also called from
sdhci_request().

To allow override of the get_cd functionality, change sdhci_request()
to call ->get_cd() instead of sdhci_do_get_cd().

Note, in the future the call to ->get_cd() will likely be removed
from sdhci_request() since most drivers don't need actually it.
However this change is being done now to facilitate a subsequent
bug fix.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      8d28b7a7
    • A
      mmc: sdhci: Allow override of mmc host operations · bf60e592
      由 Adrian Hunter 提交于 
      In the past, fixes for specific hardware devices were implemented
in sdhci using quirks.  That approach is no longer accepted because
the growing number of quirks was starting to make the code difficult
to understand and maintain.

One alternative to quirks, is to allow drivers to override the default
mmc host operations.  This patch makes it easy to do that, and it is
needed for a subsequent bug fix, for which separate patches are
provided.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      bf60e592
  13. 28 12月, 2015 1 次提交
    • 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
  15. 22 12月, 2015 4 次提交
    • 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: 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