Missing OV2740-MIPI-driver in compiled binaries

nilsmelchert commented 2 years ago

Describe the bug

It seems like that the driver for the OV2740 mipi-camera (https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/ov2740.c) ist not compiled into the kernel. Does anyone know why this is the case?

Steps to reproduce the behaviour

Standard kernel compilation does not offer the option to select the driver for the OV2740.

Device (s)

Raspberry Pi 4 Mod. B

System

Raspbian Kernel 5.15

Logs

No response

Additional context

No response

pelwell commented 2 years ago

There are many camera drivers that aren't enabled in our kernel builds - the policy is to wait for a request before enabling them. However, in the case of OV2740 the situation is more difficult because the driver has a dependency on ACPI:

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/Kconfig#L1014

Raspberry Pi devices do not use ACPI, so the driver cannot be enabled.

nilsmelchert commented 2 years ago

Thank you! Do you know if this will be resolved anytime in the future?

pelwell commented 2 years ago

It's difficult to say. The driver has been written by some Intel devs, and Intel doesn't care about Device Tree (support for which would have to be added to the driver for Raspberry Pi and other ARM-based boards).

ACPI-based drivers are in the minority, but a few of them also support Device Tree - imx258, ov7251 and ov8858. It does look as though the differences are minimal, but it's the kind of thing which is best done by the upstream kernel devs (or at least submitted upstream so that it can be maintained there).

6by9 commented 2 years ago

To extend what pelwell has said, where 3rd parties have made modules and there is a mainline driver for the sensor, then we will sometimes take on the task of adding any missing functionality and creating a device tree overlay for the sensor. This is what has been done for imx290 (and 327 and 462), imx258, adv7282-m, tc358743, ov7251 and a few others.

Others, such as imx519, have been submitted by 3rd parties, but we have requested that they upstream the driver too. The support burden is on the 3rd party, and not Raspberry Pi.

There are a couple of cases where we have developed drivers for sensors (ov9281 and ov2311 spring to mind), but those are cases where there was a 3rd party driver that could be pulled in easily and cleaned up. We ought to upstream them, but it hasn't happened yet. (For ov9281, there is an ov9282 driver in mainline which is near identical and ought to be fixed).

Summary from my side, we need:

any fixups to the drivers
enable the module in all Pi defconfigs
a dtoverlay that will configure a Pi to use that sensor

in order for a sensor driver to be enabled in the default Pi kernel. Ideally the module should be fairly readily available too, otherwise we're burdening everyone with carrying the module for the benefit of very few.

If you have an ov2740 module with suitable cabling to interface to a Pi, then I am happy to work with you to complete the above steps.

moritzvonwrangel commented 2 years ago

The Taiwanese company misumi offers such a module.

http://www.misumi.com.tw/pdf/datasheet/Others/MISUMI%20Datasheet%20MIX%20Series.pdf

It has the same JST connector with the same pinout as the Pi. I already bought the module, but could not get it to work due to missing drivers.

6by9 commented 2 years ago

Which module specifically are you looking at? B311xx? It's right as 1.4 x 1.4um pixels, and 1/6" CMOS, but they don't say what module is used. Have you ordered it direct, or through some distributor?

That datasheet also lists pin 12 as being MCLK. The Pi doesn't feed a clock up the FFC as it was found to be a nightmare for EMC (high speed non-differential 3.3V swing - eek!). All the Pi camera modules have any required oscillator on the camera board. What clock are they expecting on that wire?

It would probably only take me an hour or so to make a stab at converting ov2740 to support device tree. You'd need to be prepared to build your own kernel from source though. Are you up for trying that out?

pelwell commented 2 years ago

Kernel building isn't difficult - see https://www.raspberrypi.com/documentation/computers/linux_kernel.html#building for instructions.

moritzvonwrangel commented 2 years ago

Yes, I have purchased the 311xx module. I am in contact with Misumi and they confirmed that all 31xx modules are based on the OV2740 sensor. I ordered the module directly as I don't know any European distributors. I am not sure about the MCLK, I will have to do some more research on that. And building the kernel is indeed nothing I can't manage.

6by9 commented 2 years ago

Do you happen to know the I2C address used by the sensor? It's needed for the dtoverlay.

6by9 commented 2 years ago

