Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Felipe Balbi]

Hi,

Joseph Kogut  writes:
>>> Here's the relevant section from the Android kernel:
>>>
>>> <6>[0.612857] PCI host bridge to bus :00
>>> <6>[0.612869] pci_bus :00: root bus resource [bus 00-ff]
>>> <6>[0.612877] pci_bus :00: root bus resource [io  0x-0x006f]
>>> <6>[0.612885] pci_bus :00: root bus resource [io  0x0078-0x0cf7]
>>> <6>[0.612893] pci_bus :00: root bus resource [io  0x0d00-0x]
>>> <6>[0.612900] pci_bus :00: root bus resource [mem 
>>> 0x000a-0x000b]
>>> <6>[0.612908] pci_bus :00: root bus resource [mem 
>>> 0x000c-0x000d]
>>> <6>[0.612915] pci_bus :00: root bus resource [mem 
>>> 0x000e-0x000f]
>>> <6>[0.612923] pci_bus :00: root bus resource [mem 
>>> 0x7d01-0x7f00]
>>> <6>[0.612931] pci_bus :00: root bus resource [mem 
>>> 0x8000-0x90ee]
>>> <6>[0.612938] pci_bus :00: root bus resource [mem 
>>> 0xfed4-0xfed40fff]
>>> <7>[0.612960] pci :00:00.0: [8086:0f00] type 00 class 0x06
>>> <7>[0.613276] pci :00:02.0: [8086:0f31] type 00 class 0x03
>>> <7>[0.613304] pci :00:02.0: reg 10: [mem 0x9040-0x907f]
>>> <7>[0.613326] pci :00:02.0: reg 18: [mem 0x8000-0x8fff pref]
>>> <7>[0.613346] pci :00:02.0: reg 20: [io  0x1000-0x1007]
>>> <7>[0.613672] pci :00:03.0: [8086:0f38] type 00 class 0x048000
>>> <7>[0.613696] pci :00:03.0: reg 10: [mem 0x9000-0x903f]
>>> <7>[0.614052] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
>>> <7>[0.614087] pci :00:14.0: reg 10: [mem 0x90e0-0x90e0 
>>> 64bit]
>>> <7>[0.614179] pci :00:14.0: PME# supported from D3hot D3cold
>>> <7>[0.614473] pci :00:16.0: [8086:0f37] type 00 class 0x0c0380
>>> <6>[0.614488] EM:OEM1  table found, size=64
>>> <6>[0.614493] OEM1 charging bit = 1
>>> <7>[0.614514] pci :00:16.0: reg 10: [mem 0x9080-0x909f]
>>> <7>[0.614530] pci :00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff]
>>> <7>[0.614611] pci :00:16.0: PME# supported from D0 D3hot
>>> <7>[0.614916] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
>>> <7>[0.614957] pci :00:1a.0: reg 10: [mem 0x90d0-0x90df]
>>> <7>[0.614979] pci :00:1a.0: reg 14: [mem 0x90c0-0x90cf]
>>> <7>[0.615118] pci :00:1a.0: PME# supported from D0 D3hot
>>> <7>[0.615416] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
>>> <7>[ 0.615775] pci_bus :00: on NUMA node 0
>>>
>>> As you can see, our device controller is recognized and enumerated in
>>> Android. I suppose this explains why it works there. :)
>>>
>>> Here's the relevant section from the mainline kernel:
>>>
>>> [0.636189] PCI host bridge to bus :00
>>> [0.636196] pci_bus :00: root bus resource [io  0x0070-0x0077]
>>> [0.636201] pci_bus :00: root bus resource [io  0x-0x006f window]
>>> [0.636205] pci_bus :00: root bus resource [io  0x0078-0x0cf7 window]
>>> [0.636209] pci_bus :00: root bus resource [io  0x0d00-0x window]
>>> [0.636213] pci_bus :00: root bus resource [mem
>>> 0x000a-0x000b window]
>>> [0.636217] pci_bus :00: root bus resource [mem
>>> 0x000c-0x000d window]
>>> [0.636221] pci_bus :00: root bus resource [mem
>>> 0x000e-0x000f window]
>>> [0.636225] pci_bus :00: root bus resource [mem
>>> 0x90c0-0x90ff window]
>>> [0.636228] pci_bus :00: root bus resource [mem
>>> 0x7cf1-0x7ef0 window]
>>> [0.636232] pci_bus :00: root bus resource [mem
>>> 0x8000-0x908e window]
>>> [0.636236] pci_bus :00: root bus resource [mem
>>> 0xfed4-0xfed40fff window]
>>> [0.636241] pci_bus :00: root bus resource [bus 00-ff]
>>> [0.636258] pci :00:00.0: [8086:0f00] type 00 class 0x06
>>> [0.636608] pci :00:02.0: [8086:0f31] type 00 class 0x03
>>> [0.636627] pci :00:02.0: reg 0x10: [mem 0x9000-0x903f]
>>> [0.636644] pci :00:02.0: reg 0x18: [mem 0x8000-0x8fff pref]
>>> [0.636659] pci :00:02.0: reg 0x20: [io  0x1000-0x1007]
>>> [0.637019] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
>>> [0.637045] pci :00:14.0: reg 0x10: [mem 0x9080-0x9080 64bit]
>>> [0.637128] pci :00:14.0: PME# supported from D3hot D3cold
>>> [0.637451] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
>>> [0.637477] pci :00:1a.0: reg 0x10: [mem 0x9070-0x907f]
>>> [0.637491] pci :00:1a.0: reg 0x14: [mem 0x9060-0x906f]
>>> [0.637596] pci :00:1a.0: PME# supported from D0 D3hot
>>> [0.637915] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
>>> [0.638290] pci_bus :00: on NUMA node 0
>>>
>>> Here are the complete logs for both systems:
>>> Mainline: 
>>> 

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Joseph Kogut]

Hi,

On Mon, Oct 31, 2016 at 12:57 AM, Felipe Balbi
 wrote:
>
> Hi,
>
> Joseph Kogut  writes:
>> Well, after comparing the kernel log from both systems, it seems that
>> the device controller simply isn't being enumerated by the kernel for
>> some reason.
>>
>> Here's the relevant section from the Android kernel:
>>
>> <6>[0.612857] PCI host bridge to bus :00
>> <6>[0.612869] pci_bus :00: root bus resource [bus 00-ff]
>> <6>[0.612877] pci_bus :00: root bus resource [io  0x-0x006f]
>> <6>[0.612885] pci_bus :00: root bus resource [io  0x0078-0x0cf7]
>> <6>[0.612893] pci_bus :00: root bus resource [io  0x0d00-0x]
>> <6>[0.612900] pci_bus :00: root bus resource [mem 
>> 0x000a-0x000b]
>> <6>[0.612908] pci_bus :00: root bus resource [mem 
>> 0x000c-0x000d]
>> <6>[0.612915] pci_bus :00: root bus resource [mem 
>> 0x000e-0x000f]
>> <6>[0.612923] pci_bus :00: root bus resource [mem 
>> 0x7d01-0x7f00]
>> <6>[0.612931] pci_bus :00: root bus resource [mem 
>> 0x8000-0x90ee]
>> <6>[0.612938] pci_bus :00: root bus resource [mem 
>> 0xfed4-0xfed40fff]
>> <7>[0.612960] pci :00:00.0: [8086:0f00] type 00 class 0x06
>> <7>[0.613276] pci :00:02.0: [8086:0f31] type 00 class 0x03
>> <7>[0.613304] pci :00:02.0: reg 10: [mem 0x9040-0x907f]
>> <7>[0.613326] pci :00:02.0: reg 18: [mem 0x8000-0x8fff pref]
>> <7>[0.613346] pci :00:02.0: reg 20: [io  0x1000-0x1007]
>> <7>[0.613672] pci :00:03.0: [8086:0f38] type 00 class 0x048000
>> <7>[0.613696] pci :00:03.0: reg 10: [mem 0x9000-0x903f]
>> <7>[0.614052] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
>> <7>[0.614087] pci :00:14.0: reg 10: [mem 0x90e0-0x90e0 64bit]
>> <7>[0.614179] pci :00:14.0: PME# supported from D3hot D3cold
>> <7>[0.614473] pci :00:16.0: [8086:0f37] type 00 class 0x0c0380
>> <6>[0.614488] EM:OEM1  table found, size=64
>> <6>[0.614493] OEM1 charging bit = 1
>> <7>[0.614514] pci :00:16.0: reg 10: [mem 0x9080-0x909f]
>> <7>[0.614530] pci :00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff]
>> <7>[0.614611] pci :00:16.0: PME# supported from D0 D3hot
>> <7>[0.614916] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
>> <7>[0.614957] pci :00:1a.0: reg 10: [mem 0x90d0-0x90df]
>> <7>[0.614979] pci :00:1a.0: reg 14: [mem 0x90c0-0x90cf]
>> <7>[0.615118] pci :00:1a.0: PME# supported from D0 D3hot
>> <7>[0.615416] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
>> <7>[ 0.615775] pci_bus :00: on NUMA node 0
>>
>> As you can see, our device controller is recognized and enumerated in
>> Android. I suppose this explains why it works there. :)
>>
>> Here's the relevant section from the mainline kernel:
>>
>> [0.636189] PCI host bridge to bus :00
>> [0.636196] pci_bus :00: root bus resource [io  0x0070-0x0077]
>> [0.636201] pci_bus :00: root bus resource [io  0x-0x006f window]
>> [0.636205] pci_bus :00: root bus resource [io  0x0078-0x0cf7 window]
>> [0.636209] pci_bus :00: root bus resource [io  0x0d00-0x window]
>> [0.636213] pci_bus :00: root bus resource [mem
>> 0x000a-0x000b window]
>> [0.636217] pci_bus :00: root bus resource [mem
>> 0x000c-0x000d window]
>> [0.636221] pci_bus :00: root bus resource [mem
>> 0x000e-0x000f window]
>> [0.636225] pci_bus :00: root bus resource [mem
>> 0x90c0-0x90ff window]
>> [0.636228] pci_bus :00: root bus resource [mem
>> 0x7cf1-0x7ef0 window]
>> [0.636232] pci_bus :00: root bus resource [mem
>> 0x8000-0x908e window]
>> [0.636236] pci_bus :00: root bus resource [mem
>> 0xfed4-0xfed40fff window]
>> [0.636241] pci_bus :00: root bus resource [bus 00-ff]
>> [0.636258] pci :00:00.0: [8086:0f00] type 00 class 0x06
>> [0.636608] pci :00:02.0: [8086:0f31] type 00 class 0x03
>> [0.636627] pci :00:02.0: reg 0x10: [mem 0x9000-0x903f]
>> [0.636644] pci :00:02.0: reg 0x18: [mem 0x8000-0x8fff pref]
>> [0.636659] pci :00:02.0: reg 0x20: [io  0x1000-0x1007]
>> [0.637019] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
>> [0.637045] pci :00:14.0: reg 0x10: [mem 0x9080-0x9080 64bit]
>> [0.637128] pci :00:14.0: PME# supported from D3hot D3cold
>> [0.637451] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
>> [0.637477] pci :00:1a.0: reg 0x10: [mem 0x9070-0x907f]
>> [0.637491] pci :00:1a.0: reg 0x14: [mem 0x9060-0x906f]
>> [0.637596] pci :00:1a.0: PME# supported from D0 D3hot
>> [0.637915] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
>> [ 

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Felipe Balbi]

