* XHCI controller does not detect USB key insertion
@ 2016-12-02 8:46 Mason
2016-12-02 9:03 ` Felipe Balbi
0 siblings, 1 reply; 11+ messages in thread
From: Mason @ 2016-12-02 8:46 UTC (permalink / raw)
To: linux-arm-kernel
Hello everyone,
I'm trying out a SoC with a brand new USB controller, which is (supposedly)
a standard XHCI controller. In theory, I would just need to build the right
driver, and everything would auto-magically work, right?
So my defconfig contains:
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
And my device tree contains:
usb3 at 30040000 {
compatible = "generic-xhci";
reg = <0x30040000 0x10000>;
interrupts = <SIGMA_HWIRQ 67 IRQ_TYPE_LEVEL_HIGH>;
};
The boot messages I get:
[ 1.618214] xhci-hcd 30040000.usb3: xHCI Host Controller
[ 1.623611] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 1
[ 1.631181] reset function is xhci_plat_setup
[ 1.635588] xhci_plat_setup from usb_add_hcd
[ 1.640109] xhci-hcd 30040000.usb3: hcc params 0x30003192 hci version 0x100 quirks 0x00010010
[ 1.648766] xhci-hcd 30040000.usb3: irq 22, io mem 0x30040000
[ 1.654572] xhci_plat_start from usb_add_hcd
[ 1.659086] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.665943] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.673228] usb usb1: Product: xHCI Host Controller
[ 1.678154] usb usb1: Manufacturer: Linux 4.7.0-rc6 xhci-hcd
[ 1.683865] usb usb1: SerialNumber: 30040000.usb3
[ 1.689391] hub 1-0:1.0: USB hub found
[ 1.693227] hub 1-0:1.0: 1 port detected
[ 1.697601] xhci-hcd 30040000.usb3: xHCI Host Controller
[ 1.702983] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 2
[ 1.710545] reset function is xhci_plat_setup
[ 1.714950] xhci_plat_setup from usb_add_hcd
[ 1.719265] xhci_plat_start from usb_add_hcd
[ 1.723653] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1.731956] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 1.738814] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.746100] usb usb2: Product: xHCI Host Controller
[ 1.751025] usb usb2: Manufacturer: Linux 4.7.0-rc6 xhci-hcd
[ 1.756736] usb usb2: SerialNumber: 30040000.usb3
[ 1.762195] hub 2-0:1.0: USB hub found
[ 1.766027] hub 2-0:1.0: 1 port detected
[ 1.770661] usbcore: registered new interface driver usb-storage
[ 1.784584] usbcore: registered new interface driver usbhid
[ 1.790213] usbhid: USB HID core driver
Which looks encouraging, right?
Am I supposed to have had USB interrupts at that point?
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
20: 609 365 393 356 GIC-0 29 Edge twd
21: 101 0 0 0 INTC 1 Level serial
22: 0 0 0 0 INTC 67 Level xhci-hcd:usb1
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 794 620 1223 1045 Rescheduling interrupts
IPI3: 0 37 37 37 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
When I insert a USB key, nothing happens :-(
# lsusb -v
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0003
I'd like to hear suggestions about what I can tweak to fix the problem.
Regards.
^ permalink raw reply [flat|nested] 11+ messages in thread* XHCI controller does not detect USB key insertion 2016-12-02 8:46 XHCI controller does not detect USB key insertion Mason @ 2016-12-02 9:03 ` Felipe Balbi 2016-12-02 10:24 ` Mason 0 siblings, 1 reply; 11+ messages in thread From: Felipe Balbi @ 2016-12-02 9:03 UTC (permalink / raw) To: linux-arm-kernel Hi, Mason <slash.tmp@free.fr> writes: > Hello everyone, > > I'm trying out a SoC with a brand new USB controller, which is (supposedly) > a standard XHCI controller. In theory, I would just need to build the right > driver, and everything would auto-magically work, right? perhaps, but there might be needed initialization of other resources like PHYs and stuff like that. > So my defconfig contains: > > CONFIG_USB=y > CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_PLATFORM=y > CONFIG_USB_STORAGE=y > CONFIG_USB_STORAGE_DEBUG=y > > > And my device tree contains: > > usb3 at 30040000 { > compatible = "generic-xhci"; > reg = <0x30040000 0x10000>; > interrupts = <SIGMA_HWIRQ 67 IRQ_TYPE_LEVEL_HIGH>; > }; > > > The boot messages I get: > > [ 1.618214] xhci-hcd 30040000.usb3: xHCI Host Controller > [ 1.623611] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 1 > [ 1.631181] reset function is xhci_plat_setup > [ 1.635588] xhci_plat_setup from usb_add_hcd > [ 1.640109] xhci-hcd 30040000.usb3: hcc params 0x30003192 hci version 0x100 quirks 0x00010010 > [ 1.648766] xhci-hcd 30040000.usb3: irq 22, io mem 0x30040000 > [ 1.654572] xhci_plat_start from usb_add_hcd > [ 1.659086] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [ 1.665943] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > [ 1.673228] usb usb1: Product: xHCI Host Controller > [ 1.678154] usb usb1: Manufacturer: Linux 4.7.0-rc6 xhci-hcd > [ 1.683865] usb usb1: SerialNumber: 30040000.usb3 > [ 1.689391] hub 1-0:1.0: USB hub found > [ 1.693227] hub 1-0:1.0: 1 port detected > [ 1.697601] xhci-hcd 30040000.usb3: xHCI Host Controller > [ 1.702983] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 2 > [ 1.710545] reset function is xhci_plat_setup > [ 1.714950] xhci_plat_setup from usb_add_hcd > [ 1.719265] xhci_plat_start from usb_add_hcd > [ 1.723653] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. > [ 1.731956] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 > [ 1.738814] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > [ 1.746100] usb usb2: Product: xHCI Host Controller > [ 1.751025] usb usb2: Manufacturer: Linux 4.7.0-rc6 xhci-hcd > [ 1.756736] usb usb2: SerialNumber: 30040000.usb3 > [ 1.762195] hub 2-0:1.0: USB hub found > [ 1.766027] hub 2-0:1.0: 1 port detected > [ 1.770661] usbcore: registered new interface driver usb-storage > [ 1.784584] usbcore: registered new interface driver usbhid > [ 1.790213] usbhid: USB HID core driver > > Which looks encouraging, right? yes > Am I supposed to have had USB interrupts at that point? nope, unless a device was already plugged in. > # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 20: 609 365 393 356 GIC-0 29 Edge twd > 21: 101 0 0 0 INTC 1 Level serial > 22: 0 0 0 0 INTC 67 Level xhci-hcd:usb1 > IPI0: 0 0 0 0 CPU wakeup interrupts > IPI1: 0 0 0 0 Timer broadcast interrupts > IPI2: 794 620 1223 1045 Rescheduling interrupts > IPI3: 0 37 37 37 Function call interrupts > IPI4: 0 0 0 0 CPU stop interrupts > IPI5: 0 0 0 0 IRQ work interrupts > IPI6: 0 0 0 0 completion interrupts > Err: 0 > > > When I insert a USB key, nothing happens :-( > > # lsusb -v > Bus 001 Device 001: ID 1d6b:0002 > Bus 002 Device 001: ID 1d6b:0003 > > > I'd like to hear suggestions about what I can tweak to fix the problem. go to your documentation and see if you have initialized everything. Which SoC is this? -- balbi ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 9:03 ` Felipe Balbi @ 2016-12-02 10:24 ` Mason 2016-12-02 10:42 ` Greg KH 2016-12-02 13:46 ` Neil Armstrong 0 siblings, 2 replies; 11+ messages in thread From: Mason @ 2016-12-02 10:24 UTC (permalink / raw) To: linux-arm-kernel On 02/12/2016 10:03, Felipe Balbi wrote: > Mason wrote: > >> I'm trying out a SoC with a brand new USB controller, which is (supposedly) >> a standard XHCI controller. In theory, I would just need to build the right >> driver, and everything would auto-magically work, right? > > perhaps, but there might be needed initialization of other resources > like PHYs and stuff like that. Let me dive into additional details... First of all, there is a register aptly called "USB3_RESET" which is used to release several USB3-related blocks from reset. Of course, that's the first register I tweaked :-) There are *3* address ranges with USB3-related registers. 1) one called host_usb30_xhcl (I believe "xhcl" is a typo for "xhci") This is the address I passed to the Linux driver. The first register is CAPLENGTH_VERSION. I assume these are the standard XHCI registers. (Last register is XHCL_EXTENDED_CAP3_USB3 at offset 0xc008) 2) one called host_usb30_port This contains "Device and Port Specific Registers". Is it standard? How is Linux supposed to know where to find it? Contains registers such as Device Transaction Status Device UTMI command and status for USB2 Set ISOC Delay USB3 Function Notification Rx DMA BD Start Address for Control Endpoint EP Burst Size Tx DMA BD Start Address Control Endpoint EP $N IN/OUT Device Notification Register EP_Isochronous Timestamp Are registers named LTSSM_TIMER_REGISTER{1,2,3} standard? they have fields such as reg_12_ms_timeout (and other numbers like 2, 6, 100, 300) 3) one called host_usb30 This contains lower-level stuff 0x2e800 CONFIG 0x2e804 CONTROL 0x2e808 TEST 0x2e80c STATUS 0x2e810 CLK_RST_0 0x2e814 CLK_RST_1 0x2e818 PARAM_0 0x2e81c PARAM_1 0x2e820 PARAM_2 0x2e880 SNPS_CR_ADD 0x2e884 SNPS_CR_DATA 0x2e8c0 RESET_CTRL I haven't touched any of these so far. >> # lsusb -v >> Bus 001 Device 001: ID 1d6b:0002 >> Bus 002 Device 001: ID 1d6b:0003 Isn't lsusb verbose supposed to print much more than that? >> I'd like to hear suggestions about what I can tweak to fix the problem. > > go to your documentation and see if you have initialized > everything. Which SoC is this? (Sad face) All the documentation I have is in front of me, and nothing is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI controller + Synopsys PHY. The documentation I have: Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals) Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers) PHY databook (very low-level stuff) SoC register mapping (for how the SoC maps the IP signals to registers) So far, I'm stumped :-( Regards. ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 10:24 ` Mason @ 2016-12-02 10:42 ` Greg KH 2016-12-02 11:08 ` Mason 2016-12-02 13:46 ` Neil Armstrong 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2016-12-02 10:42 UTC (permalink / raw) To: linux-arm-kernel On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote: > >> # lsusb -v > >> Bus 001 Device 001: ID 1d6b:0002 > >> Bus 002 Device 001: ID 1d6b:0003 > > Isn't lsusb verbose supposed to print much more than that? Yes, if you are using the usbutils version of 'lsusb', odds are this is busybox, right? And these are just the root hubs, that the USB controller driver creates as "virtual" USB devices, they are not "real" USB devices on your bus. hope this helps, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 10:42 ` Greg KH @ 2016-12-02 11:08 ` Mason 2016-12-02 11:16 ` Greg KH 0 siblings, 1 reply; 11+ messages in thread From: Mason @ 2016-12-02 11:08 UTC (permalink / raw) To: linux-arm-kernel On 02/12/2016 11:42, Greg KH wrote: > On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote: > >> # lsusb -v >> Bus 001 Device 001: ID 1d6b:0002 >> Bus 002 Device 001: ID 1d6b:0003 >> >> Isn't lsusb verbose supposed to print much more than that? > > Yes, if you are using the usbutils version of 'lsusb', odds are this is > busybox, right? Right. (You win a digital cookie.) cd buildroot && make menuconfig Drop BR2_PACKAGE_USBMOUNT (maybe it causes unexpected issues) Add BR2_PACKAGE_USBUTILS (I want the real deal) > And these are just the root hubs, that the USB controller driver creates > as "virtual" USB devices, they are not "real" USB devices on your bus. # lsusb --version lsusb (usbutils) 007 I see there's a 008 version. Am I missing out on important diagnostics? # lsusb -v Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice 4.07 iManufacturer 3 Linux 4.7.0-rc6 xhci-hcd iProduct 2 xHCI Host Controller iSerial 1 30040000.usb3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 31 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0 Hub Descriptor: bLength 12 bDescriptorType 42 nNbrPorts 1 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere bHubDecLat 0.0 micro seconds wHubDelay 0 nano seconds DeviceRemovable 0x00 Hub Port Status: Port 1: 0000.02a0 5Gbps power Rx.Detect Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 15 bNumDeviceCaps 1 SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x0008 Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 3 Lowest fully-functional device speed is SuperSpeed (5Gbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds Device Status: 0x0001 Self Powered Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 4.07 iManufacturer 3 Linux 4.7.0-rc6 xhci-hcd iProduct 2 xHCI Host Controller iSerial 1 30040000.usb3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Device Status: 0x0001 Self Powered Does everything look normal? Or are there any investigation-worthy nuggets? Regards. ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 11:08 ` Mason @ 2016-12-02 11:16 ` Greg KH 0 siblings, 0 replies; 11+ messages in thread From: Greg KH @ 2016-12-02 11:16 UTC (permalink / raw) To: linux-arm-kernel On Fri, Dec 02, 2016 at 12:08:21PM +0100, Mason wrote: > On 02/12/2016 11:42, Greg KH wrote: > > > On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote: > > > >> # lsusb -v > >> Bus 001 Device 001: ID 1d6b:0002 > >> Bus 002 Device 001: ID 1d6b:0003 > >> > >> Isn't lsusb verbose supposed to print much more than that? > > > > Yes, if you are using the usbutils version of 'lsusb', odds are this is > > busybox, right? > > Right. (You win a digital cookie.) Yeah! {munch munch} > cd buildroot && make menuconfig > Drop BR2_PACKAGE_USBMOUNT (maybe it causes unexpected issues) > Add BR2_PACKAGE_USBUTILS (I want the real deal) > > > And these are just the root hubs, that the USB controller driver creates > > as "virtual" USB devices, they are not "real" USB devices on your bus. > > # lsusb --version > lsusb (usbutils) 007 > I see there's a 008 version. Wow, 008 was released in 2014, what type of old repo are you using that has 007 as the "latest"? And I really should go do a new update, lots of bug fixes have happened since 2014... > Am I missing out on important diagnostics? Not really, if you are not doing a lot of USB 3-only device specific work, which is where the majority of the changes have happened in the past 2 years in the tool. > > # lsusb -v > > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub <snip> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub <snip> > Does everything look normal? Yes, two internal "virtual" hubs. > Or are there any investigation-worthy nuggets? You need to figure out why the driver isn't getting interrupts, that's the main problem for your hardware at the moment, lsusb isn't going to help you out at all with that... good luck! greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 10:24 ` Mason 2016-12-02 10:42 ` Greg KH @ 2016-12-02 13:46 ` Neil Armstrong 2016-12-02 17:55 ` Mason 2016-12-02 18:00 ` Mason 1 sibling, 2 replies; 11+ messages in thread From: Neil Armstrong @ 2016-12-02 13:46 UTC (permalink / raw) To: linux-arm-kernel On 12/02/2016 11:24 AM, Mason wrote: > On 02/12/2016 10:03, Felipe Balbi wrote: > >> Mason wrote: >> >>> I'm trying out a SoC with a brand new USB controller, which is (supposedly) >>> a standard XHCI controller. In theory, I would just need to build the right >>> driver, and everything would auto-magically work, right? >> >> perhaps, but there might be needed initialization of other resources >> like PHYs and stuff like that. > > Let me dive into additional details... > > First of all, there is a register aptly called "USB3_RESET" which > is used to release several USB3-related blocks from reset. > Of course, that's the first register I tweaked :-) > > There are *3* address ranges with USB3-related registers. > > 1) one called host_usb30_xhcl (I believe "xhcl" is a typo for "xhci") > This is the address I passed to the Linux driver. The first register > is CAPLENGTH_VERSION. I assume these are the standard XHCI registers. > (Last register is XHCL_EXTENDED_CAP3_USB3 at offset 0xc008) > > 2) one called host_usb30_port > This contains "Device and Port Specific Registers". > Is it standard? > How is Linux supposed to know where to find it? > Contains registers such as > Device Transaction Status > Device UTMI command and status for USB2 > Set ISOC Delay > USB3 Function Notification > Rx DMA BD Start Address for Control Endpoint > EP Burst Size > Tx DMA BD Start Address Control Endpoint > EP $N IN/OUT > Device Notification Register > EP_Isochronous Timestamp > > Are registers named LTSSM_TIMER_REGISTER{1,2,3} standard? > they have fields such as reg_12_ms_timeout (and other numbers like 2, 6, 100, 300) > > 3) one called host_usb30 > This contains lower-level stuff > 0x2e800 CONFIG > 0x2e804 CONTROL > 0x2e808 TEST > 0x2e80c STATUS > 0x2e810 CLK_RST_0 > 0x2e814 CLK_RST_1 > 0x2e818 PARAM_0 > 0x2e81c PARAM_1 > 0x2e820 PARAM_2 > 0x2e880 SNPS_CR_ADD > 0x2e884 SNPS_CR_DATA > 0x2e8c0 RESET_CTRL > > I haven't touched any of these so far. > > >>> # lsusb -v >>> Bus 001 Device 001: ID 1d6b:0002 >>> Bus 002 Device 001: ID 1d6b:0003 > > Isn't lsusb verbose supposed to print much more than that? > > >>> I'd like to hear suggestions about what I can tweak to fix the problem. >> >> go to your documentation and see if you have initialized >> everything. Which SoC is this? > > (Sad face) All the documentation I have is in front of me, and nothing > is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI > controller + Synopsys PHY. > > The documentation I have: > > Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals) > Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers) > PHY databook (very low-level stuff) > SoC register mapping (for how the SoC maps the IP signals to registers) You should have all the necessary bits to enable and configure the Embedded Synopsys PHY ! You should have some register mapping of the PHY signals, or at least a way to write those registers. You should have a reset, clock gate and eventually a power regulator to enable in order to have the PHY running. > > So far, I'm stumped :-( > > Regards. > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 13:46 ` Neil Armstrong @ 2016-12-02 17:55 ` Mason 2016-12-02 18:00 ` Mason 1 sibling, 0 replies; 11+ messages in thread From: Mason @ 2016-12-02 17:55 UTC (permalink / raw) To: linux-arm-kernel On 02/12/2016 14:46, Neil Armstrong wrote: > On 12/02/2016 11:24 AM, Mason wrote: > >> (Sad face) All the documentation I have is in front of me, and nothing >> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI >> controller + Synopsys PHY. >> >> The documentation I have: >> >> Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals) >> Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers) >> PHY databook (very low-level stuff) >> SoC register mapping (for how the SoC maps the IP signals to registers) > > You should have all the necessary bits to enable and configure the Embedded Synopsys PHY ! > > You should have some register mapping of the PHY signals, or at least a way to write those registers. > > You should have a reset, clock gate and eventually a power regulator to enable in order to have the PHY running. I'll dump all the non-0 non-standard registers. Maybe someone more experienced than me will spot an obvious mistake. host_usb30_0_config: 0x2e800 - host_usb30_0_fladj 0x20 - host_usb30_0_usb30_controller_cg_disable 0x0 - host_usb30_0_mode_select 0x1 - host_usb30_0_device_reset_mode 0x0 host_usb30_0_control: 0x2e804 - host_usb30_0_app_lfps_u3_wp 0x0 - host_usb30_0_link_up 0x1 - host_usb30_0_msi_msg_sent 0x0 - host_usb30_0_usb3_p0_over_current 0x0 - host_usb30_0_usb2_p0_over_current 0x0 host_usb30_0_test: 0x2e808 - host_usb30_0_test_powerdown_hsp 0x0 - host_usb30_0_test_powerdown_ssp 0x0 - host_usb30_0_test_burnin 0x0 - host_usb30_0_acjt_level 0x14 - host_usb30_0_lane0_tx2rx_loopbk 0x0 - host_usb30_0_rtune_req 0x0 host_usb30_0_status: 0x2e80c - host_usb30_0_phystatus 0x0 - host_usb30_0_usb2_p0_pp 0x1 - host_usb30_0_usb3_p0_pp 0x1 - host_usb30_0_usb3_sleep 0x0 - host_usb30_0_rtune_ack 0x0 host_usb30_0_clk_rst_0: 0x2e810 - host_usb30_0_commononn 0x1 - host_usb30_0_portreset 0x0 - host_usb30_0_refclksel 0x2 - host_usb30_0_teneable 0x1 - host_usb30_0_fsel 0x27 - host_usb30_0_mpll_multiplier 0x19 - host_usb30_0_ref_clkdiv2 0x0 - host_usb30_0_ref_ssp_en 0x1 - host_usb30_0_ref_use_pad 0x0 - host_usb30_0_ssc_en 0x1 - host_usb30_0_ssc_range 0x0 host_usb30_0_clk_rst_1: 0x2e814 - host_usb30_0_ssc_ref_clk_sel 0x88 - host_usb30_0_sleepm 0x1 - host_usb30_0_vbusvldext 0x1 host_usb30_0_param_0: 0x2e818 - host_usb30_0_compdistune 0x4 - host_usb30_0_otgtune 0x4 - host_usb30_0_sqrxtune 0x3 - host_usb30_0_txfsltune 0x3 - host_usb30_0_txhsxvtune 0x3 - host_usb30_0_txpreempltune 0x0 - host_usb30_0_txpreemppulsetune 0x0 - host_usb30_0_txrestune 0x1 - host_usb30_0_txrisetune 0x2 - host_usb30_0_txvreftune 0x4 host_usb30_0_param_1: 0x2e81c - host_usb30_0_los_bias 0x5 - host_usb30_0_los_level 0xc - host_usb30_0_pcs_rx_los_mask_val 0xf0 - host_usb30_0_pcs_tx_deemph_3p5db 0x18 - host_usb30_0_pcs_tx_deemph_6db 0x21 host_usb30_0_param_2: 0x2e820 - host_usb30_0_pcs_tx_swing_full 0x73 - host_usb30_0_lane0_tx_term_offset 0x0 - host_usb30_0_tx_vboost_lvl 0x4 host_usb30_0_SNPS_CR_ADD: 0x2e880 - host_usb30_0_snps_cr_add 0xe03c DEVICE_AND_PORT_000: 0x70050000 - sw_reset 0x0 - gen_resume 0x0 - ss_support 0x0 - revision_id 0x0 - vendor_id 0x3 DEVICE_AND_PORT_00C: 0x7005000c - set_isoc_delay 0x0 - utmi_vstatus 0x0 - utmi_vcontrolloadm 0x1 - utmi_vcontrol 0x0 - config_dev_speed 0x1 ENDP_CONFIG_020: 0x70050020 - burst_size 0x1 - max_packet_size_7_0 0x0 - rst_seq_num 0x0 - iso_xact_type 0x0 - stall 0x0 - max_pkt_size_10_8 0x2 - setup_reenable 0x0 - endp_enable 0x1 - endp_type 0x0 - endp_no 0x0 LTSSM_STATE_REGISTER: 0x70050220 - ltssm_state_status 0x4 - u1_enable 0x0 - u2_enable 0x0 - disable_scramble_lb 0x1 - lfps_ux_exit 0x0 - disable_scramble_request 0x0 - self_powered_device 0x0 - host_device 0x1 - send_warm_reseti 0x0 - send_hot_reset 0x0 - reg_lgo_u3 0x0 PHY_TIMER_REGISTER: 0x70050410 - u2_inactivity_timeout 0x0 - pending_hp_time_out 0x2a - recv_resume 0x0 - auto_resume 0x0 - credit_hp_timer 0x46 - usb3_clk_pulse_256us 0x100 PM_LC_TIMER_REGISTER: 0x70050418 - cntr_pulse_pm_lc_timer 0x2a - cntr_pulse_pm_entry_timer 0x54 - lup_timeout_value 0xa - no_link_commands_timeout_value 0xe - pm_lc_timer_register_reserved 0x6e LTSSM_TIMER_REGISTER1: 0x7005041c - u1_exit_timeout 0x54 - u2_exit_timeout 0x54 - reg_12_ms_timeout 0xa8 LTSSM_TIMER_REGISTER2: 0x70050420 - reg_360_ms_timeout 0x34 - pipe_width 0x3 - reg_2_ms_timeout 0x3c - rxeq_timeout 0xffff LTSSM_TIMER_REGISTER3: 0x70050424 - reg_6_ms_timeout 0x54 - reg_300_ms_timeout 0x149 - reg_100_ms_timeout 0x8c - ltssm_timer_reg3_undef 0x0 LOW_POWER_LFPS_SIGNALING_REGISTER: 0x70050434 - low_power_lfps_signaling_register_value 0x4e030303 - low_power_lfps_undef 0x0 PING_POLLING_LFPS_SIGNALING_REGISTER: 0x70050440 - ping_polling_lfps_signaling_register 0x9f5beebc WARM_RESET_LFPS_SIGNALING_REGISTER: 0x70050444 - lfps_rx_trepeat_polling 0x5 - lfps_wr_undef 0x0 - lfps_wr_tresetdelay_min 0x12 - lfps_wr_tresetdelay_max 0x0 - lfps_wr_treset_total 0x76 LOW_POWER_LFPS_SIGNALING_REGISTER1: 0x70050448 - lfp_rx_undef 0x0 - lfps_rx_u2_t13_t11 0x12 - lfps_rx_u3_t13_t11 0x62 - lfps_rx_u1_t13_t11 0x7 - lfps_tx_u1_t11_t10 0xe - lfps_tx_u1_t12_t11 0x8 - lfps_tx_u1_t11_t10_7_4 0x1 LOW_POWER_LFPS_SIGNALING_REGISTER2: 0x7005044c - low_power_lfps_signaling_register2 0xc34f07d0 LOW_POWER_LFPS_SIGNALING_REGISTER3: 0x70050450 - low_power_lfps_signaling_register3 0xc34f07d0 TIMER_ENABLE_REGISTERS: 0x70050454 - pravega_counter_pulse_1us 0x9 - pravega_counter_pulse_10us 0x9 - pravega_counter_pulse_1ms 0x9 - pravega_counter_pulse_100us 0x9 - pravega_counter_pulse_10ms 0x9 - counter_pulse_100ns 0x14 I'll take a closer look on Monday. Regards. ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 13:46 ` Neil Armstrong 2016-12-02 17:55 ` Mason @ 2016-12-02 18:00 ` Mason 2016-12-05 8:26 ` Neil Armstrong 1 sibling, 1 reply; 11+ messages in thread From: Mason @ 2016-12-02 18:00 UTC (permalink / raw) To: linux-arm-kernel [ Fix incorrect address for Felipe ] On 02/12/2016 14:46, Neil Armstrong wrote: > On 12/02/2016 11:24 AM, Mason wrote: > >> (Sad face) All the documentation I have is in front of me, and nothing >> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI >> controller + Synopsys PHY. >> >> The documentation I have: >> >> Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals) >> Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers) >> PHY databook (very low-level stuff) >> SoC register mapping (for how the SoC maps the IP signals to registers) > > You should have all the necessary bits to enable and configure the Embedded Synopsys PHY ! > > You should have some register mapping of the PHY signals, or at least a way to write those registers. > > You should have a reset, clock gate and eventually a power regulator to enable in order to have the PHY running. I'll dump all the non-0 non-standard registers. Maybe someone more experienced than me will spot an obvious mistake. host_usb30_0_config: 0x2e800 - host_usb30_0_fladj 0x20 - host_usb30_0_usb30_controller_cg_disable 0x0 - host_usb30_0_mode_select 0x1 - host_usb30_0_device_reset_mode 0x0 host_usb30_0_control: 0x2e804 - host_usb30_0_app_lfps_u3_wp 0x0 - host_usb30_0_link_up 0x1 - host_usb30_0_msi_msg_sent 0x0 - host_usb30_0_usb3_p0_over_current 0x0 - host_usb30_0_usb2_p0_over_current 0x0 host_usb30_0_test: 0x2e808 - host_usb30_0_test_powerdown_hsp 0x0 - host_usb30_0_test_powerdown_ssp 0x0 - host_usb30_0_test_burnin 0x0 - host_usb30_0_acjt_level 0x14 - host_usb30_0_lane0_tx2rx_loopbk 0x0 - host_usb30_0_rtune_req 0x0 host_usb30_0_status: 0x2e80c - host_usb30_0_phystatus 0x0 - host_usb30_0_usb2_p0_pp 0x1 - host_usb30_0_usb3_p0_pp 0x1 - host_usb30_0_usb3_sleep 0x0 - host_usb30_0_rtune_ack 0x0 host_usb30_0_clk_rst_0: 0x2e810 - host_usb30_0_commononn 0x1 - host_usb30_0_portreset 0x0 - host_usb30_0_refclksel 0x2 - host_usb30_0_teneable 0x1 - host_usb30_0_fsel 0x27 - host_usb30_0_mpll_multiplier 0x19 - host_usb30_0_ref_clkdiv2 0x0 - host_usb30_0_ref_ssp_en 0x1 - host_usb30_0_ref_use_pad 0x0 - host_usb30_0_ssc_en 0x1 - host_usb30_0_ssc_range 0x0 host_usb30_0_clk_rst_1: 0x2e814 - host_usb30_0_ssc_ref_clk_sel 0x88 - host_usb30_0_sleepm 0x1 - host_usb30_0_vbusvldext 0x1 host_usb30_0_param_0: 0x2e818 - host_usb30_0_compdistune 0x4 - host_usb30_0_otgtune 0x4 - host_usb30_0_sqrxtune 0x3 - host_usb30_0_txfsltune 0x3 - host_usb30_0_txhsxvtune 0x3 - host_usb30_0_txpreempltune 0x0 - host_usb30_0_txpreemppulsetune 0x0 - host_usb30_0_txrestune 0x1 - host_usb30_0_txrisetune 0x2 - host_usb30_0_txvreftune 0x4 host_usb30_0_param_1: 0x2e81c - host_usb30_0_los_bias 0x5 - host_usb30_0_los_level 0xc - host_usb30_0_pcs_rx_los_mask_val 0xf0 - host_usb30_0_pcs_tx_deemph_3p5db 0x18 - host_usb30_0_pcs_tx_deemph_6db 0x21 host_usb30_0_param_2: 0x2e820 - host_usb30_0_pcs_tx_swing_full 0x73 - host_usb30_0_lane0_tx_term_offset 0x0 - host_usb30_0_tx_vboost_lvl 0x4 host_usb30_0_SNPS_CR_ADD: 0x2e880 - host_usb30_0_snps_cr_add 0xe03c DEVICE_AND_PORT_000: 0x70050000 - sw_reset 0x0 - gen_resume 0x0 - ss_support 0x0 - revision_id 0x0 - vendor_id 0x3 DEVICE_AND_PORT_00C: 0x7005000c - set_isoc_delay 0x0 - utmi_vstatus 0x0 - utmi_vcontrolloadm 0x1 - utmi_vcontrol 0x0 - config_dev_speed 0x1 ENDP_CONFIG_020: 0x70050020 - burst_size 0x1 - max_packet_size_7_0 0x0 - rst_seq_num 0x0 - iso_xact_type 0x0 - stall 0x0 - max_pkt_size_10_8 0x2 - setup_reenable 0x0 - endp_enable 0x1 - endp_type 0x0 - endp_no 0x0 LTSSM_STATE_REGISTER: 0x70050220 - ltssm_state_status 0x4 - u1_enable 0x0 - u2_enable 0x0 - disable_scramble_lb 0x1 - lfps_ux_exit 0x0 - disable_scramble_request 0x0 - self_powered_device 0x0 - host_device 0x1 - send_warm_reseti 0x0 - send_hot_reset 0x0 - reg_lgo_u3 0x0 PHY_TIMER_REGISTER: 0x70050410 - u2_inactivity_timeout 0x0 - pending_hp_time_out 0x2a - recv_resume 0x0 - auto_resume 0x0 - credit_hp_timer 0x46 - usb3_clk_pulse_256us 0x100 PM_LC_TIMER_REGISTER: 0x70050418 - cntr_pulse_pm_lc_timer 0x2a - cntr_pulse_pm_entry_timer 0x54 - lup_timeout_value 0xa - no_link_commands_timeout_value 0xe - pm_lc_timer_register_reserved 0x6e LTSSM_TIMER_REGISTER1: 0x7005041c - u1_exit_timeout 0x54 - u2_exit_timeout 0x54 - reg_12_ms_timeout 0xa8 LTSSM_TIMER_REGISTER2: 0x70050420 - reg_360_ms_timeout 0x34 - pipe_width 0x3 - reg_2_ms_timeout 0x3c - rxeq_timeout 0xffff LTSSM_TIMER_REGISTER3: 0x70050424 - reg_6_ms_timeout 0x54 - reg_300_ms_timeout 0x149 - reg_100_ms_timeout 0x8c - ltssm_timer_reg3_undef 0x0 LOW_POWER_LFPS_SIGNALING_REGISTER: 0x70050434 - low_power_lfps_signaling_register_value 0x4e030303 - low_power_lfps_undef 0x0 PING_POLLING_LFPS_SIGNALING_REGISTER: 0x70050440 - ping_polling_lfps_signaling_register 0x9f5beebc WARM_RESET_LFPS_SIGNALING_REGISTER: 0x70050444 - lfps_rx_trepeat_polling 0x5 - lfps_wr_undef 0x0 - lfps_wr_tresetdelay_min 0x12 - lfps_wr_tresetdelay_max 0x0 - lfps_wr_treset_total 0x76 LOW_POWER_LFPS_SIGNALING_REGISTER1: 0x70050448 - lfp_rx_undef 0x0 - lfps_rx_u2_t13_t11 0x12 - lfps_rx_u3_t13_t11 0x62 - lfps_rx_u1_t13_t11 0x7 - lfps_tx_u1_t11_t10 0xe - lfps_tx_u1_t12_t11 0x8 - lfps_tx_u1_t11_t10_7_4 0x1 LOW_POWER_LFPS_SIGNALING_REGISTER2: 0x7005044c - low_power_lfps_signaling_register2 0xc34f07d0 LOW_POWER_LFPS_SIGNALING_REGISTER3: 0x70050450 - low_power_lfps_signaling_register3 0xc34f07d0 TIMER_ENABLE_REGISTERS: 0x70050454 - pravega_counter_pulse_1us 0x9 - pravega_counter_pulse_10us 0x9 - pravega_counter_pulse_1ms 0x9 - pravega_counter_pulse_100us 0x9 - pravega_counter_pulse_10ms 0x9 - counter_pulse_100ns 0x14 I'll take a closer look on Monday. Regards. ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-02 18:00 ` Mason @ 2016-12-05 8:26 ` Neil Armstrong 2016-12-05 15:39 ` Mason 0 siblings, 1 reply; 11+ messages in thread From: Neil Armstrong @ 2016-12-05 8:26 UTC (permalink / raw) To: linux-arm-kernel Hi Mason, On 12/02/2016 07:00 PM, Mason wrote: > [ Fix incorrect address for Felipe ] > > On 02/12/2016 14:46, Neil Armstrong wrote: > >> On 12/02/2016 11:24 AM, Mason wrote: >> >>> (Sad face) All the documentation I have is in front of me, and nothing >>> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI >>> controller + Synopsys PHY. >>> >>> The documentation I have: >>> >>> Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals) >>> Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers) >>> PHY databook (very low-level stuff) >>> SoC register mapping (for how the SoC maps the IP signals to registers) >> >> You should have all the necessary bits to enable and configure the Embedded Synopsys PHY ! >> >> You should have some register mapping of the PHY signals, or at least a way to write those registers. >> >> You should have a reset, clock gate and eventually a power regulator to enable in order to have the PHY running. > > I'll dump all the non-0 non-standard registers. Maybe someone > more experienced than me will spot an obvious mistake. > > host_usb30_0_config: 0x2e800 > - host_usb30_0_fladj 0x20 > - host_usb30_0_usb30_controller_cg_disable 0x0 > - host_usb30_0_mode_select 0x1 > - host_usb30_0_device_reset_mode 0x0 > > host_usb30_0_control: 0x2e804 > - host_usb30_0_app_lfps_u3_wp 0x0 > - host_usb30_0_link_up 0x1 > - host_usb30_0_msi_msg_sent 0x0 > - host_usb30_0_usb3_p0_over_current 0x0 > - host_usb30_0_usb2_p0_over_current 0x0 > > host_usb30_0_test: 0x2e808 > - host_usb30_0_test_powerdown_hsp 0x0 > - host_usb30_0_test_powerdown_ssp 0x0 > - host_usb30_0_test_burnin 0x0 > - host_usb30_0_acjt_level 0x14 > - host_usb30_0_lane0_tx2rx_loopbk 0x0 > - host_usb30_0_rtune_req 0x0 > > host_usb30_0_status: 0x2e80c > - host_usb30_0_phystatus 0x0 > - host_usb30_0_usb2_p0_pp 0x1 > - host_usb30_0_usb3_p0_pp 0x1 > - host_usb30_0_usb3_sleep 0x0 > - host_usb30_0_rtune_ack 0x0 > > host_usb30_0_clk_rst_0: 0x2e810 > - host_usb30_0_commononn 0x1 > - host_usb30_0_portreset 0x0 > - host_usb30_0_refclksel 0x2 > - host_usb30_0_teneable 0x1 > - host_usb30_0_fsel 0x27 > - host_usb30_0_mpll_multiplier 0x19 > - host_usb30_0_ref_clkdiv2 0x0 > - host_usb30_0_ref_ssp_en 0x1 > - host_usb30_0_ref_use_pad 0x0 > - host_usb30_0_ssc_en 0x1 > - host_usb30_0_ssc_range 0x0 > > host_usb30_0_clk_rst_1: 0x2e814 > - host_usb30_0_ssc_ref_clk_sel 0x88 > - host_usb30_0_sleepm 0x1 > - host_usb30_0_vbusvldext 0x1 > > host_usb30_0_param_0: 0x2e818 > - host_usb30_0_compdistune 0x4 > - host_usb30_0_otgtune 0x4 > - host_usb30_0_sqrxtune 0x3 > - host_usb30_0_txfsltune 0x3 > - host_usb30_0_txhsxvtune 0x3 > - host_usb30_0_txpreempltune 0x0 > - host_usb30_0_txpreemppulsetune 0x0 > - host_usb30_0_txrestune 0x1 > - host_usb30_0_txrisetune 0x2 > - host_usb30_0_txvreftune 0x4 > > host_usb30_0_param_1: 0x2e81c > - host_usb30_0_los_bias 0x5 > - host_usb30_0_los_level 0xc > - host_usb30_0_pcs_rx_los_mask_val 0xf0 > - host_usb30_0_pcs_tx_deemph_3p5db 0x18 > - host_usb30_0_pcs_tx_deemph_6db 0x21 > > host_usb30_0_param_2: 0x2e820 > - host_usb30_0_pcs_tx_swing_full 0x73 > - host_usb30_0_lane0_tx_term_offset 0x0 > - host_usb30_0_tx_vboost_lvl 0x4 > > host_usb30_0_SNPS_CR_ADD: 0x2e880 > - host_usb30_0_snps_cr_add 0xe03c This is obviously the PHY registers. Commonly, the PHY from Synopsys does not have a register interface given by Synopsys, but it's in charge of the SoC integrator to add a register set to program all the PHY signals. Typically, those signal will contain some Clock selection, Enable Reset, Tunings and VBUS mode selection. commononn seems top be an enable, but active low portreset seems to be used to reset the port refclksel seem to select the clock source (you should have either an external Xtal, SoX Xtal or a PLL output) And so on. Please look at your "PHY databook" how these signals should be configured. Be aware that some "tune" register should have been calibrated in fab somehow, so you should make sure the reset values are correct. Neil > > DEVICE_AND_PORT_000: 0x70050000 > - sw_reset 0x0 > - gen_resume 0x0 > - ss_support 0x0 > - revision_id 0x0 > - vendor_id 0x3 > > DEVICE_AND_PORT_00C: 0x7005000c > - set_isoc_delay 0x0 > - utmi_vstatus 0x0 > - utmi_vcontrolloadm 0x1 > - utmi_vcontrol 0x0 > - config_dev_speed 0x1 > > ENDP_CONFIG_020: 0x70050020 > - burst_size 0x1 > - max_packet_size_7_0 0x0 > - rst_seq_num 0x0 > - iso_xact_type 0x0 > - stall 0x0 > - max_pkt_size_10_8 0x2 > - setup_reenable 0x0 > - endp_enable 0x1 > - endp_type 0x0 > - endp_no 0x0 > > LTSSM_STATE_REGISTER: 0x70050220 > - ltssm_state_status 0x4 > - u1_enable 0x0 > - u2_enable 0x0 > - disable_scramble_lb 0x1 > - lfps_ux_exit 0x0 > - disable_scramble_request 0x0 > - self_powered_device 0x0 > - host_device 0x1 > - send_warm_reseti 0x0 > - send_hot_reset 0x0 > - reg_lgo_u3 0x0 > > PHY_TIMER_REGISTER: 0x70050410 > - u2_inactivity_timeout 0x0 > - pending_hp_time_out 0x2a > - recv_resume 0x0 > - auto_resume 0x0 > - credit_hp_timer 0x46 > - usb3_clk_pulse_256us 0x100 > > PM_LC_TIMER_REGISTER: 0x70050418 > - cntr_pulse_pm_lc_timer 0x2a > - cntr_pulse_pm_entry_timer 0x54 > - lup_timeout_value 0xa > - no_link_commands_timeout_value 0xe > - pm_lc_timer_register_reserved 0x6e > > LTSSM_TIMER_REGISTER1: 0x7005041c > - u1_exit_timeout 0x54 > - u2_exit_timeout 0x54 > - reg_12_ms_timeout 0xa8 > > LTSSM_TIMER_REGISTER2: 0x70050420 > - reg_360_ms_timeout 0x34 > - pipe_width 0x3 > - reg_2_ms_timeout 0x3c > - rxeq_timeout 0xffff > > LTSSM_TIMER_REGISTER3: 0x70050424 > - reg_6_ms_timeout 0x54 > - reg_300_ms_timeout 0x149 > - reg_100_ms_timeout 0x8c > - ltssm_timer_reg3_undef 0x0 > > LOW_POWER_LFPS_SIGNALING_REGISTER: 0x70050434 > - low_power_lfps_signaling_register_value 0x4e030303 > - low_power_lfps_undef 0x0 > > PING_POLLING_LFPS_SIGNALING_REGISTER: 0x70050440 > - ping_polling_lfps_signaling_register 0x9f5beebc > > WARM_RESET_LFPS_SIGNALING_REGISTER: 0x70050444 > - lfps_rx_trepeat_polling 0x5 > - lfps_wr_undef 0x0 > - lfps_wr_tresetdelay_min 0x12 > - lfps_wr_tresetdelay_max 0x0 > - lfps_wr_treset_total 0x76 > > LOW_POWER_LFPS_SIGNALING_REGISTER1: 0x70050448 > - lfp_rx_undef 0x0 > - lfps_rx_u2_t13_t11 0x12 > - lfps_rx_u3_t13_t11 0x62 > - lfps_rx_u1_t13_t11 0x7 > - lfps_tx_u1_t11_t10 0xe > - lfps_tx_u1_t12_t11 0x8 > - lfps_tx_u1_t11_t10_7_4 0x1 > > LOW_POWER_LFPS_SIGNALING_REGISTER2: 0x7005044c > - low_power_lfps_signaling_register2 0xc34f07d0 > > LOW_POWER_LFPS_SIGNALING_REGISTER3: 0x70050450 > - low_power_lfps_signaling_register3 0xc34f07d0 > > TIMER_ENABLE_REGISTERS: 0x70050454 > - pravega_counter_pulse_1us 0x9 > - pravega_counter_pulse_10us 0x9 > - pravega_counter_pulse_1ms 0x9 > - pravega_counter_pulse_100us 0x9 > - pravega_counter_pulse_10ms 0x9 > - counter_pulse_100ns 0x14 > These seems to be non-standard Prevaga XHCI registers. > > I'll take a closer look on Monday. > > Regards. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* XHCI controller does not detect USB key insertion 2016-12-05 8:26 ` Neil Armstrong @ 2016-12-05 15:39 ` Mason 0 siblings, 0 replies; 11+ messages in thread From: Mason @ 2016-12-05 15:39 UTC (permalink / raw) To: linux-arm-kernel On 05/12/2016 09:26, Neil Armstrong wrote: > On 12/02/2016 07:00 PM, Mason wrote: > >> On 02/12/2016 14:46, Neil Armstrong wrote: >> >>> On 12/02/2016 11:24 AM, Mason wrote: >>> >>>> (Sad face) All the documentation I have is in front of me, and nothing >>>> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI >>>> controller + Synopsys PHY. >>>> >>>> The documentation I have: >>>> >>>> Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals) >>>> Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers) >>>> PHY databook (very low-level stuff) >>>> SoC register mapping (for how the SoC maps the IP signals to registers) >>> >>> You should have all the necessary bits to enable and configure the Embedded Synopsys PHY ! >>> >>> You should have some register mapping of the PHY signals, or at least a way to write those registers. >>> >>> You should have a reset, clock gate and eventually a power regulator to enable in order to have the PHY running. >> >> I'll dump all the non-0 non-standard registers. Maybe someone >> more experienced than me will spot an obvious mistake. >> >> host_usb30_0_config: 0x2e800 >> - host_usb30_0_fladj 0x20 >> - host_usb30_0_usb30_controller_cg_disable 0x0 >> - host_usb30_0_mode_select 0x1 >> - host_usb30_0_device_reset_mode 0x0 >> >> host_usb30_0_control: 0x2e804 >> - host_usb30_0_app_lfps_u3_wp 0x0 >> - host_usb30_0_link_up 0x1 >> - host_usb30_0_msi_msg_sent 0x0 >> - host_usb30_0_usb3_p0_over_current 0x0 >> - host_usb30_0_usb2_p0_over_current 0x0 >> >> host_usb30_0_test: 0x2e808 >> - host_usb30_0_test_powerdown_hsp 0x0 >> - host_usb30_0_test_powerdown_ssp 0x0 >> - host_usb30_0_test_burnin 0x0 >> - host_usb30_0_acjt_level 0x14 >> - host_usb30_0_lane0_tx2rx_loopbk 0x0 >> - host_usb30_0_rtune_req 0x0 >> >> host_usb30_0_status: 0x2e80c >> - host_usb30_0_phystatus 0x0 >> - host_usb30_0_usb2_p0_pp 0x1 >> - host_usb30_0_usb3_p0_pp 0x1 >> - host_usb30_0_usb3_sleep 0x0 >> - host_usb30_0_rtune_ack 0x0 >> >> host_usb30_0_clk_rst_0: 0x2e810 >> - host_usb30_0_commononn 0x1 >> - host_usb30_0_portreset 0x0 >> - host_usb30_0_refclksel 0x2 >> - host_usb30_0_teneable 0x1 >> - host_usb30_0_fsel 0x27 >> - host_usb30_0_mpll_multiplier 0x19 >> - host_usb30_0_ref_clkdiv2 0x0 >> - host_usb30_0_ref_ssp_en 0x1 >> - host_usb30_0_ref_use_pad 0x0 >> - host_usb30_0_ssc_en 0x1 >> - host_usb30_0_ssc_range 0x0 >> >> host_usb30_0_clk_rst_1: 0x2e814 >> - host_usb30_0_ssc_ref_clk_sel 0x88 >> - host_usb30_0_sleepm 0x1 >> - host_usb30_0_vbusvldext 0x1 >> >> host_usb30_0_param_0: 0x2e818 >> - host_usb30_0_compdistune 0x4 >> - host_usb30_0_otgtune 0x4 >> - host_usb30_0_sqrxtune 0x3 >> - host_usb30_0_txfsltune 0x3 >> - host_usb30_0_txhsxvtune 0x3 >> - host_usb30_0_txpreempltune 0x0 >> - host_usb30_0_txpreemppulsetune 0x0 >> - host_usb30_0_txrestune 0x1 >> - host_usb30_0_txrisetune 0x2 >> - host_usb30_0_txvreftune 0x4 >> >> host_usb30_0_param_1: 0x2e81c >> - host_usb30_0_los_bias 0x5 >> - host_usb30_0_los_level 0xc >> - host_usb30_0_pcs_rx_los_mask_val 0xf0 >> - host_usb30_0_pcs_tx_deemph_3p5db 0x18 >> - host_usb30_0_pcs_tx_deemph_6db 0x21 >> >> host_usb30_0_param_2: 0x2e820 >> - host_usb30_0_pcs_tx_swing_full 0x73 >> - host_usb30_0_lane0_tx_term_offset 0x0 >> - host_usb30_0_tx_vboost_lvl 0x4 >> >> host_usb30_0_SNPS_CR_ADD: 0x2e880 >> - host_usb30_0_snps_cr_add 0xe03c > > This is obviously the PHY registers. > > Commonly, the PHY from Synopsys does not have a register interface given by Synopsys, but it's in charge > of the SoC integrator to add a register set to program all the PHY signals. Apparently, it was decided to map all Synopsys registers through a single address/data register pair. > Typically, those signal will contain some Clock selection, Enable Reset, Tunings and VBUS mode selection. The Synopsys datasheet mentions two register blocks: SS Function Control Registers (SS for SuperSpeed i.e. USB3, I guess) HS Function Control Registers (HS for HighSpeed i.e. USB2, I guess) The registers in the first block are: SUP.IDCODE_LO SUP.IDCODE_HI SUP.DEBUG RTUNE_DEBUG RTUNE_STAT SS_PHASE SS_FREQ ATEOVRD MPLL_OVRD_IN_LO MPLL_OVRD_IN_HI SSC_OVRD_IN BS_OVRD_IN LEVEL_OVRD_IN SUP_OVRD_OUT MPLL_ASIC_IN BS_ASIC_IN LEVEL_ASIC_IN SSC_ASIC_IN SUP_ASIC_OUT ATEOVRD_STATUS SCOPE_ENABLES SCOPE_SAMPLES SCOPE_COUNT SCOPE_CTL SCOPE_MASK_000 SCOPE_MASK_001 SCOPE_MASK_010 SCOPE_MASK_011 SCOPE_MASK_100 SCOPE_MASK_101 SCOPE_MASK_110 SCOPE_MASK_111 MPLL_LOOP_CTL MPLL_ATB_MEAS1 MPLL_ATB_MEAS2 MPLL_OVRD RTUNE_RTUNE_CTRL ATB_SWITCHYARD_CTRL SSC_CLK_CNTRL LANE0.TX_OVRD_IN_LO LANE0.TX_OVRD_IN_HI LANE0.TX_OVRD_DRV_LO LANE0.TX_OVRD_DRV_HI LANE0.TX_OVRD_OUT LANE0.RX_OVRD_IN_LO LANE0.RX_OVRD_IN_HI LANE0.RX_OVRD_OUT LANE0.TX_ASIC_IN LANE0.TX_ASIC_DRV_LO LANE0.TX_ASIC_DRV_HI TX_ASIC_OUT RX_ASIC_IN RX_ASIC_OUT LANE0.TX_DEBUG LANE0.TX_CM_WAIT_TIME_OVRD LANE0.TX_VMD_FSM_TX_VCM_0 LANE0.TX_VMD_FSM_TX_VCM_1 LANE0.TX_LBERT_CTL LANE0.RX_LBERT_CTL LANE0.RX_LBERT_ERR LANE0.RX_SCOPE_CTL LANE0.RX_SCOPE_PHASE LANE0.RX_DPLL_FREQ LANE0.RX_CDR_CTL LANE0.RX_CDR_CDR_FSM_DEBUG LANE0.RX_CDR_LOCK_VEC_OVRD LANE0.RX_CDR_LOCK_VEC LANE0.RX_CDR_ADAP_FSM The one register with clk in the name is SSC_CLK_CNTRL. It has a 7-bit sub-field called SSC_CLK_DIV125. "Sets SSC reference clock to 20 MHz." Default val = 7 /me blank stare ... > commononn seems top be an enable, but active low > portreset seems to be used to reset the port > refclksel seem to select the clock source (you should have either an external Xtal, SoX Xtal or a PLL output) These are PHY signals, which are mapped to registers in my SoC, AFAICT. COMMONONN Common Block Power-Down Control Function: Controls the power-down signals in the HS Bias and PLL blocks when the USB 3.0 PHY is in Suspend or Sleep mode. - 1: In Suspend or Sleep mode, the HS Bias and PLL blocks are powered down. - 0: In Suspend or Sleep mode, the HS Bias and PLL blocks remain powered and continue to draw current. PORTRESET<#> Per-Port Reset Function: When asserted, this customer-specific signal resets the corresponding port's USB2.0 transmit and receive logic without disabling the clocks within the USB 3.0 PHY. - 1: The transmit and receive finite state machines (FSMs) are reset, and the line_state logic combinatorially reflects the state of the single-ended receivers. - 0: The transmit and receive FSMs are operational, and the line_state logic becomes sequential after 11 PHYCLOCK<#> cycles. Asserting PORTRESET<#> does not override any USB 3.0 PHY inputs that normally control the USB 2.0 state, nor does it cause any transient, illegal USB states. Within 100 ns of asserting PORTRESET<#>, the controller must set the inputs that control the USB 2.0 to values that cause a safe state. A safe state for Host and Device modes is defined as follows: - Host mode: Non-driving (OPMODE<#>[1:0] = 2'b01) with the 15-k? pull- down resistors enabled (DPPULLDOWN<#> and DMPULLDOWN<#> = 1'b1) - Device mode: Non-driving (OPMODE<#>[1:0] = 2'b01) with the 1.5-k? pull- up resistor disabled REFCLKSEL[1:0] Reference Clock Select for PLL Block Function: Selects reference clock source for the HS PLL block. - 11: HS PLL uses EXTREFCLK as reference. - 10: HS PLL uses either ref_pad_clk{p,m} or ref_alt_clk_{p,m} as reference. - 0x: Reserved This bus is a strapping option that must be set prior to a power-on reset and remain static during normal operation. Strapping options are not critical for STA, and any other timings or loading limits for the pin are specified in the .lib timing model included in the product deliverables. > Please look at your "PHY databook" how these signals should be configured. > Be aware that some "tune" register should have been calibrated in fab somehow, so you should make sure the reset values are correct. Hmmm... Taking a closer look at the 280-page PHY documentation... 3.2 Clocks and Resets The USB 3.0 PHY supports a wide range of input reference clocks from both external and on-chip clock sources. To support both SuperSpeed and high-speed operations, one of the following must be provided: - A compatible, shared reference clock frequency - Separate clock sources to support SuperSpeed operation and high-speed operation I checked that specific configuration requirement. (Table 3-3 Reference Clock Frequency Selection for SuperSpeed Operation) and it does look like one of the arbitrary values was not correctly set ssc_ref_clk_sel was 0x88 instead of 0x0 (for 100 MHz input clock). But "fixing" that didn't make the controller detect my USB2 key (or a USB3 hub). pipeP_phystatus is as an output signal documented as PIPE PHY Status Function: Communicates completion of several PHY functions including power management state transitions, rate change, and receiver detection. When this signal transitions during entry and exit from P3 states and PCLK is not running, the signaling is asynchronous. In error situations (where the PHY fails to assert PhyStatus), the MAC can take MAC-specific error recovery actions. I think it's a bad sign that it remains at 0. (Assuming host_usb30_0_phystatus and pipeP_phystatus are the same) Hmmm, I think it's time to punt this task to a HW engineer, and let them figure out what is required for basic functionality. Only then can I try to make the Linux driver play nice with the HW block. Regards. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-12-05 15:39 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-02 8:46 XHCI controller does not detect USB key insertion Mason 2016-12-02 9:03 ` Felipe Balbi 2016-12-02 10:24 ` Mason 2016-12-02 10:42 ` Greg KH 2016-12-02 11:08 ` Mason 2016-12-02 11:16 ` Greg KH 2016-12-02 13:46 ` Neil Armstrong 2016-12-02 17:55 ` Mason 2016-12-02 18:00 ` Mason 2016-12-05 8:26 ` Neil Armstrong 2016-12-05 15:39 ` Mason
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).