summaryrefslogtreecommitdiffstats
path: root/src/mainboard/google/zork/variants/trembyle
diff options
context:
space:
mode:
authorRaul E Rangel <rrangel@chromium.org>2020-07-14 14:32:02 -0600
committerAaron Durbin <adurbin@chromium.org>2020-07-23 21:26:14 +0000
commit728c0787f2ad742da287791bf8f606b7d5921b0b (patch)
tree1be27a7c186915ee1043fb3d51c222b435093bcc /src/mainboard/google/zork/variants/trembyle
parentbe2d6541b98639de8e8e5492af526c022366df59 (diff)
downloadcoreboot-728c0787f2ad742da287791bf8f606b7d5921b0b.tar.gz
coreboot-728c0787f2ad742da287791bf8f606b7d5921b0b.tar.bz2
coreboot-728c0787f2ad742da287791bf8f606b7d5921b0b.zip
mb/google/zork: Don't expose reset GPIO for touchscreen to OS
The Raydium ACPI entry currently provides a reset GPIO and an _ON/_OFF method to the kernel. These are contradictory. The ownership of the GPIO should be mutually exclusive between either the OS or the FW. Since we have two methods exposed this causes the OS to reset the TS twice. Once using the _ON method, and once using the GPIO. Additionally the _ON method is waiting for 20ms after reset while the OS driver uses a 50ms delay. The Raydium TS datasheet specifies 20ms for FW ready time, so the OS driver is adding additional padding. The reference design has a 32ms rise time on the reset line. So without this patch, the OS tries to reset the TS using the _ON method and it waits for 20ms. This is not enough time for the reset line to reach high, let alone account for the FW ready time. The OS driver then tries to reset the device by toggling the GPIO. It waits 50ms which is still 2ms less than required. This CL removes the GPIO from being exported in the _CRS so the OS driver won't try and reset the device. It also increases the reset delay by 32ms to account for the rise time. This isn't a complete fix. I think that the slow rise time is causing some kind of metastability in the TS reset hardware. Using a script to bind and unbind the TS driver, the TS device becomes unresponsive after ~200 iterations. The only way to reset the device is to power cycle. The TS power is also not currently controlled by the power resource. This means that we have no guarantee over when the reset line is toggled. This will lead to issues while spending and resuming. BUG=b:160854397 TEST=Boot trembyle and make sure TS works. Suspend/Resume trembyle 300+ times. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I23131be5d7109eed660a8bd6e2c156c015aa3c4e Reviewed-on: https://review.coreboot.org/c/coreboot/+/43467 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
Diffstat (limited to 'src/mainboard/google/zork/variants/trembyle')
-rw-r--r--src/mainboard/google/zork/variants/trembyle/overridetree.cb5
1 files changed, 4 insertions, 1 deletions
diff --git a/src/mainboard/google/zork/variants/trembyle/overridetree.cb b/src/mainboard/google/zork/variants/trembyle/overridetree.cb
index 4cd53eea4512..bead29335df1 100644
--- a/src/mainboard/google/zork/variants/trembyle/overridetree.cb
+++ b/src/mainboard/google/zork/variants/trembyle/overridetree.cb
@@ -66,8 +66,11 @@ chip soc/amd/picasso
register "probed" = "1"
register "irq_gpio" = "ACPI_GPIO_IRQ_EDGE_LOW(GPIO_12)"
register "reset_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPIO_140)"
- register "reset_delay_ms" = "20"
+ # 32ms: Rise time of the reset line
+ # 20ms: Firmware ready time
+ register "reset_delay_ms" = "32 + 20"
register "has_power_resource" = "1"
+ register "disable_gpio_export_in_crs" = "1"
device i2c 39 on end
end
chip drivers/i2c/generic