It appears I've been here already - https://github.com/6by9/linux/tree/rpi-5.15.y-ov2740 already existed. I'll rebase it to the latest rpi-5.15.y, and update the overlay as we have altered the basic shape of them recently.

6by9 commented 2 years ago

Branch rebased. Compile testing it now. Bizarrely I can't find any reference to why I was looking at OV2740 back in February.

If you have a contact at Misumi that you can introduce me to, then please do so. My email address is the Signed-off-by: address on the top 7 commits of that kernel branch. I have a fairly reasonable collection of sensors which we nominally support, and I'm always open to extending that collection.

6by9 commented 2 years ago

Ah, found the reason. It was asked about on the libcamera-devel list https://lists.libcamera.org/pipermail/libcamera-devel/2022-February/029086.html

moritzvonwrangel commented 2 years ago

Do i understand 140d71e0e17964eb9ec6814b99393061b217fab2 correctly, that you are uncertain about the number of active pixels? I have the following information from the sensor specification: "Of the 2,152,832 pixels, 2,121,856 (1936x1096) are active pixels and can be output. The other pixels are used for black level calibration and interpolation. The center 1920x1080 pixels are suggested to be output from the whole active pixel array."

6by9 commented 2 years ago

Do i understand https://github.com/raspberrypi/linux/commit/140d71e0e17964eb9ec6814b99393061b217fab2 correctly, that you are uncertain about the number of active pixels? I have the following information from the sensor specification: "Of the 2,152,832 pixels, 2,121,856 (1936x1096) are active pixels and can be output. The other pixels are used for black level calibration and interpolation. The center 1920x1080 pixels are suggested to be output from the whole active pixel array."

Sensors drivers are meant to advertise the number of pixels in the array, including the information about black level calibration pixels. eg ov5647, datasheet at https://www.uctronics.com/download/Image_Sensor/OV5647_DS.pdf section 3.1. The array is as 2624 x 1956, but top left active pixel is 16,6, and bottom right at 2607,1949, giving 2592 x 1944 pixels active pixels. That is then reflected in the driver at https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/ov5647.c#L69-L76, which can be retrieved through VIDIOC_G_SELECTION and https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/media/i2c/ov5647.c#L1114-L1127

I didn't have the information on the dummy lines in the OV2740 array, so assumed none.

Taking your numbers, 2152832 pixels probably translates to 1936x1112 (no other division results in integer numbers of lines and columns), so presumably we're looking at 16 dummy lines split between above and below (8 each side?)

If you can confirm that from whatever information you have about the sensor, then I can update the patch accordingly. It's all largely cosmetic anyway as we don't use the information about masked pixels for anything special.

moritzvonwrangel commented 2 years ago

Branch rebased. Compile testing it now. Bizarrely I can't find any reference to why I was looking at OV2740 back in February.

If you have a contact at Misumi that you can introduce me to, then please do so. My email address is the Signed-off-by: address on the top 7 commits of that kernel branch. I have a fairly reasonable collection of sensors which we nominally support, and I'm always open to extending that collection.

You should have recieved an E-Mail together with my contact at misumi.

6by9 commented 2 years ago

You should have recieved an E-Mail together with my contact at misumi.

I have - thank you. Please keep technical discussion on here though, rather than by email - it leaves a trail for anyone coming after you.

6by9 commented 2 years ago

I'm going to ignore the exact cropping for now as the driver seems to have some quirky register settings.

I don't have a datasheet for OV2740, but Omnivision usually define the image via registers 0x3800-0x380b

0x3800/1 X_ADDR_START
0x3802/3 Y_ADDR_START
0x3804/5 X_ADDR_END
0x3806/7 Y_ADDR_END
0x3808/9 X_OUTPUT_SIZE
0x380a/b Y_OUTPUT_SIZE

The register set for OV2740 is setting START to 0,0, END to 1935,1095, but a size of 1928x1088, so what is happening to the extra 8 pixels of width, and height? Then again OV5647 appears to do a similar thing with START being 0,0, end being 2623,1955, but an output size of 2592x1944.

However for OV5647 the mode advertised matches that size of 2592x1944. For OV2740 the mode is advertised as 1932x1092, so what's in those extra lines?

