mmc: sdhci: use the SDHCI_QUIRK_USE_WIDE8 for samsung SoC

Samsung SoC is supported the WIDE8, even if Controller version is v2.0.
So add the SDHCI_QUIRK_USE_WIDE8 for Samsung-SoC.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
mmc: Remove unused variable backup from mmc_send_cmd()

Do not call a memset for unused variable backup every time.
Remove unused variable from function.

Signed-off-by: Oleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
omap_hsmmc: omap4+/am335x: modify MMC controller internal fsm reset func

"mmc_send_cmd: timeout: No status update" error sometimes happens in
omap_hsmmc driver func mmc_send_cmd() when the MMC controller card
identification and selection sequence is executed for eMMC on OMAP4
boards.

It happens due to incorrect execution of CMD line reset procedure
for OMAP4. Because CMD(DAT) lines reset procedures are slightly
different for OMAP3 and OMAP4(AM335x,OMAP5,DRA7xx).

According to OMAP3 TRM:
Set SRC(SRD) bit in MMCHS_SYSCTL register to 0x1 and wait until
it returns to 0x0.

According to OMAP4(AM335x,OMAP5,DRA7xx) TRMs, CMD(DATA) lines reset
procedure steps must be as follows:
1. Initiate CMD(DAT) line reset by writing 0x1 to SRC(SRD) bit in
   MMCHS_SYSCTL register (SD_SYSCTL for AM335x).
2. Poll the SRC(SRD) bit until it is set to 0x1.
3. Wait until the SRC(SRD) bit returns to 0x0
  (reset procedure is completed).

Unfortunately, at present omap_hsmmc driver has support only for
OMAP3. And as result step #2 is missing for OMAP4(AM335x,OMAP5,DRA7xx).
This sometimes leads to the fact that the waiting loop which is
required in step #3 does not executed, because SRC bit does not set
yet (at the moment of checking a condition of a loop execution).
And as a result this can cause to timeout error when sending a
next command.

In the particular case (working with eMMC witch do not respond to
some SD specific command) due to incorrect reset sequence after
command SD_CMD_SEND_IF_COND which finished with CTO flag within
64 clock cycles, the next command MMC_CMD_APP_CMD leads to a
timeout error within 1s.

So, extend CMD(DATA) lines reset procedure in func
mmc_reset_controller_fsm() by adding the missing step #2 for
OMAP4+/AM335x boards.

Signed-off-by: Oleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
ARM: OMAP: Enable 8-bit eMMC access for OMAP4/5/DRA7xx

Enable 8-bit host capability for HSMMC2 and/or HSMMC3. CONFIG_HSMMC2_8BIT
(for OMAP4/5/DRA7xx) and/or CONFIG_HSMMC3_8BIT (for DRA7xx only) must be
defined in the board header if an 8-bit eMMC device is connected to the
corresponding port.

Fix the "No status update" error that appeared for eMMC devices by
inserting a 20 us delay between writing arguments and command. This
solution has been proposed by Michael Cashwell <mboards@prograde.net>.

A minor cosmetic fix in a comment as well.

Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
spl: remove unnecessary (& ARM specific) include of asm/utils.h

ARM is the only architecture which includes this header and nothing in
spl_mmc.c makes use of it. Remove the include.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT

If we don't have CONFIG_SPL_LIBCOMMON_SUPPORT defined then stdio
functions are unavailable & calling them will cause a link failure.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
mmc: don't call *printf or puts when SPL & !CONFIG_SPL_LIBCOMMON_SUPPORT

If we don't have CONFIG_SPL_LIBCOMMON_SUPPORT defined then stdio
& *printf functions are unavailable & calling them will cause a link
failure.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
mmc: size optimization when !CONFIG_MMC_SPI

When CONFIG_MMC_SPI is not enabled, the MMC_MODE_SPI capability can
never be set. However there is code in mmc.c which uses the
mmc_host_is_spi macro to check that capability & act accordingly. If we
expand that macro to 0 when CONFIG_MMC_SPI is not set (since it will
always be 0 at runtime anyway) then the compiler can optimize away the
SPI-specific code paths in mmc.c.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
bootm: use BOOTM_STATE_OS_CMDLINE flag for plain bootm

A plain bootm used to call the architecture specific boot function with
no flags, but was modified by commit 35fc84fa "Refactor the bootm
command to reduce code duplication" to call the architecture specific
boot function multiple times with various flags in sequence. The
BOOTM_STATE_OS_CMDLINE flag was not used, indeed it seems that at least
ARM prepares the command line on BOOTM_STATE_OS_PREP. However on MIPS
since commit 59e8cbdb "MIPS: bootm: refactor initialisation of kernel
cmdline" the command line is not prepared in response to a
BOOTM_STATE_OS_PREP flag, only on BOOTM_STATE_OS_CMDLINE or a call with
no flags. The end result is that a combination of those 2 commits leads
to MIPS boards booting kernels with no command line arguments.

An extra invocation of the architecture specific boot function with
BOOTM_STATE_OS_CMDLINE fixes this.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fix some obvious typos across multiple subsystems.

Typoes fixed:

  "partion" -> "partition"
  "retrive", "retreive" -> "retrieve"
  "th" -> "to"

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Fix loading freeze when netconsole is active

Netconsole calls eth_halt() before giving control to another operating
system.
But the state machine of netconsole don't take it into account.
Thus, netconsole calls network functions of an halted network device,
making the whole system freeze.
Rather than modifying the state machine of netconsole, we just unregister
the current network device before booting. It does work because
nc_send_packet() verifies that the current network device is not null.

Signed-off-by: Frédéric Leroy <fredo@starox.org>
part_efi: make sure the gpt_pte is freed

the gpt_pte wasn't being freed if it was checked against an invalid
partition. The resulting memory leakage could make it impossible
to repeatedly attempt to load non-existent files in a script.

Also, downgrade the message for not finding an invalid partition
from a printf() to a debug() so as to minimize message spam in
perfectly normal situations.

Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
boards.cfg: Fix the comment for invoking tools/reformat.py from vim

Add the missing bang (!) to execute external command, otherwise it does not
work.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
boards.cfg: show info about boards.cfg instead of MAINTAINERS

Signed-off-by: Roger Meier <roger@bufferoverflow.ch>
cosmetic: doc: uImage.FIT: fix typos

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cosmetic: Update some info in the README "arch" section.

Tidy up, reorder, and add newer info to the arch/ directory subsection
of the README file.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
git-mailrc: Update SPI custodian

Update git-mailrc with alias and nick name details.

Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Cosmetic: Fix a number of typos, no functional changes.

Fix various misspellings of things like "environment", "kernel",
"default" and "volatile", and throw in a couple grammar fixes.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
arm: omap5: echi: Add GPL-2.0+ SPDX-License-Identifier

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
SPDX: fix IBM-pibs license identifier

The SPDX License List version 1.19 now contains an official entry for
the IBM-pibs license.  However, instead of our suggestion "ibm-pibs",
the SPDX License List uses "IBM-pibs", with the following rationale:
"The reason being that all other SPDX License List short identifiers
tend towards using capital letters unless spelling a word.  I'd prefer
to be consistent to this end".

Change the license IDs to use the official name.

Signed-off-by: Wolfgang Denk <wd@denx.de>