Skip to content
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

drm/vc4: Backport to 4.9 #1813

Closed
wants to merge 183 commits into from
Closed

drm/vc4: Backport to 4.9 #1813

wants to merge 183 commits into from

Conversation

@anholt
Copy link
Contributor

anholt commented Jan 23, 2017

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.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Jan 24, 2017

Update is working on HDMI.
What should I do to test DSI display?
What should I do to test composite display?

i.e. any special config.txt settings or mods to overlays needed to enable?

@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 24, 2017

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 Documentation/fb/modedb.txt but I've just tested with xrandr on X.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Jan 24, 2017

DSI is not coming up in my testing.
If I boot with DSI LCD and HDMI connected I see the firmware rainbow splash screen on LCD. It blanks and I see boot console text appear on HDMI.
If I unplug HDMI first, I see the firmware rainbow splash screen on LCD. It blanks and I see no more. If I reattach hdmi later I see the console (but at a lower resolution).

Is this an issue with our hotplug detect on pi3?

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Jan 24, 2017

Here is what happens for me using this pull request (1813) with only DSI connected:

[    19.170] (II) glamor: EGL version 1.4 (DRI2):
[    19.228] (II) modeset(0): glamor initialized
[    19.230] (II) modeset(0): Output HDMI-1 has no monitor section
[    19.230] (II) modeset(0): Output Composite-1 has no monitor section
[    19.230] (II) modeset(0): Output DSI-1 has no monitor section
[    19.231] (II) modeset(0): EDID for output HDMI-1
[    19.231] (II) modeset(0): EDID for output Composite-1
[    19.232] (II) modeset(0): Printing probed modes for output Composite-1
[    19.232] (II) modeset(0): Modeline "720x480"x31.3   13.50  720 734 798 858  480 483 486 502 interlace (15.7 kHz e)
[    19.232] (II) modeset(0): EDID for output DSI-1
[    19.232] (II) modeset(0): Output HDMI-1 disconnected
[    19.232] (II) modeset(0): Output Composite-1 disconnected
[    19.232] (II) modeset(0): Output DSI-1 disconnected
[    19.232] (WW) modeset(0): No outputs definitely connected, trying again...
[    19.232] (II) modeset(0): Output HDMI-1 disconnected
[    19.232] (II) modeset(0): Output Composite-1 connected
[    19.232] (II) modeset(0): Output DSI-1 disconnected
[    19.232] (II) modeset(0): Using sloppy heuristic for initial modes
[    19.232] (II) modeset(0): Output Composite-1 using initial mode 720x480 +0+0
[    19.232] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[    19.232] (==) modeset(0): DPI set to (96, 96)
[    19.232] (II) Loading sub module "fb"
[    19.232] (II) LoadModule: "fb"
[    19.232] (II) Loading /usr/lib/xorg/modules/libfb.so
[    19.243] (II) Module fb: vendor="X.Org Foundation"
@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 24, 2017

@ktb83 it sounds like the panel driver isn't getting loaded. Is it in lsmod? Attach dmesg? babb24f should have caused the driver to get loaded, though I'm wondering how this works without 4c4d16a from the downstream tree.

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Jan 25, 2017

The following information is from an RPi3B running Debian Sid ARM64 with HDMI and DSI connected.

$ lsmod
Module                  Size  Used by
rfcomm                 53248  2
cmac                   16384  1
bnep                   24576  2
hci_uart               32768  1
btbcm                  16384  1 hci_uart
bluetooth             397312  29 hci_uart,bnep,btbcm,rfcomm
brcmfmac              262144  0
vc4                   163840  2
drm_kms_helper        196608  2 vc4
evdev                  24576  4
brcmutil               20480  1 brcmfmac
joydev                 20480  0
drm                   442368  5 vc4,drm_kms_helper
cfg80211              651264  1 brcmfmac
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
rfkill                 32768  5 bluetooth,cfg80211
i2c_gpio               16384  0
i2c_algo_bit           16384  1 i2c_gpio
i2c_bcm2835            16384  0
spi_bcm2835            20480  0
rpi_ft5406             16384  0
uio_pdrv_genirq        16384  0
rpi_backlight          16384  0
uio                    24576  1 uio_pdrv_genirq
i2c_dev                20480  0
ip_tables              32768  0
x_tables               45056  1 ip_tables

Xorg.0.log:
rpi3_arm64_DSI-HDMI_rpf4.9-pr1813_xorg0log.txt

dmesg:
rpi3_arm64_DSI-HDMI_rpf4.9-pr1813_dmesg.txt

For what it's worth, I also tried adding in EXPORT_SYMBOL(of_device_uevent_modalias); to drivers/of/device.c without any further success.

@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 25, 2017

@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.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Jan 25, 2017

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Jan 25, 2017

@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.

@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 25, 2017

There's the problem:

raspberrypi-touchscreen 3f700000.dsi.0: Unknown Atmel firmware revision: 0x00

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?

@anholt anholt force-pushed the anholt:rpi-4.9.y branch from 499351f to c3e2cca Jan 25, 2017
@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 25, 2017

Re-pushed to fix up bcmrpi3_defconfig

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Jan 25, 2017