Hi,

Joseph Kogut  writes:
> Well, after comparing the kernel log from both systems, it seems that
> the device controller simply isn't being enumerated by the kernel for
> some reason.
>
> Here's the relevant section from the Android kernel:
>
> <6>[0.612857] PCI host bridge to bus :00
> <6>[0.612869] pci_bus :00: root bus resource [bus 00-ff]
> <6>[0.612877] pci_bus :00: root bus resource [io  0x-0x006f]
> <6>[0.612885] pci_bus :00: root bus resource [io  0x0078-0x0cf7]
> <6>[0.612893] pci_bus :00: root bus resource [io  0x0d00-0x]
> <6>[0.612900] pci_bus :00: root bus resource [mem 
> 0x000a-0x000b]
> <6>[0.612908] pci_bus :00: root bus resource [mem 
> 0x000c-0x000d]
> <6>[0.612915] pci_bus :00: root bus resource [mem 
> 0x000e-0x000f]
> <6>[0.612923] pci_bus :00: root bus resource [mem 
> 0x7d01-0x7f00]
> <6>[0.612931] pci_bus :00: root bus resource [mem 
> 0x8000-0x90ee]
> <6>[0.612938] pci_bus :00: root bus resource [mem 
> 0xfed4-0xfed40fff]
> <7>[0.612960] pci :00:00.0: [8086:0f00] type 00 class 0x06
> <7>[0.613276] pci :00:02.0: [8086:0f31] type 00 class 0x03
> <7>[0.613304] pci :00:02.0: reg 10: [mem 0x9040-0x907f]
> <7>[0.613326] pci :00:02.0: reg 18: [mem 0x8000-0x8fff pref]
> <7>[0.613346] pci :00:02.0: reg 20: [io  0x1000-0x1007]
> <7>[0.613672] pci :00:03.0: [8086:0f38] type 00 class 0x048000
> <7>[0.613696] pci :00:03.0: reg 10: [mem 0x9000-0x903f]
> <7>[0.614052] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
> <7>[0.614087] pci :00:14.0: reg 10: [mem 0x90e0-0x90e0 64bit]
> <7>[0.614179] pci :00:14.0: PME# supported from D3hot D3cold
> <7>[0.614473] pci :00:16.0: [8086:0f37] type 00 class 0x0c0380
> <6>[0.614488] EM:OEM1  table found, size=64
> <6>[0.614493] OEM1 charging bit = 1
> <7>[0.614514] pci :00:16.0: reg 10: [mem 0x9080-0x909f]
> <7>[0.614530] pci :00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff]
> <7>[0.614611] pci :00:16.0: PME# supported from D0 D3hot
> <7>[0.614916] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
> <7>[0.614957] pci :00:1a.0: reg 10: [mem 0x90d0-0x90df]
> <7>[0.614979] pci :00:1a.0: reg 14: [mem 0x90c0-0x90cf]
> <7>[0.615118] pci :00:1a.0: PME# supported from D0 D3hot
> <7>[0.615416] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
> <7>[ 0.615775] pci_bus :00: on NUMA node 0
>
> As you can see, our device controller is recognized and enumerated in
> Android. I suppose this explains why it works there. :)
>
> Here's the relevant section from the mainline kernel:
>
> [0.636189] PCI host bridge to bus :00
> [0.636196] pci_bus :00: root bus resource [io  0x0070-0x0077]
> [0.636201] pci_bus :00: root bus resource [io  0x-0x006f window]
> [0.636205] pci_bus :00: root bus resource [io  0x0078-0x0cf7 window]
> [0.636209] pci_bus :00: root bus resource [io  0x0d00-0x window]
> [0.636213] pci_bus :00: root bus resource [mem
> 0x000a-0x000b window]
> [0.636217] pci_bus :00: root bus resource [mem
> 0x000c-0x000d window]
> [0.636221] pci_bus :00: root bus resource [mem
> 0x000e-0x000f window]
> [0.636225] pci_bus :00: root bus resource [mem
> 0x90c0-0x90ff window]
> [0.636228] pci_bus :00: root bus resource [mem
> 0x7cf1-0x7ef0 window]
> [0.636232] pci_bus :00: root bus resource [mem
> 0x8000-0x908e window]
> [0.636236] pci_bus :00: root bus resource [mem
> 0xfed4-0xfed40fff window]
> [0.636241] pci_bus :00: root bus resource [bus 00-ff]
> [0.636258] pci :00:00.0: [8086:0f00] type 00 class 0x06
> [0.636608] pci :00:02.0: [8086:0f31] type 00 class 0x03
> [0.636627] pci :00:02.0: reg 0x10: [mem 0x9000-0x903f]
> [0.636644] pci :00:02.0: reg 0x18: [mem 0x8000-0x8fff pref]
> [0.636659] pci :00:02.0: reg 0x20: [io  0x1000-0x1007]
> [0.637019] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
> [0.637045] pci :00:14.0: reg 0x10: [mem 0x9080-0x9080 64bit]
> [0.637128] pci :00:14.0: PME# supported from D3hot D3cold
> [0.637451] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
> [0.637477] pci :00:1a.0: reg 0x10: [mem 0x9070-0x907f]
> [0.637491] pci :00:1a.0: reg 0x14: [mem 0x9060-0x906f]
> [0.637596] pci :00:1a.0: PME# supported from D0 D3hot
> [0.637915] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
> [0.638290] pci_bus :00: on NUMA node 0
>
> Here are the complete logs for both systems:
> Mainline: 
> 

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Joseph Kogut]

