IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A UHS setting of SDR25 can give better results for High Speed mode.
This is because there is no setting corresponding to high speed. Currently
SDHCI sets no value, which means zero which is also the setting for SDR12.
There was an attempt to change this in sdhci.c but it caused problems for
some drivers, so it was reverted and the change was made to sdhci-brcmstb
in commit 2fefc7c5f7 ("mmc: sdhci-brcmstb: Fix incorrect switch to HS
mode"). Several other drivers also do this.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v5.4+
Link: https://lore.kernel.org/r/20201112133656.20317-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Pull MMC host fixes from Ulf Hansson:
- sdhci: Fix performance regression with auto CMD auto select
- sdhci-of-esdhc: Fix initialization for eMMC HS400 mode
- sdhci-of-esdhc: Fix timeout bug for tuning commands
* tag 'mmc-v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-of-esdhc: make sure delay chain locked for HS400
mmc: sdhci-of-esdhc: set timeout to max before tuning
mmc: sdhci: Use Auto CMD Auto Select only when v4_mode is true
Pull ARM SoC platform updates from Olof Johansson:
"SoC changes, a substantial part of this is cleanup of some of the
older platforms that used to have a bunch of board files.
In particular:
- Remove non-DT i.MX platforms that haven't seen activity in years,
it's time to remove them.
- A bunch of cleanup and removal of platform data for TI/OMAP
platforms, moving over to genpd for power/reset control (yay!)
- Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
closer to multiplatform support (not quite there yet, but getting
close).
There are a few other changes too, smaller fixlets, etc. For new
platform support, the primary ones are:
- New SoC: Hisilicon SD5203, ARM926EJ-S platform.
- Cpufreq support for i.MX7ULP"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits)
ARM: mstar: Select MStar intc
ARM: stm32: Replace HTTP links with HTTPS ones
ARM: debug: add UART early console support for SD5203
ARM: hisi: add support for SD5203 SoC
ARM: omap3: enable off mode automatically
clk: imx: imx35: Remove mx35_clocks_init()
clk: imx: imx31: Remove mx31_clocks_init()
clk: imx: imx27: Remove mx27_clocks_init()
ARM: imx: Remove unused definitions
ARM: imx35: Retrieve the IIM base address from devicetree
ARM: imx3: Retrieve the AVIC base address from devicetree
ARM: imx3: Retrieve the CCM base address from devicetree
ARM: imx31: Retrieve the IIM base address from devicetree
ARM: imx27: Retrieve the CCM base address from devicetree
ARM: imx27: Retrieve the SYSCTRL base address from devicetree
ARM: s3c64xx: bring back notes from removed debug-macro.S
ARM: s3c24xx: fix Wunused-variable warning on !MMU
ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
MAINTAINERS: mark linux-samsung-soc list non-moderated
ARM: imx: Remove remnant board file support pieces
...
On rare occations there is the following error:
mmc0: Tuning timeout, falling back to fixed sampling clock
There are SD cards which takes a significant longer time to reply to the
first CMD19 command. The eSDHC takes the data timeout value into account
during the tuning period. The SDHCI core doesn't explicitly set this
timeout for the tuning procedure. Thus on the slow cards, there might be
a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong
sequence of events. In the end this will lead to an unsuccessful tuning
procedure and to the above error.
To workaround this, set the timeout to the maximum value (which is the
best we can do) and the SDHCI core will take care of the proper timeout
handling.
Fixes: ba49cbd093 ("mmc: sdhci-of-esdhc: add tuning support")
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201022222337.19857-1-michael@walle.cc
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci-of-dwcmshc meets an eMMC read performance regression with below
command after commit 427b6514d0 ("mmc: sdhci: Add Auto CMD Auto
Select support"):
dd if=/dev/mmcblk0 of=/dev/null bs=8192 count=100000
Before the commit, the above command gives 120MB/s
After the commit, the above command gives 51.3 MB/s
So it looks like sdhci-of-dwcmshc expects Version 4 Mode for Auto
CMD Auto Select. Fix the performance degradation by ensuring v4_mode
is true to use Auto CMD Auto Select.
Fixes: 427b6514d0 ("mmc: sdhci: Add Auto CMD Auto Select support")
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201015174115.4cf2c19a@xhacker.debian
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This change fixes HS400 tuning for devices with invalid presets.
SDHCI presets are not currently used for eMMC HS/HS200/HS400, but are
used for DDR52. The HS400 retuning sequence is:
HS400->DDR52->HS->HS200->Perform Tuning->HS->HS400
This means that when HS400 tuning happens, we transition through DDR52
for a very brief period. This causes presets to be enabled
unintentionally and stay enabled when transitioning back to HS200 or
HS400. Some firmware has invalid presets, so we end up with driver
strengths that can cause I/O problems.
Fixes: 34597a3f60 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400")
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200928154718.1.Icc21d4b2f354e83e26e57e270dc952f5fe0b0a40@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
With the new SW tuning App note[1], a custom tuning algorithm is
required for eMMC HS200, HS400 and SD card UHS modes. The algorithm
involves running through the 32 possible input tap delay values and
sending the appropriate tuning command (CMD19/21) for each of them
to get a fail or pass result for each of the values. Typically, the
range will have a small contiguous failing window. Considering the
tuning range as a circular buffer, the algorithm then sets a final
tuned value directly opposite to the failing window.
[1] https://www.ti.com/lit/pdf/spract9
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20200923105206.7988-6-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
DLL need only be enabled for speed modes and clock frequencies at or
above 50 MHz. For speed modes that don't enable the DLL, we need to
configure a static input delay value. This involves reading an optional
itap-del-sel-* value from the device tree and configuring it for the
appropriate speed mode.
With this addition, make sure that DLL is always switched off at the
beginning of the set_clock() call to simplify configuration. This also
removes the need for the dll_on member in struct sdhci_am654_data.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Link: https://lore.kernel.org/r/20200923105206.7988-5-faiz_abbas@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The bit ESDHC_PERIPHERAL_CLK_SEL to select using peripheral clock
or platform clock is not able to be reset by SDHCI_RESET_ALL.
So driver needs to initialize it as 1 or 0 once, to override the
different value which may be configured in bootloader.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Link: https://lore.kernel.org/r/20200927082304.9232-1-yangbo.lu@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The struct of_device_id is not defined with !CONFIG_OF so its forward
declaration should be hidden to as well. This should address clang
compile warning:
drivers/mmc/host/sdhci-s3c.c:464:34: warning: tentative array definition assumed to have one element
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200925072532.10272-1-krzk@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The 'struct mmc_host *mmc' comes from drvdata set at the end of probe,
so it cannot be NULL. The code already dereferences it few lines before
the check with mmc_priv(). This also fixes smatch warning:
drivers/mmc/host/moxart-mmc.c:692 moxart_remove() warn: variable dereferenced before check 'mmc' (see line 688)
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200923153739.30327-1-krzk@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The MediaTek MMC driver uses pointer to get from private
msdc_host structure to the generic mmc_host structure.
However mmc_host always precedes msdc_host in memory so compute
its address with a subtraction (which is cheaper than a dereference)
using mmc_from_priv() and drop the extra pointer.
Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Link: https://lore.kernel.org/r/20200917192624.548720-1-ameynarkhede03@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If CONFIG_NO_DMA=y (e.g. Sun-3 allmodconfig):
drivers/mmc/host/mmc_spi.c:1323:15: warning: return type defaults to ‘int’ [-Wreturn-type]
static inline mmc_spi_dma_alloc(struct mmc_spi_host *host) { return 0; }
^~~~~~~~~~~~~~~~~
Fix this by adding the missing return type.
Fixes: a395acf0f6 ("mmc: mmc_spi: Allow the driver to be built when CONFIG_HAS_DMA is unset")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20200914094243.3912-1-geert@linux-m68k.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Samsung S3C24xx and S3C64xx machine code cleanup for v5.10
Big cleanup for the Samsung S3C24xx and S3C64xx platforms, although it
also touches files shared with S5Pv210 and Exynos. This is mostly Arnd
Bergmann work which Krzysztof Kozlowski took over, rebased and polished.
The goal is to cleanup, merge and finally make the Samsung S3C24xx and
S3C64xx architectures multiplatform. The multiplatform did not happen
yet here - just cleaning up and merging into one arch/arm/mach-s3c
directory. However this is step forward for multiplatform or at least
to keep this code still maintainable.
This pulls also branch with changes for Samsung SoC sound drivers from
broonie/sound because the cleanups there were part of this series and
all further patches depend on them.
* tag 'samsung-soc-s3c-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: (62 commits)
ARM: s3c: Avoid naming clash of S3C24xx and S3C64xx timer setup
ARM: s3c: Cleanup from old plat-samsung include
ARM: s3c: make headers local if possible
ARM: s3c: move into a common directory
ARM: s3c24xx: stop including mach/hardware.h from mach/io.h
cpufreq: s3c24xx: move low-level clk reg access into platform code
cpufreq: s3c2412: use global s3c2412_cpufreq_setrefresh
ARM: s3c: remove cpufreq header dependencies
cpufreq: s3c24xx: split out registers
fbdev: s3c2410fb: remove mach header dependency
ARM: s3c24xx: bast: avoid irq_desc array usage
ARM: s3c24xx: spi: avoid hardcoding fiq number in driver
ARM: s3c24xx: include mach/irqs.h where needed
ARM: s3c24xx: move s3cmci pinctrl handling into board files
ARM: s3c24xx: move iis pinctrl config into boards
ARM: s3c24xx: move spi fiq handler into platform
ARM: s3c: adc: move header to linux/soc/samsung
ARM: s3c24xx: move irqchip driver back into platform
ARM: s3c24xx: move regs-spi.h into spi driver
ARM: s3c64xx: remove mach/hardware.h
...
Link: https://lore.kernel.org/r/20200831154751.7551-1-krzk@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
Some R-Car Gen3 SoCs need some manual correction of timing parameters
after the automatic tuning has finished but before next CMD13 is
completed. This patch implements that by this state machine:
- introducing a per-SoC correction table if needed
- iff such a table exists, the 'fixup_request' callback is populated
during probe
- iff such a table exists, a runtime flag ('needs_adjust_hs400')
is set when HS400 tuning was completed
- the callback will check the runtime flag and enable the corrected
manual mode if the flag is set and CMD13 is encountered
- at the end of the enablement the runtime flag is cleared
- iff the configuration flag is set, the manual mode will be disabled
when HS400 gets downgraded
There also some helper functions added to access the TMPPORT registers.
The actual correction table is SoC and instance(!) specific and is
added to the quirks struct.
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20200902081812.1591-3-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
