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

Regression: no /dev/dri/renderD12* #3363

Closed
msisov opened this issue Dec 2, 2019 · 6 comments
Closed

Regression: no /dev/dri/renderD12* #3363

msisov opened this issue Dec 2, 2019 · 6 comments

Comments

@msisov
Copy link

msisov commented Dec 2, 2019

Hi,

I am using meta-raspberrypi yocto layer (warrior and thud branches) on my Raspberry Pi3 B+ that points to kernel v4.19 now. Since the time they've started to point to that version, I've noticed that there is no /dev/dri/renderD12* created that makes some client applications fail during startup (for example, Chromium with Ozone/Wayland support that relies on drm render nodes). In the kernel v4.14, /dev/dri/renderD12* was created and the client apps (including weston-simple-dmabuf-drm) worked fine.

I am also using vc4 graphics.

Here are some logs that may help to identify the problem:

Kernel v4.14 with working render nodes:

root@raspberrypi3:/# dmesg | grep drm
[ 2.810773] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[ 2.811031] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[ 2.811235] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[ 2.811846] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.812212] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.812709] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.834843] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[ 2.835890] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[ 2.835928] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.835953] [drm] Driver supports precise vblank timestamp query.
[ 2.962854] vc4-drm soc:gpu: fb0: frame buffer device

Kernel v4.19 where render nodes are not exposed:

root@raspberrypi3:~# dmesg | grep drm
[ 3.562379] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[ 3.562729] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[ 3.563205] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[ 3.563323] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[ 3.564111] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 3.564650] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 3.565317] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 3.587599] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[ 3.587656] fb: switching to vc4drmfb from simple
[ 3.590914] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[ 3.590937] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.590948] [drm] Driver supports precise vblank timestamp query.
[ 3.639631] vc4-drm soc:gpu: fb0: DRM emulated frame buffer device

You can refer to this guide to build with yocto and wayland for rpi3. Just be sure you use warrior or thud branches for all the layers mentioned.

@pelwell
Copy link
Contributor

pelwell commented Dec 2, 2019

We don't support Wayland or Yocto, or any non-Raspbian distribution. If you (or one of the maintainers of your preferred plaforms) can figure out what specific change has caused the issue then there is a chance we may be able to accommodate them, but any issue that requires us to rebuild unsupported software is unlikely to get any traction.

@6by9
Copy link
Contributor

6by9 commented Dec 2, 2019

I'd need to check background behind this, but I can hazard a guess at the reason.

DRM checks for the DRIVER_RENDER flag from the driver before creating the render nodes.
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/drm_drv.c#L528

Pi4 has separated 3D and rendering, so the RENDER flag gets removed under some conditions
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/vc4/vc4_drv.c#L287
That check is looking for the "brcm,bcm2835-v3d" compatible string, but should probably also be checking for "brcm,vc4-v3d" (and "brcm,cygnus-v3d") as well.
Downstream DT appears to use "brcm,vc4-v3d", so is probably disabling the nodes at the wrong point.

@msisov
Copy link
Author

msisov commented Dec 2, 2019

I'd need to check background behind this, but I can hazard a guess at the reason.

DRM checks for the DRIVER_RENDER flag from the driver before creating the render nodes.
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/drm_drv.c#L528

Pi4 has separated 3D and rendering, so the RENDER flag gets removed under some conditions
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/vc4/vc4_drv.c#L287
That check is looking for the "brcm,bcm2835-v3d" compatible string, but should probably also be checking for "brcm,vc4-v3d" (and "brcm,cygnus-v3d") as well.
Downstream DT appears to use "brcm,vc4-v3d", so is probably disabling the nodes at the wrong point.

Right, I've had the same feeling actually. In kernel v4.14, there wasn't such a remove condition. I'll try to recompile with those moments commented out and see if it fixes the issue.

@6by9
Copy link
Contributor

6by9 commented Dec 2, 2019

The patch on 5.4 (ie accepted by mainline) is different
https://github.com/raspberrypi/linux/blob/rpi-5.4.y/drivers/gpu/drm/vc4/vc4_drv.c#L266

	/* If VC4 V3D is missing, don't advertise render nodes. */
	node = of_find_matching_node_and_match(NULL, vc4_v3d_dt_match, NULL);
	if (!node || !of_device_is_available(node))
		vc4_drm_driver.driver_features &= ~DRIVER_RENDER;
	of_node_put(node);

So it handles the variants correctly. We ought to revert the 4.19 version and cherry-pick that one.
ffc2674

@6by9
Copy link
Contributor

6by9 commented Dec 2, 2019

PR #3365 pushed for review, but I'm still testing it.

schnitzeltony added a commit to schnitzeltony/meta-raspi-light that referenced this issue Dec 2, 2019
fixes plasma-wayland session see [1-2] - party party party

[1] raspberrypi/linux#3363
[2] raspberrypi/linux#3365

Signed-off-by: Andreas Müller <[email protected]>
@msisov
Copy link
Author

msisov commented Dec 3, 2019

Hi. Just verified and it worked as expected. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants