Weston on Colibri iMX7D: failed to create kms fb: Invalid argument on TorizonCore 6.8.9

Coders · September 5, 2026, 5:33am

Hello Torizon Community,

I am using a Toradex Colibri iMX7D 1GB (eMMC) on a Colibri Evaluation Board V3 with the following Torizon OS configuration:

Torizon OS:

TorizonCore Upstream

Version: 6.8.9-build.46

Kernel: 6.1.176-6.8.9+git.fdb6fcb41cc7 #1-TorizonCore

Architecture: armv7l
Hardware: Colibri iMX7D 1GB (eMMC)
Toradex version: 0039 V1.1B

I am running Weston inside Docker using the following docker-compose.yml:

services:
  tailscale:
    image: tailscale/tailscale:latest
    container_name: tailscale
    network_mode: host
    restart: always
    cap_add:
      - NET_ADMIN
      - NET_RAW
    volumes:
      - /var/lib/tailscale:/var/lib/tailscale
    environment:
      - TS_STATE_DIR=/var/lib/tailscale
      - TS_USERSPACE=false

  weston:
    image: torizon/weston:4
    restart: always
    privileged: true
    network_mode: host
    ipc: host

    environment:
      - ENABLE_RDP=1

    volumes:
      - /tmp:/tmp
      - /dev:/dev
      - /run/udev:/run/udev
      - /home/torizon/custom:/etc/xdg/weston-dev/
      - /home/torizon/custom/Loading.png:/home/torizon/custom/Loading.png

    cap_add:
      - CAP_SYS_TTY_CONFIG

    device_cgroup_rules:
      - 'c 4:* rmw'
      - 'c 13:* rmw'
      - 'c 226:* rmw'
      - 'c 10:223 rmw'

  app:
    image: intersense123/octo:1.2
    privileged: true
    restart: always
    depends_on:
      - weston

    environment:
      - QT_QPA_PLATFORM=wayland
      - WAYLAND_DISPLAY=wayland-0
      - XDG_RUNTIME_DIR=/tmp/1000-runtime-dir

    volumes:
      - /tmp:/tmp
      - /dev:/dev
      - /run/udev:/run/udev
      - /var/rootdirs/media:/media:rshared
      - /sys:/sys
      - /etc/machine-id:/etc/machine-id:ro
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - /var/run/systemd:/var/run/systemd
      - /usr/bin/systemctl:/usr/bin/systemctl:ro
      - /run/dbus:/run/dbus
      - /home/torizon/docker-compose.yml:/home/torizon/docker-compose.yml
      - /home/torizon/Precigo:/home/torizon/app/data

    devices:
      - /dev/ttymxc0
      - /dev/rtc0
      - /dev/rtc1

    cap_add:
      - SYS_TIME
      - NET_ADMIN
      - SYS_BOOT

    device_cgroup_rules:
      - 'c 13:* rmw'

    network_mode: host

Problem

The important point is that the exact same Docker Compose configuration works correctly on another identical Colibri iMX7D unit.

However, on this particular device, Weston continuously reports:

failed to create kms fb: Invalid argument
weston | [05:19:13.617] failed to get drm_fb for bo
weston | [05:19:14.420] failed to create kms fb: Invalid argument
weston | [05:19:14.420] failed to get drm_fb for bo
weston | [05:19:14.723] failed to create kms fb: Invalid argument
weston | [05:19:14.723] failed to get drm_fb for bo
weston | [05:19:15.008] failed to create kms fb: Invalid argument
weston | [05:19:15.009] failed to get drm_fb for bo
weston | [05:19:15.307] failed to create kms fb: Invalid argument
weston | [05:19:15.323] failed to get drm_fb for bo
weston | [05:19:15.732] failed to create kms fb: Invalid argument
weston | [05:19:15.735] failed to get drm_fb for bo

The error repeats continuously.

What I have already verified

The Docker Compose file is the same on both devices.
The Weston Docker image is the same:
torizon/weston:4
The hardware model is the same:
Colibri iMX7D 1GB (eMMC)
The application container works on the other unit with the same configuration.
The problem appears to be specific to this particular device.

My questions

Could this error be caused by:

A difference in the DRM/KMS device state?
A difference in the display/HDMI configuration?
A kernel or device-tree difference?
A corrupted or incorrect framebuffer/DRM configuration?
A difference in /dev/dri devices or permissions?
A Weston configuration issue?
A GPU/Vivante driver issue?
Some persistent state/configuration on this particular Torizon device?

Since the same docker-compose.yml works on another identical unit, I suspect there may be a difference at the OS, kernel, device-tree, DRM/KMS, or hardware level.

Could someone please suggest which commands I should run to compare the working and non-working devices and identify the root cause?

In particular, I would appreciate commands to check:

/dev/dri
DRM/KMS devices
kernel DRM messages
GPU/Vivante driver
device tree
Weston configuration
display/HDMI detection

Any guidance on how to diagnose the failed to create kms fb: Invalid argument error on this Colibri iMX7D would be greatly appreciated.

Thank you.

ToradexAI · September 5, 2026, 5:34am

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Thank you for the detailed description of your issue. The “failed to create kms fb: Invalid argument” error on one Colibri iMX7D while an identical unit works suggests a device-specific configuration or hardware state difference.

Diagnostic Commands

To identify the root cause, run these commands on both the working and non-working devices and compare the outputs:

Check DRM/KMS Devices and Status

# List DRM devices
ls -la /dev/dri/

# Check DRM device information
cat /sys/kernel/debug/dri/0/name

# View kernel DRM messages
dmesg | grep -i drm
dmesg | grep -i etnaviv
dmesg | grep -i display

Check Display Detection

# Find connected displays
find /sys/devices -name "edid"

# Check display controller status
cat /sys/class/drm/card*/status
```[(1)](https://developer.toradex.com/torizon/application-development/use-cases/multimedia/setting-up-displays-with-torizon)

### Verify Device Tree Overlays

Since TorizonCore 6.x uses device tree overlays for display configuration, check if the overlays are consistently applied:

```bash
# Check enabled overlays
cat /boot/overlays.txt

# Verify loaded device tree
ls /proc/device-tree/

For Colibri iMX7, the parallel RGB interface should be enabled by default(1)

Check Framebuffer and Display Mode

# Check available framebuffer devices
ls -la /dev/fb*

# View current display mode (if modetest is available)
modetest -M etnaviv
```[(2)](https://developer.toradex.com/linux-bsp/application-development/multimedia/display-output-resolution-and-timings-linux)

### Compare Weston Logs in Detail

```bash
# Get full Weston logs with more detail
docker logs weston 2>&1 | head -100

# Check Weston info from inside container
docker exec weston weston-info
```[(3)](https://developer.toradex.com/torizon/application-development/use-cases/gui/working-with-weston-on-torizoncore)

## Potential Causes

Based on the documentation, the issue could stem from:

1. **Display Connection Difference**: The non-working device may have a different display connected or no display connected, causing KMS framebuffer creation to fail

2. **Device Tree Overlay Mismatch**: Different overlay configurations between devices[(1)](https://developer.toradex.com/torizon/application-development/use-cases/multimedia/setting-up-displays-with-torizon)

3. **DRM Device State**: The etnaviv DRM driver may be in a different state

4. **Hardware Detection**: The display interface may not be properly detected on boot

## Recommended Actions

1. **Verify identical hardware setup**: Ensure both devices have the same display connected to the same port

2. **Compare `/boot/overlays.txt`**: Ensure both devices have identical overlay configurations

3. **Check kernel messages**: Look for any etnaviv or DRM initialization errors in `dmesg` output

4. **Reboot test**: Try a clean reboot of the non-working device to reset the DRM/KMS state

5. **Test without custom Weston config**: Temporarily remove the custom weston configuration mount to rule out configuration issues:
   ```yaml
   # Comment out this line temporarily
   # - /home/torizon/custom:/etc/xdg/weston-dev/