Well, after comparing the kernel log from both systems, it seems that
the device controller simply isn't being enumerated by the kernel for
some reason.

Here's the relevant section from the Android kernel:

<6>[0.612857] PCI host bridge to bus :00
<6>[0.612869] pci_bus :00: root bus resource [bus 00-ff]
<6>[0.612877] pci_bus :00: root bus resource [io  0x-0x006f]
<6>[0.612885] pci_bus :00: root bus resource [io  0x0078-0x0cf7]
<6>[0.612893] pci_bus :00: root bus resource [io  0x0d00-0x]
<6>[0.612900] pci_bus :00: root bus resource [mem 0x000a-0x000b]
<6>[0.612908] pci_bus :00: root bus resource [mem 0x000c-0x000d]
<6>[0.612915] pci_bus :00: root bus resource [mem 0x000e-0x000f]
<6>[0.612923] pci_bus :00: root bus resource [mem 0x7d01-0x7f00]
<6>[0.612931] pci_bus :00: root bus resource [mem 0x8000-0x90ee]
<6>[0.612938] pci_bus :00: root bus resource [mem 0xfed4-0xfed40fff]
<7>[0.612960] pci :00:00.0: [8086:0f00] type 00 class 0x06
<7>[0.613276] pci :00:02.0: [8086:0f31] type 00 class 0x03
<7>[0.613304] pci :00:02.0: reg 10: [mem 0x9040-0x907f]
<7>[0.613326] pci :00:02.0: reg 18: [mem 0x8000-0x8fff pref]
<7>[0.613346] pci :00:02.0: reg 20: [io  0x1000-0x1007]
<7>[0.613672] pci :00:03.0: [8086:0f38] type 00 class 0x048000
<7>[0.613696] pci :00:03.0: reg 10: [mem 0x9000-0x903f]
<7>[0.614052] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
<7>[0.614087] pci :00:14.0: reg 10: [mem 0x90e0-0x90e0 64bit]
<7>[0.614179] pci :00:14.0: PME# supported from D3hot D3cold
<7>[0.614473] pci :00:16.0: [8086:0f37] type 00 class 0x0c0380
<6>[0.614488] EM:OEM1  table found, size=64
<6>[0.614493] OEM1 charging bit = 1
<7>[0.614514] pci :00:16.0: reg 10: [mem 0x9080-0x909f]
<7>[0.614530] pci :00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff]
<7>[0.614611] pci :00:16.0: PME# supported from D0 D3hot
<7>[0.614916] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
<7>[0.614957] pci :00:1a.0: reg 10: [mem 0x90d0-0x90df]
<7>[0.614979] pci :00:1a.0: reg 14: [mem 0x90c0-0x90cf]
<7>[0.615118] pci :00:1a.0: PME# supported from D0 D3hot
<7>[0.615416] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
<7>[ 0.615775] pci_bus :00: on NUMA node 0

As you can see, our device controller is recognized and enumerated in
Android. I suppose this explains why it works there. :)

Here's the relevant section from the mainline kernel:

