Camera not working on Dell Pro Max 14 Premium (Meteor Lake) - INT3472 GPIO type 0x02 unknown

[markalexwatson]

Bug Report: Camera not working on Dell Pro Max 14 Premium (Meteor Lake) - INT3472 GPIO type 0x02 unknown

Summary

The built-in camera (OmniVision OV08F4) on Dell Pro Max 14 Premium (MA14250) with Intel Meteor Lake does not work due to the INT3472 discrete driver not recognizing GPIO type 0x02.

System Information

• Laptop: Dell Pro Max 14 Premium MA14250
• BIOS Version: 1.6.1
• CPU: Intel Core Ultra 7 265H (Meteor Lake)
• OS: Ubuntu 24.04.3 LTS
• Kernel: 6.14.0-37-generic
• IPU: Intel IPU6 [8086:7d19] (rev 05)
• Camera Sensor: OmniVision OVTI08F4 (OV08F4)

Problem Description

The camera sensor is detected by the IPU6 driver, but the INT3472 discrete power controller fails to initialize properly due to an unknown GPIO type:

[    2.011821] int3472-discrete INT3472:0c: GPIO type 0x02 unknown; the sensor may not work
[    2.061885] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002)
[    2.087207] intel-ipu6 0000:00:05.0: Found supported sensor OVTI08F4:00
[    2.087301] intel-ipu6 0000:00:05.0: Connected 1 cameras
[    2.179752] intel-ipu6 0000:00:05.0: IPU6-v4[7d19] hardware version 6

Because the INT3472 driver doesn't handle GPIO type 0x02, the camera sensor cannot be powered on, and no i2c device is created for the ov08x40 driver to bind to.

ACPI Information

• Camera sensor ACPI path: \_SB_.PC00.LNK1 (OVTI08F4:00)
• INT3472 power controller path: \_SB_.PC00.DSC0 (INT3472:0c, status=15)

Expected Behavior

The INT3472 driver should recognize GPIO type 0x02 and properly control the camera power, allowing the ov08x40 sensor driver to bind and expose the camera as a working V4L2 device.

Current Behavior

• INT3472 driver logs "GPIO type 0x02 unknown"
• No i2c device created for the camera sensor
• ov08x40 driver loaded but not bound to any device
• Camera unusable in any application

Modules Loaded

intel_ipu6_isys
intel_ipu6
ipu_bridge
intel_skl_int3472_discrete
intel_skl_int3472_common
ov08x40
v4l2_fwnode

Steps to Reproduce

1. Boot Ubuntu 24.04 on Dell Pro Max 14 Premium MA14250
2. Check dmesg for "GPIO type 0x02 unknown" message
3. Attempt to use camera in any application (e.g., cheese) - fails

Additional Notes

• The ov08x40 driver has an ACPI alias for OVTI08F4, so should be the correct driver
• The IPU6 HAL packages (libcamhal-ipu6epmtl) are installed
• The sensor is detected but cannot be powered on due to the GPIO issue

Suggested Fix

The INT3472 discrete driver (drivers/platform/x86/intel/int3472/discrete.c) needs to be updated to handle GPIO type 0x02, which appears to be used on newer Dell Meteor Lake laptops.

Attachments

DSDT dump available on request.

[astromark]

I also have Dell Pro Max 14 and see this issue. Following this comment: #369 (comment). I installed the 6.14.0-1019-oem kernel and associated drivers and now it is at least partially working (it works in Firefox, Zoom and Telegram but not Chrome or Slack).

[markalexwatson]

Thanks for this. I have now managed to get it to work in Chrome as well. Will write up in a second. Using with e.g. Google Meets (my primary use for the camera), it detects the camera, initially fails then after a couple of minutes bursts into life. I haven't tried Slack yet.

EDIT: have Slack working and Chrome, reliably, but via a hack. Updated my comment below. Hate the hack but necessary until the various participants have the hardware working reliably.

[markalexwatson]

Solution for Dell Pro Max 14 Premium (MA14250) - Camera Working

