Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
Hi, Just to add my tested-by to the patch sent by Grygorii Strashko on 03/31/2016 (https://lkml.org/lkml/2016/3/31/609). The patch was tested on a v4.6 kernel, running in a Juno r1 development board, being the USB 3.0 Host prototyped in a FPGA. Tested-by: Joao Pinto <jpi...@synopsys.com> Thanks, Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci DWC3 flavor problem
Hi, Just to give you an update. All is working great, the cause was an FPGA configuration issue. Thank you for your support. Joao On 5/19/2016 4:42 PM, Joao Pinto wrote: > > After a few moments the schedule problem happen again: > > # INFO: task kworker/0:1:349 blocked for more than 120 seconds. > Not tainted 4.6.0-rc5 #9 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/0:1 D ff8008086c60 0 349 2 0x > Workqueue: usb_hub_wq hub_event > Call trace: > [] __switch_to+0xc8/0xd4 > [] __schedule+0x18c/0x5c8 > [] schedule+0x38/0x98 > [] schedule_timeout+0x160/0x1ac > [] wait_for_common+0xac/0x150 > [] wait_for_completion+0x14/0x1c > [] xhci_alloc_dev+0xf4/0x2a0 > [] usb_alloc_dev+0x68/0x2cc > [] hub_event+0x784/0x11f4 > [] process_one_work+0x130/0x2f4 > [] worker_thread+0x54/0x434 > [] kthread+0xd4/0xe8 > [] ret_from_fork+0x10/0x40 > INFO: task kworker/0:1:349 blocked for more than 120 seconds. > Not tainted 4.6.0-rc5 #9 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/0:1 D ff8008086c60 0 349 2 0x > Workqueue: usb_hub_wq hub_event > Call trace: > [] __switch_to+0xc8/0xd4 > [] __schedule+0x18c/0x5c8 > [] schedule+0x38/0x98 > [] schedule_timeout+0x160/0x1ac > [] wait_for_common+0xac/0x150 > [] wait_for_completion+0x14/0x1c > [] xhci_alloc_dev+0xf4/0x2a0 > [] usb_alloc_dev+0x68/0x2cc > [] hub_event+0x784/0x11f4 > [] process_one_work+0x130/0x2f4 > [] worker_thread+0x54/0x434 > [] kthread+0xd4/0xe8 > [] ret_from_fork+0x10/0x40 > > So Chris' patch did not solve this problem either. > > Thanks. > > On 5/19/2016 4:39 PM, Joao Pinto wrote: >> Hi Felipe and Mathias, >> >> On 5/19/2016 1:22 PM, Mathias Nyman wrote: >>> On 19.05.2016 14:23, Joao Pinto wrote: >>>> Hi Felipe, >>>> >>>> On 5/19/2016 11:32 AM, Felipe Balbi wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> Note that we really did get a command timeout. Can you add a little >>>>> extra debugging to try and figure out why that command failed? >>>>> >>>> >>>> After instrumenting and capturing FPGA signals, the driver could go a bit >>>> further... Could this be a FPGA timming issue? >>>> >>> .. >>> >>>> xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command >>>> usb 3-1: hub failed to enable device, error -62 >>>> xhci-hcd xhci-hcd.0.auto: Endpoint 0x0 ep reset callback called >>>> xhci-hcd xhci-hcd.0.auto: xHCI dying or halted, can't queue_command >>>> xhci-hcd xhci-hcd.0.auto: FIXME: allocate a command ring segment >>>> usb usb3-port1: couldn't allocate usb_device >>>> >>>> Joao >>> >>> Does the patch from Chris Bainbridge help? >>> It's currently only Gregs tree in the usb-next branch. >>> >>> It fixes a locking issue where hw can't handle several ports being in >>> default >>> state at >>> the same time, and setup device command timeout issue when both usb2 and >>> usb3 >>> devices >>> try to enumerate at the same time. >>> >>> commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 >>> usb: core: hub: hub_port_init lock controller instead of bus >> >> Applied Chris' patch and apparently solved the cyclic crash problem that >> happened every time the wait completion timeout and context had to change. >> But >> the log after insert pen drive remains the same: >> >> xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 >> xhci-hcd xhci-hcd.0.auto: resume root hub >> xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. >> xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 >> xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 >> xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status = >> 0x6e1 >> xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 >> xhci-hcd xhci-hcd.0.auto: Get port status returned 0x101 >> xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. >> xhci-hcd xhci-hcd.0.auto: // Ding dong! >> xhci-hcd xhci-hcd.0.auto: Command timeout >> xhci-hcd xhci-hcd.0.auto: Abort command ring >> >> >> It worked a bit a few hours ago like I tiold you in a past e-mail: >> After instrumenting and capturing FPGA signals, the driver could go a bit >>
Re: xhci DWC3 flavor problem
After a few moments the schedule problem happen again: # INFO: task kworker/0:1:349 blocked for more than 120 seconds. Not tainted 4.6.0-rc5 #9 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/0:1 D ff8008086c60 0 349 2 0x Workqueue: usb_hub_wq hub_event Call trace: [] __switch_to+0xc8/0xd4 [] __schedule+0x18c/0x5c8 [] schedule+0x38/0x98 [] schedule_timeout+0x160/0x1ac [] wait_for_common+0xac/0x150 [] wait_for_completion+0x14/0x1c [] xhci_alloc_dev+0xf4/0x2a0 [] usb_alloc_dev+0x68/0x2cc [] hub_event+0x784/0x11f4 [] process_one_work+0x130/0x2f4 [] worker_thread+0x54/0x434 [] kthread+0xd4/0xe8 [] ret_from_fork+0x10/0x40 INFO: task kworker/0:1:349 blocked for more than 120 seconds. Not tainted 4.6.0-rc5 #9 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/0:1 D ff8008086c60 0 349 2 0x Workqueue: usb_hub_wq hub_event Call trace: [] __switch_to+0xc8/0xd4 [] __schedule+0x18c/0x5c8 [] schedule+0x38/0x98 [] schedule_timeout+0x160/0x1ac [] wait_for_common+0xac/0x150 [] wait_for_completion+0x14/0x1c [] xhci_alloc_dev+0xf4/0x2a0 [] usb_alloc_dev+0x68/0x2cc [] hub_event+0x784/0x11f4 [] process_one_work+0x130/0x2f4 [] worker_thread+0x54/0x434 [] kthread+0xd4/0xe8 [] ret_from_fork+0x10/0x40 So Chris' patch did not solve this problem either. Thanks. On 5/19/2016 4:39 PM, Joao Pinto wrote: > Hi Felipe and Mathias, > > On 5/19/2016 1:22 PM, Mathias Nyman wrote: >> On 19.05.2016 14:23, Joao Pinto wrote: >>> Hi Felipe, >>> >>> On 5/19/2016 11:32 AM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> >>>> Note that we really did get a command timeout. Can you add a little >>>> extra debugging to try and figure out why that command failed? >>>> >>> >>> After instrumenting and capturing FPGA signals, the driver could go a bit >>> further... Could this be a FPGA timming issue? >>> >> .. >> >>> xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command >>> usb 3-1: hub failed to enable device, error -62 >>> xhci-hcd xhci-hcd.0.auto: Endpoint 0x0 ep reset callback called >>> xhci-hcd xhci-hcd.0.auto: xHCI dying or halted, can't queue_command >>> xhci-hcd xhci-hcd.0.auto: FIXME: allocate a command ring segment >>> usb usb3-port1: couldn't allocate usb_device >>> >>> Joao >> >> Does the patch from Chris Bainbridge help? >> It's currently only Gregs tree in the usb-next branch. >> >> It fixes a locking issue where hw can't handle several ports being in default >> state at >> the same time, and setup device command timeout issue when both usb2 and usb3 >> devices >> try to enumerate at the same time. >> >> commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 >> usb: core: hub: hub_port_init lock controller instead of bus > > Applied Chris' patch and apparently solved the cyclic crash problem that > happened every time the wait completion timeout and context had to change. But > the log after insert pen drive remains the same: > > xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 > xhci-hcd xhci-hcd.0.auto: resume root hub > xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. > xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 > xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 > xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status = > 0x6e1 > xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 > xhci-hcd xhci-hcd.0.auto: Get port status returned 0x101 > xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. > xhci-hcd xhci-hcd.0.auto: // Ding dong! > xhci-hcd xhci-hcd.0.auto: Command timeout > xhci-hcd xhci-hcd.0.auto: Abort command ring > > > It worked a bit a few hours ago like I tiold you in a past e-mail: > After instrumenting and capturing FPGA signals, the driver could go a bit > further... Could this be a FPGA timming issue? > > > xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 > xhci-hcd xhci-hcd.0.auto: resume root hub > xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. > xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 > xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 > xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status = > 0x6e1 > xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. > xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 > xhci-hcd xhci-hcd.0.auto: Get port status r
Re: xhci DWC3 flavor problem
Hi Felipe and Mathias, On 5/19/2016 1:22 PM, Mathias Nyman wrote: > On 19.05.2016 14:23, Joao Pinto wrote: >> Hi Felipe, >> >> On 5/19/2016 11:32 AM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> >>> Note that we really did get a command timeout. Can you add a little >>> extra debugging to try and figure out why that command failed? >>> >> >> After instrumenting and capturing FPGA signals, the driver could go a bit >> further... Could this be a FPGA timming issue? >> > .. > >> xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command >> usb 3-1: hub failed to enable device, error -62 >> xhci-hcd xhci-hcd.0.auto: Endpoint 0x0 ep reset callback called >> xhci-hcd xhci-hcd.0.auto: xHCI dying or halted, can't queue_command >> xhci-hcd xhci-hcd.0.auto: FIXME: allocate a command ring segment >> usb usb3-port1: couldn't allocate usb_device >> >> Joao > > Does the patch from Chris Bainbridge help? > It's currently only Gregs tree in the usb-next branch. > > It fixes a locking issue where hw can't handle several ports being in default > state at > the same time, and setup device command timeout issue when both usb2 and usb3 > devices > try to enumerate at the same time. > > commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 > usb: core: hub: hub_port_init lock controller instead of bus Applied Chris' patch and apparently solved the cyclic crash problem that happened every time the wait completion timeout and context had to change. But the log after insert pen drive remains the same: xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 xhci-hcd xhci-hcd.0.auto: resume root hub xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status = 0x6e1 xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x101 xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. xhci-hcd xhci-hcd.0.auto: // Ding dong! xhci-hcd xhci-hcd.0.auto: Command timeout xhci-hcd xhci-hcd.0.auto: Abort command ring It worked a bit a few hours ago like I tiold you in a past e-mail: After instrumenting and capturing FPGA signals, the driver could go a bit further... Could this be a FPGA timming issue? xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 xhci-hcd xhci-hcd.0.auto: resume root hub xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status = 0x6e1 xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x101 xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. xhci-hcd xhci-hcd.0.auto: // Ding dong! xhci-hcd xhci-hcd.0.auto: Slot 1 output ctx = 0x9f5d64000 (dma) xhci-hcd xhci-hcd.0.auto: Slot 1 input ctx = 0x9f5d68000 (dma) xhci-hcd xhci-hcd.0.auto: Set slot id 1 dcbaa entry ff800807c008 to 0x9f5d64000 xhci-hcd xhci-hcd.0.auto: set port reset, actual port 0 status = 0x6f1 xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x200e03 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x100503 xhci-hcd xhci-hcd.0.auto: clear port reset change, actual port 0 status = 0xe03 usb 3-1: new high-speed USB device number 2 using xhci-hcd xhci-hcd xhci-hcd.0.auto: Set root hub portnum to 1 xhci-hcd xhci-hcd.0.auto: Set fake root hub portnum to 1 xhci-hcd xhci-hcd.0.auto: udev->tt = (null) xhci-hcd xhci-hcd.0.auto: udev->ttport = 0x0 xhci-hcd xhci-hcd.0.auto: Slot ID 1 Input Context: xhci-hcd xhci-hcd.0.auto: @ff8008acd000 (virt) @9f5d68000 (dma) 0x00 - drop flags xhci-hcd xhci-hcd.0.auto: @ff8008acd004 (virt) @9f5d68004 (dma) 0x03 - add flags xhci-hcd xhci-hcd.0.auto: @ff8008acd008 (virt) @9f5d68008 (dma) 0x00 - rsvd2[0] xhci-hcd xhci-hcd.0.auto: @ff8008acd00c (virt) @9f5d6800c (dma) 0x00 - rsvd2[1] xhci-hcd xhci-hcd.0.auto: @ff8008acd010 (virt) @9f5d68010 (dma) 0x00 - rsvd2[2] xhci-hcd xhci-hcd.0.auto: @ff8008acd014 (virt) @9f5d68014 (dma) 0x00 - rsvd2[3] xhci-hcd xhci-hcd.0.auto: @ff8008acd018 (virt) @9f5d68018 (dma) 0x00 - rsvd2[4] xhci-hcd xhci-hcd.0.auto: @ff8008acd01c (virt) @9f5d6801c (dma) 0x00 - rsvd2[5] xhci-hcd xhci-hcd.0.auto: @ff8008acd020 (virt) @9f5d68020 (dma) 0x00 - rsvd64[0] xhci-hcd xhci-hcd.0.auto: @ff8008acd
Re: xhci DWC3 flavor problem
Hi Mathias and Felipe, On 5/19/2016 1:22 PM, Mathias Nyman wrote: > On 19.05.2016 14:23, Joao Pinto wrote: >> Hi Felipe, >> >> On 5/19/2016 11:32 AM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> >>> Note that we really did get a command timeout. Can you add a little >>> extra debugging to try and figure out why that command failed? >>> >> >> After instrumenting and capturing FPGA signals, the driver could go a bit >> further... Could this be a FPGA timming issue? >> > .. > >> xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command >> usb 3-1: hub failed to enable device, error -62 >> xhci-hcd xhci-hcd.0.auto: Endpoint 0x0 ep reset callback called >> xhci-hcd xhci-hcd.0.auto: xHCI dying or halted, can't queue_command >> xhci-hcd xhci-hcd.0.auto: FIXME: allocate a command ring segment >> usb usb3-port1: couldn't allocate usb_device >> >> Joao > > Does the patch from Chris Bainbridge help? > It's currently only Gregs tree in the usb-next branch. > > It fixes a locking issue where hw can't handle several ports being in default > state at > the same time, and setup device command timeout issue when both usb2 and usb3 > devices > try to enumerate at the same time. > > commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 > usb: core: hub: hub_port_init lock controller instead of bus > I will apply the changes in that commit and give you update in 2h. Thanks. > -Mathias > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci DWC3 flavor problem
Hi Felipe, On 5/19/2016 11:32 AM, Felipe Balbi wrote: > > Hi, > > Joao Pinto <joao.pi...@synopsys.com> writes: >> Hi Felipe and Mathias, >> >> Sending kernel log with extra xhci messages in attachment! >> Thanks you for the help! > > yeah, no problems. So here's the interesting part: > >*INSERTING PEN DRIVE > ># xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 >xhci-hcd xhci-hcd.0.auto: resume root hub >xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. >xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 >xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 >xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status > = 0x6e1 >xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. >xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 >xhci-hcd xhci-hcd.0.auto: Get port status returned 0x101 >xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. >xhci-hcd xhci-hcd.0.auto: // Ding dong! >xhci-hcd xhci-hcd.0.auto: Command timeout >xhci-hcd xhci-hcd.0.auto: Abort command ring > > Note that we really did get a command timeout. Can you add a little > extra debugging to try and figure out why that command failed? > After instrumenting and capturing FPGA signals, the driver could go a bit further... Could this be a FPGA timming issue? xhci-hcd xhci-hcd.0.auto: Port Status Change Event for port 1 xhci-hcd xhci-hcd.0.auto: resume root hub xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x206e1 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x10101 xhci-hcd xhci-hcd.0.auto: clear port connect change, actual port 0 status = 0x6e1 xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x6e1 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x101 xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping port polling. xhci-hcd xhci-hcd.0.auto: // Ding dong! xhci-hcd xhci-hcd.0.auto: Slot 1 output ctx = 0x9f5d64000 (dma) xhci-hcd xhci-hcd.0.auto: Slot 1 input ctx = 0x9f5d68000 (dma) xhci-hcd xhci-hcd.0.auto: Set slot id 1 dcbaa entry ff800807c008 to 0x9f5d64000 xhci-hcd xhci-hcd.0.auto: set port reset, actual port 0 status = 0x6f1 xhci-hcd xhci-hcd.0.auto: get port status, actual port 0 status = 0x200e03 xhci-hcd xhci-hcd.0.auto: Get port status returned 0x100503 xhci-hcd xhci-hcd.0.auto: clear port reset change, actual port 0 status = 0xe03 usb 3-1: new high-speed USB device number 2 using xhci-hcd xhci-hcd xhci-hcd.0.auto: Set root hub portnum to 1 xhci-hcd xhci-hcd.0.auto: Set fake root hub portnum to 1 xhci-hcd xhci-hcd.0.auto: udev->tt = (null) xhci-hcd xhci-hcd.0.auto: udev->ttport = 0x0 xhci-hcd xhci-hcd.0.auto: Slot ID 1 Input Context: xhci-hcd xhci-hcd.0.auto: @ff8008acd000 (virt) @9f5d68000 (dma) 0x00 - drop flags xhci-hcd xhci-hcd.0.auto: @ff8008acd004 (virt) @9f5d68004 (dma) 0x03 - add flags xhci-hcd xhci-hcd.0.auto: @ff8008acd008 (virt) @9f5d68008 (dma) 0x00 - rsvd2[0] xhci-hcd xhci-hcd.0.auto: @ff8008acd00c (virt) @9f5d6800c (dma) 0x00 - rsvd2[1] xhci-hcd xhci-hcd.0.auto: @ff8008acd010 (virt) @9f5d68010 (dma) 0x00 - rsvd2[2] xhci-hcd xhci-hcd.0.auto: @ff8008acd014 (virt) @9f5d68014 (dma) 0x00 - rsvd2[3] xhci-hcd xhci-hcd.0.auto: @ff8008acd018 (virt) @9f5d68018 (dma) 0x00 - rsvd2[4] xhci-hcd xhci-hcd.0.auto: @ff8008acd01c (virt) @9f5d6801c (dma) 0x00 - rsvd2[5] xhci-hcd xhci-hcd.0.auto: @ff8008acd020 (virt) @9f5d68020 (dma) 0x00 - rsvd64[0] xhci-hcd xhci-hcd.0.auto: @ff8008acd028 (virt) @9f5d68028 (dma) 0x00 - rsvd64[1] xhci-hcd xhci-hcd.0.auto: @ff8008acd030 (virt) @9f5d68030 (dma) 0x00 - rsvd64[2] xhci-hcd xhci-hcd.0.auto: @ff8008acd038 (virt) @9f5d68038 (dma) 0x00 - rsvd64[3] xhci-hcd xhci-hcd.0.auto: Slot Context: xhci-hcd xhci-hcd.0.auto: @ff8008acd040 (virt) @9f5d68040 (dma) 0x830 - dev_info xhci-hcd xhci-hcd.0.auto: @ff8008acd044 (virt) @9f5d68044 (dma) 0x01 - dev_info2 xhci-hcd xhci-hcd.0.auto: @ff8008acd048 (virt) @9f5d68048 (dma) 0x00 - tt_info xhci-hcd xhci-hcd.0.auto: @ff8008acd04c (virt) @9f5d6804c (dma) 0x00 - dev_state xhci-hcd xhci-hcd.0.auto: @ff8008acd050 (virt) @9f5d68050 (dma) 0x00 - rsvd[0] xhci-hcd xhci-hcd.0.auto: @ff8008acd054 (virt) @9f5d68054 (dma) 0x00 - rsvd[1] xhci-hcd xhci-hcd.0.auto: @ff8008acd058 (virt) @9f5d68058 (dma) 0x00 - rsvd[2] xhci-hcd xhci-hcd.0.auto: @ff8008acd05c (virt) @9f5d6805c (dma) 0x00 - rsvd[3] xhci-hcd xhci-hcd.0.auto: @ff8008acd060 (virt) @9f5d68060 (dma) 0x00 -
Re: xhci DWC3 flavor problem
Hi Felipe and Mathias,
Sending kernel log with extra xhci messages in attachment!
Thanks you for the help!
On 5/19/2016 11:02 AM, Joao Pinto wrote:
> Hi Felipe!
>
> On 5/19/2016 10:57 AM, Felipe Balbi wrote:
>>
>> Hi João,
>>
>> Adding Mathias, who's xHCI's maintainer
>>
>> Joao Pinto <joao.pi...@synopsys.com> writes:
>>> Hi Felipe,
>>>
>>> I am trying to bring up a DWC USB 3.0 Host with linux (v4.6-rc5)
>>> running in a ARM64 development board.
>>
>> Just to be clear, is this Juno with dwc3 in FPGA or do you have dwc3 in ASIC?
>
> yes, this is Juno r1.
>
>>
>>> I have implemented the following suggested fix to overcome the DMA
>>> problem I was having:
>>>
>>> https://lkml.org/lkml/2016/3/31/609
>>>
>>> I received one interrupt but I am getting cyclic crashes like this:
>>
>> if they happen all the time, it probably means your command ring is
>> completely messed up and no command ever completes. Can you share a more
>> complete snippet of logs?
>>
>>> [] __switch_to+0xc8/0xd4
>>> [] __schedule+0x18c/0x5c8
>>> [] schedule+0x38/0x98
>>> [] schedule_timeout+0x160/0x1ac
>>> [] wait_for_common+0xac/0x150
>>> [] wait_for_completion+0x14/0x1c
>>> [] xhci_alloc_dev+0xf4/0x2a0
>>> [] usb_alloc_dev+0x68/0x2cc
>>> [] hub_event+0x784/0x11f4
>>> [] process_one_work+0x130/0x2f4
>>> [] worker_thread+0x54/0x434
>>> [] kthread+0xd4/0xe8
>>> [] ret_from_fork+0x10/0x40
>>>
>>> Any thoughts about what might be happening?
>>
>> pasting xhci_alloc_dev here:
>>
>>> int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
>>> {
>>> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>> unsigned long flags;
>>> int ret, slot_id;
>>> struct xhci_command *command;
>>>
>>> command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
>>> if (!command)
>>> return 0;
>>
>> we allocate a command fine
>>
>>> /* xhci->slot_id and xhci->addr_dev are not thread-safe */
>>> mutex_lock(>mutex);
>>> spin_lock_irqsave(>lock, flags);
>>> command->completion = >addr_dev;
>>> ret = xhci_queue_slot_control(xhci, command, TRB_ENABLE_SLOT, 0);
>>
>> queue it to the command ring
>>
>>> if (ret) {
>>> spin_unlock_irqrestore(>lock, flags);
>>> mutex_unlock(>mutex);
>>> xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
>>> kfree(command);
>>> return 0;
>>> }
>>> xhci_ring_cmd_db(xhci);
>>> spin_unlock_irqrestore(>lock, flags);
>>>
>>> wait_for_completion(command->completion);
>>
>> but the command never completes. I wonder if your command doorbell
>> completed before wait_for_completion() was called, or if it didn't
>> complete at all.
>
> Ok I am going to activate dynamic debug for xhci and send you complete log.
>>
>> Can you enable XHCI debugging logs and try again? (Mathias, what was the
>> easy trick to enable all XHCI debugging logs?)
>>
>
> Thanks!
>
> Joao
>
Joao
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.05.19 11:14:08 =~=~=~=~=~=~=~=~=~=~=~=
Powering up system...
Logic Tile fitted to tile site.
Switching on ATXPSU...
PMIC RAM configuration (pms_v104.bin)...
MBtemp : 30 degC
Configuring motherboard (rev C, var A)...
IOFPGA image \MB\HBI0262C\io_b117.bit
IOFPGA config: PASSED
OSC CLK config: PASSED
Configuring SCC registers...
Writing SCC 0x0054 with 0x0007FFFE
Writing SCC 0x005C with 0x00FE001E
Writing SCC 0x0100 with 0x003F1000
Writing SCC 0x0104 with 0x0001F300
Writing SCC 0x0108 with 0x00331000
Writing SCC 0x010C with 0x00019300
Writing SCC 0x0118 with 0x003F1000
Writing SCC 0x011C with 0x0001F100
Writing SCC 0x00F4 with 0x4108
Writing SCC 0x00F8 with 0x0BEC
Writing SCC 0x00FC with 0xABE4
Writing SCC 0x0A14 with 0x
Writing SCC 0x000C with 0x00C2
Writing SCC 0x0010 with 0x00C2
Writing SCC 0x0050 with 0x0001
Peripheral ID0:0x00AD
Peripheral ID1:0x00B0
Peripheral ID2:0x001B
Peripheral ID3:0x
Peripheral ID4:0x000D
Peripheral ID5:0x00F0
Peripheral ID6:0x0005
Peripheral ID7:0x00B1
Programming NOR Flash
PCIE clock configured...
Testing motherboard interfaces (FPGA build 117)...
SRAM 32MB test: PASSED
LAN9118 test: PASSED
KMI1/2test: P
xhci DWC3 flavor problem
Hi Felipe, I am trying to bring up a DWC USB 3.0 Host with linux (v4.6-rc5) running in a ARM64 development board. I have implemented the following suggested fix to overcome the DMA problem I was having: https://lkml.org/lkml/2016/3/31/609 I received one interrupt but I am getting cyclic crashes like this: [] __switch_to+0xc8/0xd4 [] __schedule+0x18c/0x5c8 [] schedule+0x38/0x98 [] schedule_timeout+0x160/0x1ac [] wait_for_common+0xac/0x150 [] wait_for_completion+0x14/0x1c [] xhci_alloc_dev+0xf4/0x2a0 [] usb_alloc_dev+0x68/0x2cc [] hub_event+0x784/0x11f4 [] process_one_work+0x130/0x2f4 [] worker_thread+0x54/0x434 [] kthread+0xd4/0xe8 [] ret_from_fork+0x10/0x40 Any thoughts about what might be happening? Thanks. Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dwc3+xhci in ARM64 issue
Hi Felipe, I confirmed that no interrupts are received. My hw colleague is going to check the design! On 4/29/2016 11:25 AM, Felipe Balbi wrote: > > Hi João, > > Joao Pinto <joao.pi...@synopsys.com> writes: >> I am trying to bring up a USB 3.0 Host Controller with an ARM64 platform >> (Juno) >> and I was also getting the dma issue discussed in this thread: >> >> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg73137.html >> [snip] >> usb usb4: Manufacturer: Linux 4.6.0-rc5 xhci-hcd >> usb usb4: SerialNumber: xhci-hcd.0.auto >> hub 4-0:1.0: USB hub found >> hub 4-0:1.0: 1 port detected >> usbcore: registered new interface driver usb-storage >> >> The problem now is when I insert a pendrive nothing really happens, not sure >> why >> exactly. >> >> Could you give me an hint? > > Do you get any interrupts at all ? When a pen drive is attached, XHCI > should interrupt and it should see a port status change. Check > /proc/interrupts before and after connecting this pendrive of yours. > Thanks for the help, I will give an update on this. Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dwc3+xhci in ARM64 issue
Hi Felipe, I am trying to bring up a USB 3.0 Host Controller with an ARM64 platform (Juno) and I was also getting the dma issue discussed in this thread: https://www.mail-archive.com/linux-usb@vger.kernel.org/msg73137.html I then applied Grygorii Strashko' patch and managed to have a bus instantiated: DWC3 logs: # dmesg | grep dwc3 dwc3 6000.dwc3: assigned reserved memory node junoipk@6000 chci logs: xhci-hcd xhci-hcd.0.auto: xHCI Host Controller xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 3 xhci-hcd xhci-hcd.0.auto: hcc params 0x0220fe65 hci version 0x110 quirks 0x00010010 xhci-hcd xhci-hcd.0.auto: irq 30, io mem 0x6000 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: xHCI Host Controller usb usb3: Manufacturer: Linux 4.6.0-rc5 xhci-hcd usb usb3: SerialNumber: xhci-hcd.0.auto hub 3-0:1.0: USB hub found hub 3-0:1.0: 1 port detected xhci-hcd xhci-hcd.0.auto: xHCI Host Controller xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 4 usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: xHCI Host Controller usb usb4: Manufacturer: Linux 4.6.0-rc5 xhci-hcd usb usb4: SerialNumber: xhci-hcd.0.auto hub 4-0:1.0: USB hub found hub 4-0:1.0: 1 port detected usbcore: registered new interface driver usb-storage The problem now is when I insert a pendrive nothing really happens, not sure why exactly. Could you give me an hint? Thanks for the help! Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] USB 3.0 PCI Endpoint problem
Hi Felipe, On 2/22/2016 8:39 AM, Felipe Balbi wrote: > > Could this be a bug in your emulation environment ? Have you tested any > other PCIe endpoints ? > We tried with a SATA endpoint and experienced the same problem, so there's some problem that must be solved in our virtualization environment. Thanks. Joao -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[HELP] USB 3.0 PCI Endpoint problem
Hi to all! I am testing a PCIe Root Complex prototyping setup in which I have a USB 3.0 host as a PCI Endpoint. Running in an ARC CPU platform it works well, but when running in an emulated ARM64 (this is done by a Synopsys virtualization tool) the endpoint initialization fails as can be seen in the following log: xhci_hcd :01:00.0: xHCI Host Controller xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 xhci_hcd :01:00.0: xHCI capability registers at ff80002c4000: xhci_hcd :01:00.0: CAPLENGTH AND HCIVERSION 0x960020: xhci_hcd :01:00.0: CAPLENGTH: 0x20 xhci_hcd :01:00.0: HCIVERSION: 0x96 xhci_hcd :01:00.0: HCSPARAMS 1: 0x4000820 xhci_hcd :01:00.0: Max device slots: 32 xhci_hcd :01:00.0: Max interrupters: 8 xhci_hcd :01:00.0: Max ports: 4 xhci_hcd :01:00.0: HCSPARAMS 2: 0x11 xhci_hcd :01:00.0: Isoc scheduling threshold: 1 xhci_hcd :01:00.0: Maximum allowed segments in event ring: 1 xhci_hcd :01:00.0: HCSPARAMS 3 0x0: xhci_hcd :01:00.0: Worst case U1 device exit latency: 0 xhci_hcd :01:00.0: Worst case U2 device exit latency: 0 xhci_hcd :01:00.0: HCC PARAMS 0x14042cb: xhci_hcd :01:00.0: HC generates 64 bit addresses xhci_hcd :01:00.0: FIXME: more HCCPARAMS debugging xhci_hcd :01:00.0: RTSOFF 0x600: xhci_hcd :01:00.0: xHCI operational registers at ff80002c4020: xhci_hcd :01:00.0: USBCMD 0x0: xhci_hcd :01:00.0: HC is being stopped xhci_hcd :01:00.0: HC has finished hard reset xhci_hcd :01:00.0: Event Interrupts disabled xhci_hcd :01:00.0: Host System Error Interrupts disabled xhci_hcd :01:00.0: HC has finished light reset xhci_hcd :01:00.0: USBSTS 0x9: xhci_hcd :01:00.0: Event ring is not empty xhci_hcd :01:00.0: No Host System Error xhci_hcd :01:00.0: HC is halted xhci_hcd :01:00.0: ff80002c4420 port status reg = 0x2a0 xhci_hcd :01:00.0: ff80002c4424 port power reg = 0x0 xhci_hcd :01:00.0: ff80002c4428 port link reg = 0x0 xhci_hcd :01:00.0: ff80002c442c port reserved reg = 0x0 xhci_hcd :01:00.0: ff80002c4430 port status reg = 0x2a0 xhci_hcd :01:00.0: ff80002c4434 port power reg = 0x0 xhci_hcd :01:00.0: ff80002c4438 port link reg = 0x0 xhci_hcd :01:00.0: ff80002c443c port reserved reg = 0x0 xhci_hcd :01:00.0: ff80002c4440 port status reg = 0x2a0 xhci_hcd :01:00.0: ff80002c port power reg = 0x0 xhci_hcd :01:00.0: ff80002c4448 port link reg = 0x0 xhci_hcd :01:00.0: ff80002c444c port reserved reg = 0x0 xhci_hcd :01:00.0: ff80002c4450 port status reg = 0x2a0 xhci_hcd :01:00.0: ff80002c4454 port power reg = 0x0 xhci_hcd :01:00.0: ff80002c4458 port link reg = 0x0 xhci_hcd :01:00.0: ff80002c445c port reserved reg = 0x0 xhci_hcd :01:00.0: // Halt the HC xhci_hcd :01:00.0: Resetting HCD xhci_hcd :01:00.0: // Reset the HC xhci_hcd :01:00.0: Wait for controller to be ready for doorbell rings xhci_hcd :01:00.0: Reset complete xhci_hcd :01:00.0: Enabling 64-bit DMA addresses. xhci_hcd :01:00.0: Calling HCD init xhci_hcd :01:00.0: xhci_init xhci_hcd :01:00.0: xHCI doesn't need link TRB QUIRK xhci_hcd :01:00.0: Supported page size register = 0x1 xhci_hcd :01:00.0: Supported page size of 4K xhci_hcd :01:00.0: HCD page size set to 4K xhci_hcd :01:00.0: // xHC can handle at most 32 device slots. xhci_hcd :01:00.0: // Setting Max device slots reg = 0x20. xhci_hcd :01:00.0: // Device context base array address = 0xfcafb000 (DMA), ff80002c7000 (virt) xhci_hcd :01:00.0: Allocated command ring at ffc07db28cc0 xhci_hcd :01:00.0: First segment DMA is 0xfc42c000 xhci_hcd :01:00.0: // Setting command ring address to 0x20 xhci_hcd :01:00.0: // xHC command ring deq ptr low bits + flags = @ xhci_hcd :01:00.0: // xHC command ring deq ptr high bits = @ xhci_hcd :01:00.0: // Doorbell array is located at offset 0x800 from cap regs base addr xhci_hcd :01:00.0: // xHCI capability registers at ff80002c4000: xhci_hcd :01:00.0: // @ff80002c4000 = 0x960020 (CAPLENGTH AND HCIVERSION) xhci_hcd :01:00.0: // CAPLENGTH: 0x20 xhci_hcd :01:00.0: // xHCI operational registers at ff80002c4020: xhci_hcd :01:00.0: // @ff80002c4018 = 0x600 RTSOFF xhci_hcd :01:00.0: // xHCI runtime registers at ff80002c4600: xhci_hcd :01:00.0: // @ff80002c4014 = 0x800 DBOFF xhci_hcd :01:00.0: // Doorbell array at ff80002c4800: xhci_hcd :01:00.0: xHCI runtime registers at ff80002c4600: xhci_hcd :01:00.0: ff80002c4600: Microframe index = 0x0 xhci_hcd :01:00.0: // Allocating event ring xhci_hcd :01:00.0: TRB math tests passed. xhci_hcd :01:00.0: // Allocated event ring segment table at 0xfc42e000 xhci_hcd :01:00.0: Set ERST to 0; private num segs = 1, virt addr =
[PATCH] gadget: added besl support
When testing the Synopsys DWC USB 3.0 Device IP, Compliant Tests are run for USB 3.0 and USB 2.0. An issue was found regarding the USB 2.0 CV Chapter 9 test: LPM L1 Suspend Resume Test. For it to be successful it is necessary to add besl support to the gadget driver and set the deep besl and baseline besl values. Signed-off-by: Joao Pinto <jpi...@synopsys.com> Tested-by: Joao Pinto <jpi...@synopsys.com> --- drivers/usb/gadget/composite.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index b474499..e907578 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -567,7 +567,14 @@ static int bos_desc(struct usb_composite_dev *cdev) usb_ext->bLength = USB_DT_USB_EXT_CAP_SIZE; usb_ext->bDescriptorType = USB_DT_DEVICE_CAPABILITY; usb_ext->bDevCapabilityType = USB_CAP_TYPE_EXT; - usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | USB_BESL_SUPPORT); + usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | + USB_BESL_SUPPORT | + USB_BESL_BASELINE_VALID | + USB_BESL_DEEP_VALID); + + usb_ext->bmAttributes &= cpu_to_le32(~(0x00f00 | 0x0f000)); + usb_ext->bmAttributes |= cpu_to_le32(4 << 8); + usb_ext->bmAttributes |= cpu_to_le32(5 << 12); /* * The Superspeed USB Capability descriptor shall be implemented by all -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB 3.0 LPM Certification issues
Hi! When testing our USB 3.0 Device IP solution we typically run the Compliance Tests for USB 3.0 and also for USB 2.0. We find an issue regarding the USB 2.0 CV Chapter 9 test: LPM L1 Suspend Resume Test. For it to be successful we have to edit the gadget driver in order to configure the baseline and deep besl parameters: --- b/drivers/usb/gadget/composite.c2015-08-05 07:21:03.0 +0100 +++ a/drivers/usb/gadget/composite.c2015-08-07 11:20:52.037425955 +0100 @@ -560,7 +560,17 @@ usb_ext-bLength = USB_DT_USB_EXT_CAP_SIZE; usb_ext-bDescriptorType = USB_DT_DEVICE_CAPABILITY; usb_ext-bDevCapabilityType = USB_CAP_TYPE_EXT; - usb_ext-bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | USB_BESL_SUPPORT); + usb_ext-bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | + USB_BESL_SUPPORT | + USB_BESL_BASELINE_VALID | + USB_BESL_DEEP_VALID); + + //baseline besl bits (0x00f00) and deep besl bits (0x0f000) + usb_ext-bmAttributes = cpu_to_le32(~(0x00f00 | 0x0f000)); + //setting baseline besl = 4 + usb_ext-bmAttributes |= cpu_to_le32(4 8); + //setting deep besl = 5 + usb_ext-bmAttributes |= cpu_to_le32(5 12); /* * The Superspeed USB Capability descriptor shall be implemented by all Is there any plans to put this parameters configurable in the gadget driver avoiding the need of patching it like shown previously? Thanks, Joao Pinto -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dwc3 issue
Hi Filipe! We are experiencing a problem in a solution using the dwc3 driver. I will start by enumerating the setup: a) CPU running Linux Kernel 3.18 b) DesignWare USB 3.0 Device IP c) Windows 7 Host PC The dwc3 is loading successfully, but when we plug to the Windows 7 PC, it takes around 2 minutes for the device to pop up in My Computer. During this time the driver seems to be looping through 2 tasks: task 1.“g_mass_storage_gadget: high-spped config #1: Linux File-Backed Storage” task 2.“dwc3 4900.usb: request * was not queued to ep1in-bulk” Could you please give us a hint about how to overcome this problem? Thanks, Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Support for OTG 2.0 in dwc3
Hi Filipe! Hope you are doing well! At Synopsys we are developing a system using our DesignWare USB 3.0 Controller, configured to operate as an USB 2.0 (featuring OTG 2.0). I talked to Jonh Youn about this and he said that something was being done to make dwc3 driver support OTG 2.0. I would like to know if you have any experimental code that we can use. If you agree we could help you in this task (involved in the development and beta testing) since we have the controller. Hope hearing from you soon! Regards, Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Synopsys IPs: USB 3.1 Device Host and USB 2.0 OTG
Hi, My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly in the USB Subsystem. I am sending you this email in order to know if someone is already working in the driver' development for Synopsys' USB 3.1 Host Device and USB 2.0 OTG Controllers. a) If no one is working, we have interest to start developing them b) If there is someone already developing them, we have interest in collaborating with the on going work Thanks, Joao Pinto -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Synopsys IPs: USB 3.1 Device Host and USB 2.0 OTG
Hi Filipe, On 4/27/2015 3:56 PM, Felipe Balbi wrote: Hi Joao, On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly in the USB Subsystem. I am sending you this email in order to know if someone is already working in the driver' development for Synopsys' USB 3.1 Host Device and USB 2.0 OTG Controllers. Have you looked at the latest kernel tree to verify what is and is not supported? That's your best source of information. I checked the USB Mailing List archive and the USB Git trees in order to find any reference of these drivers but nothing was found, so I would conclude that nothing was submitted about these 2 subjects. one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg controller available on e.g. raspberry pi. For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, I don't know anybody, except for synopsys employees, with access to the USB 3.1 documentation, but I would assume the core to be similar to the current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please confirm). If that's the case, then an incremental patch adding USB 3.1 support is much more desirable than an entire new driver. a) If no one is working, we have interest to start developing them Don't you already have internal code for these chips? Have you tested Linux with them? As you know internal code is not always suitable for kernel submission and so sometimes it is better to upgrade a std kernel driver like dwc3 (USB 3.0 Device) in order to make it support 3.1 as well. yes, it's better to upgrade that driver, however, that driver is not device only. I won't repeat myself trying to explain why we still don't have DRD/OTG support, but it's coming. b) If there is someone already developing them, we have interest in collaborating with the on going work Look at the changelog entries for the drivers for these chips, that should give you the information you need here. I have checked the USB tree' logs as I said previously and nothing relevant was found. But really, running the latest kernel and seeing what doesn't work for your hardware, and sending patches to fix this is the best way forward, don't you agree? I agree with you if we are dealing with small improvements or bug fixes, but in this case we are dealing with new drivers or important updates on existing ones. I would assume that USB 3.1 itself is a very small change. The bulk of the changes will probably come due to Type-C connector and USB Power Delivery and Billboard classes, however, that's not coupled with USB 3.1 at all. One of the good practices I read about kernel development is to ask first if someone is already working in a particular subject to avoid work duplication and that's what I am doing in this email. that's correct, it's always good to ask and doesn't really hurt anybody, but you also need to know who to ask :-) Greg can't know about everything (although usually... well), and since you're talking about changes to dwc2 and dwc3 it would be nice to Cc the maintainers for those drivers, right ? ;-) cheers Thank you very much for your inputs! When I have more details I will contact you about dwc3. Have a nice day! -- Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Synopsys IPs: USB 3.1 Device Host and USB 2.0 OTG
Hi Greg, On 4/27/2015 3:27 PM, Greg KH wrote: On Mon, Apr 27, 2015 at 09:59:19AM +0100, Joao Pinto wrote: Hi, My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly in the USB Subsystem. I am sending you this email in order to know if someone is already working in the driver' development for Synopsys' USB 3.1 Host Device and USB 2.0 OTG Controllers. Have you looked at the latest kernel tree to verify what is and is not supported? That's your best source of information. I checked the USB Mailing List archive and the USB Git trees in order to find any reference of these drivers but nothing was found, so I would conclude that nothing was submitted about these 2 subjects. a) If no one is working, we have interest to start developing them Don't you already have internal code for these chips? Have you tested Linux with them? As you know internal code is not always suitable for kernel submission and so sometimes it is better to upgrade a std kernel driver like dwc3 (USB 3.0 Device) in order to make it support 3.1 as well. b) If there is someone already developing them, we have interest in collaborating with the on going work Look at the changelog entries for the drivers for these chips, that should give you the information you need here. I have checked the USB tree' logs as I said previously and nothing relevant was found. But really, running the latest kernel and seeing what doesn't work for your hardware, and sending patches to fix this is the best way forward, don't you agree? I agree with you if we are dealing with small improvements or bug fixes, but in this case we are dealing with new drivers or important updates on existing ones. One of the good practices I read about kernel development is to ask first if someone is already working in a particular subject to avoid work duplication and that's what I am doing in this email. thanks, greg k-h Thanks, Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Synopsys IPs: USB 3.1 Device Host and USB 2.0 OTG
Hi, On 4/27/2015 4:49 PM, Felipe Balbi wrote: Hi, On Mon, Apr 27, 2015 at 04:04:08PM +0100, Joao Pinto wrote: Hi Filipe, that's Felipe (and yes, I know it's João, but you spelled it without ~) :-) On 4/27/2015 3:56 PM, Felipe Balbi wrote: Hi Joao, On Mon, Apr 27, 2015 at 03:48:48PM +0100, Joao Pinto wrote: My name is Joao Pinto and I am working at Synopsys as a Software Engineer mainly in the USB Subsystem. I am sending you this email in order to know if someone is already working in the driver' development for Synopsys' USB 3.1 Host Device and USB 2.0 OTG Controllers. Have you looked at the latest kernel tree to verify what is and is not supported? That's your best source of information. I checked the USB Mailing List archive and the USB Git trees in order to find any reference of these drivers but nothing was found, so I would conclude that nothing was submitted about these 2 subjects. one of your colleagues maintains dwc2 which is the synopsys usb 2.0 otg controller available on e.g. raspberry pi. For USB 3.1, nobody outside of synopsys (afaict) has access to any HW or FPGA with USB 3.1, so there isn't much we can do without HW :-) In fact, I don't know anybody, except for synopsys employees, with access to the USB 3.1 documentation, but I would assume the core to be similar to the current DWC USB3 (drivers/usb/dwc3) IP whose driver I maintain (please confirm). If that's the case, then an incremental patch adding USB 3.1 support is much more desirable than an entire new driver. a) If no one is working, we have interest to start developing them Don't you already have internal code for these chips? Have you tested Linux with them? As you know internal code is not always suitable for kernel submission and so sometimes it is better to upgrade a std kernel driver like dwc3 (USB 3.0 Device) in order to make it support 3.1 as well. yes, it's better to upgrade that driver, however, that driver is not device only. I won't repeat myself trying to explain why we still don't have DRD/OTG support, but it's coming. b) If there is someone already developing them, we have interest in collaborating with the on going work Look at the changelog entries for the drivers for these chips, that should give you the information you need here. I have checked the USB tree' logs as I said previously and nothing relevant was found. But really, running the latest kernel and seeing what doesn't work for your hardware, and sending patches to fix this is the best way forward, don't you agree? I agree with you if we are dealing with small improvements or bug fixes, but in this case we are dealing with new drivers or important updates on existing ones. I would assume that USB 3.1 itself is a very small change. The bulk of the changes will probably come due to Type-C connector and USB Power Delivery and Billboard classes, however, that's not coupled with USB 3.1 at all. One of the good practices I read about kernel development is to ask first if someone is already working in a particular subject to avoid work duplication and that's what I am doing in this email. that's correct, it's always good to ask and doesn't really hurt anybody, but you also need to know who to ask :-) Greg can't know about everything (although usually... well), and since you're talking about changes to dwc2 and dwc3 it would be nice to Cc the maintainers for those drivers, right ? ;-) cheers Thank you very much for your inputs! When I have more details I will contact you about dwc3. Have a nice day! you too, thanks Sorry Filipe, in Portugal we have the two ways: Felipe and Filipe! Cheers, Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for comments
On 3/3/2015 6:48 PM, Greg KH wrote: On Tue, Mar 03, 2015 at 05:06:45PM +, Joao Pinto wrote: Hello, I am sending this email in order to get some feedback from you about a feature that I am planning to do in a driver I am working on. I don't see any code here, or really, any specifics, so there's nothing to comment on at all sorry. Remember, the Linux kernel community does things based on code, and specifics, only. good luck! greg k-h Thank you for your time! Regards Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Request for comments
Hello, I am sending this email in order to get some feedback from you about a feature that I am planning to do in a driver I am working on. This new feature basically is to turn the relationship between driver and hardware IP more transparent, making the software more robust. Let me explain the idea: a) The hardware has the capability of supplying to the driver the IP version and crucial features that it support or not b) The driver would read the hardware capability features and work without hick-ups even if the developer has configured him (e.g. menuconfig during build process) to do some specific thing that is not supported by the current connected hardware c) If the driver is configured to do something that the connected hardware is not capable of doing, it simply logs a message to kernel log and automatically disables it trying to work has fluid as possible d) If the hardware does not have the capability of supplying information of this type to the driver, than it should work according to the configuration In your opinion this feature would be a value-added to a new driver / existent driver? Thank you for your time! Best regards Joao --- -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request for comments
Hello Peter, On 3/3/2015 5:35 PM, Peter Stuge wrote: Hello Joao, Joao Pinto wrote: This new feature basically is to turn the relationship between driver and hardware IP more transparent, making the software more robust. This is an important matter already today, and will only become more important in the future. a) The hardware has the capability of supplying to the driver the IP version and crucial features that it support or not b) The driver would read the hardware capability features and work without hick-ups even if the developer has configured him (e.g. menuconfig during build process) to do some specific thing that is not supported by the current connected hardware Once the driver supports auto-detecting these features, I think that the manual configuration shall be removed. In my opinion a manual configuration should always exist to give the kernel user to enable/disable some features of the driver. c) If the driver is configured to do something that the connected hardware is not capable of doing, it simply logs a message to kernel log and automatically disables it trying to work has fluid as possible How the driver reacts in this situation is a matter of policy, which should probably not be specific to any one driver, but should probably be set at a slightly higher level, perhaps even by the person configuring/building the kernel. I agree with you. d) If the hardware does not have the capability of supplying information of this type to the driver, than it should work according to the configuration Hm? Can you be more specific? If it is *possible* for the combination of hardware+driver to work according to the configuration, why would the driver ever do anything else? A company that develops hardware IP can develop a driver that has special features that are specific to its IP. Imagine a USB super speed mode that is only supported by company X hardware IP. If in the future a peripheral connects to a PC using Linux that uses the hardware IP of company X, the driver will automatically recognize it and enable the special mode if configured to do so. In your opinion this feature would be a value-added to a new driver / existent driver? In general I feel strongly that hardware and drivers must stay close to each other, but some of the things you described are not completely clear to me, so it is difficult to give specific feedback. Can you provide more details? Please check above comments. Thanks //Peter Thanks for your time! Joao -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
