diff options
author | Raul E Rangel <rrangel@chromium.org> | 2022-02-11 11:13:55 -0700 |
---|---|---|
committer | Raul Rangel <rrangel@chromium.org> | 2022-02-14 16:23:59 +0000 |
commit | 9fc5166ca74568bf292a8f9404fd5c56cce154bf (patch) | |
tree | 5de80e1007641c94214b21ce5c354e6fff8cda3b /src/mainboard/google/kahlee/Kconfig.name | |
parent | cae27ebf490ee1fb37e537e49685531fcbbdfbac (diff) |
mb/google/guybrush: Enable power resource for BT
The `reset` gpio is currently being consumed by the btusb kernel driver.
The functionality was added in https://crrev.com/c/3342774. The goal of
the patch was to reset the BT device when command timeouts occur. This
works, but it doesn't support the case where the BT device is having
problems with USB enumeration. In that case the device can't enumerate
so the driver can't help resetting the device.
If we instead switch to using an ACPI power resource, the kernel can
control the BT device's power. This is beneficial when the device is
having USB communication problems since the kernel will try and power
cycle the device.
We don't lose the ability to reset the device on command timeouts
either since `btusb_qca_cmd_timeout` will enqueue a USB port reset if
there is no `reset` GPIO. So win / win.
This results in the following power resource:
PowerResource (PR02, 0x00, 0x0000)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x01)
}
Method (_ON, 0, Serialized) // _ON_: Power On
{
\_SB.CTXS (0x84)
Sleep (0x01F4)
}
Method (_OFF, 0, Serialized) // _OFF: Power Off
{
\_SB.STXS (0x84)
Sleep (0x0A)
}
}
I switched the device tree entry from using reset_gpio to enable_gpio
because the acpi_device_add_power_res method asserts the reset in the
_ON method unconditionally. This results in a small glitch on the line.
By using the enable_gpio we get the correct behavior.
I don't have a datasheet right now, so I just picked some values for the
reset timing. The kernel driver was using 200ms. We can revisit the
numbers when we get a datasheet.
BUG=b:218295688
TEST=Suspend stress test on nipperkin with 600+ cycles. Verify power
resource is created on the kernel. This should allow the kernel to
power cycle the device via usb_acpi_set_power_state.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib1eff86db76929f76432cd6f765880c892e7a786
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Diffstat (limited to 'src/mainboard/google/kahlee/Kconfig.name')
0 files changed, 0 insertions, 0 deletions