How to Create a GMSL2 Driver for NXP i.MX95
A GMSL2 camera driver for NXP i.MX95 connects the remote sensor and SerDes transport to the i.MX95 Linux media pipeline. Prove power and remote I2C first, configure GMSL2, integrate the required V4L2 subdevices and device-tree graph, and validate raw capture before adding libcamera, NEO ISP, or image-quality tuning.
RidgeRun's NXP i.MX95 Technical Guide documents the i.MX95 multimedia stack, including MIPI CSI-2, CSI Pixel Formatter, ISI, NEO ISP, V4L2, Media Controller, and GStreamer. RidgeRun also provides custom V4L2 camera-driver development and lists GMSL2 among tested serializer/deserializer technologies.
RidgeRun has experience with more than 50 camera drivers and complex serializer/deserializer camera architectures.
Understanding the i.MX95 Camera Pipeline
Sensor -> Serializer -> GMSL2 -> Deserializer
|
v
MIPI CSI-2
|
v
CSI Pixel Formatter
|
+-------+-------+
| |
v v
ISI NEO ISP
| |
+-------+-------+
|
v
V4L2 / userspace
The exact route depends on BSP, format, and application. GMSL2 transport, Linux capture, and ISP processing are separate layers.
- Sensor layer: power, clocks, mode tables, exposure/gain controls, and stream-on.
- GMSL2 transport layer: serializer/deserializer control, link lock, video pipes, virtual channels, and CSI-2 output.
- i.MX95 capture layer: MIPI CSI-2 reception, media-controller topology, V4L2 capture, ISI/NEO ISP, and userspace.
NXP's i.MX 95 Camera Porting Guide documents the Linux camera topology and includes a MAX96724 deserializer represented as a Linux media entity for multi-camera CSI streams.[1]
Define the Target
Record the board, BSP/kernel, sensor, serializer, deserializer, camera count, I2C topology, resolution, frame rate, RAW/YUV format, bits per pixel, CSI lanes, virtual channels, clocks/GPIOs, and whether ISI, NEO ISP, or libcamera is required.
See NXP i.MX95 Technical Guide/Video Capture for RidgeRun's platform capture overview.
RidgeRun has worked with several GMSL2 configurations. Chips we have used before are:
| Chip | Type |
|---|---|
| MAX9295A | GMSL2 CSI-2 Serializer |
| MAX9296A | Quad GMSL2 CSI-2 Deserializer |
| MAX96712 | Quad GMSL2 CSI-2 Deserializer |
| MAX96714 | Single GMSL2/GMSL1 CSI-2 Deserializer |
| MAX96716A | Dual GMSL2 CSI-2 Deserializer |
| MAX96717 | GMSL2 CSI-2 Serializer |
| MAX96724 | Quad GMSL2/GMSL1 CSI-2 Deserializer |
| MAX96792A | Dual GMSL3/GMSL2 CSI-2 Deserializer |
| MAX96793 | GMSL3/GMSL2 CSI-2 Serializer |
Budget the Transport
payload = width x height x fps x bits_per_pixel
For 3840 x 2160 RAW12 at 30 fps:
2,985,984,000 bit/s
This is only active pixels. Include sensor timing, CSI-2 overhead, metadata, lane configuration, and all aggregated cameras.
The i.MX95 platform supports substantial multi-camera capability, but a real GMSL2 limit depends on the complete SerDes, CSI, routing, bandwidth, and processing design.
Bring Up I2C and GMSL2
With video disabled:
- Power/reset the deserializer.
- Read its ID.
- Configure the target GMSL2 link.
- Establish the remote control channel.
- Read the serializer ID.
- Configure address translation/aliasing.
- Read the sensor ID.
- Repeat after a cold boot.
If remote I2C fails, check sensor rails, reference clock, reset, serializer power, cable, link configuration, and address mapping.
Multiple Identical Cameras
Host -> Deserializer
+-> Link A -> Sensor address X
+-> Link B -> Sensor address X
+-> Link C -> Sensor address X
+-> Link D -> Sensor address X
Use the SerDes-supported translation or isolation mechanism so every remote device is unambiguous from Linux.
Implement the V4L2 Sensor Subdevice
Typical responsibilities:
- I2C register access and chip ID.
- Power sequencing.
- Media-bus formats and modes.
- Exposure and analogue gain.
- HBLANK/VBLANK where applicable.
- Pixel rate.
- Streaming and media pads.
V4L2_CID_EXPOSURE V4L2_CID_ANALOGUE_GAIN V4L2_CID_HBLANK V4L2_CID_VBLANK V4L2_CID_PIXEL_RATE
Accurate control semantics matter for later userspace camera algorithms.
A simplified lifecycle is:
Enable: power/resume program mode apply controls activate required SerDes route start sensor Disable: stop sensor release stream-specific SerDes resources suspend when safe
Do not tear down shared deserializer resources while another stream is active.
Integrate the SerDes Bridge
The deserializer configuration generally covers input links, incoming streams, output CSI port, output lanes, virtual channels, routing, and link frequency. The serializer generally covers CSI input, remote control, and optional GPIO/clock/synchronization functions.
Describe the Media Graph in Device Tree
Conceptually:
sensor -> serializer -> GMSL2 -> deserializer -> MIPI CSI-2 -> i.MX95 CSI
Verify remote endpoints, lanes, frequencies, clocks, GPIO polarity, regulators, I2C addresses, ports, and supported routing properties.
Validate the Media Graph and Raw Capture
v4l2-ctl --list-devices media-ctl -p v4l2-ctl -d /dev/video0 --all v4l2-ctl -d /dev/video0 --list-formats-ext
Then run a bounded capture:
v4l2-ctl -d /dev/video0 --stream-mmap=4 --stream-count=300 --stream-to=/dev/null --verbose
Use this acceptance sequence:
Remote control -> GMSL2 video -> CSI reception -> stable V4L2 buffers
-> correct controls -> libcamera/NEO ISP -> image-quality tuning
If raw transport is unstable, fix it before ISP tuning.
Add NEO ISP or libcamera When Required
NXP i.MX95 Technical Guide/Multimedia Support describes NEO ISP as part of the i.MX95 capture architecture.
A RAW sensor can require additional exposure/gain interpretation, control delays, ISP input configuration, image-processing algorithms, and image-quality tuning. These are downstream of reliable GMSL2 transport.
Add Multiple Cameras Incrementally
Bring up multi-camera systems one step at a time:
- Validate each camera alone.
- Verify I2C aliasing/translation.
- Verify virtual channels and stream routing.
- Enable two streams.
- Increase to the required camera count.
- Reverse startup order.
- Stop one stream while others continue.
- Verify aggregate bandwidth.
- Run sustained capture and collect error counters.
NXP documents that CSI-2 can carry multiple streams using virtual channels; the exact usable topology still depends on the selected deserializer, CSI routing, BSP, bandwidth, and processing path.[2]
Common i.MX95 Problems
| Symptom | First checks |
|---|---|
| Sensor not detected | Power, clock, reset, remote I2C, translation. |
| GMSL2 locks but CSI is absent | Sensor stream, video pipe, data type, CSI output. |
| Media graph misses an entity | Driver probe and device-tree endpoints. |
| V4L2 works but image is wrong | Format, Bayer order, bit depth, timing. |
| Multiple cameras fail | VC routing, address collisions, bandwidth, shared resources. |
| Raw capture works but ISP output is poor | Sensor-control semantics, ISP configuration and tuning. |
See How to Debug a GMSL2 Driver for Linux for the generic diagnostic procedure.
Key Takeaways
- A GMSL2 driver on i.MX95 is an integration of sensor control, SerDes transport, V4L2/media entities, device tree, and the SoC CSI/capture pipeline.
- Prove deterministic remote I2C before debugging video.
- Separate GMSL2 transport from i.MX95 image processing.
- Treat GMSL2 link lock, CSI-2 reception, V4L2 capture, and ISP processing as separate validation stages.
- Validate raw capture before NEO ISP or image-quality tuning.
- Bring up one camera before multi-camera routing and bandwidth tests.
- Document the exact board, BSP, kernel, SerDes, sensor, lane configuration, and measured performance so results are reproducible.
- Use the V4L2/Media Controller topology expected by the BSP.
- Use NXP i.MX95 Technical Guide and NXP i.MX95 Technical Guide/Video Capture as related platform resources.
Frequently Asked Questions
- How do I create a GMSL2 driver for NXP i.MX95?
- Bring up the sensor and GMSL2 control path first, integrate the sensor and SerDes devices into the Linux V4L2/Media Controller graph, describe the CSI-2 topology in device tree, validate stable raw capture, and only then add libcamera or NEO ISP integration.
- Does GMSL2 replace the i.MX95 CSI or ISP driver?
- No. GMSL2 transports camera data between the remote camera and the SoC. The i.MX95 MIPI CSI-2 receiver, capture blocks, V4L2 stack, and optional NEO ISP remain separate parts of the pipeline.
- Why can I read a remote sensor over I2C but capture no frames?
- The control path and video path are different. Check sensor stream-on, serializer CSI input, GMSL2 video status, deserializer routing and CSI-2 output, virtual channel, i.MX95 receiver configuration, and the Linux media graph.
- Should I tune NEO ISP while frames are dropping?
- No. First establish stable sensor streaming, GMSL2 transport, CSI-2 reception, routing, and V4L2 buffers. ISP tuning should start only after the transport path is reliable.
- How should multiple identical GMSL2 cameras be addressed?
- Use the translation, aliasing, or isolation mechanism supported by the selected SerDes so each remote sensor and serializer is uniquely addressable from Linux, then validate cameras individually before enabling all streams.
Related Pages
- How to Debug a GMSL2 Driver for Linux
- NXP i.MX95 Technical Guide
- NXP i.MX95 Technical Guide/Multimedia Support
- NXP i.MX95 Technical Guide/Video Capture
- V4L2 driver for camera sensor or capture chip
- RidgeRun Linux Camera Drivers
For direct inquiries, please refer to the contact information available on our Contact page. Alternatively, you may complete and submit the form provided at the same link. We will respond to your request at our earliest opportunity.
Links to RidgeRun Resources and RidgeRun Artificial Intelligence Solutions can be found in the footer below.
ARTIFICIAL INTELLIGENCE
