Skip to content

Disabling dispmanx in the presence of vc4 driver #595

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

Closed
anholt opened this issue May 6, 2016 · 15 comments
Closed

Disabling dispmanx in the presence of vc4 driver #595

anholt opened this issue May 6, 2016 · 15 comments

Comments

@anholt
Copy link

anholt commented May 6, 2016

Working on DSI support, the current problem I think I'm facing is that VC is taking my DSI interrupts and clearing their status bits before ARM gets to see them. The DSI interrupt isn't being masked because the firmware only disables interrupt handling for a few previously-known vc4 DT nodes. Adding "mask_gpu_interrupt1=0x1000" means the board hangs at boot, presumably when it's trying to first turn on DSI.

Meanwhile, we have users trying to use tvservice to control graphics and breaking graphics, and the undervoltage warning trashing display lists. So, while the current interrupt-masking solution has served us well until now, I think we need a better solution to get vc4 ready to enable by default.

Ideally, to me, we'd still have the firmware setting up graphics at boot, and then once vc4 loads but before it sets a mode, we'd send a property request asking that dispmanx disable everything it's doing and refuse further requests. It would be nice if dispmanx could still leave the outputs running (since that means we can implement flicker-free boot eventually), but not required.

Does this seem feasible?

@popcornmix
Copy link
Contributor

There are a number of vchiq services which run on GPU. These do nothing on their own, but respond to vchiq messages from the arm.
It may make sense to avoid starting any service we believe is incompatible with the vc4-kms-v3d driver (rather than stopping them based on a message from arm).
I guess this includes tvservice, dispmanx and khronos.
It probably includes openmax and mmal which can call dispmanx (although avoiding the video_render component may be safe).
It may include cecservice and audio (alsa) service which can write to HDMI peripheral registers (although possibly not ones you are accessing).

We could leave the services enabled, but make dispmanx_display_open return DISPMANX_NO_HANDLE which may prevent the services from doing the obvious thing that breaks your driver (but there may be other things that are harmful).

For the DSI case, do you want the firmware to not touch DSI (including DSI clock) at all, or do you rely on some initialisation? We could remove accessing the DSI vcfw driver from the firmware in the vc4-kms-v3d case. I suspect that ignore_lcd=1 in config.txt will achieve this.

@anholt
Copy link
Author

anholt commented May 6, 2016

Right now I'm relying on the firmware bringing up DSI, but then that's partly because I can't fully control DSI yet because the firmware keeps stealing my interrupts :)

I do think that having the firmware bring up graphics first is good. It's really nice to have simplefb in the u-boot case, so that you've (probably) got dmesg visible even if boot fails somewhere in the middle before bringing up vc4.

If we don't have an easy way to tear down further DSI handling after boot, then ignore_lcd would be a workaround. I'm also definitely interested in the dispmanx ban, if it's as easy as it sounds.

@anholt
Copy link
Author

anholt commented May 6, 2016

As far as CEC, we should end up with support for it in 4.7 or 4.8, and I'll want to start poking the CEC registers at that point.

@popcornmix
Copy link
Contributor

popcornmix commented May 10, 2016

I've implemented a minimal fix where dispmanx_display_open returns DISPMANX_NO_HANDLE when vc3-kms-v3d is active. Also handles the warnings (which opened the display before config.txt was parsed). You can test here:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_vc4_2.zip

Over-temp/under-voltage warnings, the hello_pi GPU demos and omxplayer were tested and don't break the graphics driver. If they didn't use the display (e.g. hello_encode) then they should work correctly. If they did want to use the display that should fail (hopefully harmlessly).

EDIT: Updated to _2 version which also disallows tvservice power on/off calls.

@popcornmix
Copy link
Contributor

What about DSI? Do you want mask_gpu_interrupt1=0x1000 to be added when we parse config.txt and the overlay? That should occur after DSI initialisation, but should stop firmware subsequently reacting to interrupts.

How do I use DSI with your driver? I have the new commits from your active PR in kernel.

@anholt
Copy link
Author

anholt commented May 10, 2016

I don't have a merge of DSI to downstream ready yet (it sits on top of the DPI series, and is a horrible mess of debug at the moment). I've been thinking that I need to just finish up the panel's i2c bits to power on/off the atmel, and then cook up a merge to downstream so that people can have DSI limping along, even if it's not upstream yet and DSI transfers are broken.

I haven't tried mask_gpu_interrupt1 with ignore_lcd yet. I should do that when I get back home.

@anholt
Copy link
Author

anholt commented May 11, 2016

ignore_lcd=1 appears to get me my interrupt. I think with a bugfix in bcm2835-dma.c I should be able to do transfers like I hoped.

popcornmix added a commit that referenced this issue May 13, 2016
kernel: adau1977-adc: Add basic machine driver for adau1977 codec driver
See: raspberrypi/linux#1454

kernel: Allow up to 24dB digital gain to be applied when using IQAudIO DAC
See: raspberrypi/linux#1458

kernel: config: Add CONFIG_DRM_LOAD_EDID_FIRMWARE
See: raspberrypi/linux#1456