[0.636189] PCI host bridge to bus :00
[0.636196] pci_bus :00: root bus resource [io  0x0070-0x0077]
[0.636201] pci_bus :00: root bus resource [io  0x-0x006f window]
[0.636205] pci_bus :00: root bus resource [io  0x0078-0x0cf7 window]
[0.636209] pci_bus :00: root bus resource [io  0x0d00-0x window]
[0.636213] pci_bus :00: root bus resource [mem
0x000a-0x000b window]
[0.636217] pci_bus :00: root bus resource [mem
0x000c-0x000d window]
[0.636221] pci_bus :00: root bus resource [mem
0x000e-0x000f window]
[0.636225] pci_bus :00: root bus resource [mem
0x90c0-0x90ff window]
[0.636228] pci_bus :00: root bus resource [mem
0x7cf1-0x7ef0 window]
[0.636232] pci_bus :00: root bus resource [mem
0x8000-0x908e window]
[0.636236] pci_bus :00: root bus resource [mem
0xfed4-0xfed40fff window]
[0.636241] pci_bus :00: root bus resource [bus 00-ff]
[0.636258] pci :00:00.0: [8086:0f00] type 00 class 0x06
[0.636608] pci :00:02.0: [8086:0f31] type 00 class 0x03
[0.636627] pci :00:02.0: reg 0x10: [mem 0x9000-0x903f]
[0.636644] pci :00:02.0: reg 0x18: [mem 0x8000-0x8fff pref]
[0.636659] pci :00:02.0: reg 0x20: [io  0x1000-0x1007]
[0.637019] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330
[0.637045] pci :00:14.0: reg 0x10: [mem 0x9080-0x9080 64bit]
[0.637128] pci :00:14.0: PME# supported from D3hot D3cold
[0.637451] pci :00:1a.0: [8086:0f18] type 00 class 0x108000
[0.637477] pci :00:1a.0: reg 0x10: [mem 0x9070-0x907f]
[0.637491] pci :00:1a.0: reg 0x14: [mem 0x9060-0x906f]
[0.637596] pci :00:1a.0: PME# supported from D0 D3hot
[0.637915] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100
[0.638290] pci_bus :00: on NUMA node 0

Here are the complete logs for both systems:
Mainline: 
https://gist.githubusercontent.com/jakogut/f726178f480b5daa1a917e3e41b46d9f/raw/80b0c273ec6a0b434c1ab0f9493283bbd0ab1635/dmesg.log
Android: 
https://gist.githubusercontent.com/jakogut/a0f77161ea3ae886bf31e2ca6c1c33a5/raw/2a2c4b6f9a5f11be15938f58161b77d730874c6d/dmesg.log

I modified the _STA method 

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Felipe Balbi]

Hi,

Joseph Kogut  writes:
> Hi Felipe,
>
> That's some great information, thanks!
>
> At first glance, the DSDT table has two interesting bits. (I would
> paste the decompiled source, but I think it may be copyrighted?
> Correct me if I'm wrong.) The first is the USB mux, an SMSC USB3750
> connected to I2C1. According to the datasheet, this IC supports
> switching the USB data lanes between functions. This looks promising.
>
> The second interesting bit is a device named "OTG1". The _STA method
> of OTG1 checks the value of OTGM--defined earlier as an 8-bit field in
> GNVS (NVRAM?)--and returns 0xF if it's not equal to zero, otherwise it
> returns zero. I'm guessing this is the host controller, based on the
> device name, "Baytrail XHCI controller (Synopsys core/OTG)".

this is the peripheral IP :-) Synopsys core/OTG tells me it's dwc3 :-)

> There's a field called OTGD in the power management capability
> registers opregion, but it's not referenced anywhere else.
>
> There doesn't appear to be anything else related to the device
> controller. The only OS interface string check appears to be in the
> configuration of the PCI bus, and it only checks against various
> versions of Windows.
>
> I'm thinking my next step is to boot into Android and dump the DSDT
> table, and see if it's the same. I'm betting it's not.

It might be the same, yes. But I'm guessing _STA will return a different
value for that OTG1 device :-)

And maybe this mux has something to do with it too. You can fiddle with
the mux by finding its doc, and using i2c-tools (specially i2cset and
i2cget) to write/read registers.

-- 
balbi


signature.asc
Description: PGP signature

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Joseph Kogut]

Hi Felipe,

That's some great information, thanks!

