Move dtbos to this tree

[lool]

Hi

The camx kernel drivers are permanently out of tree. We'd like to package them as a DKMS so that these could be built against any installed kernel headers, or used as a build-dependency of a full kernel build.

While the kernel driver sources are in this repository, but the device tree overlays for various platforms are maintained as qcom-next patches.

Could we please move the DT overlays to this repository, so that they could be delivered/built against any kernel?

Thanks!

[cjha01]

Thanks for raising this! We want to make sure we fully understand the ask before proceeding.

Currently, our setup is:

Camera driver source is consumed from qualcomm-linux/pkg-camx-dkms and packaged as DKMS.
Camera Device Tree (DT) files are sourced from the kernel tree at qualcomm-linux/kernel (qcom-next), which aligns with the in-tree kernel approach.

Our understanding of the original ask is:

The camera DT is currently delivered as qcom-next patches (in-tree). You are now proposing to move the DT overlays out-of-tree into the camera driver repository, so they can be built and delivered independently of the kernel — similar to the DKMS model used for the driver sources.

Is that the right understanding?

If so, we'd like to flag a concern — ideally, we should align this with the Yocto workflow as well, since the DT overlays are also consumed there. Any out-of-tree movement would need to be reflected consistently across both the Debian/DKMS and Yocto/BitBake delivery models to avoid divergence.

Could you please help clarify the full intent so we can evaluate the best path forward?

[lool]

Is that the right understanding?

Yup!

If so, we'd like to flag a concern — ideally, we should align this with the Yocto workflow as well, since the DT overlays are also consumed there. Any out-of-tree movement would need to be reflected consistently across both the Debian/DKMS and Yocto/BitBake delivery models to avoid divergence.

I agree that the end-result should be consumable by both Yocto and Debian (and other distros!). I think this change will help precisely with that.

Could you please help clarify the full intent so we can evaluate the best path forward?

The immediate need is to be able to package and test camx-dkms standalone in various Debian releases and derivatives against various kernels, in a true DKMS way. The longer term need is having this easily consumable in any distro.

[cjha01]

Is that the right understanding?

Yup!

If so, we'd like to flag a concern — ideally, we should align this with the Yocto workflow as well, since the DT overlays are also consumed there. Any out-of-tree movement would need to be reflected consistently across both the Debian/DKMS and Yocto/BitBake delivery models to avoid divergence.

I agree that the end-result should be consumable by both Yocto and Debian (and other distros!). I think this change will help precisely with that.

Could you please help clarify the full intent so we can evaluate the best path forward?

The immediate need is to be able to package and test camx-dkms standalone in various Debian releases and derivatives against various kernels, in a true DKMS way. The longer term need is having this easily consumable in any distro.

We will check this with the team and get back from a feasibility perspective.

Previously (before QLI mainline), the camera DT was out-of-tree, and static (compile-time) overlay was being used. However, as part of the QLI mainline Yocto effort, it was recommended to move all tech overlay DT into the tree to ensure alignment across teams, which is what we followed.

If we consider moving it out-of-tree again, there are multiple challenges and open questions, such as how to implement runtime DT overlay and how to remove dependency on qcom-next tech branches, since they are loaded by default.

Given these complexities, we expect several technical discussions will be needed. We will connect with you over a call to better understand the requirements and evaluate feasibility.

At this point, we do not have a clear assessment of feasibility. We will analyze the technical constraints and dependencies in detail and proceed further.