Please share the output of the diagnostic commands from both devices, particularly the dmesg | grep -i drm and ls -la /dev/dri/ outputs, so we can better identify the specific difference causing this issue.

Best regards,
Toradex AI Assistant

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Coders · September 5, 2026, 6:56am

torizon@colibri-imx7-emmc-08945937:~$ sudo cat /sys/kernel/debug/dri/0/name
Password:
mxsfb-drm dev=30730000.lcdif unique=30730000.lcdif
torizon@colibri-imx7-emmc-08945937:~$ dmesg | grep -i drm
[ 1.711819] [drm] Initialized mxsfb-drm 1.0.0 20160824 for 30730000.lcdif on minor 0
[ 1.714220] mxsfb 30730000.lcdif: [drm] fb0: mxsfb-drmdrmfb frame buffer device
[ 4.853877] systemd[1]: Starting Load Kernel Module drm…
[ 5.035786] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 5.037611] systemd[1]: Finished Load Kernel Module drm.
torizon@colibri-imx7-emmc-08945937:~$ dmesg | grep -i etnaviv
torizon@colibri-imx7-emmc-08945937:~$ dmesg | grep -i display
torizon@colibri-imx7-emmc-08945937:~$ find /sys/devices -name “edid”
/sys/devices/platform/soc/30400000.bus/30730000.lcdif/drm/card0/card0-DPI-1/edid
torizon@colibri-imx7-emmc-08945937:~$ cat /sys/class/drm/card*/status
connected
torizon@colibri-imx7-emmc-08945937:~$ ls /proc/device-tree/
‘#address-cells’ chosen cpus opp-table regulator-module-3v3 serial-number toradex,product-id
‘#size-cells’ clk16m gpio-keys panel-dpi regulator-module-3v3-avdd soc usbc-det
symbols clock-cki memory@80000000 pmu regulator-module-3v3-eth sound usbphynop1
aliases clock-osc model regulator-3v3 regulator-usbh-vbus timer usbphynop2
backlight compatible name regulator-5v0 replicator toradex,board-rev usbphynop3
torizon@colibri-imx7-emmc-08945937:~$ ls -la /dev/fb*
crw-rw---- 1 root video 29, 0 Sep 5 04:07 /dev/fb0
torizon@colibri-imx7-emmc-08945937:~$ modetest -M etnaviv
-sh: modetest: command not found
torizon@colibri-imx7-emmc-08945937:~$ docker logs weston 2>&1 | head -100
Switching VT tty7 to text mode if currently in graphics mode
Switching VT mode of /dev/tty7 to text
Switching to VT 7
SoC is: ‘i.MX7D’
SoC has GPU: false
SoC has DPU: false
SoC has PXP: true
Removing previously created ‘.X*-lock’ entries under /tmp before starting Weston. Pass ‘IGNORE_X_LOCKS=1’ environment variable to Weston container to disable this behavior.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format…
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format…
00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.002 [INFO] [seatd/seatd.c:194] seatd started
Date: 2026-09-05 UTC
[06:45:45.822] weston 10.0.1
https://wayland.freedesktop.org
Bug reports to: Making sure you're not a bot!
Build: 10.0.1
[06:45:45.824] Command line: weston -Bdrm-backend.so -Swayland-0
[06:45:45.825] OS: Linux, 6.1.176-6.8.9+git.fdb6fcb41cc7, #1-TorizonCore SMP Thu Feb 27 10:29:52 UTC 2025, armv7l
[06:45:45.827] Flight recorder: enabled
[06:45:45.830] Using config file ‘/etc/xdg/weston/weston.ini’
[06:45:45.831] Output repaint window is 7 ms maximum.
[06:45:45.834] Loading module ‘/usr/lib/arm-linux-gnueabihf/libweston-10/drm-backend.so’
[06:45:45.853] initializing drm backend
[06:45:45.855] Trying libseat launcher…
00:00:00.119 [INFO] [seatd/server.c:145] New client connected (pid: 31, uid: 1000, gid: 1000)
00:00:00.122 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.123 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[06:45:45.861] libseat: session control granted
[06:45:45.870] using /dev/dri/card0
[06:45:45.872] DRM: supports atomic modesetting
[06:45:45.873] DRM: supports GBM modifiers
[06:45:45.874] DRM: supports picture aspect ratio
[06:45:45.875] Loading module ‘/usr/lib/arm-linux-gnueabihf/libweston-10/gl-renderer.so’
[06:45:47.328] EGL client extensions: EGL_EXT_device_base
EGL_EXT_device_enumeration EGL_EXT_device_query
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device
EGL_EXT_platform_wayland EGL_KHR_platform_wayland
EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_EXT_platform_xcb
EGL_MESA_platform_gbm EGL_KHR_platform_gbm
EGL_MESA_platform_surfaceless
[06:45:47.336] EGL device extensions: EGL_MESA_device_software
EGL_EXT_device_drm_render_node
[06:45:47.337] failed to query DRM device from EGL
[06:45:47.337] EGL version: 1.4
[06:45:47.337] EGL vendor: Mesa Project
[06:45:47.337] EGL client APIs: OpenGL OpenGL_ES
[06:45:47.337] EGL extensions: EGL_ANDROID_blob_cache EGL_EXT_buffer_age
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2
EGL_KHR_config_attribs EGL_KHR_context_flush_control
EGL_KHR_create_context EGL_KHR_create_context_no_error
EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses
EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image
EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image
EGL_KHR_gl_texture_cubemap_image EGL_KHR_image
EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context
EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
[06:45:47.338] warning: Disabling render GPU timeline and explicit synchronization due to missing EGL_ANDROID_native_fence_sync extension
[06:45:47.338] EGL_KHR_surfaceless_context available
[06:45:47.404] GL version: OpenGL ES 3.2 Mesa 22.3.6
[06:45:47.404] GLSL version: OpenGL ES GLSL ES 3.20
[06:45:47.404] GL vendor: Mesa/X.org
[06:45:47.404] GL renderer: llvmpipe (LLVM 15.0.6, 128 bits)
[06:45:47.408] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA8888
GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float
GL_OES_texture_float_linear GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_EXT_draw_instanced
GL_EXT_texture_sRGB_decode GL_OES_EGL_image
GL_OES_depth_texture GL_OES_packed_depth_stencil
GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render
GL_OES_get_program_binary GL_APPLE_texture_max_level
GL_EXT_discard_framebuffer GL_EXT_read_format_bgra
GL_NV_pack_subimage GL_EXT_frag_depth
GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_OES_viewport_array GL_ANGLE_pack_reverse_row_order
GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5
GL_EXT_occlusion_query_boolean GL_EXT_robustness
GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers
GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil
GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range
GL_KHR_debug GL_KHR_robustness
GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object
GL_OES_depth_texture_cube_map GL_OES_required_internalformat
GL_OES_surfaceless_context GL_EXT_color_buffer_float
GL_EXT_debug_label GL_EXT_sRGB_write_control
GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch
torizon@colibri-imx7-emmc-08945937:~$ ls /boot/ostree/
torizon-7b625afd0e2e2d5086598576ecf43df8fd0462b0ac113e65f7cf96074f6724a1 torizon-a68be9d93cecf6d15dc54f8c96c00faca3d3239ed4aa2451c4eda7e937c745b1
torizon@colibri-imx7-emmc-08945937:~$ cat /boot/ostree/torizon-7b625afd0e2e2d5086598576ecf43df8fd0462b0ac113e65f7cf96074f6724a1/dtb/overlays.txt
fdt_overlays=colibri-imx7_panel-res-touch-7inch_overlay.dtbo
torizon@colibri-imx7-emmc-08945937:~$ cat /boot/ostree/torizon-a68be9d93cecf6d15dc54f8c96c00faca3d3239ed4aa2451c4eda7e937c745b1/dtb/overlays.txt
fdt_overlays=colibri-imx7_panel-res-touch-7inch_overlay.dtbo
torizon@colibri-imx7-emmc-08945937:~$
i checked all commands ,executed output i also compare wih running device with same commands thats not get any major change so why its only happen with this device can u suggest some ideas to solve this issue @ToradexAI

