arm: omap5: don't enable misc_init_r by default

Out of all OMAP5-like boards, only one of them
needs CONFIG_MISC_INIT_R, so it's best to enable
that for that particular board only, instead of
enabling for all boards unconditionally.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: omap5: tps659038: rename regulator defines

Those regulators don't have any coupling with
what they supply, so remove the suffixes in order
to not confuse anybody.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: dra7xx: prcm: add missing registers

some boards might want to use USB1 for host,
without fiddling those registers it'll be
impossible.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
usb: phy: omap_usb_phy: fix build breakage

there's no such function usb3_phy_power(),
it's likely that author meant to call,
usb_phy_power() instead, but that's already
called properly from xhci-omap.c.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: omap-common: emif: allow to map memory without interleaving

If we want to have two sections, one on each EMIF, without
interleaving, current code wouldn't enable emif2. Fix that
problem.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
configs: omap5_common : Boot rootfs from sd card by default

* Since the emmc isn't always programed trying to load the fs from the
  emmc causes boot failures/kernel panic.

* The current bootcmd is set to:
  bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; \
  setenv mmcroot /dev/mmcblk0p2 rw; run mmcboot;

My guess is the env variables should be set so that sd card boot
(dt,kernel,fs) is the default and then fallback to emmc if it fails (no
sd card detected)

The current bootcmd attempts to set mmcroot to the sd card rootfs but
that code doesn't run due to mmcboot being ran early on.

Signed-off-by: Franklin Cooper Jr. <fcooper@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: omap5: make hw_init_data weak

this way we can let boards overwrite based
on what they need.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: omap5: sdram: mark emif_get_ext_phy_ctrl_const_regs __weak

this will allow for boards to overwrite those
in case memory setup is different.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: omap_common: expose tps659038 and dra7xx_dplls

expose those two definitions so they can be
used by another board which we're adding in upcoming
patches.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
arm: omap: add support for am57xx devices

just add a few ifdefs around because this
device is very similar to dra7xxx.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
beagle_x15: add board support for Beagle x15

BeagleBoard-X15 is the next generation Open Source
Hardware BeagleBoard based on TI's AM5728 SoC
featuring dual core 1.5GHZ A15 processor. The
platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60),
separate LCD port, video In port, 4GB eMMC, uSD,
Analog audio in/out, dual 1G Ethernet.

For more information, refer to:
http://www.elinux.org/Beagleboard:BeagleBoard-X15

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
mmc: Board-specific MMC power initializations

Some devices may use non-standard combinations of regulators to power MMC:
this allows these devices to provide a board-specific MMC power init function
to set everything up in their own way.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
twl4030: device-index-specific MMC power initializations, common ramp-up delay

Not every device has multiple MMC slots available, so it makes sense to enable
only the required LDOs for the available slots. Generic code in omap_hsmmc will
enable both VMMC1 and VMMC2, in doubt.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
MMC SD fs boot partition config coding style and proper description

CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION ought to be called
CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to keep it consistent with other config
options such as: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.

In addition, it is not related to raw mode booting but to fs mode instead.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
mmc: sh_mmcif: Use DIV_ROUND_UP and fls instead of calculation loop

Use DIV_ROUND_UP and fls to simplify the code.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
mmc: sh_mmcif: Change maximum and minimum value of MMC clock

Maximum value and the minimum value of clock for sh_mmcif instead by
base of MMC clock. This removes fixed clock, make the changes to be calculated
according to environment.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
mmc: sh_mmcif: Add support rmobile

Renesas R-Mobile/R-Car ARM SoC of MMC has the same IP that are supported by
sh_mmcif. This adds support R-Mobile/R-Car ARM SoC with the setting of the
clock support.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
omap_hsmmc: Board-specific TWL4030 MMC power initializations

Boards using the TWL4030 regulator may not all use the LDOs the same way
(e.g. MMC2 power can be controlled by another LDO than VMMC2).
This delegates TWL4030 MMC power initializations to board-specific functions,
that may still call twl4030_power_mmc_init for the default behavior.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
[trini: Fix omap3_evm warning, add twl4030.h]
Signed-off-by: Tom Rini <trini@ti.com>
ARM: OMAP5: DRA7xx: Enable 8-bit eMMC access on the dra7xx_evm

Tested on a Vayu EVM Rev.E2 with DRA752 ES1.1

Signed-off-by: Lubomir Popov <l-popov@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
ARM: OMAP5: DRA7xx: Fix misleading comments in mux_data.h

The comments on the QSPI pad assignments erronously swapped
the qspi1_d0 and qspi1_d1 functionality and could cause
confusion. QSPI1_D[0] is in fact muxed on pad U1 (gpmc_a16),
and QSPI1_D[1] - on pad P3 (gpmc_a17). Fixing comments.

Signed-off-by: Lubomir Popov <l-popov@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>