- #Dmesh mac download drivers#
- #Dmesh mac download driver#
- #Dmesh mac download Patch#
- #Dmesh mac download code#
I have opened it, which was remarkably complicated. The Thunderbolt security is disabled in BIOS, and all access control settings are as relaxed as possible. I have an laptop, BIOS 2.8.2, Thunderbolt NVM 21.0, and kernel 4.17.14. So I've spent way too much time trying to get this adapter to work, and here's what I discovered. If you don't have a Linux git repo locally and don't want to clone this (it's a > 1GByte download) I'll be happy to send you the individual patches based on 4.9 or 4.10, whichever you prefer.
#Dmesh mac download Patch#
The runtime PM series with the Alpine Ridge patch on top is on this branch, it would be great if you could test the combination of the two: We do have to disable runtime PM on Alpine Ridge for now as Apple has made significant changes for these chips which need to be reverse-engineered first. I could submit the patch for Alpine Ridge on top of that if you can provide a Tested-by. Yesterday I posted v5 of my series to add runtime PM for Thunderbolt on Macs, this will hopefully land in v4.11.
#Dmesh mac download driver#
> Any plans to bring that patch upstream?ĭoes it work for you? I've heard from Bernhard Froemel that the driver loads without errors with that patch but I've yet to hear from anyone who's actually tested it with Thunderbolt devices attached. > MacBook Pros (the only ones with Thunderbolt 3 so far): > In any case you will need this patch to make Thunderbolt work on the 2016 > (In reply to Lukas Wunner from comment #5) (In reply to Daniel Roschka from comment #6) It's kind of hard to improve them as we know so little about all that.
> stuff in dmesg is pretty hard to interpret. > if we can log more intelligent messages for this situation. Other than that I think the only public source are various Thunderbolt-related patents by Intel, Apple et al.
#Dmesh mac download code#
This is done by AML code in the DSDT, it writes to a number of MMIO registers of the Thunderbolt controller.Īll of this is almost completely undocumented. To make matters even more complicated, Macs newer than 2015 that are booted with Windows will reconfigure the Thunderbolt controller to be managed by ICM rather than natively. To the best of my knowledge, PCI devices are *not* handled by pciehp but by acpiphp. When a device is hotplugged, somehow an SCI occurs and the ICM code is executed. On non-Macs the tunnels are set up by a firmware component dubbed Intel Connection Manager which runs in System Management Mode. It's important to understand this distinction because most people think Thunderbolt is just PCIe to external devices: It's a packet switching technology and one has to set up PCIe tunnels to actually communicate with devices.
Once a PCI-tunnel is set up, pciehp sees a hotplug event.
#Dmesh mac download drivers#
These drivers recognize when a Thunderbolt device is hotplugged and set up PCI- and DisplayPort-tunnels. I'm only familiar with the situation on Macs, where all of this happens natively: There's an EFI driver to configure tunnels to devices already attached on boot, and there's an OS driver which takes over after ExitBootServices. > (not pciehp) to support these Thunderbolt devices? > Is the ACPI Bus Check event that hook? Does that mean we must use acpiphp > things behind the adapter, there must be a hook where firmware gets invoked. > If the firmware is responsible for configuring This is also what Acelan Kao wrote above. In the dmesg output it can be seen that the adapter was present on boot, then unplugged and replugged. (In reply to Bjorn Helgaas from comment #2)
0 kommentar(er)