System

• Laptop: Dell Pro Max 14 Premium MA14250
• CPU: Intel Core Ultra 7 265H (Meteor Lake)
• Camera Sensor: OmniVision OVTI08F4 (OV08F4)
• OS: Ubuntu 24.04.3 LTS
• Kernel: 6.14.0-1019-oem

Problem

Camera not working due to int3472-discrete INT3472:0c: GPIO type 0x02 unknown; the sensor may not work error.

The standard intel-ipu6-dkms package from the PPA fails to build on kernel 6.14+. Additionally, the built-in v4l2-relayd service is broken on this hardware - it runs but doesn't actually feed frames to the loopback device.

Solution

Step 1: Install Dell OEM packages

Use the Dell-specific Canonical archive which provides properly built OEM kernel modules:

sudo apt install ubuntu-oem-keyring
sudo add-apt-repository "deb http://dell.archive.canonical.com/ noble somerville"
sudo apt install oem-somerville-remoraid-meta

Also install IPU6/IPU7 modules:

sudo apt install linux-modules-ipu6-oem-24.04c linux-modules-ipu7-oem-24.04c

Reboot to load the OEM kernel.

Step 2: Fix permissions

sudo usermod -aG video $USER
echo 'KERNEL=="ipu-psys0", GROUP="video", MODE="0660"' | sudo tee /etc/udev/rules.d/99-ipu-psys.rules
sudo udevadm control --reload-rules

Log out and back in for group changes to take effect.

Step 3: Disable broken v4l2-relayd

The default v4l2-relayd service is broken on this hardware - it initialises but doesn't stream frames:

sudo systemctl stop v4l2-relayd@default
sudo systemctl disable v4l2-relayd@default

Step 4: Create camera toggle script

Chrome/Slack/Electron apps need the camera fed through a v4l2loopback device. Create a toggle script to start/stop the camera on demand:

sudo tee /usr/local/bin/camera-toggle << 'EOF'
#!/bin/bash
if pgrep -f "gst-launch.*icamerasrc" > /dev/null; then
    pkill -f "gst-launch.*icamerasrc"
    echo "Camera OFF"
else
    modprobe -r v4l2loopback 2>/dev/null
    modprobe v4l2loopback card_label="Intel MIPI Camera" exclusive_caps=1 video_nr=0
    sleep 1
    gst-launch-1.0 icamerasrc ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video0 &
    echo "Camera ON"
fi
EOF
sudo chmod +x /usr/local/bin/camera-toggle

Step 5: Remove conflicting packages

If you have the PPA's DKMS package installed, remove it:

sudo apt remove intel-ipu6-dkms

Usage

Before a video call:

sudo camera-toggle

After the call (to save battery/privacy):

sudo camera-toggle

Result

Camera works in:

• ✅ gstreamer (gst-launch-1.0 icamerasrc ! videoconvert ! autovideosink)
• ✅ Firefox
• ✅ Chrome / Google Meet
• ✅ Slack
• ✅ Zoom
• ✅ Telegram

The GPIO type 0x02 warning still appears in dmesg but does not prevent the camera from functioning:

[    1.929792] int3472-discrete INT3472:0c: GPIO type 0x02 unknown; the sensor may not work
[    2.531338] ov08x40 i2c-OVTI08F4:00: start full_power

Why the toggle script is needed

Chrome/Electron apps cannot access the IPU6 camera devices directly - they need a standard V4L2 device. The system's built-in v4l2-relayd service is supposed to bridge this gap, but it's broken on this hardware (it runs but doesn't actually stream frames).

The toggle script works around this by:

1. Creating a v4l2loopback device (/dev/video0) that apps can see
2. Running gstreamer to capture from icamerasrc and feed frames to the loopback
3. Letting you turn it off when not needed (battery/privacy)

Notes

• The camera requires running sudo camera-toggle before video calls
• Firefox may work without the toggle using PipeWire directly (untested)
• Do not use v4l2-relayd@default - it's broken on this hardware
• Do not install intel-ipu6-dkms from the PPA - it conflicts with in-tree drivers

[agustinhurquiza]

@markalexwatson Nice report on how to fix the issue! I’m experiencing the same problem in a similar environment (except my laptop is 16-inch). I followed your solution, but I’m getting the following error:

st-launch-1.0 icamerasrc ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video0 
Setting pipeline to PAUSED ...
[01-26 13:24:22.851] CamHAL[INF] aiqb file name OV08X40_BBG802N3_RG_MTL.aiqb
[01-26 13:24:22.853] CamHAL[INF] aiqb file name OV08X40_BBG802N3_RG_MTL.aiqb
[01-26 13:24:22.854] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.854] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.855] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.855] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.855] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.855] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.855] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
[01-26 13:24:22.855] CamHAL[INF] aiqb file name AR0234_TGL_10bits.aiqb
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
[01-26 13:24:30.208] CamHAL[WAR] <seq0>needQueueBack: buffer error
[01-26 13:24:30.277] CamHAL[WAR] <seq1>needQueueBack: buffer error
[01-26 13:24:30.348] CamHAL[WAR] <seq2>needQueueBack: buffer error
[01-26 13:24:30.418] CamHAL[WAR] <seq3>needQueueBack: buffer error
[01-26 13:24:30.523] CamHAL[WAR] <seq4>needQueueBack: buffer error
[01-26 13:24:31.82] CamHAL[WAR] <seq5>needQueueBack: buffer error

Do you have any idea what might be causing this?

[markalexwatson]

@agustinhurquiza The buffer errors you're seeing are different from my issue - looks like the pipeline starts but frames aren't being captured properly. A few things to check:

Make sure v4l2loopback is loaded with the right parameters:

sudo modprobe -r v4l2loopback
sudo modprobe v4l2loopback card_label="Intel MIPI Camera" exclusive_caps=1 video_nr=0

Check that v4l2-relayd isn't running and fighting for the device:

sudo systemctl stop v4l2-relayd@default
sudo systemctl mask v4l2-relayd@default

Verify the basic camera works without the loopback:

sudo gst-launch-1.0 icamerasrc ! videoconvert ! autovideosink

If that last command shows video, the camera hardware is working and it's a loopback issue. If it also shows buffer errors, the problem is lower in the stack.

Also worth checking dmesg | grep -i ipu6 for any errors - the 16" model might have slightly different hardware/firmware.

[francoisjehl]

I have the same laptop (Dell Pro Max 14 14250) and the same sensor.

Kernel / system:

uname -r
6.14.0-1019-oem

Kernel logs show the INT3472 warning and the sensor powering:

[   38.200787] int3472-discrete INT3472:0c: GPIO type 0x02 unknown; the sensor may not work
[   38.296585] intel-ipu6 0000:00:05.0: Found supported sensor OVTI08F4:00
[   38.533985] ov08x40 i2c-OVTI08F4:00: start full_power

The good thing is, the camera can be made usable in apps (Zoom) via v4l2-relayd (that works on mine).
However the image is heavily artifacted and I get repeating CSI-2 errors in dmesg when streaming (same when using GStreamer directly btw)

[13051.395749] intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: Payload checksum (CRC) error
[13051.395759] intel_ipu6_isys.isys intel_ipu6.isys.40: csi2-0 error: DPHY recoverable synchronization error

