summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRaul E Rangel <rrangel@chromium.org>2022-02-11 11:13:55 -0700
committerRaul Rangel <rrangel@chromium.org>2022-02-14 16:23:59 +0000
commit9fc5166ca74568bf292a8f9404fd5c56cce154bf (patch)
tree5de80e1007641c94214b21ce5c354e6fff8cda3b
parentcae27ebf490ee1fb37e537e49685531fcbbdfbac (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>
-rw-r--r--src/mainboard/google/guybrush/variants/baseboard/devicetree.cb6
1 files changed, 5 insertions, 1 deletions
diff --git a/src/mainboard/google/guybrush/variants/baseboard/devicetree.cb b/src/mainboard/google/guybrush/variants/baseboard/devicetree.cb
index 104ba79c43..a9b0a154a1 100644
--- a/src/mainboard/google/guybrush/variants/baseboard/devicetree.cb
+++ b/src/mainboard/google/guybrush/variants/baseboard/devicetree.cb
@@ -316,7 +316,11 @@ chip soc/amd/cezanne
chip drivers/usb/acpi
register "desc" = ""Bluetooth""
register "type" = "UPC_TYPE_INTERNAL"
- register "reset_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPIO_132)"
+ register "has_power_resource" = "true"
+ register "enable_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPIO_132)"
+ # TODO(rrangel): Find data sheet
+ register "enable_delay_ms" = "500"
+ register "enable_off_delay_ms" = "10"
device ref usb2_port6 on end
end
end