* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.