Please don't fork ipu7 support as a separate repository

[vicamo]

For the kernel side, the official way to integrate ipu6-drivers has always been in-tree builds, and the out-of-tree dkms builds breaks from time to time. Under in-tree builds, you copy related driver source files along with Kconfig/Makefile changes into the kernel tree to be integrated. If there are two such in-tree builds, e.g. one ipu6 and one ipu7, the related files are meant to be conflicting to each other, and actually they (for example, drivers/media/pci/intel/cio2-bridge.*) are different right now. Forking kernel drivers with common components is never a good idea. You should really integrate ipu7 drivers into ipu6-drivers instead.

For the userspace side, please always keep in mind that you may have only one instance of a specific file path in the system. For now it appears the HAL and bins repositories are empty and icamerasrc is shared with ipu6, but creating a separate repository for HAL and bins has already been sufficient to raise a concern of potential path conflicts.

[drhooray]

Thanks for pointing out the issue, Vicamo.

the related files are meant to be conflicting to each other, and actually they (for example, drivers/media/pci/intel/cio2-bridge.*)

Based on the latest release (tag -20240625_1600), the ipu7 will change to use ipu-bridge (based on v6.8-rc4 in kernel.org).
So the conflicting part should be mitigated.

Forking kernel drivers with common components is never a good idea. You should really integrate ipu7 drivers into ipu6-drivers instead.

Understood, However, the new ISP generation of software driver is based on the new hardware design.
Do other chipset vendors use the same driver architecture for their new ISP and also support their old chipset?

For the userspace side, please always keep in mind that you may have only one instance of a specific file path in the system.

Yes, you are right. There is a gap on userspace side. We will follow up this part.

[vicamo]

Thanks for pointing out the issue, Vicamo.

the related files are meant to be conflicting to each other, and actually they (for example, drivers/media/pci/intel/cio2-bridge.*)

Based on the latest release (tag -20240625_1600), the ipu7 will change to use ipu-bridge (based on v6.8-rc4 in kernel.org). So the conflicting part should be mitigated.

While you just created #6, which duplicated the source of in-tree module ipu-bridge, does one have to update that patch when new changes are being backported to the kernel tree for ipu6? You created a chaos to manage patches across these two ipu drivers and the kernel.

Forking kernel drivers with common components is never a good idea. You should really integrate ipu7 drivers into ipu6-drivers instead.

Understood, However, the new ISP generation of software driver is based on the new hardware design. Do other chipset vendors use the same driver architecture for their new ISP and also support their old chipset?

Like everyone? You will be questioned the same thing when Intel tries to upstream ipu7. There are tons of the duplicated code from ipu6. Please justify the actual need of such duplication rather than laziness and/or incapability.

For the userspace side, please always keep in mind that you may have only one instance of a specific file path in the system.

Yes, you are right. There is a gap on userspace side. We will follow up this part.