Add support for internal matrix keyboard controller for Nvidia Tegra
platforms. This driver uses the fdt decode function to obtain its key
codes.

Support for the Ctrl modifier is provided. The left and right ctrl keys are
dealt with in the same way.

This uses the new keyboard input library (drivers/input/input.c) to decode
keys and handle most of the common input logic. The new key matrix library
is also used to decode (row, column) key positions into key codes.

The intent is to make this driver purely about dealing with the hardware.

Key detection before the driver is loaded is supported. This key will be
picked up when the keyboard driver is initialized.

Modified by Bernie Thompson <bhthompson@chromium.org> and
Simon Glass <sjg@chromium.org> for device tree, input layer, key matrix
and various other things.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Sometimes we don't need a full cell for each value. This provides
a simple function to read a byte array, both with and without
copying it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Add support for setting up the memory controller parameters. Boards
can set up an appropriate table in the device tree.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

We need to iterate through subnodes of a parent, looking only at
compatible nodes. Add a utility function to do this for us.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

fdtdec_locate_array() locates an integer array but does not copy it. This
saves the caller having to allocated wasted space.

Access to array elements should be through the fdt32_to_cpu() macro.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
The driver requires CONFIG_OF_CONTROL to obtain its configuration
from the device tree.

(Simon Glass: sjg@chromium.org modified for upstream)

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Some devices can deal with multiple compatible properties. The devices
need to know which nodes to bind to which features. For example an
I2C driver which supports two different controller types will want to
know which type it is dealing with in each case.

The new fdtdec_add_aliases_for_id() function deals with this by allowing
the driver to search for additional compatible nodes for a different ID.
It can then detect the new ones and perform appropriate processing.

Another option considered was to return a tuple (node offset, compat id)
and have the function be passed a list of compatible IDs. This is more
overhead for the common case though. We may add such a function later if
more drivers in U-Boot require it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

CONFIG_OF_CONTROL requires a valid device tree. However, we cannot call
panic() before the console is set up since the message does not appear,
and we get a silent failure.

Remove the panic from fdtdec_check_fdt() and provide a new function to
prepare the fdt for use. This will be called after the console is ready.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

This adds basic support for the Tegra2 USB controller. Board files should
call board_usb_init() to set things up.

Configuration is performed through the FDT, with aliases used to set the
order of the ports, like this fragment:

        aliases {
		/* This defines the order of our USB ports */
                usb0 = "/usb@0xc5008000";
                usb1 = "/usb@0xc5000000";
        };

drivers/usb/host files ONLY: Acked-by: Remy Bohmer <linux@bohmer.net>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

This adds some support into fdtdec for reading GPIO definitions from
the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
is of the form:

gpio-function-name = <phandle gpio_num flags>;

where:

phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags is a flag, as follows:

   bit    meaning
   0      0=polarity normal, 1=active low (inverted)

An example is:

enable-propounder-gpios = <&gpio 43 0>;

which means that GPIO 43 is used to enable the propounder (setting the
GPIO high), or that you can detect that the propounder is enabled by
checking if the GPIO is high (the fdt does not indicate input/output).

Two main functions are provided:

fdtdec_decode_gpio() reads a GPIO property from an fdt node and decodes it
into a structure.

fdtdec_setup_gpio() sets up the GPIO by calling gpio_request for you.

Both functions can cope with the property being missing, which is taken to
mean that that GPIO function is not available or is not needed.

[For reference, from Stephen Warren <swarren@nvidia.com>. It may be that
we add this extra complexity later if needed:

The correct way to parse such a GPIO property in general is:

* Read the first cell.
* Find the node referenced by the phandle (the controller).
* Ensure property gpio-controller is present in the controller node.
* Read property #gpio-cells from the controller node.
* Extract #gpio-cells from the original property.
* Keep processing more cells from the original property; there may be
multiple GPIOs listed.

According to the binding documentation in the Linux kernel, Samsung
Exynos4 doesn't use this format, and while all other chips do have a
flags cell, about 50% of the controllers indicate the cell is unused.
]

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>