usb: disable tps6598x interrupts #72
Conversation
|
Can we just unconditionally do this on init? If m1n1 isn't using/handling these IRQs it should just disable them by default. |
|
Mac OS seems to rely on the default config or iboot for the pd controller's interrupt config. When the interrupts are disabled in m1n1 the port is dead. |
|
We've run into things like this in the past, so I think I'm going to rework how we do subsystem shutdowns a bit. I'll discriminate between "shutdown for kboot" and "shutdown for chainload"; the latter tries to restore state to whatever iBoot leaves to make macOS (or another m1n1) happy, while the former leaves things in the sanest state for Linux. Let me think for a bit how I want to do this :) |
jannau
changed the title
|
I think the sanest state for chainload and linux boot does not differ in this case. Leaving the interrupts in the default config looks sane to me. The Problem is the hv guest. It wouldn't be a problem there either if we were not using one port for the hv or if both ports were not sharing the same interrupt line. Kept now mostly within m1n1. The only required proxy change is that the other USB iodev gets disabled in Also in this PR some minor python hv fixes and removal of the hiding of the second usb-c port. |
proxyclient/m1n1/hv.py
Outdated
| @@ -677,7 +683,7 @@ def rh(base, off, width): | |||
| print(f"R {base:x}+{off:x}:{width} = 0x{data:x} -> 0x{ret:x}") | |||
| return ret | |||
|
|
|||
| for addr in (0x23b700420, 0x23d280098, 0x23d280088, 0x23d280090): | |||
| for addr in (0x23b700420, 0x23d280098, 0x23d280088): | |||
There was a problem hiding this comment.
Does this cover the case where the HV is using both ports? I've only tested with port 0 so far, I imagine the problem addresses are different for each.
There was a problem hiding this comment.
I haven't noticed a difference after removing 0x23d280090 and still removing both ports from the guest's ADT.
It is however required when running running Mac OS as guest using HV on port 1. In that case it's necessary to hook (0x23b700448, 0x23d2800a0, 0x23d280090) though. I'll add that to this PR.
Is there use case where the HV would use both USB-C ports? Hiding only the used USB-C port from the guest looks like the sane default when there are devices with only two USB ports.
|
I don't like the idea of leaving IRQs enabled for Linux (the sane state for IRQ hardware is leaving stuff masked), but we can shave that yak later. Other than the comment this looks good, feel free to mark it ready. |
Restore the interrupt masks on chainload or HV guest start. The interrupt mask is not restored on the USB-C port used by the hypervisor. This prevents an interrupt storm in the guest when the other USB-C port is exposed to the guest. Both tps6598x share unfortunately an interrupt line. Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Allows running HV over each USB-C port of a Mac Mini with Mac OS as guest. Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
|
Interrupts are now only restored for the guest and for chainloading (not via |
I've experimented a little, and my theory is that on the MacBooks, the SMC (or the PMP, or any other coprocessor) snoops the PD chips' interrupt line to know when to kick the battery charging circuitry: reconnecting power with the interrupts masked, the PD chip will correctly configure 20V but no power is drawn and there are no SMC notifications. Unmasking interrupts fixes this. (I don't think there is a sane way to deal with this as it's not a sane thing for Apple to be doing.) |
Restore the interrupt masks on transition to the next state. The masks
are not restored on the USB-C port used by the hypervisor. This prevents
an interrupt storm in the guest when the other USB-C port is exposed to
the guest. The tps6598x interrupt line is shared amoung both ports.