ToradexAI · September 5, 2026, 6:56am

Thank you for providing the diagnostic output. The logs show that your system is detecting the display correctly and the DRM subsystem is initializing properly. However, I notice a critical clue in the Weston logs:

Key Finding

The Weston log shows:

[06:45:47.404] GL renderer: llvmpipe (LLVM 15.0.6, 128 bits)

This indicates Weston is using software rendering (llvmpipe) instead of hardware acceleration. On the Colibri iMX7D, this is expected since the SoC doesn’t have a GPU, but it uses the PXP (Pixel Pipeline) for 2D acceleration(1).

The “failed to create kms fb: Invalid argument” error typically occurs when there’s a mismatch between the framebuffer format that Weston is trying to create and what the DRM driver supports.

Diagnostic Steps

Since you mentioned the identical configuration works on another device, let’s check for subtle differences:

1. Compare Kernel Boot Arguments

cat /proc/cmdline

Compare this between the working and non-working devices.

2. Check DRM Capabilities

# Check available formats on the DRM device
cat /sys/kernel/debug/dri/0/state

# Check connector details
cat /sys/class/drm/card0-DPI-1/modes

3. Verify Display Timing

Since you’re using the resistive touch 7" display overlay (colibri-imx7_panel-res-touch-7inch_overlay.dtbo)(2), verify the display is physically connected and powered correctly.

