Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 14 5月, 2014 12 次提交
  3. 09 5月, 2014 1 次提交
  5. 07 5月, 2014 4 次提交
  7. 06 5月, 2014 5 次提交
    • M
      serial: zynq: Fix typo in suffix function name · 870e0bda
      由 Michal Simek 提交于 
      's/zynq_serial_initalize/zynq_serial_initialize/g'
serial_initialize is used by all serial drivers.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      870e0bda
    • M
      serial: zynq: Remove sparse warnings · 6c4da359
      由 Michal Simek 提交于 
      Warnings:
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_init' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_setbrg' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_getc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_tstc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_putc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_puts' was not declared. Should it be static?
drivers/serial/serial_zynq.c:182:22: warning: symbol 'uart_zynq_serial0_device' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_init' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_setbrg' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_getc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_tstc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_putc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_puts' was not declared. Should it be static?
drivers/serial/serial_zynq.c:185:22: warning: symbol 'uart_zynq_serial1_device' was not declared. Should it be static?
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      6c4da359
    • M
      net: zynq: Fix sparse warnings in gem · 2fd2489b
      由 Michal Simek 提交于 
      Add missing header.

Warnings:
drivers/net/zynq_gem.c:491:5: warning: symbol 'zynq_gem_initialize' was not declared. Should it be static?
drivers/net/zynq_gem.c:542:5: warning: symbol 'zynq_gem_of_init' was not declared. Should it be static?
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      2fd2489b
    • M
      net: zynq: Use predefined macros instead of hardcoded value · c1a9fa4b
      由 Michal Simek 提交于 
      MII is used by this driver.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      c1a9fa4b
    • S
      microblaze: Wire up OF support for emaclite · d1d37b5c
      由 Stephan Linz 提交于 
       - expand the condition with CONFIG_OF_CONTROL
Signed-off-by: NStephan Linz <linz@li-pro.net>
Acked-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      d1d37b5c
  9. 05 5月, 2014 10 次提交
  11. 02 5月, 2014 3 次提交
  13. 01 5月, 2014 1 次提交
    • S
      usb: gadget: allow ci_udc to build with new gadget framework · 2fc5dab2
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
      2fc5dab2
  15. 30 4月, 2014 4 次提交
    • S
      usb: ums: use only 1 buffer for CI_UDC · a022c1e1
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
      a022c1e1
    • S
      usb: ci_udc: support variants with hostpc register · fcf2ede1
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
      fcf2ede1
    • S
      usb: ci_udc: make PHY initialization conditional · 0c51dc6d
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
      0c51dc6d
    • S
      usb: ci_udc: set ep->req.actual after transfer · 8aac6e9c
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
      8aac6e9c