lategoodbye
commented
6 years ago @fluffysheap Could you please provide more information:
- Please make an estimation how often this issue occurs (downstream and upstream case)
- Please provide a dmesg of an error case
- Which kernel config did you use (downstream and upstream case)
- Which I2C pins did you use on Raspberry Pi 2?
stschake
Hello,
This is a copy of an issue I originally filed with raspberrypi/firmware, which they closed saying it is your issue. It is possible for the KMS driver to put the DSI display into a state where the firmware does not reset it on reboot, at which point it stops working until power cycled. It seems like a firmware issue to me, but popcornmix does not agree.
Sometimes, on a warm reboot, the firmware doesn't re-initialize the DSI panel. It happens only (as far as I have seen) when the KMS driver is in use - never with the closed driver, and I have never seen it in my (limited) use of the FKMS driver.
When this occurs, the panel does not work until the panel is power-cycled and the pi is rebooted. The backlight is on, sometimes patterns on the display, but there is no colored square at reboot, and no way I have found to recover the display from software. Once put into this state, warm rebooting with the closed-source video driver will not fix it. Power-cycling the pi (but not the panel) does not fix it. It occurs for me on both Pi 2 and Pi 3, not tested on other models.
While this is an intermittent problem it is by no means rare. It happens about half the time for me using official 4.9 kernel. It can't be reproduced with 4.14 because the panel is not enabled in the KMS driver in the official beta 4.14 kernel. However, in a 4.15rc5 kernel that I built myself and enabled the driver in, I can reproduce the problem. It does seem to run in streaks, I can have several good reboots in a row before a fail, but e.g. putting a reboot command in an every-other-minute cron job will reproduce the problem quickly.
Things I have noticed:
Most of the time, rebooting triggers the big rainbow square as soon as the kernel executes the reboot (within 1/4 second or so). Sometimes, however, it goes through the white patterns for a longer time. When this happens, it always fails on the current reboot. I built my 4.15 kernel with console rotation support, and enabled lcd_rotate=2 in config.txt. Most of the time the console doesn't rotate and I have put no effort into making it work. But once in a while, it comes up rotated (this causes the X display to also be rotated). When this happens, it always fails on the next reboot. It seems to happen less often when I remove the backlight and ft5406 drivers before rebooting, but this could be my imagination. It seems to happen less often using a pure upstream kernel rather than the kernel from the raspberrypi tree. This is what led me to try disabling the backlight and ft5406 drivers. However, I think I have seen it a few times even with upstream kernel (upstream kernel doesn't work well for me so I don't test it as much). When the display fails, I always get the "Unknown Atmel firmware revision: 0x0" error in dmesg, and it will appear in every reboot afterward using the KMS driver. As a workaround, is there anything that I can do from the ARM side - or even using the panel i2c pins with jumper wires - to "hard reset" the panel? I poked around in vcgencmd and vcmailbox but didn't find anything useful.
The KMS driver is in a good state now. I believe it is ready for, if not exactly prime time, at least wider experimental deployment. This is the most serious problem I have experienced in my testing, and the only one that I haven't found a workaround for. This would make it usable for many people full-time. Thanks!