@anholt Thanks. My build just finished and put me in the same place [ 4.360259] raspberrypi-touchscreen 3f700000.dsi.0: Unknown Atmel firmware revision: 0x00

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.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

@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.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

Same issue here are well:
i2c-gpio soc:i2cdsi: using pins 28 (SDA) and 29 (SCL)
raspberrypi-touchscreen 3f700000.dsi.0: Unknown Atmel firmware revision: 0x00

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

Here is something interesting from the log:
/sys/kernel/debug/pinctrl/3f200000.gpio# cat pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (gpio0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 1 (gpio1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 2 (gpio2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 3 (gpio3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 4 (gpio4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 5 (gpio5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 6 (gpio6): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 7 (gpio7): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 8 (gpio8): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 9 (gpio9): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 10 (gpio10): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 11 (gpio11): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 12 (gpio12): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 13 (gpio13): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 14 (gpio14): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 15 (gpio15): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 16 (gpio16): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 17 (gpio17): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 18 (gpio18): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 19 (gpio19): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 20 (gpio20): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 21 (gpio21): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 22 (gpio22): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 23 (gpio23): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 24 (gpio24): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 25 (gpio25): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 26 (gpio26): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 27 (gpio27): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 28 (gpio28): (MUX UNCLAIMED) pinctrl-bcm2835:28
pin 29 (gpio29): (MUX UNCLAIMED) pinctrl-bcm2835:29

pin 30 (gpio30): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 31 (gpio31): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 32 (gpio32): 3f201000.serial (GPIO UNCLAIMED) function alt3 group gpio32
pin 33 (gpio33): 3f201000.serial (GPIO UNCLAIMED) function alt3 group gpio33
pin 34 (gpio34): 3f300000.mmc (GPIO UNCLAIMED) function alt3 group gpio34
pin 35 (gpio35): 3f300000.mmc (GPIO UNCLAIMED) function alt3 group gpio35
pin 36 (gpio36): 3f300000.mmc (GPIO UNCLAIMED) function alt3 group gpio36
pin 37 (gpio37): 3f300000.mmc (GPIO UNCLAIMED) function alt3 group gpio37
pin 38 (gpio38): 3f300000.mmc (GPIO UNCLAIMED) function alt3 group gpio38
pin 39 (gpio39): 3f300000.mmc (GPIO UNCLAIMED) function alt3 group gpio39
pin 40 (gpio40): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 41 (gpio41): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 42 (gpio42): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 43 (gpio43): 3f201000.serial (GPIO UNCLAIMED) function alt0 group gpio43
pin 44 (gpio44): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 45 (gpio45): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 46 (gpio46): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 47 (gpio47): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 48 (gpio48): 3f202000.sdhost (GPIO UNCLAIMED) function alt0 group gpio48
pin 49 (gpio49): 3f202000.sdhost (GPIO UNCLAIMED) function alt0 group gpio49
pin 50 (gpio50): 3f202000.sdhost (GPIO UNCLAIMED) function alt0 group gpio50
pin 51 (gpio51): 3f202000.sdhost (GPIO UNCLAIMED) function alt0 group gpio51
pin 52 (gpio52): 3f202000.sdhost (GPIO UNCLAIMED) function alt0 group gpio52
pin 53 (gpio53): 3f202000.sdhost (GPIO UNCLAIMED) function alt0 group gpio53

@anholt anholt force-pushed the anholt:rpi-4.9.y branch from c3e2cca to d61d1e9 Jan 26, 2017
@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 26, 2017

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.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

Cool. I'm rebuilding your branch.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

OK, it works but the display is upside down. Also, I'm seeing some flickering in the display.
Any idea what that could be?

I see the pins have been changed and I don't see the firmware error anymore.
i2c-gpio soc:i2cdsi: using pins 44 (SDA) and 45 (SCL)

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Jan 26, 2017

Oh, is it ignoring lcd_rotate=2?

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

No.

And the coordinates are backward compared to the firmware touchscreen input driver.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

Backward meaning upside down. I touch at the top and it thinks I touched the bottom.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

Also, I'm wondering if this is related to the flickering:
[ 3.389870] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.389928] [drm] Driver supports precise vblank timestamp query.

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Jan 26, 2017

Interesting. I see the flickering too. I have epilepsy (I'll be careful :) )
The antialiasing is rough (non-existent?) in general, but it seems to be working OK for me.

@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.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Jan 26, 2017

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.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Jan 26, 2017

With no config.txt settings the LCD is upside down compared to firmware driver.
However the touchscreen is not oriented the same as screen (it matches firmware orientation).

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).

@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Jan 26, 2017

config.txt is configuration for the firmware, not Linux, so the Linux driver has no idea what you put there.

@pelwell

This comment has been minimized.

Copy link
Contributor

pelwell commented Jan 26, 2017

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.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Jan 26, 2017

config.txt is configuration for the firmware, not Linux, so the Linux driver has no idea what you put there

Indeed. But with blank config.txt the display is upside down compared to touchscreen. With lcd_rotate=2 the two are aligned which suggests some of the firmware setup is persisting.

