-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4 lanes DSI panel on cm3+ enabling error with VC4 #4323
Comments
Check the state of the DSI data lanes (particularly lane 0) when your display is repowered. If they aren't in LP-11 then the DSI block will timeout waiting for them to enter that state before sending the command. Are you sending the commands in LP or HS mode? ( |
HS mode for now. I'll change it to LP to see if it makes a difference. |
Unfortunately setting that flag does not seem to help much:
|
Does your panel have an enable or reset GPIO that you have connected? If so then have you verified that you are complying with the startup timings between asserting/clearing the GPIO and sending your first command? If the default state for the GPIO happens to match that for "panel active" then on boot your panel will be active far sooner than you think it is, and sending commands works. On power down the power actually gets killed, and then power up to first command time may be too short. Beyond that I can't offer much guidance without seeing code. |
It does have a reset pin (no enable pin). As far as I know I respected the timings. I'll see if I can post the code here. |
Here is the code (I eliminated the long list of initialization commands).
|
I happened to have the same problem. This problem is easy to reproduce: 'Start Menu' > Preferences > Screen Configuration > 'Right click DSI-1' > Orientation, repeatedly switch between Normal and Right many times, and it will appear. |
@aromanro Hi, How's it going now? I've tried the same method as you, and it doesn't solve the problem |
It's not solved, indeed. |
I'm just talking about the way to reproduce. It's not about 90 degrees. |
I think that call happens when you send DSI commands. |
I cannot find a pattern in the behavior. Most of the times it works ok, but sometimes it fails:
I've set a short time interval until the screen goes blank to test it. |
We have a couple of threads going on about DSI, and there isn't a simple answer. From https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=305690 I have a hunch that the DSI lanes are not being left in LP-11 state correctly during the _enable call to the bridge/panel. Depending on timing and how fussy the device is, that seems to be causing grief on the SN65DSI83/4. Could you try with commit 6by9@b939eaf from https://github.com/6by9/linux/tree/rpi-5.10.y-sn65dsi8x-marek to see whether that is the cause of your issues too. |
Thank you! I'll try it today, if possible. |
Hi, @6by9 |
It seems that I won't know until Monday because I managed to make the device unbootable. Anyway, we exposed the sources on GitHub for the panel driver, now they are available here: https://github.com/Homegear/Homegear-Linux-Touch-Panel-08-DSI-Display-Driver |
Ok, unfortunately it does the same:
Now even when blanking is activated. I don't think I've seen such case until now, usually it's when preparing that's happening. |
What's trying to send a DSI message when the panel/bridge is powered down? That sounds like a bug in the driver somewhere as the DSI bus and the panel/bridge is likely powered down. |
My guess is that's originating either from
or
in |
I get these 'Timeout' occasionally. |
I did more tests and changed the panel driver to adjust it to the patched video driver: https://github.com/Homegear/Homegear-Linux-Touch-Panel-08-DSI-Display-Driver/blob/main/lcd_driver.c My guess is that the patched driver after disabling does immediately an unpreparing, too, when the screen is blanked, the goal being that when it's woken up the prepare will reset the panel. I modified the panel driver to reset each time there is a DSI failure in initialization (I also played a lot with the timings for reset) but still the errors can happen a lot of times in a row and that renders the panel unusable. If after such failure one touches it after a while (after the blanking is active again) it can come back to life. Quite odd. |
This is because after the blanking is active again, the panel will be initialized again and the display will return to normal. |
Maybe, but why it doesn't in the retry loop? The failure there is always in the first initialization command, the 'switch page' one. |
I guess because DSI host is not ready. |
I tried various solutions, including changing the delays. Even if I put a huge delay after reset, the error can still occur. Even if that is the case, that does not explain how it's ready very often after such reset, but then when that DSI error is happening, it's not ready 3 times or more in a row (I tried even 6 times). |
We 'solved' the problems we had - for now - by eliminating mipi_dsi_dcs_set_display_off / mipi_dsi_dcs_set_display_on calls from disable / enable, also the mipi_dsi_dcs_enter_sleep_mode from unprepare. With the official kernel it works, no more DSI command errors that lock the screen. I've still noticed once a |
Unfortunately I was too eager to say that the fix from yesterday works... it doesn't always work. I touched the screen once and it didn't came back to life, it remained blank. 'Enable' was called but not having any DSI call anymore, there was no error in there. That means that the flag remained zero. The issue is definitively originating elsewhere. Now with no DSI error in the log, too. After entering screen blanking again, it came back to life. I need to find out what's really happening when blanking/unblanking... My guess is that something / somewhere puts some circuitry in low power mode and leave it that way sometimes when unblanking. The DSI errors are a consequence of that. Also a LE: It is related, it appears a little bit later than the issue, but seems connected. |
This is no matter. It just needs to be modified: |
I've got rid of all the errors by changing the VC4 driver. I'll add a description today after I'll do some more tests with the DSI commands back in the enable/disable functions. |
Can you show me what you have changed? |
Yes. Btw, with those changes I still get those timeouts from above, if I turn on the dsi commands in enable/disable and so on in the panel driver, but it recovers in the loop. As it is right now https://github.com/Homegear/Homegear-Linux-Touch-Panel-08-DSI-Display-Driver/blob/main/lcd_driver.c there are no errors anymore, and I tested turning on/off the screen thousands of times (with a script). Before, typically in 100 attempts it happened and it wasn't recoverable at panel reset (unless blanking activated again). Here are the changes: Here, in
In Comment out the code:
I'm currently trying to understand what difference does it make to disable only clocks disabling/unpreparing. With the committed code, I needed to comment out both the clocks code and the pm code, but it might work ok if I turn back on the on/off/sleep dsi commands in the panel driver, with only one of them commented out. Still testing... |
I also get
But they recover. Strange. |
pll_phy_clock, escape_clock, and pixel_clock are all internal clocks to the SoC. They shouldn't take any significant time to come up, but that's the only thing I can think of in vc4_dsi_encoder_enable between enabling the clocks and calls into the pre_enable functions. pm_runtime_[get|put] should power the blocks up/down, however there isn't fully discrete blocks power gating to the blocks, so I suspect that they actually result in very little different (AIUI they should request the power domains as registered at https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm/boot/dts/bcm2835-rpi.dtsi#L85) Having looked into the way DRM wants DSI to work, the current driver doesn't fully do the job, and I'm looking to rework it. There seems to be an expectation that the transfer function can be called at any time, so what state should the DSI lines be left in afterwards? Dropping to ULPS or LP-00 (off) actually means leaving the PHY active. The pre_enable functions of all devices are called starting from the panel, and coming back towards the DSI encoder. Many drivers send their DSI initialisation sequences from pre_enable, but haven't used pm_runtime to power up the chain, and the encoder hasn't had any prior notification that it is being enabled, Yet if you read the datasheets for most of these devices they expect the DSI lines to be in LP-11 (enabled) state before the chip is powered on. I don't see how this is achieved on other platforms. This is the reason why vc4_dsi deliberately breaks the chain of encoders/bridges/displays so that the framework sees it as the end of the chain. It therefore gets called before the bridges/panels so can power up, and it then calls all the pre_enables/enables/disables/post_disables once it has got the DSI block into a sensible state. However this also then breaks the the calling of all the mode_fixups, mode_set, and mode_valid calls from the framework, and there is no way to replicate those within vc4_dsi as it doesn't have all the state. The only solution I can see is to power up DSI from bind, and power it down in unbind. Anything else is leaving things in odd states or unable to honour all the requests that a bridge or panel driver can make. |
@aromanro Hi, have you solved the problem? |
Completely, no. I just reduced its frequency by one order of magnitude with the already mentioned changes. I'm still looking into it. |
Ok, I give up for now. Besides the changes I described above, I also tweaked some flags, here: Unfortunately the DSI errors did not go away, but they are now fewer and can recover (usually?). I am testing with this simple script https://github.com/Homegear/Homegear-Linux-Touch-Panel-08-DSI-Display-Driver/blob/master/test/test.sh and in 3000 blanking/unblankings I see a little over 100 DSI errors, but they go away when retrying (maybe they need two retries). Sometimes they cannot be fixed by retrying, in which case BIG PROBLEM! is displayed because it is signaled by the panel driver in the proc file. This happens once each 6000 blanking/unblankings or so. I think the patch from @6by9 made things worse for us, for some reason the errors couldn't be avoided by retrying to send the command anymore (so lots of BIG PROBLEMs). As an odd thing, the DSI errors occur mostly when disabling the panel but the commands work after a retry or two. If they occur when preparing the panel (typically in the initialization sequence after reset) they fail no matter how many times they are resent (even if the panel is reset again before retrying). |
I'm still looking into the DSI driver. Reports are that it is working with SN65DSI83 (the old driver wasn't), and it certainly works with the LT070ME05000 (1200x1920 Nexus 7) panel. I need to try it with the Pi 7" DSI panel (TC358743 + 800x480 panel). It'd be interesting to know if it works for your panel. |
Nice, that looks like quite a change, I'll check it out. Thank you! |
@6by9 Unfortunately I cannot say it works better for us. I started testing it and I got already three "BIG PROBLEM!" (that is, DSI errors at initialization that couldn't be recovered by resetting again and retrying sending the initialization sequence - several times). And probably will issue several more until the end of the 3000 tries loop. With the variant I changed, we get at most one of those more serious issues each 3000 blanking/unblanking tests. |
Please discard that, I think I cloned the wrong branch. I'll try again. |
Unfortunately, the correct branch didn't work out as well.
The old DSI transfer errors are still there including the ones that cannot be recovered by retries. Maybe this is relevant, but each time it's unrecoverable the sequence of retries is preceded by:
|
I commented out the vc4_dsi_ulps calls to enable and disable ulps, but still the problem (reset/reinitialization does not work, no matter how many retries) remains, so probably the above issue is just an effect, not a cause. |
OK, thanks for trying. DSI is an absolute pain to debug at the best of times. STAT of 0x00020803 is The bits are latched though (reset by writing 1 to them), and only reset in a successful pass through vc4_dsi_ulps or vc4_dsi_runtime_resume. Your code in https://github.com/Homegear/Homegear-Linux-Touch-Panel-08-DSI-Display-Driver/blob/master/lcd_driver.c with regard SLOW_MODE looks confusing if nothing else. Looking at it in more detail, it looks very much like an ILI9881 initialisation sequence with the bank switching. The driver for that panel already includes an initialisation table for each variant, so it seems a little odd duplicating all that information. I have an ILI9881C panel running from the Pi, although on 2 lanes. The init tables do seem to be magic runes though. |
I'm sure it looks confusing, it went in that state while trying to workaround the problems. Initially it used slow mode only for the initialization sequence. I'll change the flag to have it set permanently on Monday. |
We got rid of a lot of DSI errors by increasing the repeat count for short packets to 5 (currently 3 in what's committed: https://github.com/Homegear/homegear-vc4-driver/blob/e8e3608184141c379f4f11d93727081d4207a8d2/vc4_dsi.c#L1253 ). So a combination of avoiding pm issues and this change basically solve the issues for us (very seldom they can still appear, but then the repeat loop in the panel driver solves it). There is another issue that's maybe left, the case (out of many thousands) when after a reset initialization commands don't go through. I still have to reproduce that with the current changes. LE: A repeat count of 3 seems close to optimal in our case, more than this does not seem to help much (could even make things worse). DSI errors still occur but their frequency drops about one order of magnitude compared with the previous version. |
This issue happened from the raspberrypi kernel issue in [here](raspberrypi/linux#4323) When it happened, we find a way to fix it with help of user code: `DISPLAY=:0 xset s activate` just run this command twice.the lcd will back to work nomally. To achieve this,we crate a file system node dsi_state for user app to get the state of it.
Due to a potential bug(raspberrypi/linux#4323) in VC4's driver, the DSI panel cannot be reliably initialized. The updated patch set fix the poweroff sequence of the DSI display, but also expose the bug to post-power-up environment. When testing the DSI bus by turning the panel on and off, there's a 10 percent chance that error occurs when initializing the panel. I believe Clockworkpi has recognized this issue before the first batch of uConsole coming out, as there are big trunks of code disabled by preprocessor directives. Their solution is to only initialize the display once at boot. The panel driver is updated to properly deinitialize the panel, but that makes the bug having a chance to occur when the screen is unblanked(recover from idle black screen). In order to workaround it, the DSI bus error state is exposed through a sysfs node. On RPi3 series, it's `/sys/devices/platform/soc/3f700000.dsi/3f700000.dsi.0/dsi_state`. That is the `dsi_state` file in the panel node's folder. Read it and `ok\n` means no error and `error\n` means error occurred. Userspace programs can read this file and blank/unblank the screen when needed. There are different methods to blank/unblank the display under different circumstances. CLI/X11/Wayland all have different ways to do that, yet not interchangable. I really doubt if I should push this commit to the main branch though it's tested for months.
Description
We have a custom device using cm3+ that has a 4 lanes DSI panel. The panel is disabled when it enters in screen saving mode, and sometimes when it's enabled back (e.g. when touched) the log contains this:
Initially the screen remained blank but I added a workaround attempting to call to mipi_dsi_dcs_set_display_on several times (with a small delay between the calls) before giving up, hopefully this solves the issue for now.
System
cm3+
cat /etc/rpi-issue
)?Raspberry Pi reference 2021-01-11
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 21090519d85bdaa1615d5d5057d37b09368ea5d2, stage4
vcgencmd version
)?Feb 25 2021 12:12:09
Copyright (c) 2012 Broadcom
version 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) (release) (start)
uname -a
)?Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux
The text was updated successfully, but these errors were encountered: