-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
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. We could leave the services enabled, but make 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 |
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. |
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. |
I've implemented a minimal fix where dispmanx_display_open returns DISPMANX_NO_HANDLE when 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 |
What about DSI? Do you want How do I use DSI with your driver? I have the new commits from your active PR in kernel. |
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. |
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. |
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
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
Latest rpi-update firmware should protect vc4-kms-drm driver from dispmanx and tvservice commands. |
@anholt has this issue been resolved with the latest firmware? |
@anholt resolved? |
@popcornmix please consider closing this issue as it looks like it has been fixed. Thanks. |
@anholt as it looks like this issue has been resolved, please close it. If not, please provide additional information. Thanks. |
@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. |
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
@anholt Hi, sorry to bother you here, but could you please explain current status with VC4 driver and DSI port? |
You are probably better off searching/posting on https://github.com/anholt/linux/issues/ I'll close this issue as it is resolved. |
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?
The text was updated successfully, but these errors were encountered: