USB: Some cleanup prior to USB 3.0 interface addition

Some cleanup in usb framework, nothing much on feature side.

Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
usb: hub: Power-cycle on root-hub ports

XHCI ports are powered on after a H/W reset, however
EHCI ports are not. So disabling and re-enabling power
on all ports invariably.

Signed-off-by: Amar <amarendra.xt@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
usb: Update device class in usb device's descriptor

Fetch the device class into usb device's dwcriptors,
so that the host controller's driver can use this info
to differentiate between HUB and DEVICE.

Signed-off-by: Amar <amarendra.xt@samsung.com>
usb: hub: Fix enumration timeout

Patch b6d7852c increases timeout for enumeration, taking
worst case to be 10 sec.
get_timer() api returns timestamp in milliseconds, which is
what we are checking in the do-while() loop in usb_hub_configure()
(get_timer(start) < CONFIG_SYS_HZ * 10).
This should give us a required check for 10 seconds, and thereby
we don't need to add additional mdelay of 100 microseconds in
each cycle.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Reviewed-by: Vipin Kumar <vipin.kumar@st.com>
USB: SS: Add support for Super Speed USB interface

This adds usb framework support for super-speed usb, which will
further facilitate to add stack support for xHCI.

Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
USB: ohci-at91: make OHCI work on at91sam9g10 SoC

The at91sam9g10 need to configure HCK0 to make OHCI work

Signed-off-by: Bo Shen <voice.shen@atmel.com>
usb: hub: Parallelize power-cycling of root-hub ports

Untill now we power-cycle (aka: disable power on a port
and re-enabling again) one port at a time.
Delay of 20ms for Port-power to change multiplies with
number of ports in this case.
So better we parallelize this process:
disable power on all ports, wait for port-power to stabilize
and then re-enable the power subsequently.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
usb: fix: Fixing Port status and feature number constants

Fix the Port status bit constants and Port feature number
constants as a part of USB 2.0 and USB 3.0 Hub class.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
usb: common: Use a global definition for 'min3'

We can use a common global method for calculating minimum of
3 numbers. Put the same in 'common header' and let 'ehci'
use it.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Acked-by: Tom Rini <trini@ti.com>
mx23: Operate DDR voltage supply at 2.5V

After the recent fixes in the mx23 DDR setup, it is safe to operate DDR voltage
at the recommended 2.5V voltage level again.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
mx23evk: Do not set voltage selection bit for SSP pads

mx23 SSP pad registers do not contain voltage selection bit, so just remove it.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
mx23_olinuxino: Do not set voltage selection bit for SSP pads

mx23 SSP pad registers do not contain voltage selection bit, so just remove it.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
mxs: Explain why some mx23 DDR registers are not configured

Put an explanation in the source code as to why some DDR registers do not
need to be configured.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
arm: mx23: Fix VDDMEM misconfiguration

The VDDMEM ramped up in very weird way as it was horribly misconfigured.
Instead of setting up VDDMEM in one swipe, let it rise slowly the same
way as VDDD and VDDA in spl_power_init.c and then only clear ILIMIT before
memory gets inited. This makes sure the VDDMEM rises sanely, not jumps up
and down as it did till now.

The VDDMEM prior to this change did this:
     2V0____   .--------2V5
       |    `--'
 0V____|

The VDDMEM now does this:
    2V0_____,-----------2V5
      /
 0V__|

Moreover, VDDIO on MX23 uses 25mV steps while MX28 uses 50mV steps,
fix this difference too.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
arm: mxs: Preprocess u-boot.bd so they contain full path

The u-boot-imx23.bd and u-boot-imx28.bd need to be preprocessed, otherwise
they have issues with out-of-tree build where elftosb tool couldn't sometimes
find the u-boot.bin and spl/u-boot-spl.bin .

Preprocess these .bd files with sed and insert full path to u-boot.bin and
spl/u-boot-spl.bin to prevent this issue. Moreover, to avoid adding more
churn into main Makefile, move all this preprocessing and u-boot.sb generation
into CPU directory instead.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
fpga: Clean coding style

No functional changes.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
fpga: Fix debug message compilation error

CONFIG_FPGA in past was a bitfield where bits
were use for vendor identification.

This fix should be the part of this commit:
"Improve configuration of FPGA subsystem"
(sha1: 0133502e39ff89b67c26cb4015e0e7e8d9571184)

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
cmd: fpga: Clean coding style

No functional changes.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
cmd: fpga: Move fpga_loadbitstream to fpga.c

In bitstream decoding you can directly check device
which you want to load and in fpga.c are fpga_validate
and fpga_dev_info functions which should be used for it.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>
fpga: Change the first parameter in fpga_loadbitstream

All fpga functions use devnum as int. Only fpga_loadbitstream
is using it as unsinged long dev.
This patch synchronize it.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@ti.com>