IPU4p drivers on Surface Pro 7

[ruslanbay]

Hi everyone,

First of all, thank you all for your work on open-sourcing the IPU4 driver.

I'm currently trying to make the IPU4P driver work on my Surface Pro 7 tablet (i5-1035G4, Ice Lake):

• patches
• kernel
• the original IPU4 driver

It feels like I’m very close to a working setup, but I’m currently blocked by a media bus code mismatch during stream start. I’ve collected logs, kernel traces, and libcamera output in this discussion: linux-surface/linux-surface#1353

If anyone has time to take a look or can point me to the right area in the driver to investigate further, I’d really appreciate it. If there’s someone else I should reach out to, please let me know.

Thanks again for making this code available and for any guidance you can share.

CC (apologies in advance if any tags are unnecessary): @krispan-intel @khaiwenng @shilld3 @D3-jwatts @bjwood05 @mengwei-intel @xiahui9527 @karthiketintc @kumarkan @changchingyew @hao-yao

[ruslanbay]

Here’s an additional update with more details on my current setup and observations.

To rule out any early-init or probe ordering issues, I’ve blacklisted all IPU4-related modules in /etc/modprobe.d/ipu4.conf:

# options intel_ipu4p_isys dyndbg="+pfl"

blacklist intel_ipu4p
blacklist intel_ipu4p_isys
blacklist intel_ipu4p_psys
blacklist ipu_bridge
blacklist intel_ipu4p_isys_csslib
blacklist intel_ipu4p_psys_csslib

After boot, I load the modules manually in this order:

sudo modprobe ipu_bridge && \
  sudo modprobe intel_ipu4p_isys_csslib && \
  sudo modprobe intel_ipu4p_psys_csslib && \
  sudo modprobe intel_ipu4p && \
  sudo modprobe intel_ipu4p_psys && \
  sudo modprobe intel_ipu4p_isys

The full initialization log: ipu4_init.log

To capture a frame, I’m using the script below. I consistently hit the wrong media bus code 0x0000200a (0x00003007 expected) error if VFMT is set to SBGGR10. Switching to SBGGR10P avoids that specific error, but streaming still does not complete.

RESOLUTION=3264x2448
FMT=SBGGR10_1X10
VFMT=SBGGR10P

media-ctl -r

media-ctl -V "\"ov8865 1-0010\":0 [fmt:$FMT/$RESOLUTION]"
media-ctl -V "\"Intel IPU4 CSI-2 3\":0 [fmt:$FMT/$RESOLUTION]"
# media-ctl -V "\"Intel IPU4 CSI-2 3\":1 [fmt:$FMT/$RESOLUTION]"

media-ctl -l '"ov8865 1-0010":0 -> "Intel IPU4 CSI-2 3":0 [1]'
media-ctl -l '"Intel IPU4 CSI-2 3":1 -> "Intel IPU4 CSI-2 3 capture 0":0 [1]'

CAPTURE_DEV=$(media-ctl -e "Intel IPU4 CSI-2 3 capture 0")

yavta -c1 ${CAPTURE_DEV} -s${RESOLUTION} -Fframe-a-#.bin -f$VFMT

In this case, yavta hangs indefinitely. From the driver logs, it looks like the ISYS pipeline is configured, but streaming never fully starts.

• yavta_image_capture.log (during the hang)
• yavta_cancel.log (after interrupting with Ctrl+C)

[ruslanbay]

Can someone please verify offsets values for ipu4p_csi_offsets:

• ruslanbay/linux@b337b22

With this change now I have two sensors to play with. The bad news is that image capture still doesn’t work on either (the ov8865 pipeline seems to progress slightly further):

• ipu_init.log
• capture_ov8865.log
• capture_ov5693.log