On 5/19/25 11:35 AM, Johan Hovold wrote: > On Sat, May 17, 2025 at 07:27:49PM +0200, Konrad Dybcio wrote: >> SC8280XP features a SLPI, much like its distant relative, SM8350. > > Please get into the habit of spelling out *and* explaining internal > Qualcomm acronyms like "SLPI" so that your cover letter and commit > messages makes sense to people outside of Qualcomm.
It's difficult to judge which acronyms are known when half the words I type on my other computer are TLAs.. > > Also say something about whether and how this is useful for anyone > currently or if it, for example, depends on Qualcomm proprietary user > space bits. > >> Dmitry Baryshkov (1): >> arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: enable sensors DSP > > At first I was worried that missing firmware could cause issues here > (e.g. drivers not reaching sync state as with venus), but Lenovo has > indeed released the SLPI firmware already. > > Are there any other potential downsides to enabling this (e.g. before > anyone can actually use the sensors)? It's probably only upsides resulting from keeping the rproc in a known state > >> Konrad Dybcio (4): >> dt-bindings: remoteproc: qcom,sm8350-pas: Add SC8280XP >> arm64: dts: qcom: sc8280xp: Fix node order >> arm64: dts: qcom: sc8280xp: Add SLPI > >> arm64: dts: qcom: sc8280xp-crd: Enable SLPI > > Without firmware this results in errors like: > > remoteproc remoteproc0: slpi is available > remoteproc remoteproc0: Direct firmware load for > qcom/sc8280xp/qcslpi8280.mbn failed with error -2 > remoteproc remoteproc0: powering up slpi > remoteproc remoteproc0: Direct firmware load for > qcom/sc8280xp/qcslpi8280.mbn failed with error -2 > remoteproc remoteproc0: request_firmware failed: -2 > > but enabling for the CRD reference design and requiring users (read: > developers) to copy it from Windows should be OK. We shouldn't expect non-developers to have the CRD on hand, right? ;)
