Disabling dispmanx in the presence of vc4 driver

[anholt]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Ruffio]

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

[Ruffio]

@anholt resolved?

[Ruffio]

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

[Ruffio]

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

[anholt]

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

[dobegor]

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

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

I'll close this issue as it is resolved.