u-boot.git/drivers/usb, branch v2018.07 Unnamed repository; edit this file 'description' to name the repository. sunxi: A64: OHCI: prevent turning off shared USB clock 2018-07-05T09:25:50+00:00 Andre Przywara andre.przywara@arm.com 2018-07-04T23:57:48+00:00 0bc846a769d43810af9e4622473b85ffaead3dea On the A64 the clock for the first USB controller is actually the parent of the clock for the second controller, so turning them off in that order makes the system hang. Fix this by only turning off *both* clocks when the *last* OHCI controller is brought down. This covers the case when only one controller is used. Signed-off-by: Andre Przywara <andre.przywara@arm.com> 
On the A64 the clock for the first USB controller is actually the parent
of the clock for the second controller, so turning them off in that order
makes the system hang.
Fix this by only turning off *both* clocks when the *last* OHCI controller
is brought down. This covers the case when only one controller is used.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
usb: dwc2: Add brcm,bcm2708-usb compatible 2018-07-05T09:25:49+00:00 Emmanuel Vadot manu@freebsd.org 2018-07-02T12:34:23+00:00 ff5d5cc2331033c8a6987bb644827b52484160d9 When using CONFIG_OF_BOARD on rpi to use the dtb provided by the RaspberryPi Fundation, the compatible string isn't the same, resulting in not-functional usb from u-boot. Signed-off-by: Oleksandr Tymoshenko <gonzo@FreeBSD.org> Signed-off-by: Emmanuel Vadot <manu@freebsd.org> 
When using CONFIG_OF_BOARD on rpi to use the dtb provided by the
RaspberryPi Fundation, the compatible string isn't the same, resulting
in not-functional usb from u-boot.

Signed-off-by: Oleksandr Tymoshenko <gonzo@FreeBSD.org>
Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
usb: sunxi: Use proper reg_mask for clock gate, reset 2018-06-29T08:52:18+00:00 Jagan Teki jagannadh.teki@gmail.com 2018-06-28T14:10:46+00:00 9c22aec4102de0f0dc35e21772d9f21d4616c3d2 Masking clock gate, reset register bits based on the probed controller is proper only due to the assumption that masking should start with 0 even thought the controller has separate PHY or shared between OTG. unfortunately these are fixed due to lack of separate clock, reset drivers. Say for example EHCI1 - EHCI3 in the datasheet (EHCI0 is for the OTG) so we need to start reg_mask 0 - 2. This patch calculated the mask, based on the register base so that we can get the proper bits to set with respect to probed controller. We even do this masking by using PHY index specifier from dt, but dev_read_addr_size is failing for 64-bit boards. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> 
Masking clock gate, reset register bits based on the
probed controller is proper only due to the assumption
that masking should start with 0 even thought the controller
has separate PHY or shared between OTG.

unfortunately these are fixed due to lack of separate
clock, reset drivers.

Say for example EHCI1 - EHCI3 in the datasheet (EHCI0 is for the OTG)
so we need to start reg_mask 0 - 2.

This patch calculated the mask, based on the register base
so that we can get the proper bits to set with respect to
probed controller.

We even do this masking by using PHY index specifier from dt,
but dev_read_addr_size is failing for 64-bit boards.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
usb: ohci: change the NUM_EDs from 8 to 32 2018-06-29T08:52:12+00:00 Zeng Tao prime.zeng@hisilicon.com 2018-06-28T17:54:19+00:00 11080bf6c705ca1ebed23417204a73738bd81669 For ohci, the maximam supported endpoint number is 32(in and out), and now we have used (usb_pipeendpoint(pipe) << 1) to index the specified endpoint descritor, usb_pipeendpoint(pipe) can reach 0xf, so we need change the NUM_EDs from 8 to 32. Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com> 
For ohci, the maximam supported endpoint number is 32(in and out), and
now we have used (usb_pipeendpoint(pipe) << 1) to index the specified
endpoint descritor, usb_pipeendpoint(pipe) can reach 0xf, so we need
change the NUM_EDs from 8 to 32.

Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com>
usb: sunxi: ohci: make ohci_t the first member in private data 2018-06-29T08:52:07+00:00 Vasily Khoruzhick anarsoul@gmail.com 2018-06-17T16:13:42+00:00 ebbc23a0495cd189cda2760f66cc0195dd030a19 ohci-hcd casts priv_data pointer to (ohci_t *), thus it must be the first member in private data struct. Fixes 831cc98b1 ("usb: sunxi: Simplify ccm reg base code") Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> 
ohci-hcd casts priv_data pointer to (ohci_t *), thus it must be
the first member in private data struct.

Fixes 831cc98b1 ("usb: sunxi: Simplify ccm reg base code")

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
dwc2 USB controller hangs with lan78xx 2018-06-28T02:21:25+00:00 Andrew Thomas andrew.thomas@oracle.com 2018-06-18T18:56:06+00:00 af15946aa081dbcd0bec7d507a2b2db4e6b6cda5 This bug is the combination of dwc2 USB controller and lan78xx USB ethernet controller, which is the combination in use on the Raspberry Pi Model 3 B+. When the host attempts to receive a packet, but a packet has not arrived, the lan78xx controller responds by setting BIR (Bulk-In Empty Response) to NAK. Unfortunately, this hangs the USB controller and requires the USB controller to be reset. The fix proposed is to have the lan78xx controller respond by setting BIR to ZLP. Signed-off-by: Andrew Thomas <andrew.thomas@oracle.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de> 
This bug is the combination of dwc2 USB controller and lan78xx
USB ethernet controller, which is the combination in use on
the Raspberry Pi Model 3 B+.

When the host attempts to receive a packet, but a packet has not
arrived, the lan78xx controller responds by setting BIR
(Bulk-In Empty Response) to NAK. Unfortunately, this hangs
the USB controller and requires the USB controller to
be reset.

