drm/vc4: Backport to 4.9 #1813
drm/vc4: Backport to 4.9 #1813
Conversation
|
Update is working on HDMI. i.e. any special config.txt settings or mods to overlays needed to enable? |
|
DSI just comes up with no extra config.txt. This is because I'm not using DSI transactions any more (never got them to work), so the firmware stealing our interrupt isn't a problem any more. TV-out won't be enabled by default by fbdev or X, because we have no load detection of TV (sigh) so we report unknown connector state. You may be able to bring up fbdev with kernel command line described in |
|
DSI is not coming up in my testing. Is this an issue with our hotplug detect on pi3? |
|
Here is what happens for me using this pull request (1813) with only DSI connected: |
|
The following information is from an RPi3B running Debian Sid ARM64 with HDMI and DSI connected. Xorg.0.log: dmesg: For what it's worth, I also tried adding in |
|
@ktb83 Wait, debian sid arm64? What defconfig did you use? Are you sure you built the panel driver? @popcornmix would need to see your dmesg/xorg log, too. |
|
@anholt Yes. bcmrpi3_defconfig. Sorry, I didn't realize that wasn't updated. So, I'm pretty sure that I didn't build the panel driver after looking at your commits and my .config. I've modified bcmrpi3_defconfig and I'm trying again. |
|
There's the problem: So what's going wrong with i2c-gpio? Does the pinmux for them show us still muxed to GPIO input/output, not the HW I2C controller? |
|
Re-pushed to fix up bcmrpi3_defconfig |
|
@anholt Thanks. My build just finished and put me in the same place Edit: BTW, I don't understand your question, but if I can provide any helpful command output (i2cdetect, raspi-gpio get), feel free to request it. |
|
@anhot: Thanks for fixing bcmrpi3_defconfig. I have a touchscreen, so I'll do a build an see what I can do to possibly help. |
|
Same issue here are well: |
|
Here is something interesting from the log: |
|
Yet another SD card died today, so I've swapped my main dev system from a pi2 with u-boot on the sd card to a pi3 network-booting without u-boot. This should make downstream dev a lot easier for me. In the process I reproduced the error, which was that we were using the wrong pins for I2C on pi3 and early pi1. Fixed now. |
|
Cool. I'm rebuilding your branch. |
|
OK, it works but the display is upside down. Also, I'm seeing some flickering in the display. I see the pins have been changed and I don't see the firmware error anymore. |
|
Oh, is it ignoring lcd_rotate=2? |
|
No. And the coordinates are backward compared to the firmware touchscreen input driver. |
|
Backward meaning upside down. I touch at the top and it thinks I touched the bottom. |
|
Also, I'm wondering if this is related to the flickering: |
|
Interesting. I see the flickering too. I have epilepsy (I'll be careful :) ) @Electron752 I don't notice a reversed/flipped image or reversed/flipped touch interface on my panel. That seems to be working correctly for me at least in LightDM+Xfce. I am using lcd_rotate=2. |
|
I'm also using LightDM+xfce. I tried adding lcd_rotate=2 and it didn't change anything. I know the display can be mounted in both directions so maybe I just have it mounted differently. I suspect something may be wrong with the vertical hold, but I really don't know. I'll leave that up to the experts. I just stopped in because I noticed the I2C issue and that's something I know about. Just thought I could help. I'm also looking for a fix for weird GPU Resets/Hangs and CMA issues. I was maybe hoping these got fixed. |
|
With no config.txt settings the LCD is upside down compared to firmware driver. If I add lcd_rotate=2 to config.txt then the orientation of firmware and kms driver matches (including touchscreen). I do see some sparkling orange pixels with the kms driver that aren't present in the firmware driver (visible with the default PIXEL "road" desktop wallpaper). |
|
config.txt is configuration for the firmware, not Linux, so the Linux driver has no idea what you put there. |
Of course - I think @popcornmix was just trying to establish a common frame of reference, i.e. which way is up. |
Indeed. But with blank config.txt the display is upside down compared to touchscreen. With I'm quite happy for |
Add the VEC (Video EnCoder) node definition in bcm283x.dtsi. Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Eric Anholt <[email protected]> (cherry picked from commit b899c45)
Enable the VEC IP on all RaspberryPi boards. Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Eric Anholt <[email protected]> (cherry picked from commit 5ab1a37)
Signed-off-by: Eric Anholt <[email protected]>
This makes debugging nicer, compared to trying to remember what the IDs are. Signed-off-by: Eric Anholt <[email protected]>
Trying to debug weston on fkms involved figuring out what calls I was making to the firmware. Signed-off-by: Eric Anholt <[email protected]>
In the rewrite of vc4_crtc.c for fkms, I dropped the part of the CRTC's atomic flush handler that moved the completion event from the proposed atomic state change to the CRTC's current state. That meant that when full screen pageflipping happened (glxgears -fullscreen in X, compton, por weston), the app would end up blocked firever waiting to draw its next frame. Signed-off-by: Eric Anholt <[email protected]>
The from_cache flag was actually "the BO is invisible to userspace", so we can repurpose to just zero out a cached BO and return it to userspace. Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by -1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that appeared to be other system noise) Note that there's an intel-gpu-tools test to check for the proper zeroing behavior here, which we continue to pass. Signed-off-by: Eric Anholt <[email protected]>
If a CMA allocation failed, the partially constructed BO would be unreferenced through the normal path, and we might choose to put it in the BO cache. If we then reused it before it expired from the cache, the kernel would OOPS. Signed-off-by: Eric Anholt <[email protected]> Fixes: c826a6e ("drm/vc4: Add a BO cache.")
I've seen lots of users cranking CMA up higher, so throw an error if they do. Signed-off-by: Eric Anholt <[email protected]>
|
Updated with the three commits I sent to 4.4.y, and rebased on current 4.9. Confirmed that without the branch compton fails in fkms, and with the branch it's fine. |
|
It works well for me. Same report as last time. Kodi 18 works well for me with this config: |
|
I think I've found the cause of the kernel panic/neverball crash. With fkms driver if HDMI cable is unplugged LCD display works fine. No dmesg complaints, neverball runs. Does that help reproduce? (I'm testing with latest version of this PR). |
|
All my tests have been performed with HDMI and DSI plugged in. However, the HDMI is connected through an HDMI switcher which is switched to a different input (Mac Mini) while using fkms. I'll see if I can reproduce what you're seeing with both DSI and HDMI actually connected. |
popcornmix
force-pushed
the
rpi-4.9.y
branch
from
75f6e5b to
bc589fd
Compare
|
I tested vc4-fkms-v3d two other ways with my setup.
I see no unusual complaints in dmesg in either scenario. Perhaps I need to set a debug flag/variable some place to see what you're seeing? I don't know what to think. |
|
For whatever it's worth, I have a simple fix for the weird spinning cursor display hang issue with KMS and FKMS. I was wondering if anybody would be interested in testing that as well. BTW, I don't really understand what is holding up this pull request. It is progress, perhaps it can be improved with additional requests? |
|
I'm wondering if these topics are related to this pull request? |
Lets see what @anholt says about the fkms with DSI display and HDMI attached issue. If it is hard to reproduce or tricky to fix then we can accept this PR and get the fix in a subsequent PR, but there is a risk of wasting users' time who run into the issue. |
|
@popcornmix Is your bug a regression in this PR, though? If it's not a regression, it would be really nice to get merged so that we can have it as a baseline (and avoid more rebases of the series). I may or may not get to testing for your bug today. |
|
No problem. A rebase was needed so I've merged the patches from your tree directly. |
See: raspberrypi/linux#1813 kernel: Revert clk-bcm2835: Mark used PLLs and dividers CRITICAL
See: raspberrypi/linux#1813 kernel: Revert clk-bcm2835: Mark used PLLs and dividers CRITICAL
|
@popcornmix the dmesg warn in drm_irq.c at boot is a race condition of DRM telling us that a vblank interrupt happened before vblank interrupts should have been enabled, which happens because we don't currently have a way to mask out the hacky interrupt we're using in fkms mode. neverball displays fine for me, though it doesn't process touches as input in its menus or mouse locations in any useful way in game. input shows up slightly weird (but fine afaict) in xev, and this doesn't seem vc4-related at all. |
|
@anholt are you running on DSI LCD using fkms driver with HDMI cable connected? |
|
Yes, that's what I was using. |
|
@ktb83 seemed to have a similar issue but only when going through a hdmi switch. My setup was using a DELL monitor connected through HDMI. The firmware does choose a CEA mode: Possibly something hotplug or edid related causes the issue? |
|
FYI, I am no longer able to reproduce any Neverball hanging issues on BRANCH=next rpi-update. |
Here's a giant backport for the 4.9 branch. vc4-kms-v3d is working on my DSI panel. TV out ought to work, but I haven't tested it.