4. Check for Hardware Differences

# Compare the exact hardware revision
cat /proc/device-tree/toradex,board-rev
cat /proc/device-tree/toradex,product-id

# Check if there are any hardware-related kernel messages
dmesg | grep -i "lcdif\|panel\|mxsfb"

Potential Solutions

Solution 1: Force Pixel Format in Weston Configuration

The issue might be related to the pixel format Weston is trying to use. Create a custom weston.ini to force a specific format:

In your /home/torizon/custom/weston.ini, add or modify:

[core]
gbm-format=xrgb8888

[output]
name=DPI-1
mode=800x480

This forces Weston to use a specific pixel format that should be compatible with the mxsfb driver(1).

Solution 2: Remove Privileged Mode

Your docker-compose has privileged: true for the Weston container, which isn’t necessary and might cause permission conflicts. Try using the recommended device access approach instead:

weston:
  image: torizon/weston:4
  restart: always
  # Remove: privileged: true
  network_mode: host
  
  environment:
    - ENABLE_RDP=1

  volumes:
    - /tmp:/tmp
    - /dev:/dev
    - /run/udev:/run/udev
    - /home/torizon/custom:/etc/xdg/weston-dev/
    - /home/torizon/custom/Loading.png:/home/torizon/custom/Loading.png

  cap_add:
    - CAP_SYS_TTY_CONFIG

  device_cgroup_rules:
    - 'c 4:* rmw'
    - 'c 13:* rmw'
    - 'c 226:* rmw'
    - 'c 10:223 rmw'

Solution 3: Check for eMMC Corruption

Since this is device-specific, there might be filesystem or boot partition corruption:

# Check filesystem integrity
sudo ostree fsck

# Verify boot partition
sudo fsck.vfat -n /dev/mmcblk0p1

Solution 4: Reflash TorizonCore

If the above doesn’t resolve it, consider reflashing TorizonCore on the problematic device to ensure a clean baseline configuration.

Request for Additional Information

Please run these commands and share the output:

dmesg | grep -i "lcdif\|panel\|mxsfb"
cat /sys/class/drm/card0-DPI-1/modes
cat /proc/cmdline

This will help identify if there’s a specific timing or format incompatibility on this particular device.