The fix proposed is to have the lan78xx controller respond
by setting BIR to ZLP.

Signed-off-by: Andrew Thomas <andrew.thomas@oracle.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Merge branch 'master' of git://git.denx.de/u-boot-usb 2018-06-16T04:07:37+00:00 Tom Rini trini@konsulko.com 2018-06-16T04:07:37+00:00 a715415bb5948c84cc44c601b193188990f7238b 






usb: sunxi: access ahb_reset0_cfg in CCM using its offset
2018-06-14T10:57:19+00:00

Vasily Khoruzhick
anarsoul@gmail.com

2018-06-14T06:19:34+00:00

b9f34757db5dcde9ccfa6ce35705b025bc4843fc

struct sunxi_ccm_reg doesn't have ahb_reset0_cfg on sun4i and sun5i,
thus compilation fails with:

drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
no member named 'ahb_reset0_cfg'

Access this reg using its offset to fix this issue.

Fixes commit 1ed9c1118 ("usb: sunxi: ehci: get rid of ifdefs")
and commit 56830cee3 ("usb: sunxi: ohci: get rid of ifdefs")

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>





struct sunxi_ccm_reg doesn't have ahb_reset0_cfg on sun4i and sun5i,
thus compilation fails with:

drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
no member named 'ahb_reset0_cfg'

Access this reg using its offset to fix this issue.

Fixes commit 1ed9c1118 ("usb: sunxi: ehci: get rid of ifdefs")
and commit 56830cee3 ("usb: sunxi: ohci: get rid of ifdefs")

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>







Merge git://git.denx.de/u-boot-x86
2018-06-13T15:43:59+00:00

Tom Rini
trini@konsulko.com

2018-06-13T15:43:59+00:00

66398944f53921ec641e1c2202390933767dbb87












lib: Add hexdump
2018-06-13T11:49:12+00:00

Alexey Brodkin
Alexey.Brodkin@synopsys.com

2018-06-05T14:17:57+00:00

f8c987f8f127f867d96ca74bcd1fcb11d8265b67

Often during debugging session it's very interesting to see
what data we were dealing with. For example what we write or read
to/from memory or peripherals.

This change introduces functions that allow to dump binary
data with one simple function invocation like:
------------------->8----------------
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
------------------->8----------------

which gives us the following:
------------------->8----------------
00000000: f2 b7 c9 88 62 61 75 64 72 61 74 65 3d 31 31 35  ....baudrate=115
00000010: 32 30 30 00 62 6f 6f 74 61 72 67 73 3d 63 6f 6e  200.bootargs=con
00000020: 73 6f 6c 65 3d 74 74 79 53 33 2c 31 31 35 32 30  sole=ttyS3,11520
00000030: 30 6e 38 00 62 6f 6f 74 64 65 6c 61 79 3d 33 00  0n8.bootdelay=3.
00000040: 62 6f 6f 74 66 69 6c 65 3d 75 49 6d 61 67 65 00  bootfile=uImage.
00000050: 66 64 74 63 6f 6e 74 72 6f 6c 61 64 64 72 3d 39  fdtcontroladdr=9
00000060: 66 66 62 31 62 61 30 00 6c 6f 61 64 61 64 64 72  ffb1ba0.loadaddr
00000070: 3d 30 78 38 32 30 30 30 30 30 30 00 73 74 64 65  =0x82000000.stde
00000080: 72 72 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32  rr=serial0@e0022
00000090: 30 30 30 00 73 74 64 69 6e 3d 73 65 72 69 61 6c  000.stdin=serial
000000a0: 30 40 65 30 30 32 32 30 30 30 00 73 74 64 6f 75  0@e0022000.stdou
000000b0: 74 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 30  t=serial0@e00220
000000c0: 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00..............
...
------------------->8----------------

Source of hexdump.c was copied from Linux kernel v4.7-rc2.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>





Often during debugging session it's very interesting to see
what data we were dealing with. For example what we write or read
to/from memory or peripherals.

This change introduces functions that allow to dump binary
data with one simple function invocation like:
------------------->8----------------
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
------------------->8----------------

which gives us the following:
------------------->8----------------
00000000: f2 b7 c9 88 62 61 75 64 72 61 74 65 3d 31 31 35  ....baudrate=115
00000010: 32 30 30 00 62 6f 6f 74 61 72 67 73 3d 63 6f 6e  200.bootargs=con
00000020: 73 6f 6c 65 3d 74 74 79 53 33 2c 31 31 35 32 30  sole=ttyS3,11520
00000030: 30 6e 38 00 62 6f 6f 74 64 65 6c 61 79 3d 33 00  0n8.bootdelay=3.
00000040: 62 6f 6f 74 66 69 6c 65 3d 75 49 6d 61 67 65 00  bootfile=uImage.
00000050: 66 64 74 63 6f 6e 74 72 6f 6c 61 64 64 72 3d 39  fdtcontroladdr=9
00000060: 66 66 62 31 62 61 30 00 6c 6f 61 64 61 64 64 72  ffb1ba0.loadaddr
00000070: 3d 30 78 38 32 30 30 30 30 30 30 00 73 74 64 65  =0x82000000.stde
00000080: 72 72 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32  rr=serial0@e0022
00000090: 30 30 30 00 73 74 64 69 6e 3d 73 65 72 69 61 6c  000.stdin=serial
000000a0: 30 40 65 30 30 32 32 30 30 30 00 73 74 64 6f 75  0@e0022000.stdou
000000b0: 74 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 30  t=serial0@e00220
000000c0: 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00..............
...
------------------->8----------------

Source of hexdump.c was copied from Linux kernel v4.7-rc2.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>