I'm quite happy for lcd_rotate to be unsupported with the kms driver, but it appears necessary at the moment to get a consistent orientation of display and touchscreen.

Boris Brezillon and others added 9 commits Dec 2, 2016
Add the VEC (Video EnCoder) node definition in bcm283x.dtsi.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit b899c45)
Enable the VEC IP on all RaspberryPi boards.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 5ab1a37)
Signed-off-by: Eric Anholt <eric@anholt.net>
This makes debugging nicer, compared to trying to remember what the
IDs are.

Signed-off-by: Eric Anholt <eric@anholt.net>
Trying to debug weston on fkms involved figuring out what calls I was
making to the firmware.

Signed-off-by: Eric Anholt <eric@anholt.net>
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 <eric@anholt.net>
I've seen lots of users cranking CMA up higher, so throw an error if
they do.

Signed-off-by: Eric Anholt <eric@anholt.net>
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 <eric@anholt.net>
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 <eric@anholt.net>
Fixes: c826a6e ("drm/vc4: Add a BO cache.")
@anholt anholt force-pushed the anholt:rpi-4.9.y branch from e8b376d to 384a15d Feb 9, 2017
@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Feb 9, 2017

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.

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Feb 9, 2017

It works well for me. Same report as last time.

Kodi 18 works well for me with this config:
raspbian_arm_rpi3_rpi-4.9.y-pr1813_vc4-fkms-v3d_kodi_config.txt

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Feb 10, 2017

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.
With fkms driver if HDMI cable is plugged in LCD display works fine for desktop. HDMI is blank as expected. But we get the dmesg complaints and neverball crashes on starting.

Does that help reproduce?

(I'm testing with latest version of this PR).

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Feb 10, 2017

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 popcornmix force-pushed the raspberrypi:rpi-4.9.y branch from 75f6e5b to bc589fd Feb 10, 2017
@ktb83

This comment has been minimized.

Copy link

ktb83 commented Feb 10, 2017

I tested vc4-fkms-v3d two other ways with my setup.

  1. DSI connected, HDMI connected through HDMI switcher (RadioShack 2-In/1-Out Mechanical HDMI Selector Switch) to a Samsung LCD TV (LN22B460B2DXZA, HDMI 1.3) and Pi input selected on the HDMI switcher. This leads to some interesting Neverball behavior in that the intro Neverball screen loads but I'm unable to click or select any of the buttons in the neverball GUI by mouse or keyboard. Neverball is completely unresponsive and requires killing it.

  2. DSI connected, HDMI directly connected to the Samsung LCD TV. My experience in this situation is that Neverball works perfectly well for me. I don't experience any issues just like when I only have DSI actually connected.

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.

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Feb 11, 2017

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.

#1840

BTW, I don't really understand what is holding up this pull request. It is progress, perhaps it can be improved with additional requests?

@Electron752

This comment has been minimized.

Copy link
Contributor

Electron752 commented Feb 12, 2017

I'm wondering if these topics are related to this pull request?

raspberrypi/userland#375
#1840
#1843

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Feb 13, 2017

BTW, I don't really understand what is holding up this pull request. It is progress, perhaps it can be improved with additional requests?

Lets see what @anholt says about the fkms with DSI display and HDMI attached issue.
If it is something he can reproduce and resolve quickly we'll wait for the fix before merging.

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.

@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Feb 13, 2017

@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.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Feb 14, 2017

No problem. A rebase was needed so I've merged the patches from your tree directly.
I'll push out a BRANCH=next rpi-update kernel later today for testing.

@popcornmix popcornmix closed this Feb 14, 2017
popcornmix added a commit to raspberrypi/firmware that referenced this pull request Feb 14, 2017
See: raspberrypi/linux#1813

kernel: Revert clk-bcm2835: Mark used PLLs and dividers CRITICAL
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this pull request Feb 14, 2017
See: raspberrypi/linux#1813

kernel: Revert clk-bcm2835: Mark used PLLs and dividers CRITICAL
@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Feb 14, 2017

@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.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Feb 14, 2017

@anholt are you running on DSI LCD using fkms driver with HDMI cable connected?
That was the setup that caused neverball to hang after a few seconds of running.
It works fine without that combination.

@anholt

This comment has been minimized.

Copy link
Contributor Author

anholt commented Feb 14, 2017

Yes, that's what I was using.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

popcornmix commented Feb 15, 2017

@ktb83 seemed to have a similar issue but only when going through a hdmi switch.
I'm not quite sure what a mechanical HDMI switch would actually change - I would have thought it would look just like a direct connection, but maybe it alters hotplug or (less likely) edid behaviour.

My setup was using a DELL monitor connected through HDMI. The firmware does choose a CEA mode:

pi@domnfs:~ $ tvservice  -s
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive

Possibly something hotplug or edid related causes the issue?

@ktb83

This comment has been minimized.

Copy link

ktb83 commented Feb 15, 2017

FYI, I am no longer able to reproduce any Neverball hanging issues on BRANCH=next rpi-update.

rpi3_rpi-4.9.y_vc4-fkms-v3d_2017-02-15_test-notes.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.