At first glance, the DSDT table has two interesting bits. (I would
paste the decompiled source, but I think it may be copyrighted?
Correct me if I'm wrong.) The first is the USB mux, an SMSC USB3750
connected to I2C1. According to the datasheet, this IC supports
switching the USB data lanes between functions. This looks promising.

The second interesting bit is a device named "OTG1". The _STA method
of OTG1 checks the value of OTGM--defined earlier as an 8-bit field in
GNVS (NVRAM?)--and returns 0xF if it's not equal to zero, otherwise it
returns zero. I'm guessing this is the host controller, based on the
device name, "Baytrail XHCI controller (Synopsys core/OTG)".

There's a field called OTGD in the power management capability
registers opregion, but it's not referenced anywhere else.

There doesn't appear to be anything else related to the device
controller. The only OS interface string check appears to be in the
configuration of the PCI bus, and it only checks against various
versions of Windows.

I'm thinking my next step is to boot into Android and dump the DSDT
table, and see if it's the same. I'm betting it's not.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Felipe Balbi]

Hi,

Joseph Kogut  writes:
> Hi David,
>
> I know this is a pretty old thread. I tried searching for the LKML
> etiquette on something like this and came up empty. If I should start
> a new thread, let me know.
>
> After what I learned from the last thread, I dropped the idea of using
> the device controller from the Dell tablet I had. A few months later,
> I learned that some overseas electronics companies are now making
> dual-boot tablets, that support both Android and generic x86 operating
> systems through an IA32 UEFI firmware. I did some research on the
> devices, and found that they support interaction over USB with the
> Android tools ADB and fastboot, which indicated to me that they likely
> had a working USB device controller.
>
> With my curiosity piqued, I acquired one. My testing confirmed that
> the installed Android OS had the capability of utilizing both the host
> and device controllers, and allowed file transfer over MTP, as well as
> USB networking.
>
> After discovering that much of the kernel code supporting Baytrail had
> yet to be mainlined, I shelved the device for a few months.
>
> In the last few days, I've revisited the tablet, and replaced the
> second OS that came on it with a Linux distribution running the
> mainline kernel, compiled with DWC3 and OTG support. After booting the
> tablet and attempting to load a gadget module, I had a bout of deja
> vu. The device controller doesn't appear in the list of PCI devices.
>
> When attempting to load a gadget module, the kernel log reports:
>
>> udc-core: couldn't find an available UDC
>
> After reviewing this thread, I confirmed that the device id 8086:0f37
> does not appear in the output of 'lspci -nn', but 8086:0f35 does.
>
> The dual-boot capability of the device seems to be implemented by
> switching between two distinct firmwares, but I can't be sure. If that
> is the case, I'm wondering if the PC compatible firmware just doesn't
> expose the device controller for some reason. Alternatively, like
> Felipe mentioned, I wonder if there's not a muxer between the phy and
> device/host controllers that needs to be configured somehow.
>
> Do you have any light to shed on this?

You can extract ACPI tables to figure this one out:

# acpidump -o acpi.bin

Then copy that over to your PC using, e.g. MTP and run:

$ acpixtract -a acpi.bin

followed by:

$ iasl -d *.dat

Then you can look in dsdt.dsl for XDCI or OTGD, or whatever might look
like the peripheral controller. Look at the _STA method and see what it
returns. Devices only show up on PCI bus when _STA is non-zero (usually,
it returns 0xF). I'd assume there's a If() condition for the reported OS
type.

To test things out, you can overwrite FW DSDT with your own, but be
very, very careful when doing so. I recommend reading on Google and
Documentation directory before attempting.

-- 
balbi


signature.asc
Description: PGP signature

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Joseph Kogut]

Hi David,

I know this is a pretty old thread. I tried searching for the LKML
etiquette on something like this and came up empty. If I should start
a new thread, let me know.

After what I learned from the last thread, I dropped the idea of using
the device controller from the Dell tablet I had. A few months later,
I learned that some overseas electronics companies are now making
dual-boot tablets, that support both Android and generic x86 operating
systems through an IA32 UEFI firmware. I did some research on the
devices, and found that they support interaction over USB with the
Android tools ADB and fastboot, which indicated to me that they likely
had a working USB device controller.

With my curiosity piqued, I acquired one. My testing confirmed that
the installed Android OS had the capability of utilizing both the host
and device controllers, and allowed file transfer over MTP, as well as
USB networking.

After discovering that much of the kernel code supporting Baytrail had
yet to be mainlined, I shelved the device for a few months.

In the last few days, I've revisited the tablet, and replaced the
second OS that came on it with a Linux distribution running the
mainline kernel, compiled with DWC3 and OTG support. After booting the
tablet and attempting to load a gadget module, I had a bout of deja
vu. The device controller doesn't appear in the list of PCI devices.

When attempting to load a gadget module, the kernel log reports:

> udc-core: couldn't find an available UDC

After reviewing this thread, I confirmed that the device id 8086:0f37
does not appear in the output of 'lspci -nn', but 8086:0f35 does.

The dual-boot capability of the device seems to be implemented by
switching between two distinct firmwares, but I can't be sure. If that
is the case, I'm wondering if the PC compatible firmware just doesn't
expose the device controller for some reason. Alternatively, like
Felipe mentioned, I wonder if there's not a muxer between the phy and
device/host controllers that needs to be configured somehow.

Do you have any light to shed on this?

Best,
Joseph
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Joseph Kogut]

 Why they use uAB connector I can only assume is because of the smaller
 size then standard-A, and because they are not interested in standards.


That actually sounds remarkably characteristic of Microsoft.

 So 0f35 is indeed is the xHCI host controller. Baytrail boards that
 have the device controller have second USB controller with device id
 0f37.


Any idea if the device controller is wholly absent, or simply not
connected/enumerated?

