APPLIED (u-boot-video/master): config: enable CMD_BMP when API+LCD is enabled

When both CONFIG_API and CONFIG_LCD are enabled, the API code calls
lcd_display_bitmap(). That isn't compiled unless either CONFIG_CMD_BMP
or CONFIG_SPLASH_SCREEN is enabled. In order to prevent build problems,
have config_fallbacks.h enable CONFIG_CMD_BMP when both API and LCD are
enabled.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
cmd_part: fix type in part command help text

All the sub-commands start with the main command anme, but it was
missing from one of the help texts.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
disk: support devices with HW partitions

Some device types (e.g. eMMC) have hardware-level partitions (for eMMC,
separate boot and user data partitions). This change allows the user to
specify the HW partition they wish to access when passing a device ID to
U-Boot Commands such as part, ls, load, ums, etc.

The syntax allows an optional ".$hwpartid" to be appended to the device
name string for those commands.

Existing syntax, for MMC device 0, default HW partition ID, SW partition
ID 1:

ls mmc 0:1 /

New syntax, for MMC device 0, HW partition ID 1 (boot0), SW partition
ID 2:

ls mmc 0.1:2 /

For my purposes, this is most useful for the ums (USB mass storage
gadget) command, but there's no reason not to allow the new syntax
globally.

This patch adds the core support infra-structure. The next patch will
provide the implementation for MMC.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
mmc: provide a select_hwpart implementation for get_device()

This enables specifying which eMMC HW partition to target for any U-Boot
command that uses the generic get_partition() function to parse its
command-line arguments.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
cmd_mmc: use new mmc_select_hwpart() function

The implementation of mmc_select_hwpart() was cribbed from do_mmcops().
Update do_mmcops() to call mmc_select_hwpart() to avoid duplication.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: fix CPU VDD comment in Tegra30 CPU init code

The register writes performed by arch/arm/cpu/arm720t/tegra30/cpu.c
enable_cpu_power_rail() set the voltage to 1.0V not 1.4V as the comment
implies. Fix the comment.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: allow pinmux mux option not to be set by init tables

Define enum PMUX_FUNC_DEFAULT, which indicates that a table entry passed
to pinmux_config_pingrp()/pinmux_config_pingrp_table() shouldn't change
the mux option in HW.

For pins that will be used as GPIOs, the mux option is irrelevant, so we
simply don't want to define any mux option in the pinmux initialization
table.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: add GPIO initialization table function

The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. Add a feature to the GPIO driver
which executes a GPIO configuration table. Board files will use this to
implement the correct HW initialization procedure.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: add function to enable input clamping on tristate

The HW-defined procedure for booting Tegra requires that
CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
Add a function to the pinmux driver to allow boards to do this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: make use of GPIO init table on Jetson TK1

The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. This patch implements this
procedure for Jetson TK1. For pins which are to be used as GPIOs, the
pinmux mux function need not be programmed, so the pinmux table is also
adjusted.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: clamp inputs on Jetson TK1

The HW-defined procedure for booting Tegra requires that
CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
Modify the Jetson TK1 board to do this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: update Venice2 pinmux

This re-imports the entire Venice2 pinmux data from the board's master
spreadsheet, and makes use of the new IO clamping GPIO initialization
table features. This makes the board port fully compliant with the
required HW-defined pinmux initialization sequence.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: use a CPU freq that all SKUs can support

U-Boot on Tegra30 currently selects a main CPU frequency that cannot be
supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values
on some others. This can result in unreliable operation of the main CPUs.

Resolve this by switching to a CPU frequency that can be supported by any
SKU. According to the following link, the maximum supported CPU frequency
of the slowest Tegra30 SKU is 600MHz:

repo http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
branch l4t/l4t-r16-r2
path arch/arm/mach-tegra/tegra3_dvfs.c
table cpu_dvfs_table[]

According to that same table, the minimum VDD_CPU required to operate at
that frequency across all SKUs is 1.007V. Given the adjustment resolution
of the TPS65911 PMIC that's used on all Tegra30-based boards we support,
we'll end up using 1.0125V instead.

At that VDD_CPU, tegra3_get_core_floor_mv() in that same file dictates
that VDD_CORE must be at least 1.2V on all SKUs. According to
tegra_core_speedo_mv() (in tegra3_speedo.c in the same source tree),
that voltage is safe for all SKUs.

An alternative would be to port much of the code from tegra3_dvfs.c and
tegra3_speedo.c in the kernel tree mentioned above. That's more work
than I want to take on right now.

While all the currently supported boards use the same regulator chip for
VDD_CPU, different types of regulators are used for VDD_CORE. Hence, we
add some small conditional code to select how VDD_CORE is programmed. If
this becomes more complex in the future as new boards are added, or we
end up adding code to detect the SoC SKU and dynamically determine the
allowed frequency and required voltages, we should probably make this a
runtime call into a function provided by the board file and/or relevant
PMIC driver.

