fastrpcdlkm: Add recipe to support fastrpc DLKM by ekanshibu · Pull Request #857 · qualcomm-linux/meta-qcom

ekanshibu · 2025-04-30T10:48:05Z

FastRPC DLKM carries additional features like static PD restart and enhanced invocation support. Add recipe to support fastrpc DLKM.

FastRPC DLKM carries additional features like static PD restart and enhanced invocation support. Add recipe to support fastrpc DLKM. Signed-off-by: Ekansh Gupta <[email protected]>

github-actions · 2025-04-30T11:27:23Z

Test Results

3 files ±0 6 suites ±0 2m 18s ⏱️ ±0s
23 tests ±0 23 ✅ ±0 0 💤 ±0 0 ❌ ±0
57 runs ±0 57 ✅ ±0 0 💤 ±0 0 ❌ ±0

Results for commit 3ed4f50. ± Comparison against base commit e701e3a.

github-actions · 2025-04-30T11:27:24Z

Test jobs for commit `3ed4f50`

sbanerjee-quic · 2025-04-30T12:49:24Z

@quic-ekangupt need the corresponding change to include this in the CI

vkraleti · 2025-04-30T13:45:54Z

@quic-ekangupt as discussed in #854 (comment) as this is a kernel module recipe, place it under recipes-kernel/fastrpc-module.

vkraleti · 2025-04-30T13:46:02Z

recipes-multimedia/fastrpcdlkm/fastrpcdlkm_1.0.bb

+
+RPROVIDES:${PN} += "kernel-module-fastrpc-kernel"
+
+FILESPATH =+ "${WORKSPACE}:"


vkraleti · 2025-04-30T13:47:12Z

recipes-multimedia/fastrpcdlkm/fastrpcdlkm_1.0.bb

+
+EXTRA_OEMAKE += "M=${S}"
+
+RPROVIDES:${PN} += "kernel-module-fastrpc-kernel"


Why to use an additional RPROVIDES? Which other recipe is referring this module as "fastrpc-kernel" ?

vkraleti · 2025-04-30T13:51:00Z

recipes-multimedia/fastrpcdlkm/fastrpcdlkm_1.0.bb

+
+MAKE_TARGETS = "modules"
+
+MODULES_INSTALL_TARGET = "modules_install"


No need. modules.bbclass already defaults to this.

vkraleti · 2025-04-30T13:52:28Z

recipes-multimedia/fastrpcdlkm/fastrpcdlkm_1.0.bb

+
+SRC_URI = "git://git.codelinaro.org/clo/la/platform/vendor/qcom/opensource/dsp-kernel.git;protocol=https;branch=dsp-kernel.lnx.3.3;destsuffix=vendor/qcom/opensource/dsp-kernel"
+
+S = "${WORKDIR}/vendor/qcom/opensource/dsp-kernel"


remove destsuffix in SRC_URI and set S = "${WORKDIR}/git"

lumag · 2025-04-30T16:41:12Z

Definite NAK. Please include the relevant patches into the linux-yocto / linux-qcom rather than pulling full DKML.
DKLMs are a way to provide missing drivers for the IP blocks that we don't support upstream (like vidc, camera ISP, etc). If we have a driver, we should not be using DKLMs in a way to circumvent upstreaming rules / requirements.

ricardosalveti · 2025-04-30T16:51:24Z

Didn't compare the sources, but is this a fork of the upstream driver? If so I'm also aligned with @lumag, should be proposed as kernel patches instead.

ekanshibu · 2025-05-13T09:01:19Z

Definite NAK. Please include the relevant patches into the linux-yocto / linux-qcom rather than pulling full DKML. DKLMs are a way to provide missing drivers for the IP blocks that we don't support upstream (like vidc, camera ISP, etc). If we have a driver, we should not be using DKLMs in a way to circumvent upstreaming rules / requirements.

I have 1 question regarding maintaining patches into linux-yocto / linux-qcom, what are the expectations for any patch carrying uAPI change?

ekanshibu · 2025-05-16T05:41:00Z

Definite NAK. Please include the relevant patches into the linux-yocto / linux-qcom rather than pulling full DKML. DKLMs are a way to provide missing drivers for the IP blocks that we don't support upstream (like vidc, camera ISP, etc). If we have a driver, we should not be using DKLMs in a way to circumvent upstreaming rules / requirements.

I have 1 question regarding maintaining patches into linux-yocto / linux-qcom, what are the expectations for any patch carrying uAPI change?

I'm seeking details for this, please help with your comments. @lumag, @ricardosalveti

ndechesne · 2025-05-16T08:01:53Z

if the uAPI change has been discussed and reviewed upstream it's not a problem. If it's a custom never-going-upstream uAPI, we are going to push back on it.

Please note that we are moving soon away from linux-yocto-dev, and we will be using a QCOM hosted kernel (qcom-next). At this point we will no longer carry any kernel patches in meta-qcom.

ekanshibu · 2025-05-16T09:47:08Z

if the uAPI change has been discussed and reviewed upstream it's not a problem. If it's a custom never-going-upstream uAPI, we are going to push back on it.

Please note that we are moving soon away from linux-yocto-dev, and we will be using a QCOM hosted kernel (qcom-next). At this point we will no longer carry any kernel patches in meta-qcom.

Thanks for the explanation. I have 2 follow-up questions:

For any feature which uAPI change with no immediate upstream plans, What should be the steps once migration to qcom-next is done? I believe such changes cannot be merged in qcom-next(or topic branches).
Say if any uAPI change is under review upstream and is merged onto qcom-next, can I pull the corresponding user library change over here to meta-qcom(maybe as a .patch)?

ndechesne · 2025-05-16T09:52:47Z

Thanks for the explanation. I have 2 follow-up questions:

For any feature which uAPI change with no immediate upstream plans, What should be the steps once migration to qcom-next is done? I believe such changes cannot be merged in qcom-next(or topic branches).

That's when we get into issues :) and when we need to deep dive a bit more.
The right approach would be to have a 'less features' variant of your software (e.g. what we call the base variant). Which is intended to work purely on top of upstream.

Note that with the 'clean overlay' approach and ongoing discussions, this will be no longer acceptable anyway. e.g. any of our QCOM 'value add' (or non upstream, proprietary, ...) solutions will need to work with a vanilla upstream kernel.

Say if any uAPI change is under review upstream and is merged onto qcom-next, can I pull the corresponding user library change over here to meta-qcom(maybe as a .patch)?

Yes, if the uAPI change is actively being upstream and with some hints that it will eventually get merged, then it will be accepted in qcom-next, and then we will accept corresponding user space changes in meta-qcom, of course.

lumag · 2025-05-16T13:08:09Z

@quic-ekangupt for the sake of it. No, adding extra uAPI to fastrpc driver is not possible. If I read it correctly, it was vetoed by Simona.

ekanshibu · 2025-08-02T03:44:57Z

Closing the PR as this dlkm change is dropped and the polling feature is discussed to be brought from upstream.

fastrpcdlkm: Add recipe to support fastrpc DLKM

3ed4f50

FastRPC DLKM carries additional features like static PD restart and enhanced invocation support. Add recipe to support fastrpc DLKM. Signed-off-by: Ekansh Gupta <[email protected]>

ekanshibu requested review from ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners April 30, 2025 10:48

vkraleti reviewed Apr 30, 2025

View reviewed changes

ekanshibu closed this Aug 2, 2025

ekanshibu deleted the fastrpcdlkm branch August 29, 2025 10:52


		RPROVIDES:${PN} += "kernel-module-fastrpc-kernel"

		FILESPATH =+ "${WORKSPACE}:"


		EXTRA_OEMAKE += "M=${S}"

		RPROVIDES:${PN} += "kernel-module-fastrpc-kernel"


		MAKE_TARGETS = "modules"

		MODULES_INSTALL_TARGET = "modules_install"


		SRC_URI = "git://git.codelinaro.org/clo/la/platform/vendor/qcom/opensource/dsp-kernel.git;protocol=https;branch=dsp-kernel.lnx.3.3;destsuffix=vendor/qcom/opensource/dsp-kernel"

		S = "${WORKDIR}/vendor/qcom/opensource/dsp-kernel"

Conversation

ekanshibu commented Apr 30, 2025

Uh oh!

github-actions bot commented Apr 30, 2025

Test Results

Uh oh!

github-actions bot commented Apr 30, 2025

Test jobs for commit 3ed4f50

Uh oh!

sbanerjee-quic commented Apr 30, 2025

Uh oh!

vkraleti commented Apr 30, 2025

Uh oh!

vkraleti Apr 30, 2025

Choose a reason for hiding this comment

Uh oh!

vkraleti Apr 30, 2025

Choose a reason for hiding this comment

Uh oh!

vkraleti Apr 30, 2025

Choose a reason for hiding this comment

Uh oh!

vkraleti Apr 30, 2025

Choose a reason for hiding this comment

Uh oh!

lumag commented Apr 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ricardosalveti commented Apr 30, 2025

Uh oh!

ekanshibu commented May 13, 2025

Uh oh!

ekanshibu commented May 16, 2025

Uh oh!

ndechesne commented May 16, 2025

Uh oh!

ekanshibu commented May 16, 2025

Uh oh!

ndechesne commented May 16, 2025

Uh oh!

lumag commented May 16, 2025

Uh oh!

ekanshibu commented Aug 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Test jobs for commit `3ed4f50`

lumag commented Apr 30, 2025 •

edited

Loading