On Tue, Feb 10, 2015 at 1:39 AM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
 Hi Joseph,

 On Mon, Feb 09, 2015 at 10:27:53AM -0600, Felipe Balbi wrote:
 On Sun, Feb 08, 2015 at 02:51:16PM -0700, Joseph Kogut wrote:
  I have an Intel Valleyview/Baytrail based device (specifically a Dell
  Venue 8 Pro 5830) that I'd like to be able to use the Linux Gadget
  subsystem on, but it seems that the controller isn't currently
  supported. I'm running the 3.19rc7 mainline release.
 
  The device has a micro AB connector. Based on my experiences with a
  similar (Merrifield) platform using Intel's own out of tree patchset
  that had working DRD support using a modified DWC3 driver, I suspected
  that the Baytrail platform I'm working on would also use the DWC3
  driver.

 Unfortunately Dell Venue 8 Pro 5000 Series tablets do not have USB
 device controller. You only have the xHCI host controller. In fact,
 this is the case with basically all new Windows tablets. Microsoft is
 simply not interested in USB device mode.

 Why they use uAB connector I can only assume is because of the smaller
 size then standard-A, and because they are not interested in standards.

  The output of lspci -nn shows:
 
   00:14.0 USB controller [0c03]: Intel Corporation Atom Processor
   Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 09)

 So 0f35 is indeed is the xHCI host controller. Baytrail boards that
 have the device controller have second USB controller with device id
 0f37.


 Br,

 --
 heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Heikki Krogerus]

Hi Joseph,

On Mon, Feb 09, 2015 at 10:27:53AM -0600, Felipe Balbi wrote:
 On Sun, Feb 08, 2015 at 02:51:16PM -0700, Joseph Kogut wrote:
  I have an Intel Valleyview/Baytrail based device (specifically a Dell
  Venue 8 Pro 5830) that I'd like to be able to use the Linux Gadget
  subsystem on, but it seems that the controller isn't currently
  supported. I'm running the 3.19rc7 mainline release.
  
  The device has a micro AB connector. Based on my experiences with a
  similar (Merrifield) platform using Intel's own out of tree patchset
  that had working DRD support using a modified DWC3 driver, I suspected
  that the Baytrail platform I'm working on would also use the DWC3
  driver.

Unfortunately Dell Venue 8 Pro 5000 Series tablets do not have USB
device controller. You only have the xHCI host controller. In fact,
this is the case with basically all new Windows tablets. Microsoft is
simply not interested in USB device mode.

Why they use uAB connector I can only assume is because of the smaller
size then standard-A, and because they are not interested in standards.

  The output of lspci -nn shows:
  
   00:14.0 USB controller [0c03]: Intel Corporation Atom Processor
   Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 09)

So 0f35 is indeed is the xHCI host controller. Baytrail boards that
have the device controller have second USB controller with device id
0f37.


Br,

-- 
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[David Cohen]

On Mon, Feb 09, 2015 at 10:27:53AM -0600, Felipe Balbi wrote:
 Hi,

Hi,

 
 On Sun, Feb 08, 2015 at 02:51:16PM -0700, Joseph Kogut wrote:
  I have an Intel Valleyview/Baytrail based device (specifically a Dell
  Venue 8 Pro 5830) that I'd like to be able to use the Linux Gadget
  subsystem on, but it seems that the controller isn't currently
  supported. I'm running the 3.19rc7 mainline release.
  
  The device has a micro AB connector. Based on my experiences with a
  similar (Merrifield) platform using Intel's own out of tree patchset
  that had working DRD support using a modified DWC3 driver, I suspected
  that the Baytrail platform I'm working on would also use the DWC3
  driver.
  
  The output of lspci -nn shows:
  
   00:14.0 USB controller [0c03]: Intel Corporation Atom Processor
   Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 09)
 
 hmm... looking at what we support today we for PCI, we support Baytrail,
 Merrifield, SPTLP, SPTH, BSW (whatever these last three are) and AMD NL.
 
 However Baytrail is reported as 0x0f37, not 0x0f35. If you have a
 micro-AB and then it ought to support peripheral mode.
 
 I have a feeling the problem you're having is the same David Cohen (in
 Cc) has been trying to support upstream. The SoC has two controllers
 inside, one is peripheral only while the other is host only; there's
 discrete mux in front of them to mux the data lines to one or the other
 controller.
 
 David, is this what's going on ?

I don't have deep knowledge about this hardware, but after a quick look
at internet it seems to be in similar case of Asus T100: The micro AB
connector is used for charging only.
Since it's BYT SoC, it sure has DWC3 controller. But it doesn't mean the
micro AB connector reaches it.

Br, David

 
  Also, a string in the ACPI table tells me that the device uses a
  Synopsys XHCI core, though I'm not sure if it's DRD capable, or host
  only.
  
   _DDN.Baytrail XHCI controller (Synopsys core/OTG)
  
  
  I tried adding the controller's PCI ID to drivers/usb/dwc3/dwc3-pci.c,
  and upon rebooting, the DWC3 module loaded, but reported:
  
   [5.962605] dwc3 dwc3.0.auto: this is not a DesignWare USB3 DRD Core
  
  
  I don't know if this is the result of Dell messing with the ACPI
  table, as they seem prone to do, making the otherwise compatible
  hardware undetected by the proper driver, or if I'm just barking up
  the wrong tree. I think it's premature to file a bug report,
  considering the fact that I'm not yet sure this controller uses the
  DWC3 core.
  
  Attached is the acpi dump from the device in question.
  
  Thank you for your time,
  Joseph
 
 
 
 -- 
 balbi


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Joseph Kogut]

Sorry, David, I'm using Gmail, and still new to the LKML. I guess it
hid the part that was quoted, I'll have to figure out how to turn that
off.

