Based on reading over the GCC manual, passing both -m2a and -m2a-nofpu
are redundant, as -m2a-nofpu will provide functional code for both.  As
-m2a-nofpu functions with more toolchains and does what is expected,
switch.

Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

This commit fixes several issues:

- After moving env related code to ./env directory the env_common.o file
is no longer present in the system (has been replaced with built-in.o).

- Use ${OBJCOPY} if available, fallback to system default's objcopy if not
present.

- Extend the script to accept different build directory than current one.
It is extremely handy with OE usage, where source code is separated from
build.
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Tested-by: NAlex Kiernan <alex.kiernan@gmail.com>

When booting from a non-MMC device, the MMC sub-system may not be
initialized when the environment is first accessed.
We need to make sure that the MMC sub-system is ready in even a non-MMC
boot case.

Therefore, initialize mmc before loading environment from it.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>

These ARM boards are in nice shape and still being used a lot
with e.g. QEMU, so I can maintain them.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When using omap_hsmmc without the device model then the allocation
of mmc->priv ends up uninitialised.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>
Tested-by: NRobert Nelson <robertcnelson@gmail.com>
Reviewed-by: NSam Protsenko <semen.protsenko@linaro.org>

The correspondence between mmc versions as used in u-boot and the version
numbers reported in register EXT_CSD_REV is wrong for versions above and
including MMC_VERSION_4_41. All those versions were shifted by one:
real 4.5 hardware appeared to be MMC_VERSION_5_0.

Fix this by adding the missing version in the correspondence table.
Reported-by: Neil Eilmsteiner Heribert <eil@keba.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NSam Protsenko <semen.protsenko@linaro.org>

After settings the speed of the sd with the switch command, a check is
done to make sure that the new speed has been set. The current check has a
masking error: speed are encoded on 4 bits only.
Fix it by masking the upper bits.

This fixes a problem seen with QEmu emulating a vexpress-a15.
Reported-by: NJonathan Gray <jsg@jsg.id.au>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Tested-by: NJonathan Gray <jsg@jsg.id.au>

By default UHS and HS200 are not enabled.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Since DRA7xx/AM57xx SR1.1 and SR1.0 has errata to limit the frequency of
MMC1 to 96MHz and frequency of MMC2 to 48MHz for AM572x SR1.1, limit the
frequency and disable higher speed modes for those revision.
Also use the recommended IO delays (those tagged with "rev11")
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

The UHS modes are not supported in beagle-x15 because it's not possible to
switch the IO lines supply voltage to 1.8v.
Also HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

On DRA7 family SoCs, MMC1 controller supports SDR104,
SDR50, DDR50, SDR25 and SDR12 UHS modes.

MMC2 controller supports HS200 and DDR modes.

MMC3 controller supports SDR12, SDR25 and SDR50 modes.

MMC4 controller supports SDR12 and SDR25 modes.

Add these supported modes in device-tree file.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Use the new compatible string "ti,dra7-hsmmc" that was specifically
added for dra7 and dra72. This is required since for dra7 and dra72
processors iodelay values has to be set unlike other processors.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Now that omap_hsmmc has support for hs200 mode, change the clock
frequency to 192MHz. Also change the REFERENCE CLOCK frequency to
192MHz based on which the internal mmc clock divider is calculated.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

I/O data lines of UHS SD card operates at 1.8V when in UHS speed
mode (same is true for eMMC in DDR and HS200 modes). Add support
to switch signal voltage to 1.8V in order to support
UHS cards and eMMC HS200 and DDR modes.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

mmc core has defined a new parameter *clk_disable* to gate the clock.
Disable the clock here if *clk_disable* is set.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

This callback is used to send the 74 clock cycles after power up.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

When the clock is applied, compute the actual value of the clock. It may be
slightly different from the requested value (max freq, divisor threshold)
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

The default configuration is usually working fine for the the HS modes.
Don't enforce the presence of a dedicated pinmux for the HS modes.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

AM572x SR1.1 requires different IODelay values to be used than that used
in AM572x SR2.0. These values are populated in device tree. Add
capability in omap_hsmmc driver to extract IOdelay values for different
silicon revision. The maximum frequency is also reduced when using a ES1.1.
To keep the ability to boot both revsions with the same dtb, those values
can be provided by the platform code.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met.

Add support to parse mux values and iodelay values from device tree
and set these depending on the enumerated MMC mode.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Add a new API to perform iodelay recalibration without isolate
io to be used in uboot.

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met. The MMC driver can use the new API to
set the IO delay values depending on the MMC mode.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Use the mmc_of_parse library function to populate mmc_config instead of
repeating the same code in host controller driver.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

