| 9fb02491 | 03-Sep-2014 |
Simon Glass <sjg@chromium.org> |
dm: Make driver model available before board_init()
For some boards board_init() will change GPIOs, so we need to have driver
model available before then. Adjust the board init to arrange this, but
dm: Make driver model available before board_init()
For some boards board_init() will change GPIOs, so we need to have driver
model available before then. Adjust the board init to arrange this, but
enable it for driver model only, just to be safe.
This does create additional #ifdef logic, but it is safer than trying to
make a pervasive change which may cause some boards to break.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 294b91a5 | 03-Sep-2014 |
Simon Glass <sjg@chromium.org> |
Set up stdio earlier when using driver model
Since driver model registers itself with the stdio subsystem, and we
want to avoid delayed registration and other complexity associated with
the current
Set up stdio earlier when using driver model
Since driver model registers itself with the stdio subsystem, and we
want to avoid delayed registration and other complexity associated with
the current serial console, move the stdio subsystem init earlier when
driver model is used for serial.
This simplifies the implementation. Should there be any problems with
this approach they can be dealt with as boards are converted over to
use driver model for serial.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 9165e842 | 11-Aug-2014 |
Simon Glass <sjg@chromium.org> |
dm: gpio: Allow gpio command to adjust GPIOs that are busy
The gpio command mostly relies on gpio_request() and gpio_free() being
nops, in that you can request a GPIO twice. With driver model this i
dm: gpio: Allow gpio command to adjust GPIOs that are busy
The gpio command mostly relies on gpio_request() and gpio_free() being
nops, in that you can request a GPIO twice. With driver model this is
now implemented correctly, so it fails.
Change the command to deal with a failure to claim the GPIO.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 74c0d756 | 07-Aug-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: hub: don't check CONNECTION in hub_port_reset()
One specific USB 3.0 device behaves strangely when reset by
usb_new_device()'s call to hub_port_reset(). For some reason, the device
appears to b
usb: hub: don't check CONNECTION in hub_port_reset()
One specific USB 3.0 device behaves strangely when reset by
usb_new_device()'s call to hub_port_reset(). For some reason, the device
appears to briefly drop off the bus when this second bus reset is
executed, yet if we retry this loop, it'll eventually come back after
another two resets.
If USB bus reset is executed over and over within usb_new_device()'s call
to hub_port_reset(), I see the following sequence of results, which
repeats as long as you want:
1) STAT_C_CONNECTION = 1 STAT_CONNECTION = 0 USB_PORT_STAT_ENABLE 0
2) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0
3) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1
The device in question is a SanDisk Ultra USB 3.0 16GB memory stick with
USB VID/PID 0x0781/0x5581.
In order to allow this device to work with U-Boot, ignore the
{C_,}CONNECTION bits in the status/change registers, and only use the
ENABLE bit to determine if the reset was successful.
To be honest, extensive investigation has failed to determine why this
problem occurs. I'd love to know! I don't know if it's caused by:
* A HW bug in the device
* A HW bug in the Tegra USB controller
* A SW bug in the U-Boot Tegra USB driver
* A SW bug in the U-Boot USB core
This issue only occurs when the device's USB3 pins are attached to the
host; if only the USB2 pins are connected the issue does not occur. The
USB3 controller on Tegra is in reset, so is not actively communicating
with the device at all - a USB3 analyzer confirms this. Slightly
unplugging the device (so the USB3 pins don't contact) or using a USB2
cable or hub as an intermediary avoids the problem. For some reason,
the Linux kernel (either on the same Tegra board, or on an x86 host)
has no issue with the device, and I observe no disconnections during
reset.
This change won't affect any USB device that already works, since such
devices could not currently be triggering the error return this patch
removes, or they wouldn't be working currently.
However, this patch is quite reliable in practice, hence I hope it's
acceptable to solve the problem.
The only potential fallout I can see from this patch is:
* A broken device that triggers C_CONNECTION/!CONNECTION now causes the
loop in hub_port_reset() to run multiple times. If it never succeeds,
this will cause "usb start" to take roughly 1s extra to execute.
* If the user unplugs a device while hub_port_reset() is executing, and
very quickly swaps in a new device, hub_port_reset() might succeed on
the new device. This would mean that any information cached about the
original device (from the descriptor read in usb_new_device(), which
simply caches the max packet size) might be invalid, which would cause
problems talking to the new device. However, without this change, the
new device wouldn't work anyway, so this is probably not much of a
loss.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| b1ba62d4 | 06-Aug-2014 |
Hans de Goede <hdegoede@redhat.com> |
pxe: Allow use of environment variables in append string
Use cli_simple_process_macros, so that environment
variables (e.g. ${console}) can be used in append strings.
Signed-off-by: Hans de Goede <
pxe: Allow use of environment variables in append string
Use cli_simple_process_macros, so that environment
variables (e.g. ${console}) can be used in append strings.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|