Thanks for the information!
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[David Cohen]

Hi Joseph,

Interesting mix of top and bottom post.

On Tue, Feb 10, 2015 at 10:07:04AM -0700, Joseph Kogut wrote:
  Why they use uAB connector I can only assume is because of the smaller
  size then standard-A, and because they are not interested in standards.
 
 
 That actually sounds remarkably characteristic of Microsoft.
 
  So 0f35 is indeed is the xHCI host controller. Baytrail boards that
  have the device controller have second USB controller with device id
  0f37.
 
 
 Any idea if the device controller is wholly absent, or simply not
 connected/enumerated?

The controller is part of the BYT SoC, but it's not enumerated and
probably not connected too. I assume a phy is missing too (which is not
part of SoC).
Better to consider as Heikki pointed out: if you don't see the id 0f37,
you can't use it.

Br, David

 
 On Tue, Feb 10, 2015 at 1:39 AM, Heikki Krogerus
 heikki.kroge...@linux.intel.com wrote:
  Hi Joseph,
 
  On Mon, Feb 09, 2015 at 10:27:53AM -0600, Felipe Balbi wrote:
  On Sun, Feb 08, 2015 at 02:51:16PM -0700, Joseph Kogut wrote:
   I have an Intel Valleyview/Baytrail based device (specifically a Dell
   Venue 8 Pro 5830) that I'd like to be able to use the Linux Gadget
   subsystem on, but it seems that the controller isn't currently
   supported. I'm running the 3.19rc7 mainline release.
  
   The device has a micro AB connector. Based on my experiences with a
   similar (Merrifield) platform using Intel's own out of tree patchset
   that had working DRD support using a modified DWC3 driver, I suspected
   that the Baytrail platform I'm working on would also use the DWC3
   driver.
 
  Unfortunately Dell Venue 8 Pro 5000 Series tablets do not have USB
  device controller. You only have the xHCI host controller. In fact,
  this is the case with basically all new Windows tablets. Microsoft is
  simply not interested in USB device mode.
 
  Why they use uAB connector I can only assume is because of the smaller
  size then standard-A, and because they are not interested in standards.
 
   The output of lspci -nn shows:
  
00:14.0 USB controller [0c03]: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 09)
 
  So 0f35 is indeed is the xHCI host controller. Baytrail boards that
  have the device controller have second USB controller with device id
  0f37.
 
 
  Br,
 
  --
  heikki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[David Cohen]

On Tue, Feb 10, 2015 at 12:26:53PM -0700, Joseph Kogut wrote:
 Sorry, David, I'm using Gmail, and still new to the LKML. I guess it
 hid the part that was quoted, I'll have to figure out how to turn that
 off.

NP. Take your time :)

 
 Thanks for the information!

You're welcome.

Br, David
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Identifying Synopsys USB3 Controller on Baytrail Device

[Felipe Balbi]

Hi,

On Sun, Feb 08, 2015 at 02:51:16PM -0700, Joseph Kogut wrote:
 I have an Intel Valleyview/Baytrail based device (specifically a Dell
 Venue 8 Pro 5830) that I'd like to be able to use the Linux Gadget
 subsystem on, but it seems that the controller isn't currently
 supported. I'm running the 3.19rc7 mainline release.
 
 The device has a micro AB connector. Based on my experiences with a
 similar (Merrifield) platform using Intel's own out of tree patchset
 that had working DRD support using a modified DWC3 driver, I suspected
 that the Baytrail platform I'm working on would also use the DWC3
 driver.
 
 The output of lspci -nn shows:
 
  00:14.0 USB controller [0c03]: Intel Corporation Atom Processor
  Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 09)

hmm... looking at what we support today we for PCI, we support Baytrail,
Merrifield, SPTLP, SPTH, BSW (whatever these last three are) and AMD NL.

However Baytrail is reported as 0x0f37, not 0x0f35. If you have a
micro-AB and then it ought to support peripheral mode.

I have a feeling the problem you're having is the same David Cohen (in
Cc) has been trying to support upstream. The SoC has two controllers
inside, one is peripheral only while the other is host only; there's
discrete mux in front of them to mux the data lines to one or the other
controller.

David, is this what's going on ?

 Also, a string in the ACPI table tells me that the device uses a
 Synopsys XHCI core, though I'm not sure if it's DRD capable, or host
 only.
 
  _DDN.Baytrail XHCI controller (Synopsys core/OTG)
 
 
 I tried adding the controller's PCI ID to drivers/usb/dwc3/dwc3-pci.c,
 and upon rebooting, the DWC3 module loaded, but reported:
 
  [5.962605] dwc3 dwc3.0.auto: this is not a DesignWare USB3 DRD Core
 
 
 I don't know if this is the result of Dell messing with the ACPI
 table, as they seem prone to do, making the otherwise compatible
 hardware undetected by the proper driver, or if I'm just barking up
 the wrong tree. I think it's premature to file a bug report,
 considering the fact that I'm not yet sure this controller uses the
 DWC3 core.
 
 Attached is the acpi dump from the device in question.
 
 Thank you for your time,
 Joseph



-- 
balbi


signature.asc
Description: Digital signature