I’m holding off on further debugging until 6.17 lands (hoping the upstream driver/kernel fixes reduce these errors.

[markalexwatson]

Update (31-01-2026): Updated to kernel 6.14.0-1020-oem with latest IPU6/IPU7 modules. Unfortunately the v4l2-relayd issue persists - the service runs but doesn't actually stream frames to the loopback device. Still need the manual gstreamer toggle script as a workaround.

The camera hardware itself works fine (gst-launch-1.0 icamerasrc ! videoconvert ! autovideosink displays video), it's just the relay that's broken.

[praveenpuglia]

I am on a Dell Pro Max 16 Premium - MA16250 and I have been able to fix all the camera problems. To begin with, here's the screenshot.

This laptop comes with OEM Ubuntu - factory installed. I was frustrated with the pink and green artifacts in the stream and the lower resolution as well.

With some basic knowledge and Opus 4.5 at hand, I was able to debug it a lot and finally do some fixes that make the camera great.

Root Cause - Pink & Green Artifacts

Two bugs in ipu6-isys-dwc-phy.c (the MIPI CSI-2 PHY driver for Meteor Lake / Arrow Lake):

1. HSFREQRANGE band too high: The PHY receiver frequency band selected for 1498 Mbps puts the data rate at the very bottom edge of the band (index 43: 1461–1640 Mbps), giving poor sampling margins. Shifting down 2 bands (index 41: 1366–1535 Mbps) centers the data rate in the band.

2. Deskew polarity applied incorrectly: The driver applies deskew polarity when mbps < 1500. The OV08X40 runs at 749 MHz × 2 = 1498 Mbps — just barely under the threshold due to integer math. Deskew at this speed causes sampling errors rather than correcting them.

It's a bit too detailed so together with Opus, have documented the steps to fix this in the attached markdown files. Some directory paths etc may need tweaking so please read the document before running it.

These fix the artifacts and continuous CSI2 errors.

DWC_PHY_FIX_GUIDE.md

KERNEL_UPDATE_REDO_STEPS.md

Root Cause - Camera Start & Handshake Failures

Another issue was that the camera tries to switches on multiple times before actually turning on. The LED blinks a bunch of times before being stable. This was fixed here - #228 (comment)

With all this, the camera now starts in a few seconds without trying to negotiate and fail a few times at the beginning.

Resolution Fix

edit /etc/v4l2-relayd.d/default.conf and change the resolution here. The config will look something like this. You may have more things in your config so choose and replace the necessary parts.

VIDEOSRC=icamerasrc buffer-count=7 ! videoconvert
FORMAT=YUY2
WIDTH=1920
HEIGHT=1080
FRAMERATE=30/1
CARD_LABEL=Intel MIPI Camera

Once done, restart with

sudo systemctl restart v4l2-relayd.service

[markalexwatson]

@praveenpuglia Great detective work with Opus! Interesting to see the PHY timing issues documented in detail.
I'm on the 14" model (MA14250) with the same OV08F4 sensor and kernel. My video is clean with no artifacts or CRC errors, so I think the PHY issue might be specific to the 16" model or certain hardware revisions.

My issue is different - the built-in v4l2-relayd service runs but doesn't actually stream frames to the loopback device. Chrome/Slack can't access the IPU6 devices directly, so they need the loopback. The manual gstreamer toggle script above feeds the loopback on demand.

Will keep your PHY fix docs handy in case artifacts appear after a future kernel update. Thanks for sharing!

[giulianopz]

Hi @markalexwatson, I'm experiencing the same issue on a Dell Precision 5690. The issue happened after the last system update (Ubuntu 24.04). You said that v4l2-relayd is running. Are you really sure? On my machine, it has status active (exited). Unfortunately, the daemon does not log anything useful (so no errors in journalctl output). It just exits with 0 exit code after trying to start.

[markalexwatson]

@giulianopz I got it to the point of running but not transferring frames. Try the toggle hack above.

[praveenpuglia]

@praveenpuglia Great detective work with Opus! Interesting to see the PHY timing issues documented in detail. I'm on the 14" model (MA14250) with the same OV08F4 sensor and kernel. My video is clean with no artifacts or CRC errors, so I think the PHY issue might be specific to the 16" model or certain hardware revisions.

My issue is different - the built-in v4l2-relayd service runs but doesn't actually stream frames to the loopback device. Chrome/Slack can't access the IPU6 devices directly, so they need the loopback. The manual gstreamer toggle script above feeds the loopback on demand.

Will keep your PHY fix docs handy in case artifacts appear after a future kernel update. Thanks for sharing!

May be another detective work with Opus is required :D