>From OMAP3 SoCs (OMAP3, OMAP4, OMAP5, AM572x, AM571x), the DAT/CMD lines
reset procedure section in TRM suggests to first poll the SRD/SRC bit
until it is set to 0x1. But looks like that bit is never set to 1 and there
is an observable delay of 1sec everytime the driver tries to reset DAT/CMD.
(The same is observed in linux kernel).

Reduce the time the driver waits for the controller to set the SRC/SRD bits
to 1 so that there is no observable delay.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

According to errata i802, DCRC error interrupts
(MMCHS_STAT[21] DCRC=0x1) can occur during the tuning procedure.

The DCRC interrupt, occurs when the last tuning block fails
(the last ratio tested). The delay from CRC check until the
interrupt is asserted is bigger than the delay until assertion
of the tuning end flag. Assertion of tuning end flag is what
masks the interrupts. Because of this race, an erroneous DCRC
interrupt occurs.

The suggested  workaround is to disable DCRC interrupts during
the tuning procedure which is implemented here.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

HS200/SDR104 requires tuning command to be sent to the card. Use
the mmc_send_tuning library function to send the tuning
command and configure the internal DLL.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

In order to enable DDR mode, Dual Data Rate mode bit has to be set in
MMCHS_CON register. Set it here.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Use the timing parameter set in the MMC core to set the
mode in UHSMS  bit field. This is in preparation for
adding HS200 support in omap hsmmc driver.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

"ti,dual-volt" is used in linux kernel to set the voltage capabilities.
For host controller dt nodes that doesn't have "ti,dual-volt",
it's assumed 1.8v is the io voltage. This is not always true (like in
the case of beagle-x15 where the io lines are connected to 3.3v).
Hence if "no-1-8-v" property is set, io voltage will be set to 3v.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

No functional change. Move bus width configuration setting to a
separate function and invoke it only if there is a change in the
bus width.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Add a separate function for starting the clock, stopping the clock and
setting the clock. Starting the clock and stopping the clock can
be used irrespective of setting the clock (For example during iodelay
recalibration).
Also set the clock only if there is a change in frequency.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Use pr_* log functions from Linux.  They can be enabled/disabled
via CONFIG_LOGLEVEL.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

Fixes a bug found on thuban boards, which were for 2 years in
a long-term test with varying temperatures. They showed
problems in u-boot when attaching the ubi partition:

U-Boot# run flash_self_test
Booting from nand
set A...
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
data abort
pc : [<87f97c3c>]          lr : [<87f97c28>]
reloc pc : [<8012cc3c>]    lr : [<8012cc28>]
sp : 85f686e8  ip : 00000020     fp : 000001f7
r10: 8605ce40  r9 : 85f68ef8     r8 : 0001f000
r7 : 00000001  r6 : 00000006     r5 : 0001f000  r4 : 85f6ecc0
r3 : 00000000  r2 : 44e35000     r1 : 87fcbcd4  r0 : 87fc755b
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

Reason is, that accidentially the U-Boot implementation
from __schedule_ubi_work() did not check the flag
ubi->thread_enabled and started with wearleveling work,
but ubi did not have setup all structures at this point
and crashes.

Solve this problem by splitting work scheduling and processing.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NHeiko Schocher <hs@denx.de>

Previous patch for this driver breaks i2c initialization.

commit 8bcf12cc ("i2c: mvtwsi.c: Avoid NULL dereference")

If actual_speed is passed as NULL in this function:
static void __twsi_i2c_init(struct mvtwsi_registers *twsi, int speed,
			    int slaveadd, uint *actual_speed)
than __twsi_i2c_set_bus_speed never get called. This causes i2c clock
to run on default speed - 2MHz (measured with oscilloscope). This is issue
on some boards, sunxi for example, since on I2C0 bus PMU is connected.

The bootlogs with and without the patch are as follows:

Wihtout the patch:
U-Boot SPL 2018.03-rc2 (Feb 13 2018 - 09:23:17 +0200)
DRAM: 1024 MiB
Failed to set core voltage! Can't set CPU frequency
Trying to boot from FEL

U-Boot 2018.03-rc2 (Feb 13 2018 - 09:23:17 +0200) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Olimex A20-OLinuXino-LIME2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0

With the patch:
U-Boot SPL 2018.03-rc2-00001-g838ff85 (Feb 13 2018 - 09:24:34 +0200)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from FEL

U-Boot 2018.03-rc2-00001-g838ff85 (Feb 13 2018 - 09:24:34 +0200) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Olimex A20-OLinuXino-LIME2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
Signed-off-by: NStefan Mavrodiev <stefan@olimex.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>