Cc: Alban Bedel <alban.bedel@avionic-design.de>
Cc: Marcel Ziswiler <marcel@ziswiler.com>
Cc: Bard Liao <bardliao@realtek.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Alban, I don't know which regulator is used for VDD_CORE on Tec-NG. If
could you find this out, I can adjust tec-ng.h too. Thanks.
ARM: tegra: set CONFIG_SYS_MMC_MAX_DEVICE

If CONFIG_API is ever to be enabled on Tegra, this define must be set,
since api/api_storage.c uses it.

A couple of annoyting things about CONFIG_SYS_MMC_MAX_DEVICE

1) It isn't documented in README. The same is true for a lot of similar
   defines used by api_storage.c.

2) It doesn't represent MAX_DEVICE but rather NUM_DEVICES, since the
   valid values are 0..n-1 not 0..n.

However, I this patch does not address those shortcomings.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: gadget: allow ci_udc to build with new gadget framework

Allow ci_udc.o to be built when using the new(?) USB gadget framework,
as enabled by CONFIG_USB_GADGET.

Note that this duplicates the Makefile entry for ci_udc.o, since it's
also included inside #ifdef CONFIG_USB_ETHER. I'm not sure what that
define means; perhaps an old style of Ethernet-specific USB gadget
implementation?

I wonder if the line that this patch adds shouldn't be outside all of
the ifdefs, so it stands on its own, similar to how e.g. epautoconf.o
is shared between the two?

Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: tegra: fix PHY selection code

The TRM for Tegra30 and later all state that USBMODE_CM_HC must be set
before writing to hostpc1_devlc to select which PHY to use for a USB
controller. However, neither init_{utmi,ulpi}_usb_controller() do this
today, so the register writes they perform for PHY selection do not
work.

For the UTMI case, this was hacked around in commit 7e44d9320ed4 "ARM:
Tegra: USB: EHCI: Add support for Tegra30/Tegra114" by adding code to
ehci_hcd_init() which sets USBMODE_CM_HC and duplicates the PHY
selection register write. This code doesn't cover the ULPI case, so I
wouldn't be surprised if ULPI doesn't work with the current code, unless
the ordering requirement only ends up being an issue in HW for UTMI not
ULPI.

This patch fixes init_{utmi,ulpi}_usb_controller() to correctly set
USBMODE_CM_HC before selecting the PHY. Now that this works, we can
remove the duplicate UTMI-specific code in ehci_hcd_init(), thus
simplifying that function.

Cc: Jim Lin <jilin@nvidia.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: tegra: refactor PHY type selection

Both init_{utmi,ulpi}_usb_controller() have nearly identical code for
PHY type selection. Pull this out into a common function to remove the
duplication.

Cc: Jim Lin <jilin@nvidia.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: tegra: support device mode

A few changes are made to the Tegra EHCI driver so that it can set
everything up for device-mode operation on the first USB controller.
This can be used in conjunction with ci_udc.c to operate as a USB
device.

Detailed changes are:

* Rename set_host_mode() to set_up_vbus() since that's really what it
  does.

* Modify set_up_vbus() to know whether it's initializing in host or
  device mode, and:

  - Skip the external VBUS check in device mode, since external VBUS is
    expected in this case.

  - Disable VBUS output in device mode.

* Modify init_phy_mux() to know whether it's initializing in host or
  device mode, and hence skip setting USBMODE_CM_HC (which enables host
  mode) in device mode. See the comments in that function for why this
  is safe w.r.t. the ordering requirements of PHY selection.

* Modify init_utmi_usb_controller() to force "b session valid" in device
  mode, since the HW requires this. This is done in UTMI-specific code,
  since we only support device mode on the first USB controller, and that
  controller can only talk to a UTMI PHY.

* Enhance ehci_hcd_init() to error-check the requested host-/device-mode
  vs. the dr_mode (dual-role mode) value present in device tree, and the
  HW configurations which support device mode.

* Enhance ehci_hcd_init() not to skip HW initialization when switching
  between host and device mode on a controller. This requires remembering
  which mode the last initialization used.

Cc: Jim Lin <jilin@nvidia.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: enable USB device mode and UMS on some boards

For each of Jetson TK1, Venice2, and Beaver:

- Enable the first USB controller in DT, and describe its configuration.

- Enable USB device/gadge support. This allows the user to type e.g.
  "ums 0 mmc 0" at the command-line to cause U-Boot to act a USB device
  implementing the USB Mass Storage protocol, and expose MMC device 0
  that way.

This allows a host PC to mount the Tegra device's MMC, partition it, and
install a filesystem on it.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Add missing tegra-common-ums.h

Note: This depends on a bunch of changes to the Tegra EHCI driver and
U-Boot UMS (USB Mass Storage) code, which are likely to be taken through
the USB maintainer tree. We should hold off until those commits show up
in the main U-Boot repo before applying this patch.

Oh, and I also need to investigate whether we can allocate a better value
for CONFIG_G_DNL_PRODUCT_NUM.
ARM: tegra: Venice2 pinmux spreadsheet updates

The Venice2 pinmux spreadsheet was updated to fix a few issues. Import
those changes into the U-Boot pinmux initialization tables.

Signed-off-by: Stephen Warren <swarren@nvidia.com>