Image sensor configuration can often be weird and quirky. The one thing I'm hoping is that your sensor also runs off a 19.2MHz clock, because messing with the PLL settings is a real pain.

Phil123456789 commented 2 years ago

Hi, I have also recently been working on the implementation of the sensor based on the Denebola CX3 board. The mentioned registers should fit so far. I also get an image of size 1928x1088 where no black pixels are present.

Probably there are 8 active dummy pixels (according to my interpretation). Otherwise there are probably also pixels for black level calibration and interpolation.

To my understanding the sensor works with a 6~64 MHz input clock where the corresponding clock divider must be set correctly. Here is my implementation: Reference Clock 24Mhz PPl Clock 360 MHz.

/ OV2740_RAW10_1080P30 : / CyU3PMipicsiCfg_t OV2740_RAW10_1080P30 = { CY_U3P_CSI_DF_RAW10, / CyU3PMipicsiDataFormat_t dataFormat / 2, / uint8_t numDataLanes / 2, / uint8_t pllPrd / 89, / uint16_t pllFbd / CY_U3P_CSI_PLL_FRS_250_500M, / CyU3PMipicsiPllClkFrs_t pllFrs / CY_U3P_CSI_PLL_CLK_DIV_4, / CyU3PMipicsiPllClkDiv_t csiRxClkDiv / CY_U3P_CSI_PLL_CLK_DIV_4, / CyU3PMipicsiPllClkDiv_t parClkDiv / 0, / uint16_t mClkCtl / CY_U3P_CSI_PLL_CLK_DIV_2, / CyU3PMipicsiPllClkDiv_t mClkRefDiv / 1928, / uint16_t hResolution / 50 / uint16_t fifoDelay / };

moritzvonwrangel commented 2 years ago

Which module specifically are you looking at? B311xx? It's right as 1.4 x 1.4um pixels, and 1/6" CMOS, but they don't say what module is used. Have you ordered it direct, or through some distributor?

That datasheet also lists pin 12 as being MCLK. The Pi doesn't feed a clock up the FFC as it was found to be a nightmare for EMC (high speed non-differential 3.3V swing - eek!). All the Pi camera modules have any required oscillator on the camera board. What clock are they expecting on that wire?

It would probably only take me an hour or so to make a stab at converting ov2740 to support device tree. You'd need to be prepared to build your own kernel from source though. Are you up for trying that out?

According to Misumi we should use an external 24MHz oscillator for the MCLK signal on pin 12. So I could test the driver adapted from @6by9 with a Pi4, the Misumi camera module and an external oscillator connected to pin 12, right? In the long run it would probably be better to develop a mezzanine board with internal oscilator.

6by9 commented 2 years ago

@Phil123456789 This is the problem with not having a datasheet for the sensor. Without it it is largely guesswork.

