BBB failure to exit standby mode on touchscreen IRQ assertion.

General Discussion
,
1

My ultimate goal is to get the BBB to wake up from standby state on either a touch event or periodically using the internal RTC alarm (for a battery check). And I’m running into trouble getting the touchscreen wakeup action happening. I put the touchscreen’s IRQ output on GPIO0[27] and it isn’t waking up from the touchscreen, or even the RTC, if the touchscreen is hit while it’s in standby mode.

Several months ago, I had managed to prove to myself that the hardware can do it. I hacked together some code that used mmap that would directly set the appropriate bits for GPIO0[27]’s SYSCONFIG, IRQWAKEN0, LVDET0, and H2LDET registers. It was a qualified success. The BBB woke up on gpio27 transition, but a number of other necessary conditions made it a non-starter. The USB channels were in the idle state and unconnected, and I used kernel revs 4.19&4.20 instead of 5.10.65.

I have since moved up to kernel 5.10.65, to take advantage of the latest driver(s) for another unrelated accessory. It did force me to do a shut-off of all the active PWM channels, but I was otherwise successful at getting the device to enter standby mode. When I let it time out and wake from the RTC alarm, it resume. However, getting an immediate wakeup when the touchscreen showed a behavior worse than just not working. Touching the screen while waiting for the RTC alarm’s wakeup action made the standby mode permanent. It’s as if the touchscreen’s IRQ managed to unset the general wakeup trigger causing the RTC to fail to wake up.

Looking over the documentation and git history on the edt-ft5x06 driver I’m using, I’ve seen some chatter about the “wakeup-source;” device tree specifier, but adding it to the overlay had no positive effect. Adding the line “wake-gpios = <&gpio0 27 GPIO_ACTIVE_HIGH>;” caused some irq based conflict errors, and took out touchscreen functionality all together.

So, my question is this:
Is It possible to get the kernel to set the AM3358 to wake up on both the RTC and GPIO0[27], or is doing so going to require a second GPIO line (if not a UART the way the 4D systems display cape does)?

2

That figures…
The rubber duck debugging method comes through again…well, almost.
The act of organizing thoughts to come up with what is hopefully a coherent question comes through again.

I got it to properly wake up, but sacrificed a gpio line to do it. For posterity, here’s the complete device tree overlay block that got the feature to function:

	edt-ft5336@38 {
		status = "okay";
		compatible = "edt,edt-ft5336", "edt,edt-ft5306", "edt,edt-ft5x06";

		reg = <0x38>;
		pinctrl-names = "default";
		pinctrl-0 = <&edt_ft5336_ts_pins>;

		interrupt-parent = <&gpio0>;
		interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
		wakeup-source;
		reset-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
		wake-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;

		touchscreen-size-x = <272>;
		touchscreen-size-y = <480>;
		touchscreen-swapped-x-y;
	};

The additions that brought about wake-from-standby functionality were the “wakeup-source;” and the “wake-gpios = …” lines.

I’m still at a loss as to why the driver needed to have a line that’s not even connected to anything to make the wake-from-standby action work. GPIO0[20] is a line I haven’t yet allocated to any task. And it remains unconnected in my system. The lesson here is that there’s something going on in the driver and power management that requires this hack to avoid allocation conflicts, etc.

This workaround is about as robust as dropping a detour sign in front of a sinkhole and called the road fixed, but it does work well enough to enable me to push my attention onto other backlogged issues…like getting the wilc3000 module to connect with its latest drivers.