APPLIED: usb: ci_udc: Support larger packets

ci_ep_queue() currently only fills in the page0/page1 fields in the
queue item. If the buffer is larger than 4KiB (unaligned) or 8KiB
(page-aligned), then this prevents the HW from knowing where to write
the balance of the data.

Fix this by initializing all 5 pageN pointers, which allows up to
16KiB (potentially non-page-aligned) buffers.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: usb: ci_udc: set ep->req.actual after transfer

At least drivers/usb/gadget/storage_common.c expects that ep->req.actual
contain the number of bytes actually transferred. (At least in practice,
I observed it failing to work correctly unless this was the case).

However, ci_udc.c modifies ep->req.length instead. I assume that .length
 is supposed to represent the allocated buffer size, whereas .actual is
supposed to represent the actual number of bytes transferred. In the OUT
transaction case, this may happen simply because the host sends a smaller
 packet than the max possible size, which is quite legal. In the IN case,
transferring fewer bytes than requested could presumably happen as an
error.

Modify handle_ep_complete() to write to .actual rather than modifying
.length.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: usb: ci_udc: make PHY initialization conditional

usb_gadget_register_driver() currently unconditionally programs PORTSC
to select a ULPI PHY. This is incorrect on at least the Tegra boards I
am testing with, which use a UTMI PHY for the OTG ports. Make the PHY
selection code conditional upon the specific EHCI controller that is in
use.

Ideally, I believe that the PHY initialization code should be part of
ehci_hcd_init() in the relevant EHCI controller driver, or some board-
specific function that ehci_hcd_init() calls.

For MX6, I'm not sure this PHY initialization code is correct even before
this patch, since ehci-mx6's ehci_hcd_init() already configures PORTSC to
a board-specific value, and it seems likely that the code in ci_udc.c is
incorrectly undoing this. Perhaps this is not an issue if the PHY
selection register bits aren't implemented on this instance of the MX6
USB controller?

ehci-mxs.c doens't appear to touch PORTSC, so this code is likely still
required there.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: usb: ci_udc: support variants with hostpc register

Tegra's USB controller appears to be a variant of the ChipIdea
controller; perhaps derived from it, or simply a different version of
the IP core to what U-Boot supports today.

In this variant, at least the following difference are present:
- Some registers are moved about.
- Setup transaction completion is reported in a separate 'epsetupstat'
  register, rather than in 'epstat' (which still exists, perhaps for
  other transaction types).
- USB connection speed is reported in a separate 'hostpc1_devlc'
  register, rather than 'portsc'.
- The registers used by ci_udc.c begin at offset 0x130 from the USB
  register base, rather than offset 0x140. However, this is handled
  by the associated EHCI controller driver, since the register address
  is stored in controller.ctrl->hcor.

Introduce define CONFIG_CI_UDC_HAS_HOSTPC to indicate which variant of
the controller should be supported. The "HAS_HOSTPC" part of this name
mirrors the similar "has_hostpc" field used by the Linux EHCI controller
core to represent the presence/absence of the hostpc1_devlc register.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: usb: ums: use only 1 buffer for CI_UDC

ci_udc.c allocates only a single buffer for each endpoint, which
ci_ep_alloc_request() returns as a hard-coded value rather than
dynamically allocating. Consequently, storage_common.c must limit
itself to using a single buffer at a time. Add a special case
to the definition of FSG_NUM_BUFFERS for this.

Another option would be to fix ci_ep_alloc_request() to dynamically
allocate the buffers like some/all(?) other device mode drivers do.
However, I don't think that ci_ep_queue() supports queueing up
multiple buffers either yet, and I'm not familiar enough with the
controller yet to implement that. As such, any attempt to use multiple
buffers simply results in data corruption and other errors.

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>
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>
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: modify ehci_hcd_init() not to repeat initialization

ehci_hcd_init() currently skips most of its body if the USB port is
already initialized. However, some HW initialization was still executed
in this case. Move all the initialization before the point that the
code jumps to when not reinitializing the port.

Note that this patch seems slightly redundant with the next two patches.
However, it isolates the change to move where this code executes from
the later changes that refactor the code, for easier bisection if the
series causes problems.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: tegra: move manipulation of USBMODE_CM_HC

Move the code that sets up USBMODE_CM_HC (int the has_hostpc case) into
set_host_mode(). A future change will amend set_host_mode() to perform
host-vs-device-specific setup, and this code will need to vary depending
on the host-vs-device mode.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: tegra: remove redundant PTS_UTMI setup

init_utmi_usb_controller() already selects the USB controller's UTMI
interface, with identical code to that in ehci_hcd_init(). Remove the
duplicate code from ehci_hcd_init().

FIXME: Why does this break USB host on at least Beaver???
Does it do so on other SoCs?

Signed-off-by: Stephen Warren <swarren@nvidia.com>
USB Mass Storage hacks for Venice2