⚠ This page is served via a proxy. Original site: https://github.com
This service does not collect credentials or authentication data.
Skip to content

Conversation

@bemug-st
Copy link
Contributor

@bemug-st bemug-st commented Jan 8, 2026

Again, better late than never 😉

As we briefly discussed at Embedded Recipes with @naushir and @davidplowman, I would like to enable ST BrightSense cameras in the Raspberry Pi kernel to allow users to utilize them with minimal modifications to a fresh RaspiOS, if possible.
Following @naushir's advice, here is the pull request adding this support.

Currently, kernel drivers and libcamera support are mainlined for both vd55g1 and vd56g3.

This pull request adds the remaining integration for Raspberry Pis

  • Device tree overlays
  • Drivers compiled as modules by default

By merging this code, users will only need to specify the device tree overlay in /boot/firmware/config.txt with dtoverlay=<sensor> to enable the camera functionality. Please note that automatic camera detection is beyond the scope of this pull request.

I'm not fully aware of how you manage your branches. Since 6.18 is expected to be the next LTS this pull request targets this branch, but it applies successfully down to 6.16. Feel free to rebase it onto whichever branch you find most appropriate.

Please share your thoughts on this pull request and let me know if any changes are needed.

Thank you.

@6by9
Copy link
Contributor

6by9 commented Jan 8, 2026

Hi Benjamin - thanks for the PR.

Targeting 6.18 is fine - it should become the default branch within the next few months.

The 2 defconfig patches may as well get squashed together - they get regenerated and squashed as a whole on each revision bump anyway.

Seeing as the overlays for vd56g3 and vd66gy are duplicates other than the node name and compatible, it'd be nicer to put all the common part in a dtsi file, with the individual overlays just setting the compatible. We do a similar thing with imx290, imx327 and imx462 which all pull in imx290_327-overlay.dtsi.
The only downside is that the sensor node name is either generic or only adopts one of the sensor names.

Same for vd55g1 and vd65g4.

Overlays need to be documented in https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/README

Camera autodetection is not supported for third party sensors, only those made by Raspberry Pi.

I assume this works with the ST eval boards for these sensors, eg https://www.st.com/en/evaluation-tools/steval-56g3mai.html ? It's probably worth us buying in a couple for basic support purposes.

@bemug-st
Copy link
Contributor Author

bemug-st commented Jan 9, 2026

Thank you for your review. I updated this pull request accordingly.

I assume this works with the ST eval boards for these sensors, eg https://www.st.com/en/evaluation-tools/steval-56g3mai.html ? It's probably worth us buying in a couple for basic support purposes.

Exactly, we can ship some boards to you for free if you want. Please provide the quantities and the shipping address, and I'll get that sorted.

Copy link
Contributor

@6by9 6by9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One very minor observation that fragment 5 which is activated by the media-controller=0 override isn't redirected to csi0 by the cam0 override. I'm not that bothered as almost all use cases use media controller for configuration.

I'll drop you an email regarding samples, although 3 of the 4 appear to be stocked by Farnell so are easy enough to source anyway.
It's nice being able to suggest further options for global shutter sensors that are easily available.

@bemug-st
Copy link
Contributor Author

bemug-st commented Jan 12, 2026

One very minor observation that fragment 5 which is activated by the media-controller=0 override isn't redirected to csi0 by the cam0 override. I'm not that bothered as almost all use cases use media controller for configuration.

Just to make sure, imx290_327-overlay.dtsi have the same issue right ?

@pelwell
Copy link
Contributor

pelwell commented Jan 12, 2026

Just be make sure, imx290_327-overlay.dtsi have the same issue right ?

Yes, it does.

bemug-st added a commit to STMicroelectronics/vd55g1-linux-driver that referenced this pull request Jan 16, 2026
Now on part with rpi overlay definition for easier maintainance.
See raspberrypi/linux#7189

All common code is factorized in vd55g1_vd65g4-overlay.dtsi.
Every pcb overlay includes vd55g1_vd65g4-overlay.dtsi, adds its
corresponding compatible, and optionnaly adds extra required properties.

Contrary to rpi kernel, the C preprocessor '#include' instruction has
been replaced by '/include/' dtc instruction to avoid running gcc,
allowing to build overlays outside of the Linux kernel environnement
in a standalone way.

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
bemug-st added a commit to STMicroelectronics/vd56g3-linux-driver that referenced this pull request Jan 19, 2026
Now on part with rpi overlay definition for easier maintainance.
See raspberrypi/linux#7189

All common code is factorized in vd16gz_vd56g3_vd66gy-overlay.dtsi.
Every pcb overlay includes vd16gz_vd56g3_vd66gy-overlay.dtsi, adds its
corresponding compatible, and optionnaly adds extra required properties.

Contrary to rpi kernel, the C preprocessor '#include' instruction has
been replaced by '/include/' dtc instruction to avoid running gcc,
allowing to build overlays outside of the Linux kernel environnement
in a standalone way.

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
bemug-st added a commit to STMicroelectronics/vd1943-linux-driver that referenced this pull request Jan 19, 2026
Now on part with rpi overlay definition for easier maintainance.
See raspberrypi/linux#7189

All common code is factorized in vd1943_vd5943-overlay.dtsi.
Every pcb overlay includes vd1943_vd5943-overlay.dtsi, adds its
corresponding compatible, and optionnaly adds extra required properties.

Contrary to rpi kernel, the C preprocessor '#include' instruction has
been replaced by '/include/' dtc instruction to avoid running gcc,
allowing to build overlays outside of the Linux kernel environnement
in a standalone way.

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
…nfigs

Build CONFIG_VIDEO_VD56G3 and CONFIG_VIDEO_VD55G1 as module by default.

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Provide two device trees : vd56g3 is monochrome, while vd66gy is RGB.

Factorize most of the definitions in vd56g3_vd66gy-overlay.dtsi and
describe the overlays in README.

Support both cam0 and cam1 interfaces with raspberry pi __overrides__
mechanism.

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Provide two device trees : vd55g1 is monochrome, while vd65g4 is RGB.

Factorize most of the definitions in vd55g1_vd65g4-overlay.dtsi and
describe the overlays in README.

Support both cam0 and cam1 interfaces with raspberry pi __overrides__
mechanism.

Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
@pelwell pelwell merged commit 85f9ed0 into raspberrypi:rpi-6.18.y Jan 20, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants