Adding support for the BeagleBone White DVI-D with audio cape


The current 3.8 rcn linux-dev is missing the devicetree spec for this cape ( This cape is based on the DVI-D rev A2 cape ( combined with the audio rev A cape ( Typically, capemgr says at boot:

bone-capemgr bone_capemgr.8: slot #0: Requesting firmware ‘BB-BONE-DVID-02-00A1.dtbo’ for board-name ‘BeagleBone DVI-D WITH AUDIO CAPE’, version ‘00A1’
bone-capemgr bone_capemgr.8: failed to load firmware ‘BB-BONE-DVID-02-00A1.dtbo’

The attached patch creates a new dts for this particular cape. It was tested as working for both DVI and audio out (ffmpeg -i file.mp3 -f alsa “default:EVM” -re -vol 50). However the HDMI cable has to be plugged in before the kernel boots, otherwise it says it defaults to 1024x768 (instead of the max resolution 1680x1050) and nothing is displayed. Does anyone have this problem with the DVI cape (with or without audio) has well? Also, is there a proper way to select the resolution? Typically, I’m looking to set 1280x720@60 at boot. TILCDC_DEFAULT_MAX_BANDWIDTH in drivers/gpu/drm/tilcdc/tilcdc_drv.h seems to be the only way to force the resolution (also see

0xyz-beaglebone-create-dvi-audio-cape-dts.patch (7.15 KB)

For the record, the DVI not turning on problem was caused by the excessive pruning of the video modes in tilcdc_crtc.c (see below); in addition when plugging the cable after the beagle had booted, drm_fb_helper.c would ignore any EDID and try to force 1024x768 or any lower resolution. The pruning is unnecessary, I’m not sure why it is done since any mode within the BB bandwidth works fine (the “reduced blanking mode” is not an issue at all). The attached patch fixes both problems and ensures a 1280x720@60 resolution at all times.

Another issue was with omaplfb_linux.c provided in SDK Compiling with PM_SUPPORT=1 FBDEV=yes is required however compilation fails as functions register_vsync_cb() and unregister_vsync_cb() are unknown. I commented the two if blocks and everything works fine after running /opt/gfxsdkdemos/335x-demo (testing with the raw demos provided in the SDK). It’s likely those two callbacks are not stricly needed, and will only allow synchronizing frame switching with the monitor’s vertical sync.

tilcdc-1280x720.patch (1.38 KB)

Please excuse me for this question, but I am new to this. This looks like the answer to my problem, but, new problem, what do I do with the patch? I haven’t found the bit of info that tells me how to deal with patches.