Hi,

On Mon, Oct 31, 2016 at 12:57 AM, Felipe Balbi
<felipe.ba...@linux.intel.com> wrote:
>
> Hi,
>
> Joseph Kogut <joseph.ko...@gmail.com> 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 0000:00
>> <6>[    0.612869] pci_bus 0000:00: root bus resource [bus 00-ff]
>> <6>[    0.612877] pci_bus 0000:00: root bus resource [io  0x0000-0x006f]
>> <6>[    0.612885] pci_bus 0000:00: root bus resource [io  0x0078-0x0cf7]
>> <6>[    0.612893] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
>> <6>[    0.612900] pci_bus 0000:00: root bus resource [mem 
>> 0x000a0000-0x000bffff]
>> <6>[    0.612908] pci_bus 0000:00: root bus resource [mem 
>> 0x000c0000-0x000dffff]
>> <6>[    0.612915] pci_bus 0000:00: root bus resource [mem 
>> 0x000e0000-0x000fffff]
>> <6>[    0.612923] pci_bus 0000:00: root bus resource [mem 
>> 0x7d000001-0x7f000000]
>> <6>[    0.612931] pci_bus 0000:00: root bus resource [mem 
>> 0x80000000-0x90effffe]
>> <6>[    0.612938] pci_bus 0000:00: root bus resource [mem 
>> 0xfed40000-0xfed40fff]
>> <7>[    0.612960] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
>> <7>[    0.613276] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000
>> <7>[    0.613304] pci 0000:00:02.0: reg 10: [mem 0x90400000-0x907fffff]
>> <7>[    0.613326] pci 0000:00:02.0: reg 18: [mem 0x80000000-0x8fffffff pref]
>> <7>[    0.613346] pci 0000:00:02.0: reg 20: [io  0x1000-0x1007]
>> <7>[    0.613672] pci 0000:00:03.0: [8086:0f38] type 00 class 0x048000
>> <7>[    0.613696] pci 0000:00:03.0: reg 10: [mem 0x90000000-0x903fffff]
>> <7>[    0.614052] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
>> <7>[    0.614087] pci 0000:00:14.0: reg 10: [mem 0x90e00000-0x90e0ffff 64bit]
>> <7>[    0.614179] pci 0000:00:14.0: PME# supported from D3hot D3cold
>> <7>[    0.614473] pci 0000: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 0000:00:16.0: reg 10: [mem 0x90800000-0x909fffff]
>> <7>[    0.614530] pci 0000:00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff]
>> <7>[    0.614611] pci 0000:00:16.0: PME# supported from D0 D3hot
>> <7>[    0.614916] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
>> <7>[    0.614957] pci 0000:00:1a.0: reg 10: [mem 0x90d00000-0x90dfffff]
>> <7>[    0.614979] pci 0000:00:1a.0: reg 14: [mem 0x90c00000-0x90cfffff]
>> <7>[    0.615118] pci 0000:00:1a.0: PME# supported from D0 D3hot
>> <7>[    0.615416] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
>> <7>[ 0.615775] pci_bus 0000: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 0000:00
>> [    0.636196] pci_bus 0000:00: root bus resource [io  0x0070-0x0077]
>> [    0.636201] pci_bus 0000:00: root bus resource [io  0x0000-0x006f window]
>> [    0.636205] pci_bus 0000:00: root bus resource [io  0x0078-0x0cf7 window]
>> [    0.636209] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
>> [    0.636213] pci_bus 0000:00: root bus resource [mem
>> 0x000a0000-0x000bffff window]
>> [    0.636217] pci_bus 0000:00: root bus resource [mem
>> 0x000c0000-0x000dffff window]
>> [    0.636221] pci_bus 0000:00: root bus resource [mem
>> 0x000e0000-0x000fffff window]
>> [    0.636225] pci_bus 0000:00: root bus resource [mem
>> 0x90c00000-0x90ffffff window]
>> [    0.636228] pci_bus 0000:00: root bus resource [mem
>> 0x7cf00001-0x7ef00000 window]
>> [    0.636232] pci_bus 0000:00: root bus resource [mem
>> 0x80000000-0x908ffffe window]
>> [    0.636236] pci_bus 0000:00: root bus resource [mem
>> 0xfed40000-0xfed40fff window]
>> [    0.636241] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [    0.636258] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
>> [    0.636608] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000
>> [    0.636627] pci 0000:00:02.0: reg 0x10: [mem 0x90000000-0x903fffff]
>> [    0.636644] pci 0000:00:02.0: reg 0x18: [mem 0x80000000-0x8fffffff pref]
>> [    0.636659] pci 0000:00:02.0: reg 0x20: [io  0x1000-0x1007]
>> [    0.637019] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
>> [    0.637045] pci 0000:00:14.0: reg 0x10: [mem 0x90800000-0x9080ffff 64bit]
>> [    0.637128] pci 0000:00:14.0: PME# supported from D3hot D3cold
>> [    0.637451] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
>> [    0.637477] pci 0000:00:1a.0: reg 0x10: [mem 0x90700000-0x907fffff]
>> [    0.637491] pci 0000:00:1a.0: reg 0x14: [mem 0x90600000-0x906fffff]
>> [    0.637596] pci 0000:00:1a.0: PME# supported from D0 D3hot
>> [    0.637915] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
>> [    0.638290] pci_bus 0000: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 from the OTG1 device to always return 0xF,
>> and the device controller still didn't show up on the PCI bus. I
>
> I don't think your kernel is using your DSDT. There's no "taint" message
> in your dmesg logs.
>
> Make sure you set CONFIG_ACPI_CUSTOM_DSDT_FILE properly. Have a look
> https://01.org/linux-acpi/documentation/overriding-dsdt for more details
>
> cheers
>
> --
> balbi

Thanks for your pointers, I've just revisited this project again, and
I have the device controller working. :)

It seems you were correct about the DSDT disabling it. I worked around the
firmware by creating an Android boot image with my own kernel and
ramdisk, and booting it from the Android mode of the device.

Am I correct in understanding that if the firmware disables hardware,
there's no patching the kernel to work around it, and the DSDT itself
must be patched?
--
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

Reply via email to