kernel: Rpi 4.4.y: HDMI hotplug detection, overlay cleanup
See: raspberrypi/linux#1457

kernel: BCM270X_DT: Add umbrella I2C Mux overlay i2c-mux
See: raspberrypi/linux#1465

kernel: BCM270X_DT: Fix the tinylcd35 overlay RTC support

firmware: ldconfig: Support filter based on gpio level
firmware: ldconfig: Allow specifying a overlay_prefix from config.txt
See: #593

firmware: dispmanx: Avoid dispmanx updates when running vc4-kms-v3d driver
See: #595

firmware: RIL Camera: Correct buffer size checking for RGB and BGR888
firmware: RIL video_encode: Add support for levels 4.1 and 4.2
firmware: IMX219: Add assert on failure to init
firmware: imx219: New VGA and full FOV 720p modes
firmware: imx219: Reorder modes to roughly match OV5647
firmware: imx219: Enable sensor DPC
See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=145815
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue May 13, 2016
kernel: adau1977-adc: Add basic machine driver for adau1977 codec driver
See: raspberrypi/linux#1454

kernel: Allow up to 24dB digital gain to be applied when using IQAudIO DAC
See: raspberrypi/linux#1458

kernel: config: Add CONFIG_DRM_LOAD_EDID_FIRMWARE
See: raspberrypi/linux#1456

kernel: Rpi 4.4.y: HDMI hotplug detection, overlay cleanup
See: raspberrypi/linux#1457

kernel: BCM270X_DT: Add umbrella I2C Mux overlay i2c-mux
See: raspberrypi/linux#1465

kernel: BCM270X_DT: Fix the tinylcd35 overlay RTC support

firmware: ldconfig: Support filter based on gpio level
firmware: ldconfig: Allow specifying a overlay_prefix from config.txt
See: raspberrypi/firmware#593

firmware: dispmanx: Avoid dispmanx updates when running vc4-kms-v3d driver
See: raspberrypi/firmware#595

firmware: RIL Camera: Correct buffer size checking for RGB and BGR888
firmware: RIL video_encode: Add support for levels 4.1 and 4.2
firmware: IMX219: Add assert on failure to init
firmware: imx219: New VGA and full FOV 720p modes
firmware: imx219: Reorder modes to roughly match OV5647
firmware: imx219: Enable sensor DPC
See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=145815
@popcornmix
Copy link
Contributor

popcornmix commented May 13, 2016

Latest rpi-update firmware should protect vc4-kms-drm driver from dispmanx and tvservice commands.

@Ruffio
Copy link

Ruffio commented Jun 29, 2016

@anholt has this issue been resolved with the latest firmware?

@Ruffio
Copy link

Ruffio commented Jul 24, 2016

@anholt resolved?

@Ruffio
Copy link

Ruffio commented Jul 29, 2016

@popcornmix please consider closing this issue as it looks like it has been fixed. Thanks.

@Ruffio
Copy link

Ruffio commented Aug 8, 2016

@anholt as it looks like this issue has been resolved, please close it. If not, please provide additional information. Thanks.

@anholt
Copy link
Author

anholt commented Aug 8, 2016

@Ruffio I'm still waiting on DSI resolution. The pull request for the no-power-management DSI driver is still open, and we're going to need more work on getting the firmware off of the display to implement power management.

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
kernel: adau1977-adc: Add basic machine driver for adau1977 codec driver
See: raspberrypi/linux#1454

kernel: Allow up to 24dB digital gain to be applied when using IQAudIO DAC
See: raspberrypi/linux#1458

kernel: config: Add CONFIG_DRM_LOAD_EDID_FIRMWARE
See: raspberrypi/linux#1456

kernel: Rpi 4.4.y: HDMI hotplug detection, overlay cleanup
See: raspberrypi/linux#1457

kernel: BCM270X_DT: Add umbrella I2C Mux overlay i2c-mux
See: raspberrypi/linux#1465

kernel: BCM270X_DT: Fix the tinylcd35 overlay RTC support

firmware: ldconfig: Support filter based on gpio level
firmware: ldconfig: Allow specifying a overlay_prefix from config.txt
See: raspberrypi#593

firmware: dispmanx: Avoid dispmanx updates when running vc4-kms-v3d driver
See: raspberrypi#595

firmware: RIL Camera: Correct buffer size checking for RGB and BGR888
firmware: RIL video_encode: Add support for levels 4.1 and 4.2
firmware: IMX219: Add assert on failure to init
firmware: imx219: New VGA and full FOV 720p modes
firmware: imx219: Reorder modes to roughly match OV5647
firmware: imx219: Enable sensor DPC
See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=145815
@dobegor
Copy link

dobegor commented Jul 25, 2017

@anholt Hi, sorry to bother you here, but could you please explain current status with VC4 driver and DSI port?
Can we now connect any random DSI screen to RPi?

@popcornmix
Copy link
Contributor

You are probably better off searching/posting on https://github.com/anholt/linux/issues/

I'll close this issue as it is resolved.

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

4 participants