I don’t personally know how the wake function deals with power rails, and how the rails may differ between the UART for ttyS0 and ttyS2. I suspect that this is the issue, but I don’t know how to test. There may be a location in “/sys” which can verify if a rail tied to ttyS0 or ttyS2 UARTs is up or down at the moment. This is long because I’m experimenting rather than going straight to a known answer, and more or less naming steps to examine in the hope of finding something.
Just as an experiment (this is actually on a TX2, but the L4T version and addresses of UARTs should be the same), first identify where that UART has its “/sys” exports:
sudo find /sys -name ttyS0
In this case one location, which mentions the serial itself, is “/sys/devices/3100000.serial/tty/ttyS0/”. Interestingly enough, I do see a “power/” subdirectory, and within that some “wakeup*” entries. I suspect that “wakeup” though is the reverse of what you are asking about, and perhaps only deals with activity on the UART causing wakeup. The “runtime*” might be of more interest, but I have no way of actually knowing, it’s all guesswork.
If I look at the same information for ttyS2 (or ttyTHS2), something changes. Take a look at this:
sudo find /sys -name ttyS2
Notice that it now says “serial8250” instead of an address.serial (e.g., “3100000.serial”). This is probably due to device tree, but again I’m just poking around and speculating. If I switch to the “/sys/class/tty/ttyS<change to 0 or 2 depending on ttyS0 or ttyS2>/power/” what I see seems to be more relevant.
So I’m going to propose an experiment. Before the tty goes away, save the output of this (you can ignore any error messages, it’s only the successful reads which matter), and then compare the output again after the port goes to unwakeable sleep:
egrep '.*' `find /sys -name ttyS2 | sed -e 's/ttyS2/ttyS2\/power\/\*/g'` | sort | tee /some/log/location/log.txt
What this will do is list all associated “/sys” files for ttyS2, grep for content in the “power” subdirectory, and thus name the file on the left and the content of the file on the right, and then sort it (sort is important for later on when doing a diff). The “tee” just lets you log what you see (it leaves the log file location up to you).
Assuming you have a “log_before_sleep.txt” and a “log_after_sleep.txt”, then you can see what changed via:
diff -c log_before_sleep.txt log_after_sleep.txt
If you find something suspicious which we can relate to a device tree entry, then we might be able to to figure it out just from the device tree. If not, then someone from NVIDIA will have to comment on what internally sets up, sleeps, and restarts a serial UART as console…and why ttyS0 works, but not ttyS2.
Can you post a copy of the before and after logs? If you hover your mouse over the “pencil” icon in the upper right corner of an existing post, then a paper clip icon will show up…you can attach a file to an existing post via the paper clip icon.