@moritzvonwrangel Yes I saw the response from Misumi. The external clock signal can typically be anything in a range of around 6-27MHz, as you then configure the internal PLL to run the internal blocks at the appropriate rates. Please note that the current driver is configuring the OV2740 for a 19.2MHz input (https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov2740.c#L18) - to use 24MHz will require some mods (which are tricky without the datasheet).

moritzvonwrangel commented 2 years ago

@Phil123456789 This is the problem with not having a datasheet for the sensor. Without it it is largely guesswork.

@moritzvonwrangel Yes I saw the response from Misumi. The external clock signal can typically be anything in a range of around 6-27MHz, as you then configure the internal PLL to run the internal blocks at the appropriate rates. Please note that the current driver is configuring the OV2740 for a 19.2MHz input (https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov2740.c#L18) - to use 24MHz will require some mods (which are tricky without the datasheet).

Thank you for the hint. I will then set the external frequency generator to 19.2MHz.

steveninfibi commented 1 year ago

@6by9 I am testing a camera with ov2740 sensor on raspi 4 too. After compile the kernel you mentioned, it seems that driver load successfully and ov2740 sensor could be detected on i2c bus. But when I use libcamera to get sensor data. it shows IPA module for ov2740 is not found. The camera handler need to be added... I have found some sensor handlers implementation in https://github.com/kbingham/libcamera/tree/master/src/ipa/raspberrypi It seems some parameters are hardware dependent... Could you give me some clue to start? thanks.

6by9 commented 1 year ago

@steveninfibi libcamera's main git repo is https://git.linuxtv.org/libcamera.git/. kbingham is one of the developers involved and you've linked to his personal fork, so it could have anything on there.

Each sensor needs a cam_helper class in https://git.linuxtv.org/libcamera.git/tree/src/ipa/raspberrypi, and a tuning in https://git.linuxtv.org/libcamera.git/tree/src/ipa/raspberrypi/data, with them both correctly added to the meson.build files so that they get built. The main bits of information required are how to compute the gain code, and delays between setting exposure, gain, hblank or vblank and those values being reflected in the output stream. This information should all be in the datasheet. Get it wrong and you are likely to see blinking on sharp exposure/gain changes.

For a first pass, I'd copy ov9281, search/replace references to be ov2740, and see how it behaves.

steveninfibi commented 1 year ago

@6by9 Thank very much! I will go through the datasheet and take a try! By the way, are there any another ways to check the camera hardware with ov2740 sensor and capture the image? such as v4l2 utility...etc I am new to the mipi camera in Pi. Use v4l2-compliance shows no error happened but I dont know which application in Pi could capture the image. What is different between raspstill and libcamera-still? I am confused...

JosephFeld commented 1 year ago

@6by9 Is there a working driver for the OV2740 on raspberry pi? I'm not sure how far development is - it seems there's something in the repo you linked to (https://github.com/6by9/linux/tree/rpi-5.15.y-ov2740) but based on this thread it's unclear to me if it's finished. If I get a raspberry pi, what remaining steps would I need to take to get the OV2740 working?

6by9 commented 1 year ago

AFAIK there is no vendor selling a module that is compatible with the Pi. The Misumi module that moritzvonwrangel linked to requires an external clock that the Pi doesn't provide. Until there is a module available that can be tested, I won't push anything for merge. If anyone else wishes to maintain such a driver, they're welcome to create a PR.

If you want a simple approach for a 1080p60 camera, then the IMX327 (or IMX290 or IMX462 which are the successors) have drivers and overlays already working, and can be easily bought from a few manufacturers. Why specifically are you wanting to use the OV2740?

JosephFeld commented 1 year ago

@6by9 I have an OV2740 on one of the misumi modules that @moritzvonwrangel linked to since it's the only camera I've found with a small enough form factor for my application. I can provide my own clock signal using a function generator. @steveninfibi and @moritzvonwrangel, did you get the OV2740 working? If so, could you share you code? If not, would you want help?

misumi-800 commented 1 year ago

@6by9 Please e-mail:mscctv@misumi.com.tw Contact: Isable

misumi-800 commented 1 year ago

@6by9 link RPi Driver File and SOP https://www.misumi.com.tw/en/support/download#a17

6by9 commented 1 year ago

@misumi-800

Thank you for the link to your driver files, but there are a few significant issues.

The Linux kernel is licenced under the GPLv2 licence - https://opensource.org/licenses/gpl-2.0.php Your module information states

~/Pi/tmp/ov2740/5.15.61-v7l+$ modinfo ov2740.ko
filename:       /home/user/Pi/tmp/ov2740/5.15.61-v7l+/ov2740.ko
license:        GPL v2
description:    OmniVision OV2740 sensor driver
author:         Bingbu Cao <bingbu.cao@intel.com>
author:         Shawn Tu <shawnx.tu@intel.com>
author:         Qiu, Tianshu <tian.shu.qiu@intel.com>
srcversion:     08409EB08598916F319DE12
alias:          acpi*:INT3474:*
alias:          of:N*T*Covti,ov2740C*
alias:          of:N*T*Covti,ov2740
depends:        videodev,v4l2-async,v4l2-fwnode,mc,regmap-i2c
intree:         Y
name:           ov2740
vermagic:       5.15.70-v7l-ov2740+ SMP mod_unload modversions ARMv7 p2v8

That presumably means you've modified the driver from https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov2740.c that also states it is GPLv2.

Clause 3 of the licence:

You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

Distributing only pre-compiled modules violates those licence terms.

Also note clause 2a

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

Currently there is no such information, therefore the original authors at Intel would likely get any bug reports on your modules.

This repo hosts the source code of the Linux kernel as built for Raspberry Pi. We do not accept pre-compiled modules as there is then no way to rebuild them when the kernel is updated (done automatically via Github workflows on every update of this source repo).

If you have validated whatever changes you've made with your module on Raspberry Pi, and are willing to provide ongoing support for it, then please create a Pull Request with the source changes. They can then be reviewed and merged into the kernel tree. Beyond ensuring the driver builds, Raspberry Pi can not be responsible for the maintenance of your driver modifications.

Ideally changes to the driver should be submitted to the mainline Linux tree via the linux-media mailing list, as then the maintenance burden is shifted to mainline. I do acknowledge that that can be a little daunting for a first time submitter. The overlays only live in our downstream tree, so will only be merged via a pull request.

libcamera changes should be submitted to the libcamera mailing list. Presumably you've added a tuning file (I can see that) and a cam_helper to the Pi IPA. Beyond that it's impossible for us to tell what has been done.

misumi-800 commented 1 year ago

Dear sir,

Good day to you.

Just back from long holiday, we are working under pressure.

Hope to get back to you upon engineer feedback is available in these two days.

Your understanding is highly appreciated.

Best regards, Isabel Hsu

https://www.youtube.com/user/misumi101 You https://www.youtube.com/user/misumi101 tube https://www.facebook.com/Misumi-Electronic-Corporation-137240736386869/ Facebook MISUMI Electronics Corp. | Manufacturer & Exporter | Since 1982 5F-3, No.70, Jian 6th Rd., Zhonghe Dist., New Taipei City 23585, Taiwan Tel: +886-2-2226-6303 Fax: +886-2-2222-5620 Skype: callto://mscctv mscctv (message) or callto://misumi-800 misumi-800 ( for call only) Email: @.> @. What's app: +886 968 037 681 WeChat: misumi_tw168 Line: @100namms

(To prevent fraud, please make sure both beneficiary name and A/C number are correct before money transfer.)

From: 6by9 @.> Sent: Thursday, February 2, 2023 9:49 PM To: raspberrypi/linux @.> Cc: misumi-800 @.>; Mention @.> Subject: Re: [raspberrypi/linux] Missing OV2740-MIPI-driver in compiled binaries (Issue #5170)

@misumi-800 https://github.com/misumi-800

Thank you for the link to your driver files, but there are a few significant issues.

The Linux kernel is licenced under the GPLv2 licence - https://opensource.org/licenses/gpl-2.0.php Your module information states

~/Pi/tmp/ov2740/5.15.61-v7l+$ modinfo ov2740.ko filename: /home/user/Pi/tmp/ov2740/5.15.61-v7l+/ov2740.ko license: GPL v2 description: OmniVision OV2740 sensor driver author: Bingbu Cao @.> author: Shawn Tu @.> author: Qiu, Tianshu @.**> srcversion: 08409EB08598916F319DE12 alias: acpi:INT3474: alias: of:NTCovti,ov2740C alias: of:NTCovti,ov2740 depends: videodev,v4l2-async,v4l2-fwnode,mc,regmap-i2c intree: Y name: ov2740 vermagic: 5.15.70-v7l-ov2740+ SMP mod_unload modversions ARMv7 p2v8

That presumably means you've modified the driver from https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov2740.c that also states it is GPLv2.

Clause 3 of the licence:

You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

Distributing only pre-compiled modules violates those licence terms.

Also note clause 2a

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

Currently there is no such information, therefore the original authors at Intel would likely get any bug reports on your modules.

This repo hosts the source code of the Linux kernel as built for Raspberry Pi. We do not accept pre-compiled modules as there is then no way to rebuild them when the kernel is updated (done automatically via Github workflows on every update of this source repo).

If you have validated whatever changes you've made with your module on Raspberry Pi, and are willing to provide ongoing support for it, then please create a Pull Request https://github.com/raspberrypi/linux/pulls with the source changes. They can then be reviewed and merged into the kernel tree. Beyond ensuring the driver builds, Raspberry Pi can not be responsible for the maintenance of your driver modifications.

Ideally changes to the driver should be submitted to the mainline Linux tree via the linux-media mailing list https://www.linuxtv.org/lists.php , as then the maintenance burden is shifted to mainline. I do acknowledge that that can be a little daunting for a first time submitter. The overlays only live in our downstream tree, so will only be merged via a pull request.

libcamera changes should be submitted to the libcamera mailing list https://libcamera.org/contributing.html . Presumably you've added a tuning file (I can see that) and a cam_helper to the Pi IPA. Beyond that it's impossible for us to tell what has been done.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/5170#issuecomment-1413774307 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A5TC5B247GDODT5ORRQJUGDWVO3LPANCNFSM6AAAAAAQIOVFAQ . You are receiving this because you were mentioned.Message ID: @.***>

misumi-800 commented 1 year ago

Dear Sir,

We understand its GPL v3 now. We are not quite sure about submit code process, and we will check or we release it on web. However, we will release source eventually. We prepares to release source now, and will release it soon. We will update you again once the source code released. Thanks.

Best regards, Isabel Hsu

https://www.youtube.com/user/misumi101 You https://www.youtube.com/user/misumi101 tube https://www.facebook.com/Misumi-Electronic-Corporation-137240736386869/ Facebook MISUMI Electronics Corp. | Manufacturer & Exporter | Since 1982 5F-3, No.70, Jian 6th Rd., Zhonghe Dist., New Taipei City 23585, Taiwan Tel: +886-2-2226-6303 Fax: +886-2-2222-5620 Skype: callto://mscctv mscctv (message) or callto://misumi-800 misumi-800 ( for call only) Email: @.> @. What's app: +886 968 037 681 WeChat: misumi_tw168 Line: @100namms

(To prevent fraud, please make sure both beneficiary name and A/C number are correct before money transfer.)

From: 6by9 @.> Sent: Thursday, February 2, 2023 9:49 PM To: raspberrypi/linux @.> Cc: misumi-800 @.>; Mention @.> Subject: Re: [raspberrypi/linux] Missing OV2740-MIPI-driver in compiled binaries (Issue #5170)

@misumi-800 https://github.com/misumi-800

Thank you for the link to your driver files, but there are a few significant issues.

The Linux kernel is licenced under the GPLv2 licence - https://opensource.org/licenses/gpl-2.0.php Your module information states

~/Pi/tmp/ov2740/5.15.61-v7l+$ modinfo ov2740.ko filename: /home/user/Pi/tmp/ov2740/5.15.61-v7l+/ov2740.ko license: GPL v2 description: OmniVision OV2740 sensor driver author: Bingbu Cao @.> author: Shawn Tu @.> author: Qiu, Tianshu @.**> srcversion: 08409EB08598916F319DE12 alias: acpi:INT3474: alias: of:NTCovti,ov2740C alias: of:NTCovti,ov2740 depends: videodev,v4l2-async,v4l2-fwnode,mc,regmap-i2c intree: Y name: ov2740 vermagic: 5.15.70-v7l-ov2740+ SMP mod_unload modversions ARMv7 p2v8

That presumably means you've modified the driver from https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov2740.c that also states it is GPLv2.

Clause 3 of the licence:

You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

Distributing only pre-compiled modules violates those licence terms.

Also note clause 2a

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

Currently there is no such information, therefore the original authors at Intel would likely get any bug reports on your modules.

This repo hosts the source code of the Linux kernel as built for Raspberry Pi. We do not accept pre-compiled modules as there is then no way to rebuild them when the kernel is updated (done automatically via Github workflows on every update of this source repo).

If you have validated whatever changes you've made with your module on Raspberry Pi, and are willing to provide ongoing support for it, then please create a Pull Request https://github.com/raspberrypi/linux/pulls with the source changes. They can then be reviewed and merged into the kernel tree. Beyond ensuring the driver builds, Raspberry Pi can not be responsible for the maintenance of your driver modifications.

Ideally changes to the driver should be submitted to the mainline Linux tree via the linux-media mailing list https://www.linuxtv.org/lists.php , as then the maintenance burden is shifted to mainline. I do acknowledge that that can be a little daunting for a first time submitter. The overlays only live in our downstream tree, so will only be merged via a pull request.

libcamera changes should be submitted to the libcamera mailing list https://libcamera.org/contributing.html . Presumably you've added a tuning file (I can see that) and a cam_helper to the Pi IPA. Beyond that it's impossible for us to tell what has been done.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/5170#issuecomment-1413774307 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A5TC5B247GDODT5ORRQJUGDWVO3LPANCNFSM6AAAAAAQIOVFAQ . You are receiving this because you were mentioned.Message ID: @.***>

6by9 commented 1 year ago

We understand its GPL v3 now. We are not quite sure about submit code process, and we will check or we release it on web. However, we will release source eventually. We prepares to release source now, and will release it soon. We will update you again once the source code released. Thanks.

The kernel is GPLv2. v3 adds more restrictions which haven't always been accepted by developers, and see https://www.kernel.org/doc/html/latest/process/1.Intro.html#licensing for the issues in changing the licence when ownership is split between all contributors to the project.

Source control is all through a system called git, hence this being git hub.

If you wish to submit patches, then you fork this repo to create your own copy on Github, push your changes to it, and then create a "pull request" to ask for your changes to be reviewed and merged. Patches should do one thing, and you create a sequence of them to add all the functionality you want (eg see https://github.com/6by9/linux/commits/rpi-5.15.y-ov2740 for the changes that I had proposed as necessary for this sensor).

The general docs for kernel development are https://www.kernel.org/doc/html/latest/process/development-process.html https://www.kernel.org/doc/html/latest/process/submitting-patches.html (this is submitting to mainline kernel rather than the Raspberry Pi tree. We have largely the same requirements, and would ideally like to see patches merged into mainline if at all possible)

I'm happy to assist if you wish to put your engineer's in contact - you have my email address.

nilsmelchert commented 1 year ago

@6by9 it seems like the source code is now available on the website which was posted above:

https://www.misumi.com.tw/en/support/download#a17

I would be great to see a PR for this. Would @misumi-800 take care of this? Otherwise I would offer to test the code and create a PR.

6by9 commented 1 year ago

Looking at that ZIP file, it looks to have a bundle of good stuff in there, but also some bits that aren't acceptable.

A patch set for a PR also needs to be a sequence of patches that each do one thing, not a big splat of changes. That's why https://github.com/6by9/linux/commits/rpi-5.15.y-ov2740 has 5 patches changing the driver, rather than 1. Patches need a Signed-off-by: tag so that the authorship is obvious and there is no ambiguity over the grant of GPLv2 licence for the code - see https://www.kernel.org/doc/html/latest/process/submitting-patches.html

The bits that aren't acceptable, or at least need justification

Dropping 19.2MHz clock to only support 24MHz.
Chunks of code commented out or disabled via #if 1 ... #endif```` /#if 0 ... #endif, particularly as some of the other paths won't compile (two definitions ofmipi_data_rate_720mbps``` for example)
Arbitrary change of resolution from 1932x1096 to 1936x1096. From the datasheet fig 3-1 the sensor is meant to only have 1920x1080 active pixels, with 8 dummy active pixels on each edge (total array size 1936x1096). Are we really reading the dummy pixels? The current driver registers are setting [HV]ROP_START] to (0,0), [HV]CROP_END to (1935,1095), and [HV]_OUTPUT_SIZE of (1932x1092) but that is now commented out so it will be the defaults of (0,4) to (2035,1091) with size (1920x1080), so I don't see how that works.
Changes to HTS register without explanation and not reflected in V4L2_CID_HBLANK - that will mess up the exposure and frame rate calculations.
Change of Bayer order from GRBG to BGGR - Have they changed the start line number by 1 to change the order, changed a flip/mirror option, or was the original just wrong?
it's based on an older kernel revision - rpi-6.1.y is now the default, and there have been changes from mainline Linux to that driver. I'm just creating a version of my rpi-5.15.y-ov2740 branch based on rpi-6.1.y, but I can't test it.

We do not have the resources to maintain many downstream image sensor drivers. For a few modules that are easily available we have undertaken additional work, but currently I don't see ov2740 in that category. All support needs to come from the contributor of the driver changes, particularly if we don't have modules to test with. This is already the case with irs1125, imx519, arducam_64mp, and arducam_pivariety.

All patches to existing drivers should really be submitted to the linux-media mailing list to be integrated into the main Linux code base. Doing so avoids issues with merging changes when mainline is updated.

6by9 commented 1 year ago

Branch https://github.com/6by9/linux/tree/rpi-6.1.y-ov2740 pushed which updates for 6.1.

raspberrypi / linux