Best regards,
Toradex AI Assistant

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Coders · September 5, 2026, 7:08am

on this command i got one difference with working device and not working
torizon@colibri-imx7-emmc-08945937:~$ sudo cat /sys/kernel/debug/dri/0/state
plane[31]: plane-0
crtc=crtc-0
fb=38
allocated by = [fbcon]
refcount=2
format=XR24 little-endian (0x34325258)
modifier=0x0
size=800x480
layers:
size[0]=800x480
pitch[0]=3200
offset[0]=0
obj[0]:
name=0
refcount=3
start=00010000
size=1536000
imported=no
dma_addr=0xb0100000
vaddr=219b9fad
crtc-pos=800x480+0+0
src-pos=800.000000x480.000000+0.000000+0.000000
rotation=1
normalized-zpos=0
color-encoding=ITU-R BT.601 YCbCr
color-range=YCbCr limited range
plane[33]: plane-1
crtc=(null)
fb=0
crtc-pos=0x0+0+0
src-pos=0.000000x0.000000+0.000000+0.000000
rotation=1
normalized-zpos=0
color-encoding=ITU-R BT.601 YCbCr
color-range=YCbCr limited range
crtc[35]: crtc-0
enable=1
active=1
self_refresh_active=0
planes_changed=1
mode_changed=0
active_changed=0
connectors_changed=0
color_mgmt_changed=0
plane_mask=1
connector_mask=1
encoder_mask=1
mode: “800x480”: 57 25165 800 816 859 860 480 491 493 514 0x48 0x0
connector[37]: DPI-1
crtc=crtc-0
self_refresh_aware=0
max_requested_bpc=0
here it is non working device allocated by = [fbcon]
and on working allocated by = weston
torizon@colibri-imx7-emmc-06673347:~$ cat /proc/device-tree/toradex,board-rev
V1.1At
and not working
torizon@colibri-imx7-emmc-08945937:~$ cat /proc/device-tree/toradex,board-rev
V1.1B

working-device:
torizon@colibri-imx7-emmc-06673347:~$ cat /sys/class/drm/card0-DPI-1/modes
800x480
torizon@colibri-imx7-emmc-06673347:~$ cat /proc/device-tree/toradex,board-rev
V1.1Atorizon@colibri-imx7-emmc-06673347:~$ cat /proc/device-tree/toradexuct-id
0039torizon@colibri-imx7-emmc-06673347:~$ dmesg | grep -i "lcdif|panel\fb"sf
[ 0.081044] /soc/bus@30400000/lcdif@30730000: Fixed dependency cycle(s) with /panel-dpi
[ 0.081174] /panel-dpi: Fixed dependency cycle(s) with /soc/bus@30400000/lcdif@30730000
[ 2.141905] [drm] Initialized mxsfb-drm 1.0.0 20160824 for 30730000.lcdif on minor 0
[ 2.144699] mxsfb 30730000.lcdif: [drm] fb0: mxsfb-drmdrmfb frame buffer device
not-working device:
torizon@colibri-imx7-emmc-08945937:~$ cat /sys/class/drm/card0-DPI-1/modes
800x480
torizon@colibri-imx7-emmc-08945937:~$ cat /proc/device-tree/toradex,board-rev
V1.1Btorizon@colibri-imx7-emmc-08945937:~$ cat /proc/device-tree/toradexuct-id
0039torizon@colibri-imx7-emmc-08945937:~$ dmesg | grep -i "lcdif|panel\fb"sf
[ 0.072433] /soc/bus@30400000/lcdif@30730000: Fixed dependency cycle(s) with /panel-dpi
[ 0.072541] /panel-dpi: Fixed dependency cycle(s) with /soc/bus@30400000/lcdif@30730000
[ 1.711819] [drm] Initialized mxsfb-drm 1.0.0 20160824 for 30730000.lcdif on minor 0
[ 1.714220] mxsfb 30730000.lcdif: [drm] fb0: mxsfb-drmdrmfb frame buffer device
so is this affects other command i run so i not get major difference