Re: [PATCH v3] dt-bindings: remoteproc: qcom,sa8775p-pas: Document QCS8300 remoteproc
On Wed, 25 Sept 2024 at 10:35, Jingyi Wang wrote: > > > > On 9/25/2024 4:01 PM, Dmitry Baryshkov wrote: > > On Wed, Sep 25, 2024 at 03:21:37PM GMT, Jingyi Wang wrote: > >> Document the components used to boot the ADSP, CDSP and GPDSP on the > >> Qualcomm QCS8300 SoC. Use fallback to indicate the compatibility of the > >> remoteproc on the QCS8300 with that on the SA8775P. > > Hi Dmitry, > > > > > Are there any SoC-specific quirks that demand a separate compat string? > > > > In other similar cases (sm8250 vs qrb5165, sc7280 vs qcm6490 vs qcs6490 > > we are adding new compatibles only if it is expected that the hardware > > (or firmware) is actually different. > > > > This case is different from the cases above as qcs8300 and sa8775p are > different SoCs.(sm8250 and qrb5165 are different variants for the same > SoC). QCS8300 has one cdsp&gpdsp while SA8775P has 2, but they share the > same driver data, we used to discuss with Krzysztof how to deal case > like this and got the following suggestion to use fallback in yaml: > https://lore.kernel.org/all/6652a08e-7143-4214-a864-9f27c10d7...@kernel.org/ Ack, excuse me. I got confused by qcs8300 vs qcs9100. > > >> Co-developed-by: Xin Liu > >> Signed-off-by: Xin Liu > >> Signed-off-by: Jingyi Wang > >> --- > >> Changes in v3: > >> - add "contains" and remove redundant compatible. > >> - Link to v2: > >> https://lore.kernel.org/r/20240911-qcs8300_remoteproc_binding-v2-1-01921b110...@quicinc.com > >> > >> Changes in v2: > >> - decoupled from the original series. > >> - Use fallback to indicate compatibility with SA8775P. > >> - Link to v1: > >> https://lore.kernel.org/r/20240904-qcs8300_initial_dtsi-v1-0-d0ea9afdc...@quicinc.com > >> --- > >> .../bindings/remoteproc/qcom,sa8775p-pas.yaml | 44 > >> +++--- > >> 1 file changed, 30 insertions(+), 14 deletions(-) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > >> b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > >> index 7fe401a06805..a66007951d58 100644 > >> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > >> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > >> @@ -15,12 +15,25 @@ description: > >> > >> properties: > >>compatible: > >> -enum: > >> - - qcom,sa8775p-adsp-pas > >> - - qcom,sa8775p-cdsp0-pas > >> - - qcom,sa8775p-cdsp1-pas > >> - - qcom,sa8775p-gpdsp0-pas > >> - - qcom,sa8775p-gpdsp1-pas > >> +oneOf: > >> + - items: > >> + - enum: > >> + - qcom,qcs8300-adsp-pas > >> + - const: qcom,sa8775p-adsp-pas > >> + - items: > >> + - enum: > >> + - qcom,qcs8300-cdsp-pas > >> + - const: qcom,sa8775p-cdsp0-pas > >> + - items: > >> + - enum: > >> + - qcom,qcs8300-gpdsp-pas > >> + - const: qcom,sa8775p-gpdsp0-pas > >> + - enum: > >> + - qcom,sa8775p-adsp-pas > >> + - qcom,sa8775p-cdsp0-pas > >> + - qcom,sa8775p-cdsp1-pas > >> + - qcom,sa8775p-gpdsp0-pas > >> + - qcom,sa8775p-gpdsp1-pas > >> > >>reg: > >> maxItems: 1 > >> @@ -63,8 +76,9 @@ allOf: > >>- if: > >>properties: > >> compatible: > >> - enum: > >> -- qcom,sa8775p-adsp-pas > >> + contains: > >> +enum: > >> + - qcom,sa8775p-adsp-pas > >> then: > >>properties: > >> power-domains: > >> @@ -79,9 +93,10 @@ allOf: > >>- if: > >>properties: > >> compatible: > >> - enum: > >> -- qcom,sa8775p-cdsp0-pas > >> -- qcom,sa8775p-cdsp1-pas > >> + contains: > >> +enum: > >> + - qcom,sa8775p-cdsp0-pas > >> + - qcom,sa8775p-cdsp1-pas > >> then: > >>properties: > >> power-domains: > >> @@ -98,9 +113,10 @@ allOf: > >>- if: > >>properties: > >> compatible: > >> - enum: > >> -- qcom,sa8775p-gpdsp0-pas > >> -- qcom,sa8775p-gpdsp1-pas > >> + contains: > >> +enum: > >> + - qcom,sa8775p-gpdsp0-pas > >> + - qcom,sa8775p-gpdsp1-pas > >> then: > >>properties: > >> power-domains: > >> > >> --- > >> base-commit: 4d0326b60bb753627437fff0f76bf1525bcda422 > >> change-id: 20240925-qcs8300_remoteproc_binding-a2837bab2150 > >> > >> Best regards, > >> -- > >> Jingyi Wang > >> > > > Thanks, > Jingyi > -- With best wishes Dmitry
Re: [PATCH v3] dt-bindings: remoteproc: qcom,sa8775p-pas: Document QCS8300 remoteproc
On Wed, Sep 25, 2024 at 03:21:37PM GMT, Jingyi Wang wrote: > Document the components used to boot the ADSP, CDSP and GPDSP on the > Qualcomm QCS8300 SoC. Use fallback to indicate the compatibility of the > remoteproc on the QCS8300 with that on the SA8775P. Are there any SoC-specific quirks that demand a separate compat string? In other similar cases (sm8250 vs qrb5165, sc7280 vs qcm6490 vs qcs6490 we are adding new compatibles only if it is expected that the hardware (or firmware) is actually different. > Co-developed-by: Xin Liu > Signed-off-by: Xin Liu > Signed-off-by: Jingyi Wang > --- > Changes in v3: > - add "contains" and remove redundant compatible. > - Link to v2: > https://lore.kernel.org/r/20240911-qcs8300_remoteproc_binding-v2-1-01921b110...@quicinc.com > > Changes in v2: > - decoupled from the original series. > - Use fallback to indicate compatibility with SA8775P. > - Link to v1: > https://lore.kernel.org/r/20240904-qcs8300_initial_dtsi-v1-0-d0ea9afdc...@quicinc.com > --- > .../bindings/remoteproc/qcom,sa8775p-pas.yaml | 44 > +++--- > 1 file changed, 30 insertions(+), 14 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > index 7fe401a06805..a66007951d58 100644 > --- a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml > @@ -15,12 +15,25 @@ description: > > properties: >compatible: > -enum: > - - qcom,sa8775p-adsp-pas > - - qcom,sa8775p-cdsp0-pas > - - qcom,sa8775p-cdsp1-pas > - - qcom,sa8775p-gpdsp0-pas > - - qcom,sa8775p-gpdsp1-pas > +oneOf: > + - items: > + - enum: > + - qcom,qcs8300-adsp-pas > + - const: qcom,sa8775p-adsp-pas > + - items: > + - enum: > + - qcom,qcs8300-cdsp-pas > + - const: qcom,sa8775p-cdsp0-pas > + - items: > + - enum: > + - qcom,qcs8300-gpdsp-pas > + - const: qcom,sa8775p-gpdsp0-pas > + - enum: > + - qcom,sa8775p-adsp-pas > + - qcom,sa8775p-cdsp0-pas > + - qcom,sa8775p-cdsp1-pas > + - qcom,sa8775p-gpdsp0-pas > + - qcom,sa8775p-gpdsp1-pas > >reg: > maxItems: 1 > @@ -63,8 +76,9 @@ allOf: >- if: >properties: > compatible: > - enum: > -- qcom,sa8775p-adsp-pas > + contains: > +enum: > + - qcom,sa8775p-adsp-pas > then: >properties: > power-domains: > @@ -79,9 +93,10 @@ allOf: >- if: >properties: > compatible: > - enum: > -- qcom,sa8775p-cdsp0-pas > -- qcom,sa8775p-cdsp1-pas > + contains: > +enum: > + - qcom,sa8775p-cdsp0-pas > + - qcom,sa8775p-cdsp1-pas > then: >properties: > power-domains: > @@ -98,9 +113,10 @@ allOf: >- if: >properties: > compatible: > - enum: > -- qcom,sa8775p-gpdsp0-pas > -- qcom,sa8775p-gpdsp1-pas > + contains: > +enum: > + - qcom,sa8775p-gpdsp0-pas > + - qcom,sa8775p-gpdsp1-pas > then: >properties: > power-domains: > > --- > base-commit: 4d0326b60bb753627437fff0f76bf1525bcda422 > change-id: 20240925-qcs8300_remoteproc_binding-a2837bab2150 > > Best regards, > -- > Jingyi Wang > -- With best wishes Dmitry
Re: [PATCH] remoteproc: qcom: q6v5-mss: Use common error handling code in q6v5_mpss_load()
On Tue, Sep 24, 2024 at 04:08:11PM GMT, Markus Elfring wrote:
> From: Markus Elfring
> Date: Tue, 24 Sep 2024 15:55:06 +0200
>
> Add jump targets so that a bit of exception handling can be better reused
> at the end of this function implementation.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/remoteproc/qcom_q6v5_mss.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 2a42215ce8e0..b398ae3083a1 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -1451,9 +1451,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
> dev_err(qproc->dev,
> "failed to load segment %d from
> truncated file %s\n",
> i, fw_name);
> - ret = -EINVAL;
Please keep error assignment where it is. It is much cleaner to read it
this way, rather than checking the error-handling basement.
> - memunmap(ptr);
> - goto release_firmware;
> + goto e_inval_unmap;
> }
>
> memcpy(ptr, fw->data + phdr->p_offset, phdr->p_filesz);
> @@ -1464,18 +1462,15 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
> ptr, phdr->p_filesz);
> if (ret) {
> dev_err(qproc->dev, "failed to load %s\n",
> fw_name);
> - memunmap(ptr);
> - goto release_firmware;
> + goto unmap_mem;
> }
>
> if (seg_fw->size != phdr->p_filesz) {
> dev_err(qproc->dev,
> "failed to load segment %d from
> truncated file %s\n",
> i, fw_name);
> - ret = -EINVAL;
> release_firmware(seg_fw);
> - memunmap(ptr);
> - goto release_firmware;
> + goto e_inval_unmap;
> }
>
> release_firmware(seg_fw);
> @@ -1528,6 +1523,12 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
> kfree(fw_name);
>
> return ret < 0 ? ret : 0;
> +
> +e_inval_unmap:
> + ret = -EINVAL;
> +unmap_mem:
> + memunmap(ptr);
> + goto release_firmware;
Ugh. No. ptr should be a variable that is declared inside the loop.
Calling memunmap outside of the for loop is incorrect. And goto just
complicates things by adding non-linearity.
> }
>
> static void qcom_q6v5_dump_segment(struct rproc *rproc,
> --
> 2.46.1
>
--
With best wishes
Dmitry
Re: [PATCH 17/19] arm64: defconfig: enable clock controller, interconnect and pinctrl for QCS8300
On Fri, 6 Sept 2024 at 09:15, Jingyi Wang wrote: > > Hi Dmitry, > > On 9/6/2024 11:18 AM, Dmitry Baryshkov wrote: > > On Thu, Sep 05, 2024 at 12:54:35PM GMT, Jingyi Wang wrote: > >> > >> > >> On 9/4/2024 5:39 PM, Krzysztof Kozlowski wrote: > >>> On 04/09/2024 10:33, Jingyi Wang wrote: > >>>> Enable clock controller, interrconnect and pinctrl for QCS8300. > >>> > >>> NXP QCS8300? What is QCS8300? Which products use it? That's a defconfig > >>> for entire kernel, not your Qualcomm one. > >>> > >> Will describe it in more detail. > >>>> It needs to be built-in for UART to provide a console. > >>>> > >>>> Signed-off-by: Jingyi Wang > >>>> --- > >>>> arch/arm64/configs/defconfig | 3 +++ > >>>> 1 file changed, 3 insertions(+) > >>>> > >>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > >>>> index 81ca46e3ab4b..a9ba6b25a0ed 100644 > >>>> --- a/arch/arm64/configs/defconfig > >>>> +++ b/arch/arm64/configs/defconfig > >>>> @@ -606,6 +606,7 @@ CONFIG_PINCTRL_MSM8996=y > >>>> CONFIG_PINCTRL_MSM8998=y > >>>> CONFIG_PINCTRL_QCM2290=y > >>>> CONFIG_PINCTRL_QCS404=y > >>>> +CONFIG_PINCTRL_QCS8300=y > >>>> CONFIG_PINCTRL_QDF2XXX=y > >>>> CONFIG_PINCTRL_QDU1000=y > >>>> CONFIG_PINCTRL_SA8775P=y > >>>> @@ -1317,6 +1318,7 @@ CONFIG_MSM_MMCC_8998=m > >>>> CONFIG_QCM_GCC_2290=y > >>>> CONFIG_QCM_DISPCC_2290=m > >>>> CONFIG_QCS_GCC_404=y > >>>> +CONFIG_QCS_GCC_8300=y > >>>> CONFIG_QDU_GCC_1000=y > >>>> CONFIG_SC_CAMCC_8280XP=m > >>>> CONFIG_SC_DISPCC_7280=m > >>>> @@ -1618,6 +1620,7 @@ CONFIG_INTERCONNECT_QCOM_MSM8996=y > >>>> CONFIG_INTERCONNECT_QCOM_OSM_L3=m > >>>> CONFIG_INTERCONNECT_QCOM_QCM2290=y > >>>> CONFIG_INTERCONNECT_QCOM_QCS404=m > >>>> +CONFIG_INTERCONNECT_QCOM_QCS8300=y > >>> > >>> Why this cannot be a module? > >>> > >>> > >> I think the commit-msg "It needs to be built-in for UART to provide a > >> console." can > >> explain that, could you please help to share your insights on that? > > > > Unless loading these modules from initramfs doesn't work, please use =m. > > The drivers that are enabled here are going to be enabled for everybody > > using arm64 defconfig, taking up memory on their platforms, etc. > > > We had previous discussion here about why these drivers needs to be built-in > to support > debug-uart: > https://lore.kernel.org/linux-arm-msm/c11fd3c2-770a-4d40-8cf3-d8bc81f7c...@kernel.org/ > I will mention more details in the commit message of this patch. Yes, please. Explicitly mention that this is required to get UART to work. -- With best wishes Dmitry
Re: [PATCH 17/19] arm64: defconfig: enable clock controller, interconnect and pinctrl for QCS8300
On Thu, Sep 05, 2024 at 12:54:35PM GMT, Jingyi Wang wrote: > > > On 9/4/2024 5:39 PM, Krzysztof Kozlowski wrote: > > On 04/09/2024 10:33, Jingyi Wang wrote: > >> Enable clock controller, interrconnect and pinctrl for QCS8300. > > > > NXP QCS8300? What is QCS8300? Which products use it? That's a defconfig > > for entire kernel, not your Qualcomm one. > > > Will describe it in more detail. > >> It needs to be built-in for UART to provide a console. > >> > >> Signed-off-by: Jingyi Wang > >> --- > >> arch/arm64/configs/defconfig | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > >> index 81ca46e3ab4b..a9ba6b25a0ed 100644 > >> --- a/arch/arm64/configs/defconfig > >> +++ b/arch/arm64/configs/defconfig > >> @@ -606,6 +606,7 @@ CONFIG_PINCTRL_MSM8996=y > >> CONFIG_PINCTRL_MSM8998=y > >> CONFIG_PINCTRL_QCM2290=y > >> CONFIG_PINCTRL_QCS404=y > >> +CONFIG_PINCTRL_QCS8300=y > >> CONFIG_PINCTRL_QDF2XXX=y > >> CONFIG_PINCTRL_QDU1000=y > >> CONFIG_PINCTRL_SA8775P=y > >> @@ -1317,6 +1318,7 @@ CONFIG_MSM_MMCC_8998=m > >> CONFIG_QCM_GCC_2290=y > >> CONFIG_QCM_DISPCC_2290=m > >> CONFIG_QCS_GCC_404=y > >> +CONFIG_QCS_GCC_8300=y > >> CONFIG_QDU_GCC_1000=y > >> CONFIG_SC_CAMCC_8280XP=m > >> CONFIG_SC_DISPCC_7280=m > >> @@ -1618,6 +1620,7 @@ CONFIG_INTERCONNECT_QCOM_MSM8996=y > >> CONFIG_INTERCONNECT_QCOM_OSM_L3=m > >> CONFIG_INTERCONNECT_QCOM_QCM2290=y > >> CONFIG_INTERCONNECT_QCOM_QCS404=m > >> +CONFIG_INTERCONNECT_QCOM_QCS8300=y > > > > Why this cannot be a module? > > > > > I think the commit-msg "It needs to be built-in for UART to provide a > console." can > explain that, could you please help to share your insights on that? Unless loading these modules from initramfs doesn't work, please use =m. The drivers that are enabled here are going to be enabled for everybody using arm64 defconfig, taking up memory on their platforms, etc. -- With best wishes Dmitry
Re: [PATCH 03/19] dt-bindings: phy: Add QMP UFS PHY comptible for QCS8300
On Wed, Sep 04, 2024 at 04:33:44PM GMT, Jingyi Wang wrote: > From: Xin Liu > > Document the QMP UFS PHY compatible for QCS8300 to support physical > layer functionality for USB found on the SoC. So this is talking about USB, but the patch changes UFS. Please adjust. > > Signed-off-by: Xin Liu > Signed-off-by: Jingyi Wang > --- > Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml > b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml > index f9cfbd0b2de6..a3540f7a8ef8 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml > @@ -18,6 +18,7 @@ properties: > enum: >- qcom,msm8996-qmp-ufs-phy >- qcom,msm8998-qmp-ufs-phy > + - qcom,qcs8300-qmp-ufs-phy >- qcom,sa8775p-qmp-ufs-phy >- qcom,sc7180-qmp-ufs-phy >- qcom,sc7280-qmp-ufs-phy > @@ -85,6 +86,7 @@ allOf: >contains: > enum: >- qcom,msm8998-qmp-ufs-phy > + - qcom,qcs8300-qmp-ufs-phy >- qcom,sa8775p-qmp-ufs-phy >- qcom,sc7180-qmp-ufs-phy >- qcom,sc7280-qmp-ufs-phy > > -- > 2.25.1 > -- With best wishes Dmitry
Re: [PATCH V2 2/4] remoteproc: qcom: add hexagon based WCSS secure PIL driver
On Thu, Aug 29, 2024 at 07:10:19PM GMT, Gokul Sriram Palanisamy wrote:
> From: Vignesh Viswanathan
>
> Add support to bring up hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ9574 supports secure PIL remoteproc.
Could you please clarify, why this can't be handled by the qcom_q6v5_pas
driver.
>
> Signed-off-by: Vignesh Viswanathan
> Signed-off-by: Manikanta Mylavarapu
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> changes since v1: Addressed comments by Krzysztof
> - moved of_node_put( ) before return value check to avoid
> leaking refcount.
> - simplified if/else for error handling.
> - implemented 'devm_clk_get_enabled' instead of using
> 'devm_clk_get' and 'clk_prepare_enable' conscutively.
> - implemented 'dev_err_probe' for error handling.
>
> drivers/remoteproc/Kconfig | 22 ++
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/qcom_q6v5_wcss_sec.c | 354
> 3 files changed, 377 insertions(+)
> create mode 100644 drivers/remoteproc/qcom_q6v5_wcss_sec.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0f0862e20a93..3e7c6fc62ca1 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -255,6 +255,28 @@ config QCOM_Q6V5_WCSS
> Hexagon V5 based WCSS remote processors on e.g. IPQ8074. This is
> a non-TrustZone wireless subsystem.
>
> +config QCOM_Q6V5_WCSS_SEC
> + tristate "Qualcomm Hexagon based WCSS Secure Peripheral Image Loader"
> + depends on OF && ARCH_QCOM
> + depends on QCOM_SMEM
> + depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
> + depends on QCOM_SYSMON || QCOM_SYSMON=n
> + depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
> + depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
> + select QCOM_MDT_LOADER
> + select QCOM_PIL_INFO
> + select QCOM_Q6V5_COMMON
> + select QCOM_RPROC_COMMON
> + select QCOM_SCM
> + help
> + Say y here to support the Qualcomm Secure Peripheral Image Loader
> + for the Hexagon based remote processors on e.g. IPQ5332.
> +
> + This is TrustZone wireless subsystem. The firmware is
> + verified and booted with the help of the Peripheral Authentication
> + System (PAS) in TrustZone.
> +
> config QCOM_SYSMON
> tristate "Qualcomm sysmon driver"
> depends on RPMSG
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 5ff4e2fee4ab..d4971b672812 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_QCOM_Q6V5_ADSP)+=
> qcom_q6v5_adsp.o
> obj-$(CONFIG_QCOM_Q6V5_MSS) += qcom_q6v5_mss.o
> obj-$(CONFIG_QCOM_Q6V5_PAS) += qcom_q6v5_pas.o
> obj-$(CONFIG_QCOM_Q6V5_WCSS) += qcom_q6v5_wcss.o
> +obj-$(CONFIG_QCOM_Q6V5_WCSS_SEC) += qcom_q6v5_wcss_sec.o
> obj-$(CONFIG_QCOM_SYSMON)+= qcom_sysmon.o
> obj-$(CONFIG_QCOM_WCNSS_PIL) += qcom_wcnss_pil.o
> qcom_wcnss_pil-y += qcom_wcnss.o
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss_sec.c
> b/drivers/remoteproc/qcom_q6v5_wcss_sec.c
> new file mode 100644
> index ..3c8bb2639567
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_q6v5_wcss_sec.c
> @@ -0,0 +1,354 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016-2018 Linaro Ltd.
> + * Copyright (C) 2014 Sony Mobile Communications AB
> + * Copyright (c) 2012-2018, 2024 The Linux Foundation. All rights reserved.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "qcom_common.h"
> +#include "qcom_q6v5.h"
> +
> +#include "remoteproc_internal.h"
> +
> +#define WCSS_CRASH_REASON421
> +
> +#define WCSS_PAS_ID 0x6
> +#define MPD_WCSS_PAS_ID 0xD
> +
> +struct wcss_sec {
> + struct device *dev;
> + struct qcom_rproc_glink glink_subdev;
> + struct qcom_rproc_ssr ssr_subdev;
> + struct qcom_q6v5 q6;
> + phys_addr_t mem_phys;
> + phys_addr_t mem_reloc;
> + void *mem_region;
> + size_t mem_size;
> + const struct wcss_data *desc;
> + const char *fw_name;
> +
> + struct clk *sleep_clk;
> +};
> +
> +struct wcss_data {
> + u32 pasid;
> + const struct rproc_ops *ops;
> + bool need_auto_boot;
This isn't set anywere, drop it
> + u8 bootargs_version;
Not used, drop it
> + int (*init_clk)(struct wcss_sec *wcss);
> +};
> +
> +static int wcss_sec_start(struct rproc *rproc)
> +{
> + struct wcss_sec *wcss = rproc->priv;
> + struct device *dev = wcss->dev;
> + const struct wcss_data *desc = of_device_get_match_data(dev);
> + int ret;
> +
> + qcom_q6v5_prepare(&wcss->q6);
Re: [PATCH V2 1/4] dt-bindings: remoteproc: qcom: document hexagon based WCSS secure PIL
On Thu, Aug 29, 2024 at 07:10:18PM GMT, Gokul Sriram Palanisamy wrote: > From: Manikanta Mylavarapu > > Add new binding document for hexagon based WCSS secure PIL remoteproc. > IPQ5332, IPQ9574 follows secure PIL remoteproc. What is the difference between PAS and secure PIL? > > Signed-off-by: Manikanta Mylavarapu > Signed-off-by: Gokul Sriram Palanisamy > --- > changes since v1: Addressed comments by Krzysztof > - expanded the acronym WCSS > - added 'maxItems' to property 'firmware-name' > - renamed sleep clock name 'im_sleep' to 'sleep' > - reordered items of property 'qcom,smem-states' keeping 'stop' > first. Addressed the same in example and in dtsi files. > - ordered required properties in the same order as property description > - dropped unused label 'q6v5_wcss' in example dts > > .../remoteproc/qcom,wcss-sec-pil.yaml | 125 ++ > 1 file changed, 125 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/qcom,wcss-sec-pil.yaml > > diff --git > a/Documentation/devicetree/bindings/remoteproc/qcom,wcss-sec-pil.yaml > b/Documentation/devicetree/bindings/remoteproc/qcom,wcss-sec-pil.yaml > new file mode 100644 > index ..98206b403681 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcss-sec-pil.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/remoteproc/qcom,wcss-sec-pil.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm WCSS Secure Peripheral Image Loader > + > +maintainers: > + - Manikanta Mylavarapu > + > +description: > + Wireless Connectivity Subsystem (WCSS) Secure Peripheral Image Loader loads > + firmware and power up QDSP6 remoteproc on the Qualcomm IPQ9574, IPQ5332 > SoC. > + > +properties: > + compatible: > +enum: > + - qcom,ipq5332-wcss-sec-pil > + - qcom,ipq9574-wcss-sec-pil > + > + reg: > +maxItems: 1 > + > + firmware-name: > +maxItems: 1 > +description: Firmware name for the Hexagon core > + > + interrupts: > +items: > + - description: Watchdog interrupt > + - description: Fatal interrupt > + - description: Ready interrupt > + - description: Handover interrupt > + - description: Stop acknowledge interrupt Does it make sense to make use of qcom,pas-common.yaml? > + > + interrupt-names: > +items: > + - const: wdog > + - const: fatal > + - const: ready > + - const: handover > + - const: stop-ack > + -- With best wishes Dmitry
Re: [PATCH V5 1/1] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
On Tue, Aug 20, 2024 at 02:42:31PM GMT, Gokul Sriram Palanisamy wrote:
> From: Vignesh Viswanathan
>
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574 and IPQ5332, crash reason information is
> present in target specific partition due to which the crash reason is
> not printed in the current implementation.
>
> Add support to pass crash_reason_partition along with crash_reason_item
> number in qcom_q6v5_init call and use the same to get the crash information
> from SMEM in fatal and watchdog IRQ handlers.
>
> While at it, rename all instances of "crash_reason_smem" with
> "crash_reason_item" as this reflects the proper meaning.
"While at it" => separate commits, plesae.
>
> Signed-off-by: Vignesh Viswanathan
Missing your sign-off.
> ---
>
> This change depends on WCSS secure PIL driver [1].
>
> Changes in V5: Added changes to WCSS secure PIL driver.
>
> Changes in V4: Rename all instances of crash_reason_smem to
> crash_reason_item
>
> Changes in V3: Updated commit message.
>
> Changes in V2: Addressed comments in V1.
Which comments?
>
> [1]
> https://patchwork.kernel.org/project/linux-arm-msm/cover/20240820085517.435566-1-quic_gokul...@quicinc.com/
>
> drivers/remoteproc/qcom_q6v5.c | 10 ++--
> drivers/remoteproc/qcom_q6v5.h | 6 ++-
> drivers/remoteproc/qcom_q6v5_adsp.c | 17 +++---
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 69 +
> drivers/remoteproc/qcom_q6v5_wcss.c | 12 +++--
> drivers/remoteproc/qcom_q6v5_wcss_sec.c | 3 +-
> 7 files changed, 66 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 4ee5e67a9f03..4d801ba3c791 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -100,7 +100,7 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void
> *data)
> return IRQ_HANDLED;
> }
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
> + msg = qcom_smem_get(q6v5->crash_reason_partition,
> q6v5->crash_reason_item, &len);
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "watchdog received: %s\n", msg);
> else
> @@ -121,7 +121,7 @@ static irqreturn_t q6v5_fatal_interrupt(int irq, void
> *data)
> if (!q6v5->running)
> return IRQ_HANDLED;
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
> + msg = qcom_smem_get(q6v5->crash_reason_partition,
> q6v5->crash_reason_item, &len);
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
> else
> @@ -244,14 +244,16 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
> * Return: 0 on success, negative errno on failure
> */
> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
> -struct rproc *rproc, int crash_reason, const char
> *load_state,
> +struct rproc *rproc, int crash_reason_partition,
> +int crash_reason_item, const char *load_state,
> void (*handover)(struct qcom_q6v5 *q6v5))
> {
> int ret;
>
> q6v5->rproc = rproc;
> q6v5->dev = &pdev->dev;
> - q6v5->crash_reason = crash_reason;
> + q6v5->crash_reason_partition = crash_reason_partition;
> + q6v5->crash_reason_item = crash_reason_item;
> q6v5->handover = handover;
>
> init_completion(&q6v5->start_done);
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 5a859c41896e..7cdfa21fd9e4 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -34,7 +34,8 @@ struct qcom_q6v5 {
> struct completion start_done;
> struct completion stop_done;
>
> - int crash_reason;
> + int crash_reason_partition;
> + int crash_reason_item;
>
> bool running;
>
> @@ -43,7 +44,8 @@ struct qcom_q6v5 {
> };
>
> int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
> -struct rproc *rproc, int crash_reason, const char
> *load_state,
> +struct rproc *rproc, int crash_reason_partition,
> +int crash_reason_item, const char *load_state,
> void (*handover)(struct qcom_q6v5 *q6v5));
> void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
>
> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
> b/drivers/remoteproc/qcom_q6v5_adsp.c
> index 572dcb0f055b..174b0e213b12 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -60,7 +60,7 @@
> #define LPASS_EFUSE_Q6SS_EVB_SEL 0x0
>
> struct adsp_pil_data {
> - int crash_reason_smem;
> + int crash_reason_item;
> const char *firmware_name;
>
> const char *ssr_name;
> @@ -97,
Re: [PATCH V2 1/1] remoteproc: qcom: Add NOTIFY_FATAL event type to SSR subdevice
On Tue, Aug 20, 2024 at 11:39:43AM GMT, Gokul Sriram Palanisamy wrote: > From: Vignesh Viswanathan > > Currently the SSR subdevice notifies the client driver on crash of the > rproc from the recovery workqueue using the BEFORE_SHUTDOWN event. > However, the client driver might be interested to know that the device > has crashed immediately to pause any further transactions with the > rproc. This calls for an event to be sent to the driver in the IRQ > context as soon as the rproc crashes. > > Add NOTIFY_FATAL event to SSR subdevice to atomically notify rproc has > crashed to the client driver. The client driver in this scenario is a > ath Wi-Fi driver which is continuously queuing data to the remoteproc and > needs to know if remoteproc crashes as soon as possible to stop queuing > further data and also dump some debug statistics on the driver side that > could potentially help in debug of why the remoteproc crashed. > > Validated the event in IPQ9574 and IPQ5332 by forcing the rproc to crash > and ensuring the registered notifier function receives the notification > in IRQ context. > > The client driver in this scenario is a Wi-Fi driver which is continuously > queuing data to the remoteproc and needs to know if remoteproc crashes > as soon as possible to stop queuing further data and also dump some > debug statistics on the driver side that could potentially help in > debug of why the remoteproc crashed. Please post the patch together with the user of the API. Right now the series has just a single patch in it, so it's impossible to judge whether it makes sense or not. > > Signed-off-by: Vignesh Viswanathan > Acked-by: Mukesh Ojha > Signed-off-by: Gokul Sriram Palanisamy > --- > changes since v1: > - No changes. Rebased on top of linux-next. > - We will now have a user for this notifier, ath12k. > > drivers/remoteproc/qcom_common.c | 60 +++ > drivers/remoteproc/remoteproc_core.c | 12 ++ > include/linux/remoteproc.h| 3 ++ > include/linux/remoteproc/qcom_rproc.h | 17 > 4 files changed, 92 insertions(+) -- With best wishes Dmitry
[PATCH v2 5/5] arm64: dts: qcom: add generic compat string to RPM glink channels
Add the generic qcom,smd-rpm / qcom,glink-smd-rpm compatible to RPM
nodes to follow the schema.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 2 +-
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8939.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8976.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8994.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm6375.dtsi | 2 +-
15 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index e1e45da7f787..8edd535a188f 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -168,7 +168,7 @@ glink-edge {
mboxes = <&apcs_glb 0>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-ipq6018";
+ compatible = "qcom,rpm-ipq6018",
"qcom,glink-smd-rpm";
qcom,glink-channels = "rpm_requests";
regulators {
diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
index 48dfafea46a7..08a82a5cf667 100644
--- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
@@ -181,7 +181,7 @@ glink-edge {
mboxes = <&apcs_glb 0>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-ipq9574";
+ compatible = "qcom,rpm-ipq9574",
"qcom,glink-smd-rpm";
qcom,glink-channels = "rpm_requests";
};
};
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 7383bcc603ab..0ee44706b70b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -312,7 +312,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-msm8916";
+ compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 46d9480cd464..28634789a8a9 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -252,7 +252,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-msm8936";
+ compatible = "qcom,rpm-msm8936", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index a4bfb624fb8a..d20fd3d7c46e 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -199,7 +199,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-msm8953";
+ compatible = "qcom,rpm-msm8953", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d62dcb76fa48..c76cab9174be 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -247,7 +247,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-msm8976";
+ compatible = "qcom,rpm-msm8976", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/b
[PATCH v2 4/5] ARM: dts: qcom: add generic compat string to RPM glink channels
Add the generic qcom,smd-rpm compatible to RPM nodes to follow the
schema.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom/qcom-apq8084.dtsi | 2 +-
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 2 +-
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
index 2b52e5d5eb51..014e6c5ee889 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8084.dtsi
@@ -792,7 +792,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm-requests {
- compatible = "qcom,rpm-apq8084";
+ compatible = "qcom,rpm-apq8084", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
regulators-0 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
index b2f92ad6499a..2ea3b4a94d50 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
@@ -125,7 +125,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-msm8226";
+ compatible = "qcom,rpm-msm8226", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 15568579459a..4a694bfa4732 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -136,7 +136,7 @@ smd-edge {
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
- compatible = "qcom,rpm-msm8974";
+ compatible = "qcom,rpm-msm8974", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
--
2.39.2
[PATCH v2 3/5] soc: qcom: smd-rpm: add qcom,smd-rpm compatible
Add the generic qcom,smd-rpm and qcom,glink-smd-rpm compatibles so that
there is no need to add further compat strings to the list. Existing
strings are intact to keep compatibility with existing DTS.
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/smd-rpm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 9d64283d2125..f2b3e02abdf1 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -216,6 +216,12 @@ static void qcom_smd_rpm_remove(struct rpmsg_device *rpdev)
}
static const struct of_device_id qcom_smd_rpm_of_match[] = {
+ { .compatible = "qcom,glink-smd-rpm" },
+ { .compatible = "qcom,smd-rpm" },
+ /*
+* Don't add any more compatibles to the list, two previous entryes
+* should match all defined devices.
+*/
{ .compatible = "qcom,rpm-apq8084" },
{ .compatible = "qcom,rpm-ipq6018" },
{ .compatible = "qcom,rpm-ipq9574" },
--
2.39.2
[PATCH v2 2/5] dt-bindings: soc: qcom: smd-rpm: add generic compatibles
Add two generic compatibles to all smd-rpm devices, they follow the same
RPMSG protocol and are either accessed through the smd-edge or through
the glink-edge.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
.../bindings/remoteproc/qcom,glink-rpm-edge.yaml | 2 +-
.../bindings/remoteproc/qcom,rpm-proc.yaml | 4 +-
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 74 ++
.../devicetree/bindings/soc/qcom/qcom,smd.yaml | 2 +-
5 files changed, 38 insertions(+), 46 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index 3665dd30604a..02fcffe93f1a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -139,7 +139,7 @@ examples:
- |
rpm {
rpm-requests {
-compatible = "qcom,rpm-msm8916";
+compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
clock-controller {
diff --git
a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
index 3766d4513b37..c54234247ab3 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
@@ -90,7 +90,7 @@ examples:
qcom,rpm-msg-ram = <&rpm_msg_ram>;
rpm-requests {
-compatible = "qcom,rpm-msm8996";
+compatible = "qcom,rpm-msm8996", "qcom,glink-smd-rpm";
qcom,glink-channels = "rpm_requests";
/* ... */
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
index 7afafde17a38..0c3e668b5d31 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
@@ -142,7 +142,7 @@ examples:
qcom,smd-edge = <15>;
rpm-requests {
- compatible = "qcom,rpm-msm8916";
+ compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
/* ... */
};
@@ -163,7 +163,7 @@ examples:
mboxes = <&apcs_glb 0>;
rpm-requests {
- compatible = "qcom,rpm-qcm2290";
+ compatible = "qcom,rpm-qcm2290", "qcom,glink-smd-rpm";
qcom,glink-channels = "rpm_requests";
/* ... */
};
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
index 2fa725b8af5d..270bcd079f88 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -30,31 +30,37 @@ maintainers:
properties:
compatible:
-enum:
- - qcom,rpm-apq8084
- - qcom,rpm-ipq6018
- - qcom,rpm-ipq9574
- - qcom,rpm-mdm9607
- - qcom,rpm-msm8226
- - qcom,rpm-msm8610
- - qcom,rpm-msm8909
- - qcom,rpm-msm8916
- - qcom,rpm-msm8917
- - qcom,rpm-msm8936
- - qcom,rpm-msm8937
- - qcom,rpm-msm8952
- - qcom,rpm-msm8953
- - qcom,rpm-msm8974
- - qcom,rpm-msm8976
- - qcom,rpm-msm8994
- - qcom,rpm-msm8996
- - qcom,rpm-msm8998
- - qcom,rpm-qcm2290
- - qcom,rpm-qcs404
- - qcom,rpm-sdm660
- - qcom,rpm-sm6115
- - qcom,rpm-sm6125
- - qcom,rpm-sm6375
+oneOf:
+ - items:
+ - enum:
+ - qcom,rpm-apq8084
+ - qcom,rpm-mdm9607
+ - qcom,rpm-msm8226
+ - qcom,rpm-msm8610
+ - qcom,rpm-msm8909
+ - qcom,rpm-msm8916
+ - qcom,rpm-msm8917
+ - qcom,rpm-msm8936
+ - qcom,rpm-msm8937
+ - qcom,rpm-msm8952
+ - qcom,rpm-msm8953
+ - qcom,rpm-msm8974
+ - qcom,rpm-msm8976
+ - qcom,rpm-msm8994
+ - const: qcom,smd-rpm
+ - items:
+ - enum:
+ - qcom,rpm-ipq6018
+ - qcom,rpm-ipq9574
+ - qcom,rpm-msm8996
+ - qcom,rpm-msm8998
+ - qcom,rpm-qcm2290
+ - qcom,rpm-qcs404
+ - qcom,rpm-sdm660
+ - qcom,rpm-sm6115
+ - qcom,rpm-sm6125
+ - qcom,rpm-sm6375
+ - const: qcom,glink-smd-rpm
clock-controller:
$ref: /schemas/clock/qcom,rpmcc.yaml#
@@ -84,21 +90,7 @@ if:
properties:
compatible:
contains:
-enum:
- - qcom,rpm-apq8084
- - qc
[PATCH v2 0/5] soc: qcom: fix rpm_requests module probing
The GLINK RPMSG channels get modalias based on the compatible string
rather than the channel type, however the smd-rpm module uses rpmsg ID
instead. Thus if the smd-rpm is built as a module, it doesn't get
automatically loaded. Add generic compatible to such devices and fix
module's ID table.
Module loading worked before the commit bcabe1e09135 ("soc: qcom:
smd-rpm: Match rpmsg channel instead of compatible"), because the driver
listed all compatible strings, but the mentioned commit changed ID
table. Revert the offending commit and add generic compatible strings
instead.
Signed-off-by: Dmitry Baryshkov
---
Changes in v2:
- Separate fix from the improvements (Krzysztof
- Split the qcom,glink-smd-rpm compat from the qcom,smd-rpm as they use
different channels underneath.
- Link to v1:
https://lore.kernel.org/r/20240729-fix-smd-rpm-v1-0-99a96133c...@linaro.org
---
Dmitry Baryshkov (5):
Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible"
dt-bindings: soc: qcom: smd-rpm: add generic compatibles
soc: qcom: smd-rpm: add qcom,smd-rpm compatible
ARM: dts: qcom: add generic compat string to RPM glink channels
arm64: dts: qcom: add generic compat string to RPM glink channels
.../devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
.../bindings/remoteproc/qcom,glink-rpm-edge.yaml | 2 +-
.../bindings/remoteproc/qcom,rpm-proc.yaml | 4 +-
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 74 ++
.../devicetree/bindings/soc/qcom/qcom,smd.yaml | 2 +-
arch/arm/boot/dts/qcom/qcom-apq8084.dtsi | 2 +-
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 2 +-
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 2 +-
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 2 +-
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8939.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8976.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8994.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm6375.dtsi | 2 +-
drivers/soc/qcom/smd-rpm.c | 41 +---
24 files changed, 88 insertions(+), 73 deletions(-)
---
base-commit: 668d33c9ff922c4590c58754ab064aaf53c387dd
change-id: 20240729-fix-smd-rpm-9651e87a9bb0
Best regards,
--
Dmitry Baryshkov
[PATCH v2 1/5] Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible"
The rpm_requests device nodes have the compatible node. As such the
rpmsg core uses OF modalias instead of a native rpmsg modalias. Thus if
smd-rpm is built as a module, it doesn't get autoloaded for the device.
Revert the commit bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel
instead of compatible")
Fixes: bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel instead of
compatible")
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/smd-rpm.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index b7056aed4c7d..9d64283d2125 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -196,9 +196,6 @@ static int qcom_smd_rpm_probe(struct rpmsg_device *rpdev)
{
struct qcom_smd_rpm *rpm;
- if (!rpdev->dev.of_node)
- return -EINVAL;
-
rpm = devm_kzalloc(&rpdev->dev, sizeof(*rpm), GFP_KERNEL);
if (!rpm)
return -ENOMEM;
@@ -218,18 +215,38 @@ static void qcom_smd_rpm_remove(struct rpmsg_device
*rpdev)
of_platform_depopulate(&rpdev->dev);
}
-static const struct rpmsg_device_id qcom_smd_rpm_id_table[] = {
- { .name = "rpm_requests", },
- { /* sentinel */ }
+static const struct of_device_id qcom_smd_rpm_of_match[] = {
+ { .compatible = "qcom,rpm-apq8084" },
+ { .compatible = "qcom,rpm-ipq6018" },
+ { .compatible = "qcom,rpm-ipq9574" },
+ { .compatible = "qcom,rpm-msm8226" },
+ { .compatible = "qcom,rpm-msm8909" },
+ { .compatible = "qcom,rpm-msm8916" },
+ { .compatible = "qcom,rpm-msm8936" },
+ { .compatible = "qcom,rpm-msm8953" },
+ { .compatible = "qcom,rpm-msm8974" },
+ { .compatible = "qcom,rpm-msm8976" },
+ { .compatible = "qcom,rpm-msm8994" },
+ { .compatible = "qcom,rpm-msm8996" },
+ { .compatible = "qcom,rpm-msm8998" },
+ { .compatible = "qcom,rpm-sdm660" },
+ { .compatible = "qcom,rpm-sm6115" },
+ { .compatible = "qcom,rpm-sm6125" },
+ { .compatible = "qcom,rpm-sm6375" },
+ { .compatible = "qcom,rpm-qcm2290" },
+ { .compatible = "qcom,rpm-qcs404" },
+ {}
};
-MODULE_DEVICE_TABLE(rpmsg, qcom_smd_rpm_id_table);
+MODULE_DEVICE_TABLE(of, qcom_smd_rpm_of_match);
static struct rpmsg_driver qcom_smd_rpm_driver = {
.probe = qcom_smd_rpm_probe,
.remove = qcom_smd_rpm_remove,
.callback = qcom_smd_rpm_callback,
- .id_table = qcom_smd_rpm_id_table,
- .drv.name = "qcom_smd_rpm",
+ .drv = {
+ .name = "qcom_smd_rpm",
+ .of_match_table = qcom_smd_rpm_of_match,
+ },
};
static int __init qcom_smd_rpm_init(void)
--
2.39.2
Re: [PATCH v2 4/4] ASoC: qcom: apq8016_sbc: Add support for msm8953/msm8976 SoC
On Sat, Jul 27, 2024 at 08:20:27PM GMT, Adam Skladowski wrote:
> From: Vladimir Lypak
>
> Introduce support for audio card on MSM8953/MSM8976 platform.
> Main difference between those two is Q6AFE CLK API supported by firmware
> which influence way we enable digital codec clock.
> Either inside machine driver or outside via q6afe-clocks driver.
>
> Signed-off-by: Vladimir Lypak
> [Adam: Add MSM8976, rename functions, add mclk setting,add msg]
> Co-developed-by: Adam Skladowski
> Signed-off-by: Adam Skladowski
> ---
> sound/soc/qcom/apq8016_sbc.c | 68 ++--
> 1 file changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c
> index 303dd88206b1..453ca4795603 100644
> --- a/sound/soc/qcom/apq8016_sbc.c
> +++ b/sound/soc/qcom/apq8016_sbc.c
> @@ -22,6 +22,11 @@
>
> #define MI2S_COUNT (MI2S_QUINARY + 1)
>
> +enum afe_clk_api {
> + Q6AFE_CLK_V1,
> + Q6AFE_CLK_V2
> +};
Are these v1/v2 coming from some msm-N.M kernel? It's not obvious from
the patch, but msm8916 also falls into v1 category. Is that expected?
> +
> struct apq8016_sbc_data {
> struct snd_soc_card card;
> void __iomem *mic_iomux;
> @@ -29,6 +34,8 @@ struct apq8016_sbc_data {
> void __iomem *quin_iomux;
> struct snd_soc_jack jack;
> bool jack_setup;
> + enum afe_clk_api q6afe_clk_ver;
> + bool dig_cdc_mclk_en;
> int mi2s_clk_count[MI2S_COUNT];
> };
>
> @@ -192,6 +199,28 @@ static int qdsp6_dai_get_lpass_id(struct snd_soc_dai
> *cpu_dai)
> }
> }
>
> +static int qdsp6_get_clk_id(struct apq8016_sbc_data *data, int mi2s_id)
> +{
> + if (data->q6afe_clk_ver == Q6AFE_CLK_V2) {
> + switch (mi2s_id) {
> + case MI2S_PRIMARY:
> + return Q6AFE_LPASS_CLK_ID_PRI_MI2S_IBIT;
> + case MI2S_SECONDARY:
> + return Q6AFE_LPASS_CLK_ID_SEC_MI2S_IBIT;
> + case MI2S_TERTIARY:
> + return Q6AFE_LPASS_CLK_ID_TER_MI2S_IBIT;
> + case MI2S_QUATERNARY:
> + return Q6AFE_LPASS_CLK_ID_QUAD_MI2S_IBIT;
> + case MI2S_QUINARY:
> + return Q6AFE_LPASS_CLK_ID_QUI_MI2S_IBIT;
> + default:
> + break;
> + }
> + }
> + /* If AFE CLK isn't V2 return V1 */
> + return LPAIF_BIT_CLK;
> +}
> +
> static int msm8916_qdsp6_dai_init(struct snd_soc_pcm_runtime *rtd)
> {
> struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
> @@ -214,8 +243,17 @@ static int msm8916_qdsp6_startup(struct
> snd_pcm_substream *substream)
>
> if (++data->mi2s_clk_count[mi2s] > 1)
> return 0;
> + /*
> + * On newer legacy SoC (MSM8976) lpass codec clocks are not available
> in gcc region
> + * so we have to request clock from machine driver using V1 API)
> + */
> + if (data->q6afe_clk_ver == Q6AFE_CLK_V1 && data->dig_cdc_mclk_en ==
> true) {
Nit: line feed after &&
> + ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_DIG_CLK,
> DEFAULT_MCLK_RATE, 0);
> + if (ret)
> + dev_err(card->dev, "Failed to enable LPAIF dig clk:
> %d\n", ret);
> + }
>
> - ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_BIT_CLK, MI2S_BCLK_RATE, 0);
> + ret = snd_soc_dai_set_sysclk(cpu_dai, qdsp6_get_clk_id(data, mi2s),
> MI2S_BCLK_RATE, 0);
> if (ret)
> dev_err(card->dev, "Failed to enable LPAIF bit clk: %d\n", ret);
> return ret;
> @@ -236,9 +274,16 @@ static void msm8916_qdsp6_shutdown(struct
> snd_pcm_substream *substream)
> if (--data->mi2s_clk_count[mi2s] > 0)
> return;
>
> - ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_BIT_CLK, 0, 0);
> + ret = snd_soc_dai_set_sysclk(cpu_dai, qdsp6_get_clk_id(data, mi2s), 0,
> 0);
> if (ret)
> dev_err(card->dev, "Failed to disable LPAIF bit clk: %d\n",
> ret);
> +
> + if (data->q6afe_clk_ver == Q6AFE_CLK_V1 && data->dig_cdc_mclk_en ==
> true) {
Nit: And here too, please.
> + ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_DIG_CLK, 0, 0);
> + if (ret)
> + dev_err(card->dev, "Failed to disable LPAIF dig clk:
> %d\n", ret);
> + }
> +
> }
>
> static const struct snd_soc_ops msm8916_qdsp6_be_ops = {
> @@ -279,6 +324,23 @@ static void msm8916_qdsp6_add_ops(struct snd_soc_card
> *card)
> }
> }
>
> +static void msm8953_qdsp6_add_ops(struct snd_soc_card *card)
> +{
> + struct apq8016_sbc_data *pdata = snd_soc_card_get_drvdata(card);
> +
> + pdata->q6afe_clk_ver = Q6AFE_CLK_V2;
> + msm8916_qdsp6_add_ops(card);
> +}
> +
> +static void msm8976_qdsp6_add_ops(struct snd_soc_card *card)
> +{
> + struct apq8016_sbc_data *pdata = snd_soc_card_get_drvdata(card);
> +
> + pdata->q6afe_clk_ver = Q6AFE_CLK_V1;
> + pdata->dig_cdc_mclk_en = true;
> + msm8916_qds
Re: [PATCH v2 3/4] ASoC: dt-bindings: apq8016-sbc: Add msm8953/msm8976-qdsp6-sndcard
On Sat, Jul 27, 2024 at 08:20:26PM GMT, Adam Skladowski wrote: > Document MSM8953/MSM8976 QDSP6 cards. > > Signed-off-by: Adam Skladowski > --- > .../sound/qcom,apq8016-sbc-sndcard.yaml | 51 --- > 1 file changed, 45 insertions(+), 6 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml > b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml > index 6ad451549036..1706ce334d2f 100644 > --- a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml > +++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml > @@ -15,16 +15,16 @@ properties: > enum: >- qcom,apq8016-sbc-sndcard >- qcom,msm8916-qdsp6-sndcard > + - qcom,msm8953-qdsp6-sndcard > + - qcom,msm8976-qdsp6-sndcard > >reg: > -items: > - - description: Microphone I/O mux register address > - - description: Speaker I/O mux register address > +minItems: 2 > +maxItems: 3 > >reg-names: > -items: > - - const: mic-iomux > - - const: spkr-iomux > +minItems: 2 > +maxItems: 3 > >audio-routing: > $ref: /schemas/types.yaml#/definitions/non-unique-string-array > @@ -106,6 +106,45 @@ required: >- reg-names >- model > > +allOf: > + - if: > + properties: > +compatible: > + contains: > +enum: > + - qcom,apq8016-sbc-sndcard > + - qcom,msm8916-qdsp6-sndcard > +then: > + properties: > +reg: > + items: > +- description: Microphone I/O mux register address > +- description: Speaker I/O mux register address > +reg-names: > + items: > +- const: mic-iomux > +- const: spkr-iomux > + > + - if: > + properties: > +compatible: > + contains: > +enum: > + - qcom,msm8953-qdsp6-sndcard > + - qcom,msm8976-qdsp6-sndcard > +then: > + properties: > +reg: > + items: > +- description: Microphone I/O mux register address > +- description: Speaker I/O mux register address > +- description: Quinary Mi2S I/O mux register address > +reg-names: > + items: > +- const: mic-iomux > +- const: spkr-iomux > +- const: quin-iomux As msm8953 / msm8976 just add one new region it might be better to move the lists back to top-level definitions (still having mix/maxItems next to it) and then in the conditional branches just specify maxItems:2 for apq8016/msm8916 and maxItems:3 for msm8953/msm8976. This way it becomes: reg: items: - description: Microphone I/O mux register address - description: Speaker I/O mux register address minItems: 2 maxItems: 3 # same for reg-names [] - if: properties: compatible: contains: enum: - qcom,apq8016-sbc-sndcard - qcom,msm8916-qdsp6-sndcard then: properties: reg: maxItems: 2 reg-names: maxItems: 2 else: properties: reg: maxItems: 3 reg-names: maxItems: 3 > + > additionalProperties: false > > examples: > -- > 2.45.2 > -- With best wishes Dmitry
Re: [PATCH v2 2/4] ASoC: msm8916-wcd-analog: add cajon and cajon v2 support
On Sat, Jul 27, 2024 at 08:20:25PM GMT, Adam Skladowski wrote:
> From: Vladimir Lypak
>
> Add regs overrides for Cajon(PM8952) and Cajon v2(PM8953) codecs.
>
> Signed-off-by: Vladimir Lypak
> [Adam: Add Cajon support,add msg]
> Co-developed-by: Adam Skladowski
> Signed-off-by: Adam Skladowski
> ---
> sound/soc/codecs/msm8916-wcd-analog.c | 63 +--
> 1 file changed, 60 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/codecs/msm8916-wcd-analog.c
> b/sound/soc/codecs/msm8916-wcd-analog.c
> index 9ca381812975..daf65f5d4e99 100644
> --- a/sound/soc/codecs/msm8916-wcd-analog.c
> +++ b/sound/soc/codecs/msm8916-wcd-analog.c
> @@ -250,6 +250,7 @@
> SPKR_DRV_CAL_EN | SPKR_DRV_SETTLE_EN | \
> SPKR_DRV_FW_EN | SPKR_DRV_BOOST_SET | \
> SPKR_DRV_CMFB_SET | SPKR_DRV_GAIN_SET)
> +#define CDC_A_SPKR_ANA_BIAS_SET (0xf1B3)
> #define CDC_A_SPKR_OCP_CTL (0xf1B4)
> #define CDC_A_SPKR_PWRSTG_CTL(0xf1B5)
> #define SPKR_PWRSTG_CTL_DAC_EN_MASK BIT(0)
> @@ -264,12 +265,15 @@
>
> #define CDC_A_SPKR_DRV_DBG (0xf1B7)
> #define CDC_A_CURRENT_LIMIT (0xf1C0)
> +#define CDC_A_BYPASS_MODE(0xf1C2)
> #define CDC_A_BOOST_EN_CTL (0xf1C3)
> #define CDC_A_SLOPE_COMP_IP_ZERO (0xf1C4)
> #define CDC_A_SEC_ACCESS (0xf1D0)
> #define CDC_A_PERPH_RESET_CTL3 (0xf1DA)
> #define CDC_A_PERPH_RESET_CTL4 (0xf1DB)
>
> +#define CDC_A_RX_EAR_STATUS (0xf1A1)
This one should go before CDC_A_SPKR_DAC_CTL
> +
> #define MSM8916_WCD_ANALOG_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000
> |\
> SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000)
> #define MSM8916_WCD_ANALOG_FORMATS (SNDRV_PCM_FMTBIT_S16_LE |\
> @@ -715,6 +719,50 @@ static const struct reg_default wcd_reg_defaults_2_0[] =
> {
> {CDC_A_MASTER_BIAS_CTL, 0x30},
> };
>
> +static const struct reg_default wcd_reg_defaults_cajon[] = {
> + {CDC_A_RX_COM_OCP_CTL, 0xD1},
> + {CDC_A_RX_COM_OCP_COUNT, 0xFF},
> + {CDC_D_SEC_ACCESS, 0xA5},
> + {CDC_D_PERPH_RESET_CTL3, 0x0F},
> + {CDC_A_TX_1_2_OPAMP_BIAS, 0x4C},
> + {CDC_A_NCP_FBCTRL, 0xA8},
> + {CDC_A_NCP_VCTRL, 0xA4},
> + {CDC_A_SPKR_DRV_CTL, 0x69},
> + {CDC_A_SPKR_DRV_DBG, 0x01},
> + {CDC_A_SEC_ACCESS, 0xA5},
> + {CDC_A_PERPH_RESET_CTL3, 0x0F},
> + {CDC_A_CURRENT_LIMIT, 0x82},
> + {CDC_A_SPKR_ANA_BIAS_SET, 0x41},
> + {CDC_A_SPKR_DAC_CTL, 0x03},
> + {CDC_A_SPKR_OCP_CTL, 0xE1},
> + {CDC_A_RX_HPH_BIAS_PA, 0xFA},
> + {CDC_A_MASTER_BIAS_CTL, 0x30},
> + {CDC_A_MICB_1_INT_RBIAS, 0x00},
> +};
> +
> +static const struct reg_default wcd_reg_defaults_cajon_2_0[] = {
> + {CDC_A_RX_COM_OCP_CTL, 0xD1},
> + {CDC_A_RX_COM_OCP_COUNT, 0xFF},
> + {CDC_D_SEC_ACCESS, 0xA5},
> + {CDC_D_PERPH_RESET_CTL3, 0x0F},
> + {CDC_A_TX_1_2_OPAMP_BIAS, 0x4C},
> + {CDC_A_NCP_FBCTRL, 0xA8},
> + {CDC_A_NCP_VCTRL, 0xA4},
> + {CDC_A_SPKR_DRV_CTL, 0x69},
> + {CDC_A_SPKR_DRV_DBG, 0x01},
> + {CDC_A_SEC_ACCESS, 0xA5},
> + {CDC_A_PERPH_RESET_CTL3, 0x0F},
> + {CDC_A_CURRENT_LIMIT, 0xA2},
> + {CDC_A_BYPASS_MODE, 0x18},
> + {CDC_A_SPKR_ANA_BIAS_SET, 0x41},
> + {CDC_A_SPKR_DAC_CTL, 0x03},
> + {CDC_A_SPKR_OCP_CTL, 0xE1},
> + {CDC_A_RX_HPH_BIAS_PA, 0xFA},
> + {CDC_A_RX_EAR_STATUS, 0x10},
> + {CDC_A_MASTER_BIAS_CTL, 0x30},
> + {CDC_A_MICB_1_INT_RBIAS, 0x00},
> +};
> +
> static int pm8916_wcd_analog_probe(struct snd_soc_component *component)
> {
> struct pm8916_wcd_analog_priv *priv = dev_get_drvdata(component->dev);
> @@ -738,9 +786,18 @@ static int pm8916_wcd_analog_probe(struct
> snd_soc_component *component)
> snd_soc_component_write(component, CDC_D_PERPH_RESET_CTL4, 0x01);
> snd_soc_component_write(component, CDC_A_PERPH_RESET_CTL4, 0x01);
>
> - for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_2_0); reg++)
> - snd_soc_component_write(component,
> wcd_reg_defaults_2_0[reg].reg,
> - wcd_reg_defaults_2_0[reg].def);
> + if (priv->codec_version == 4)
> + for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_cajon_2_0);
> reg++)
> + snd_soc_component_write(component,
> wcd_reg_defaults_cajon_2_0[reg].reg,
> + wcd_reg_defaults_cajon_2_0[reg].def);
> + else if (priv->codec_version == 3)
> + for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_cajon); reg++)
> + snd_soc_component_write(component,
> wcd_reg_defaults_cajon[reg].reg,
> + wcd_reg_defaults_cajon[reg].def);
> + else
> + for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_2_0); reg++)
> + snd_soc_component_write(component,
> wcd_reg_defaults_2_0[reg].reg,
> + wcd_reg_defaults_2_0[reg].def
Re: [PATCH v2 1/4] ASoC: qcom: apq8016_sbc.c: Add Quinary support
On Sat, Jul 27, 2024 at 08:20:24PM GMT, Adam Skladowski wrote: > From: Vladimir Lypak > > Add support for configuring Quinary Mi2S interface > it will be used on MSM8953 and MSM8976 platform. > > Signed-off-by: Vladimir Lypak > [Adam: Split from MSM8953 support patch,add msg] > Signed-off-by: Adam Skladowski > --- > sound/soc/qcom/apq8016_sbc.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) [...] > > @@ -320,6 +331,9 @@ static int apq8016_sbc_platform_probe(struct > platform_device *pdev) > if (IS_ERR(data->spkr_iomux)) > return PTR_ERR(data->spkr_iomux); > > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "quin-iomux"); > + data->quin_iomux = devm_ioremap_resource(&pdev->dev, res); This will still print an error if there is no quin-iomux. It's better to call devm_ioremap_resource() only if res is not NULL. LGTM otherwise > + > snd_soc_card_set_drvdata(card, data); > > add_ops(card); > -- > 2.45.2 > -- With best wishes Dmitry
Re: [PATCH 1/4] ASoC: qcom: apq8016_sbc.c: Add Quinary support
On Mon, Jul 22, 2024 at 11:51:05AM GMT, Adam Skladowski wrote: > From: Vladimir Lypak > > Add support for configuring Quinary Mi2S interface > it will be used on MSM8953 and MSM8976 platform. > > Signed-off-by: Vladimir Lypak > [Adam: Split from MSM8953 support patch,add msg] > Signed-off-by: Adam Skladowski > --- > sound/soc/qcom/apq8016_sbc.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c > index 3023cf180a75..8971f4f5d339 100644 > --- a/sound/soc/qcom/apq8016_sbc.c > +++ b/sound/soc/qcom/apq8016_sbc.c > @@ -320,6 +330,10 @@ static int apq8016_sbc_platform_probe(struct > platform_device *pdev) > if (IS_ERR(data->spkr_iomux)) > return PTR_ERR(data->spkr_iomux); > > + data->quin_iomux = devm_platform_ioremap_resource_byname(pdev, > "quin-iomux"); This should probably handle -ENOENT (or -ENODEV?) case and set the pointer to NULL. > + if (IS_ERR(data->quin_iomux)) > + return PTR_ERR(data->quin_iomux); > + > snd_soc_card_set_drvdata(card, data); > > add_ops(card); > -- > 2.45.2 > -- With best wishes Dmitry
Re: [PATCH v4 2/5] remoteproc: qcom: pas: Add SDX75 remoteproc support
On Tue, Jul 09, 2024 at 12:19:21PM GMT, Naina Mehta wrote: > Add MPSS Peripheral Authentication Service support for SDX75 platform. > > Signed-off-by: Naina Mehta > --- > drivers/remoteproc/qcom_q6v5_pas.c | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] arm64: dts: qcom: sm6350: Add missing qcom,non-secure-domain property
On Wed, Jul 03, 2024 at 09:03:01AM GMT, Luca Weiss wrote:
> By default the DSP domains are non secure, add the missing
nit: secure
With that fixed:
Reviewed-by: Dmitry Baryshkov
> qcom,non-secure-domain property to mark them as non-secure.
>
> Fixes: efc33c969f23 ("arm64: dts: qcom: sm6350: Add ADSP nodes")
> Fixes: 8eb5287e8a42 ("arm64: dts: qcom: sm6350: Add CDSP nodes")
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
--
With best wishes
Dmitry
Re: [PATCH] soc: qcom: socinfo: Add PM6350 PMIC
On Wed, Jul 03, 2024 at 09:01:03AM GMT, Luca Weiss wrote: > Add the ID for the PM6350 PMIC found on e.g. SM7225 Fairphone 4. > > Signed-off-by: Luca Weiss > --- > drivers/soc/qcom/socinfo.c | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH V3 2/2] soc: qcom: smp2p: Introduce tracepoint support
On Thu, Jun 27, 2024 at 04:18:31PM GMT, Sudeepgoud Patil wrote: > This commit introduces tracepoint support for smp2p, enabling See Documentation/process/submitting-patches.rst, "This patch". > logging of communication between local and remote processors. > These tracepoints include information about the remote subsystem > name, negotiation details, supported features, bit change > notifications, and ssr activity. These logs are useful for > debugging issues between subsystems. > > Signed-off-by: Sudeepgoud Patil > --- > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/smp2p.c | 9 > drivers/soc/qcom/trace-smp2p.h | 98 ++ > 3 files changed, 108 insertions(+) > create mode 100644 drivers/soc/qcom/trace-smp2p.h > -- With best wishes Dmitry
Re: [PATCH V3 1/2] soc: qcom: smp2p: Use devname for interrupt descriptions
On Thu, Jun 27, 2024 at 04:18:30PM GMT, Sudeepgoud Patil wrote: > From: Chris Lew > > When using /proc/interrupts to collect statistics on smp2p interrupt > counts, it is hard to distinguish the different instances of smp2p from > each other. For example to debug a processor boot issue, the ready and > handover interrupts are checked for sanity to ensure the firmware > reached a specific initialization stage. > > Remove "smp2p" string from the irq request so that the irq will default > to the device name. Add an .irq_print_chip() callback to print the irq > chip name as the device name. These two changes allow for a unique name > to be used in /proc/interrupts as shown below. > > / # cat /proc/interrupts | grep smp2p > 18: ... ipcc 196610 Edge smp2p-adsp > 20: ... ipcc 131074 Edge smp2p-modem > 170: ... smp2p-modem 1 Edge q6v5 ready > 178: ... smp2p-adsp 1 Edge q6v5 ready > > Signed-off-by: Chris Lew Your sign-off is missing. LGTM otherwise > --- > drivers/soc/qcom/smp2p.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > -- With best wishes Dmitry
Re: [PATCH] arm64: dts: qcom: sm7225-fairphone-fp4: Name the regulators
On Thu, Jun 27, 2024 at 03:15:54PM GMT, Luca Weiss wrote: > Without explicitly specifying names for the regulators they are named > based on the DeviceTree node name. This results in multiple regulators > with the same name, making debug prints and regulator_summary impossible > to reason about. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 34 > +++ > 1 file changed, 34 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v9 1/8] remoteproc: qcom: Add PRNG proxy clock
On Thu, Jun 27, 2024 at 04:59:38PM GMT, Gokul Sriram P wrote: > > On 6/27/2024 4:38 PM, Dmitry Baryshkov wrote: > > On Thu, Jun 27, 2024 at 03:31:01PM GMT, Gokul Sriram P wrote: > > > On 6/27/2024 12:47 AM, Dmitry Baryshkov wrote: > > > > On Tue, Jun 25, 2024 at 11:03:30AM GMT, Gokul Sriram P wrote: > > > > > On 6/22/2024 2:38 AM, Dmitry Baryshkov wrote: > > > > > > On Fri, Jun 21, 2024 at 05:16:52PM GMT, Gokul Sriram Palanisamy > > > > > > wrote: > > > > > > > PRNG clock is needed by the secure PIL, support for the same > > > > > > > is added in subsequent patches. > > > > > > Which 'same'? > > > > > > What is 'secure PIL'? > > > > > will elaborate in the updated version. > > > > > To answer your question, secure PIL is signed PIL image which only > > > > > TrustZone can authenticate and load. > > > > Fine. So, the current driver can not load WCSS firmware on IPQ8074, is > > > > that correct? Or was there some kind of firmware interface change? The > > > > driver was added in 2018, so I can only hope that at that point it > > > > worked. Could you please explain, what happened? > > > The existing wcss driver can load unsigned PIL images without the > > > involvement of TrustZone. That works even now. > > > With the current change, we are trying to add signed PIL as an option > > > based > > > on "wcss->need_mem_protection" if set. For signed PIL alone, we send a PAS > > > request to TrustZone to authenticate and load. > > I see that you are enabling it unconditionally for IPQ8074. How is it > > going to work? > > Correct Dmitry. In this change, it is forcing secure PIL. With a separate > driver for secure PIL, this will be sorted right? That depends. How will the running system decide, which driver to use? It can not be a compile-time decision. > > Regards, > > Gokul > > > > I also just noticed that Bjorn had suggested to submit a new driver for > > > the > > > PAS based IPQ WCSS instead of overloading this driver. Will also address > > > that and post a new driver in updated revision. > > > > > > Regards, > > > Gokul > > > > > > > Signed-off-by: Nikhil Prakash V > > > > > > > Signed-off-by: Sricharan R > > > > > > > Signed-off-by: Gokul Sriram Palanisamy > > > > > > > --- > > > > > > > drivers/remoteproc/qcom_q6v5_wcss.c | 65 > > > > > > > + > > > > > > > 1 file changed, 47 insertions(+), 18 deletions(-) -- With best wishes Dmitry
Re: [PATCH v9 3/8] remoteproc: qcom: Add support for split q6 + m3 wlan firmware
On Fri, Jun 21, 2024 at 05:16:54PM GMT, Gokul Sriram Palanisamy wrote: > IPQ8074 supports split firmware for q6 and m3 as well. > So add support for loading the m3 firmware before q6. > Now the drivers works fine for both split and unified > firmwares. Right now linux-firmware ships both q6 and m3 firmware files. The driver loads just the q6 firmware. Is it enough for the hardware to get working WiFi? > > Signed-off-by: Nikhil Prakash V > Signed-off-by: Sricharan R > Signed-off-by: Gokul Sriram Palanisamy Who is the original author of the patch? > --- > drivers/remoteproc/qcom_q6v5_wcss.c | 33 + > 1 file changed, 29 insertions(+), 4 deletions(-) > -- With best wishes Dmitry
Re: [PATCH v9 1/8] remoteproc: qcom: Add PRNG proxy clock
On Thu, Jun 27, 2024 at 03:31:01PM GMT, Gokul Sriram P wrote: > > On 6/27/2024 12:47 AM, Dmitry Baryshkov wrote: > > On Tue, Jun 25, 2024 at 11:03:30AM GMT, Gokul Sriram P wrote: > > > On 6/22/2024 2:38 AM, Dmitry Baryshkov wrote: > > > > On Fri, Jun 21, 2024 at 05:16:52PM GMT, Gokul Sriram Palanisamy wrote: > > > > > PRNG clock is needed by the secure PIL, support for the same > > > > > is added in subsequent patches. > > > > Which 'same'? > > > > What is 'secure PIL'? > > > will elaborate in the updated version. > > > To answer your question, secure PIL is signed PIL image which only > > > TrustZone can authenticate and load. > > Fine. So, the current driver can not load WCSS firmware on IPQ8074, is > > that correct? Or was there some kind of firmware interface change? The > > driver was added in 2018, so I can only hope that at that point it > > worked. Could you please explain, what happened? > The existing wcss driver can load unsigned PIL images without the > involvement of TrustZone. That works even now. > With the current change, we are trying to add signed PIL as an option based > on "wcss->need_mem_protection" if set. For signed PIL alone, we send a PAS > request to TrustZone to authenticate and load. I see that you are enabling it unconditionally for IPQ8074. How is it going to work? > I also just noticed that Bjorn had suggested to submit a new driver for the > PAS based IPQ WCSS instead of overloading this driver. Will also address > that and post a new driver in updated revision. > > Regards, > Gokul > > > > > Signed-off-by: Nikhil Prakash V > > > > > Signed-off-by: Sricharan R > > > > > Signed-off-by: Gokul Sriram Palanisamy > > > > > --- > > > > >drivers/remoteproc/qcom_q6v5_wcss.c | 65 > > > > > + > > > > >1 file changed, 47 insertions(+), 18 deletions(-) > > -- With best wishes Dmitry
Re: [PATCH v9 1/8] remoteproc: qcom: Add PRNG proxy clock
On Tue, Jun 25, 2024 at 11:03:30AM GMT, Gokul Sriram P wrote: > > On 6/22/2024 2:38 AM, Dmitry Baryshkov wrote: > > On Fri, Jun 21, 2024 at 05:16:52PM GMT, Gokul Sriram Palanisamy wrote: > > > PRNG clock is needed by the secure PIL, support for the same > > > is added in subsequent patches. > > Which 'same'? > > What is 'secure PIL'? > will elaborate in the updated version. > To answer your question, secure PIL is signed PIL image which only > TrustZone can authenticate and load. Fine. So, the current driver can not load WCSS firmware on IPQ8074, is that correct? Or was there some kind of firmware interface change? The driver was added in 2018, so I can only hope that at that point it worked. Could you please explain, what happened? > > > Signed-off-by: Nikhil Prakash V > > > Signed-off-by: Sricharan R > > > Signed-off-by: Gokul Sriram Palanisamy > > > --- > > > drivers/remoteproc/qcom_q6v5_wcss.c | 65 + > > > 1 file changed, 47 insertions(+), 18 deletions(-) -- With best wishes Dmitry
[PATCH 2/2] remoteproc: qcom: select AUXILIARY_BUS
The QCOM_PD_MAPPER implementation made Qualcomm remoteproc drivers use
auxiliary bus for the pd-mapper subdevice. Add necessary dependency.
Reported-by: Mark Brown
Fixes: 5b9f51b200dc ("remoteproc: qcom: enable in-kernel PD mapper")
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa85..dda2ada215b7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -166,6 +166,7 @@ config QCOM_PIL_INFO
config QCOM_RPROC_COMMON
tristate
+ select AUXILIARY_BUS
config QCOM_Q6V5_COMMON
tristate
--
2.39.2
[PATCH 1/2] soc: qcom: add missing pd-mapper dependencies
The pd-mapper driver uses auxiliary bus and Qualcomm PDR message format
data. Add missing dependencies to the driver's Kconfig entry.
Reported-by: Mark Brown
Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 0a2f2bfd7863..432c85bd8ad4 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -75,6 +75,8 @@ config QCOM_OCMEM
config QCOM_PD_MAPPER
tristate "Qualcomm Protection Domain Mapper"
select QCOM_QMI_HELPERS
+ select QCOM_PDR_MSG
+ select AUXILIARY_BUS
depends on NET && QRTR
default QCOM_RPROC_COMMON
help
--
2.39.2
[PATCH 0/2] qcom: fix missing dependencies for the QCOM_PD_MAPPER
While refactoring pd-mapper to use auxiliary bus for the PD mapper instantiation I forgot to select the bus in Kconfig entries. Fix it now. Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (2): soc: qcom: add missing pd-mapper dependencies remoteproc: qcom: select AUXILIARY_BUS drivers/remoteproc/Kconfig | 1 + drivers/soc/qcom/Kconfig | 2 ++ 2 files changed, 3 insertions(+) --- base-commit: b07e1e375f6389b6715b9aca590da17039bcd447 change-id: 20240626-qcom-pd-mapper-fix-deps-1cf064ee4715 Best regards, -- Dmitry Baryshkov
Re: [PATCH v9 4/8] remoteproc: qcom: Add ssr subdevice identifier
On Tue, Jun 25, 2024 at 09:04:17AM GMT, Krzysztof Kozlowski wrote: > On 25/06/2024 08:28, Gokul Sriram P wrote: > > > > On 6/21/2024 8:40 PM, Krzysztof Kozlowski wrote: > >> On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote: > >>> Add name for ssr subdevice on IPQ8074 SoC. > >> Why? > > Oops! Missed the change. Will add and update. > >>> Signed-off-by: Nikhil Prakash V > >>> Signed-off-by: Sricharan R > >>> Signed-off-by: Gokul Sriram Palanisamy > >> Three people developed that single line? > >> > >> Something is really odd with your DCO chain. > > The change was originally authored by Nikhil and reviewed by > > Sricharan. I'm just submitting the change to upstream so retained their > > names. > >> > > Then your DCO chain is not correct. Please carefully read submitting > patches, especially documents about authorship, DCO, reviewed tags. Also there should be From: Nikhil header before the patch. -- With best wishes Dmitry
[PATCH v9 5/5] remoteproc: qcom: enable in-kernel PD mapper
Request in-kernel protection domain mapper to be started before starting
Qualcomm DSP and release it once DSP is stopped. Once all DSPs are
stopped, the PD mapper will be stopped too.
Reviewed-by: Chris Lew
Tested-by: Steev Klimaszewski
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_common.c| 87 +
drivers/remoteproc/qcom_common.h| 10 +
drivers/remoteproc/qcom_q6v5_adsp.c | 3 ++
drivers/remoteproc/qcom_q6v5_mss.c | 3 ++
drivers/remoteproc/qcom_q6v5_pas.c | 3 ++
drivers/remoteproc/qcom_q6v5_wcss.c | 3 ++
6 files changed, 109 insertions(+)
diff --git a/drivers/remoteproc/qcom_common.c b/drivers/remoteproc/qcom_common.c
index 03e5f5d533eb..8c8688f99f0a 100644
--- a/drivers/remoteproc/qcom_common.c
+++ b/drivers/remoteproc/qcom_common.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,6 +26,7 @@
#define to_glink_subdev(d) container_of(d, struct qcom_rproc_glink, subdev)
#define to_smd_subdev(d) container_of(d, struct qcom_rproc_subdev, subdev)
#define to_ssr_subdev(d) container_of(d, struct qcom_rproc_ssr, subdev)
+#define to_pdm_subdev(d) container_of(d, struct qcom_rproc_pdm, subdev)
#define MAX_NUM_OF_SS 10
#define MAX_REGION_NAME_LENGTH 16
@@ -519,5 +521,90 @@ void qcom_remove_ssr_subdev(struct rproc *rproc, struct
qcom_rproc_ssr *ssr)
}
EXPORT_SYMBOL_GPL(qcom_remove_ssr_subdev);
+static void pdm_dev_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ kfree(adev);
+}
+
+static int pdm_notify_prepare(struct rproc_subdev *subdev)
+{
+ struct qcom_rproc_pdm *pdm = to_pdm_subdev(subdev);
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc(sizeof(*adev), GFP_KERNEL);
+ if (!adev)
+ return -ENOMEM;
+
+ adev->dev.parent = pdm->dev;
+ adev->dev.release = pdm_dev_release;
+ adev->name = "pd-mapper";
+ adev->id = pdm->index;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ kfree(adev);
+ return ret;
+ }
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ pdm->adev = adev;
+
+ return 0;
+}
+
+
+static void pdm_notify_unprepare(struct rproc_subdev *subdev)
+{
+ struct qcom_rproc_pdm *pdm = to_pdm_subdev(subdev);
+
+ if (!pdm->adev)
+ return;
+
+ auxiliary_device_delete(pdm->adev);
+ auxiliary_device_uninit(pdm->adev);
+ pdm->adev = NULL;
+}
+
+/**
+ * qcom_add_pdm_subdev() - register PD Mapper subdevice
+ * @rproc: rproc handle
+ * @pdm: PDM subdevice handle
+ *
+ * Register @pdm so that Protection Device mapper service is started when the
+ * DSP is started too.
+ */
+void qcom_add_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm)
+{
+ pdm->dev = &rproc->dev;
+ pdm->index = rproc->index;
+
+ pdm->subdev.prepare = pdm_notify_prepare;
+ pdm->subdev.unprepare = pdm_notify_unprepare;
+
+ rproc_add_subdev(rproc, &pdm->subdev);
+}
+EXPORT_SYMBOL_GPL(qcom_add_pdm_subdev);
+
+/**
+ * qcom_remove_pdm_subdev() - remove PD Mapper subdevice
+ * @rproc: rproc handle
+ * @pdm: PDM subdevice handle
+ *
+ * Remove the PD Mapper subdevice.
+ */
+void qcom_remove_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm)
+{
+ rproc_remove_subdev(rproc, &pdm->subdev);
+}
+EXPORT_SYMBOL_GPL(qcom_remove_pdm_subdev);
+
MODULE_DESCRIPTION("Qualcomm Remoteproc helper driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/remoteproc/qcom_common.h b/drivers/remoteproc/qcom_common.h
index 9ef4449052a9..b07fbaa091a0 100644
--- a/drivers/remoteproc/qcom_common.h
+++ b/drivers/remoteproc/qcom_common.h
@@ -34,6 +34,13 @@ struct qcom_rproc_ssr {
struct qcom_ssr_subsystem *info;
};
+struct qcom_rproc_pdm {
+ struct rproc_subdev subdev;
+ struct device *dev;
+ int index;
+ struct auxiliary_device *adev;
+};
+
void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
void (*rproc_dumpfn_t)(struct rproc *rproc,
struct rproc_dump_segment *segment, void *dest,
size_t offset,
@@ -52,6 +59,9 @@ void qcom_add_ssr_subdev(struct rproc *rproc, struct
qcom_rproc_ssr *ssr,
const char *ssr_name);
void qcom_remove_ssr_subdev(struct rproc *rproc, struct qcom_rproc_ssr *ssr);
+void qcom_add_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm);
+void qcom_remove_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm);
+
#if IS_ENABLED(CONFIG_QCOM_SYSMON)
struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
[PATCH v9 4/5] soc: qcom: add pd-mapper implementation
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted later), etc.
Provide in-kernel service implementing protection domain mapping
required to work with several services, which are provided by the DSP
firmware.
This module is loaded automatically by the remoteproc drivers when
necessary via the symbol dependency. It uses a root node to match a
protection domains map for a particular board. It is not possible to
implement it as a 'driver' as there is no corresponding device.
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Reviewed-by: Chris Lew
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 11 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/pdr_internal.h | 14 +
drivers/soc/qcom/qcom_pd_mapper.c | 676 ++
drivers/soc/qcom/qcom_pdr_msg.c | 34 ++
5 files changed, 736 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 95973c6b828f..0a2f2bfd7863 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -72,6 +72,17 @@ config QCOM_OCMEM
requirements. This is typically used by the GPU, camera/video, and
audio components on some Snapdragon SoCs.
+config QCOM_PD_MAPPER
+ tristate "Qualcomm Protection Domain Mapper"
+ select QCOM_QMI_HELPERS
+ depends on NET && QRTR
+ default QCOM_RPROC_COMMON
+ help
+ The Protection Domain Mapper maps registered services to the domains
+ and instances handled by the remote DSPs. This is a kernel-space
+ implementation of the service. It is a simpler alternative to the
+ userspace daemon.
+
config QCOM_PDR_HELPERS
tristate
select QCOM_QMI_HELPERS
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 3110ac3288bc..d3560f861085 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
+obj-$(CONFIG_QCOM_PD_MAPPER) += qcom_pd_mapper.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
obj-$(CONFIG_QCOM_PDR_MSG) += qcom_pdr_msg.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 7e5bb5a95275..8d17f7fb79e7 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -13,6 +13,8 @@
#define SERVREG_SET_ACK_REQ0x23
#define SERVREG_RESTART_PD_REQ 0x24
+#define SERVREG_LOC_PFR_REQ0x24
+
#define SERVREG_DOMAIN_LIST_LENGTH 32
#define SERVREG_RESTART_PD_REQ_MAX_LEN 67
#define SERVREG_REGISTER_LISTENER_REQ_LEN 71
@@ -20,6 +22,7 @@
#define SERVREG_GET_DOMAIN_LIST_REQ_MAX_LEN74
#define SERVREG_STATE_UPDATED_IND_MAX_LEN 79
#define SERVREG_GET_DOMAIN_LIST_RESP_MAX_LEN 2389
+#define SERVREG_LOC_PFR_RESP_MAX_LEN 10
struct servreg_location_entry {
char name[SERVREG_NAME_LENGTH + 1];
@@ -79,6 +82,15 @@ struct servreg_set_ack_resp {
struct qmi_response_type_v01 resp;
};
+struct servreg_loc_pfr_req {
+ char service[SERVREG_NAME_LENGTH + 1];
+ char reason[257];
+};
+
+struct servreg_loc_pfr_resp {
+ struct qmi_response_type_v01 rsp;
+};
+
extern const struct qmi_elem_info servreg_location_entry_ei[];
extern const struct qmi_elem_info servreg_get_domain_list_req_ei[];
extern const struct qmi_elem_info servreg_get_domain_list_resp_ei[];
@@ -89,5 +101,7 @@ extern const struct qmi_elem_info
servreg_restart_pd_resp_ei[];
extern const struct qmi_elem_info servreg_state_updated_ind_ei[];
extern const struct qmi_elem_info servreg_set_ack_req_ei[];
extern const struct qmi_elem_info servreg_set_ack_resp_ei[];
+extern const struct qmi_elem_info servreg_loc_pfr_req_ei[];
+extern const struct qmi_elem_info servreg_loc_pfr_resp_ei[];
#endif
diff --git a/drivers/soc/qcom/qcom_pd_mapper.c
b/drivers/soc/qcom/qcom_pd_mapper.c
new file mode 100644
index ..ecb64f06527f
--- /dev/null
+++ b/drivers/soc/qcom/qcom_pd_mapper.c
@@ -0,0 +1,676 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm Protection Domain mapper
+ *
+ * Copyright (c) 2023 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pdr_internal.h"
+
+#define SERVREG_QMI_VERSION 0x101
+#define SERVREG_QMI_INSTANCE 0
+
+#de
[PATCH v9 3/5] soc: qcom: pdr: extract PDR message marshalling data
The in-kernel PD mapper is going to use same message structures as the
QCOM_PDR_HELPERS module. Extract message marshalling data to separate
module that can be used by both PDR helpers and by PD mapper.
Reviewed-by: Bryan O'Donoghue
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig| 4 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/pdr_internal.h | 306 ++
drivers/soc/qcom/qcom_pdr_msg.c | 319
4 files changed, 334 insertions(+), 296 deletions(-)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 5af33b0e3470..95973c6b828f 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -75,8 +75,12 @@ config QCOM_OCMEM
config QCOM_PDR_HELPERS
tristate
select QCOM_QMI_HELPERS
+ select QCOM_PDR_MSG
depends on NET
+config QCOM_PDR_MSG
+ tristate
+
config QCOM_PMIC_PDCHARGER_ULOG
tristate "Qualcomm PMIC PDCharger ULOG driver"
depends on RPMSG
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ca0bece0dfff..3110ac3288bc 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
+obj-$(CONFIG_QCOM_PDR_MSG) += qcom_pdr_msg.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink_altmode.o
obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG) += pmic_pdcharger_ulog.o
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 03c282b7f17e..7e5bb5a95275 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -28,83 +28,12 @@ struct servreg_location_entry {
u32 instance;
};
-static const struct qmi_elem_info servreg_location_entry_ei[] = {
- {
- .data_type = QMI_STRING,
- .elem_len = SERVREG_NAME_LENGTH + 1,
- .elem_size = sizeof(char),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- name),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- instance),
- },
- {
- .data_type = QMI_UNSIGNED_1_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u8),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- service_data_valid),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- service_data),
- },
- {}
-};
-
struct servreg_get_domain_list_req {
char service_name[SERVREG_NAME_LENGTH + 1];
u8 domain_offset_valid;
u32 domain_offset;
};
-static const struct qmi_elem_info servreg_get_domain_list_req_ei[] = {
- {
- .data_type = QMI_STRING,
- .elem_len = SERVREG_NAME_LENGTH + 1,
- .elem_size = sizeof(char),
- .array_type = NO_ARRAY,
- .tlv_type = 0x01,
- .offset = offsetof(struct servreg_get_domain_list_req,
- service_name),
- },
- {
- .data_type = QMI_OPT_FLAG,
- .elem_len = 1,
- .elem_size = sizeof(u8),
- .array_type = NO_ARRAY,
- .tlv_type = 0x10,
- .offset = offsetof(struct servreg_get_domain_list_req,
- domain_offset_valid),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0x10,
- .offset = offsetof(struct servreg_get_domain_list_req,
-
[PATCH v9 2/5] soc: qcom: pdr: fix parsing of domains lists
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Reviewed-by: Chris Lew
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/pdr_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index 76a62c2ecc58..216166e98fae 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -417,7 +417,7 @@ static int pdr_locate_service(struct pdr_handle *pdr,
struct pdr_service *pds)
if (ret < 0)
goto out;
- for (i = domains_read; i < resp->domain_list_len; i++) {
+ for (i = 0; i < resp->domain_list_len; i++) {
entry = &resp->domain_list[i];
if (strnlen(entry->name, sizeof(entry->name)) ==
sizeof(entry->name))
--
2.39.2
[PATCH v9 1/5] soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/pdr_interface.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index a1b6a4081dea..76a62c2ecc58 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle *qmi,
locator_hdl);
struct pdr_service *pds;
+ mutex_lock(&pdr->lock);
/* Create a local client port for QMI communication */
pdr->locator_addr.sq_family = AF_QIPCRTR;
pdr->locator_addr.sq_node = svc->node;
pdr->locator_addr.sq_port = svc->port;
- mutex_lock(&pdr->lock);
pdr->locator_init_complete = true;
mutex_unlock(&pdr->lock);
@@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle *qmi,
mutex_lock(&pdr->lock);
pdr->locator_init_complete = false;
- mutex_unlock(&pdr->lock);
pdr->locator_addr.sq_node = 0;
pdr->locator_addr.sq_port = 0;
+ mutex_unlock(&pdr->lock);
}
static const struct qmi_ops pdr_locator_ops = {
@@ -365,12 +365,14 @@ static int pdr_get_domain_list(struct
servreg_get_domain_list_req *req,
if (ret < 0)
return ret;
+ mutex_lock(&pdr->lock);
ret = qmi_send_request(&pdr->locator_hdl,
&pdr->locator_addr,
&txn, SERVREG_GET_DOMAIN_LIST_REQ,
SERVREG_GET_DOMAIN_LIST_REQ_MAX_LEN,
servreg_get_domain_list_req_ei,
req);
+ mutex_unlock(&pdr->lock);
if (ret < 0) {
qmi_txn_cancel(&txn);
return ret;
--
2.39.2
[PATCH v9 0/5] soc: qcom: add in-kernel pd-mapper implementation
Protection domain mapper is a QMI service providing mapping between 'protection domains' and services supported / allowed in these domains. For example such mapping is required for loading of the WiFi firmware or for properly starting up the UCSI / altmode / battery manager support. The existing userspace implementation has several issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't reread the JSON files if the firmware location is changed (or if the firmware was not available at the time pd-mapper was started but the corresponding directory is mounted later), etc. However this configuration is largely static and common between different platforms. Provide in-kernel service implementing static per-platform data. --- Changes in v9: - Adjust locking in pdr_get_domain_list(), releasing the mutex right after qmi_send_request() (Chris Lew) - Link to v8: https://lore.kernel.org/r/20240512-qcom-pd-mapper-v8-0-5ecbb276f...@linaro.org Changes in v8: - Reworked pd-mapper to register as an rproc_subdev / auxdev - Dropped Tested-by from Steev and Alexey from the last patch since the implementation was changed significantly. - Add sensors, cdsp and mpss_root domains to 660 config (Alexey Minnekhanov) - Added platform entry for sm4250 (used for qrb4210 / RB2) - Added locking to the pdr_get_domain_list() (Chris Lew) - Remove the call to qmi_del_server() and corresponding API (Chris Lew) - In qmi_handle_init() changed 1024 to a defined constant (Chris Lew) - Link to v7: https://lore.kernel.org/r/20240424-qcom-pd-mapper-v7-0-05f7fc646...@linaro.org Changes in v7: - Fixed modular build (Steev) - Link to v6: https://lore.kernel.org/r/20240422-qcom-pd-mapper-v6-0-f96957d01...@linaro.org Changes in v6: - Reworked mutex to fix lockdep issue on deregistration - Fixed dependencies between PD-mapper and remoteproc to fix modular builds (Krzysztof) - Added EXPORT_SYMBOL_GPL to fix modular builds (Krzysztof) - Fixed kerneldocs (Krzysztof) - Removed extra pr_debug messages (Krzysztof) - Fixed wcss build (Krzysztof) - Added platforms which do not require protection domain mapping to silence the notice on those platforms - Link to v5: https://lore.kernel.org/r/20240419-qcom-pd-mapper-v5-0-e35b6f847...@linaro.org Changes in v5: - pdr: drop lock in pdr_register_listener, list_lock is already held (Chris Lew) - pd_mapper: reworked to provide static configuration per platform (Bjorn) - Link to v4: https://lore.kernel.org/r/20240311-qcom-pd-mapper-v4-0-24679cca5...@linaro.org Changes in v4: - Fixed missing chunk, reenabled kfree in qmi_del_server (Konrad) - Added configuration for sm6350 (Thanks to Luca) - Removed RFC tag (Konrad) - Link to v3: https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-0-6858fa1ac...@linaro.org Changes in RFC v3: - Send start / stop notifications when PD-mapper domain list is changed - Reworked the way PD-mapper treats protection domains, register all of them in a single batch - Added SC7180 domains configuration based on TCL Book 14 GO - Link to v2: https://lore.kernel.org/r/20240301-qcom-pd-mapper-v2-0-5d12a081d...@linaro.org Changes in RFC v2: - Swapped num_domains / domains (Konrad) - Fixed an issue with battery not working on sc8280xp - Added missing configuration for QCS404 To: Bjorn Andersson To: Konrad Dybcio To: Sibi Sankar To: Mathieu Poirier Cc: linux-arm-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-remotep...@vger.kernel.org --- Dmitry Baryshkov (5): soc: qcom: pdr: protect locator_addr with the main mutex soc: qcom: pdr: fix parsing of domains lists soc: qcom: pdr: extract PDR message marshalling data soc: qcom: add pd-mapper implementation remoteproc: qcom: enable in-kernel PD mapper drivers/remoteproc/qcom_common.c| 87 + drivers/remoteproc/qcom_common.h| 10 + drivers/remoteproc/qcom_q6v5_adsp.c | 3 + drivers/remoteproc/qcom_q6v5_mss.c | 3 + drivers/remoteproc/qcom_q6v5_pas.c | 3 + drivers/remoteproc/qcom_q6v5_wcss.c | 3 + drivers/soc/qcom/Kconfig| 15 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/pdr_interface.c| 8 +- drivers/soc/qcom/pdr_internal.h | 318 ++--- drivers/soc/qcom/qcom_pd_mapper.c | 676 drivers/soc/qcom/qcom_pdr_msg.c | 353 +++ 12 files changed, 1183 insertions(+), 298 deletions(-) --- base-commit: 2102cb0d050d34d50b9642a3a50861787527e922 change-id: 20240301-qcom-pd-mapper-e12d622d4ad0 Best regards, -- Dmitry Baryshkov
Re: [PATCH v2 0/3] Add Sony Xperia Z3 Compact smartphone
On Fri, Jun 21, 2024 at 05:26:41PM GMT, Valeriy Klimin wrote: > This is almost the same as the dts of the Xperia Z3, except for the > battery charge limits. > > The current on the l21 regulator for shinano is also bumped up > to stop SD card errors. > > Signed-off-by: Valeriy Klimin > --- > Changes in v2: > - Reordered dt-bindings and dts commits > - Link to v1: > https://lore.kernel.org/r/20240621-sony-aries-v1-0-bcf968769...@gmail.com Please let reviewers finish their job first. It's recommended to post once in 24 hours timeframe. Otherwise you end up getting feedback and tags for v1, while you have already posted v2. > > --- > Valeriy Klimin (3): > dt-bindings: arm: qcom: Add Sony Xperia Z3 Compact > ARM: dts: qcom: Add Sony Xperia Z3 Compact smartphone > ARM: dts: qcom: msm8974-sony-shinano: increase load on l21 for sdhc2 > > Documentation/devicetree/bindings/arm/qcom.yaml| 1 + > arch/arm/boot/dts/qcom/Makefile| 1 + > .../qcom-msm8974pro-sony-xperia-shinano-aries.dts | 44 > ++ > ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 2 + > 4 files changed, 48 insertions(+) > --- > base-commit: cd214efd16e30bf1aa40ccfaaf9177f47dd21fd5 > change-id: 20240620-sony-aries-4a5bce06c91d > > Best regards, > -- > Valeriy Klimin > -- With best wishes Dmitry
Re: [PATCH v9 7/8] clk: qcom: Add WCSSAON reset
On Fri, Jun 21, 2024 at 05:16:58PM GMT, Gokul Sriram Palanisamy wrote:
> Add WCSSAON reset required for Q6v5 on IPQ8074 SoC.
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Three authors for a single line?
> Acked-by: Stephen Boyd
> ---
> drivers/clk/qcom/gcc-ipq8074.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
> index 32fd01ef469a..d382d16b9c10 100644
> --- a/drivers/clk/qcom/gcc-ipq8074.c
> +++ b/drivers/clk/qcom/gcc-ipq8074.c
> @@ -4712,6 +4712,7 @@ static const struct qcom_reset_map gcc_ipq8074_resets[]
> = {
> [GCC_NSSPORT4_RESET] = { .reg = 0x68014, .bitmask = BIT(27) |
> GENMASK(9, 8) },
> [GCC_NSSPORT5_RESET] = { .reg = 0x68014, .bitmask = BIT(28) |
> GENMASK(11, 10) },
> [GCC_NSSPORT6_RESET] = { .reg = 0x68014, .bitmask = BIT(29) |
> GENMASK(13, 12) },
> + [GCC_WCSSAON_RESET] = { 0x59010, 0 },
Do you notice that you line is pretty significantly different from the
previous lines? The time has passed since Stephen has acked this line in
2019.
> };
>
> static struct gdsc *gcc_ipq8074_gdscs[] = {
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v9 0/8] remoteproc: qcom: q6v5-wcss: Add support for secure pil
On Fri, Jun 21, 2024 at 05:16:51PM GMT, Gokul Sriram Palanisamy wrote: > IPQ8074 needs support for secure pil as well. > Also, currently only unified firmware is supported. > IPQ8074 supports split firmware for q6 and m3, so > adding support for that. > > changes since v8: > - Rebased on top of Linux 6.10-rc4 Why do you have so many dead email addresses in you To/Cc lists? > > Gokul Sriram Palanisamy (8): > remoteproc: qcom: Add PRNG proxy clock > remoteproc: qcom: Add secure PIL support > remoteproc: qcom: Add support for split q6 + m3 wlan firmware > remoteproc: qcom: Add ssr subdevice identifier > remoteproc: qcom: Update regmap offsets for halt register > dt-bindings: clock: qcom: Add reset for WCSSAON > clk: qcom: Add WCSSAON reset > arm64: dts: qcom: Enable Q6v5 WCSS for ipq8074 SoC > > arch/arm64/boot/dts/qcom/ipq8074.dtsi| 80 + > drivers/clk/qcom/gcc-ipq8074.c | 1 + > drivers/remoteproc/qcom_q6v5_wcss.c | 162 +++ > include/dt-bindings/clock/qcom,gcc-ipq8074.h | 1 + > 4 files changed, 212 insertions(+), 32 deletions(-) > > -- > 2.34.1 > -- With best wishes Dmitry
Re: [PATCH v9 4/8] remoteproc: qcom: Add ssr subdevice identifier
On Fri, Jun 21, 2024 at 05:16:55PM GMT, Gokul Sriram Palanisamy wrote:
> Add name for ssr subdevice on IPQ8074 SoC.
Is it SSR or ssr? Why is it necessary?
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
Three authors for a single-line patch?
> ---
> drivers/remoteproc/qcom_q6v5_wcss.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
> b/drivers/remoteproc/qcom_q6v5_wcss.c
> index d8b79765d5c6..06936ca1d079 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -1170,6 +1170,7 @@ static const struct wcss_data wcss_ipq8074_res_init = {
> .crash_reason_smem = WCSS_CRASH_REASON,
> .aon_reset_required = true,
> .wcss_q6_reset_required = true,
> + .ssr_name = "q6wcss",
> .ops = &q6v5_wcss_ipq8074_ops,
> .requires_force_stop = true,
> .need_mem_protection = true,
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v9 0/8] remoteproc: qcom: q6v5-wcss: Add support for secure pil
On Fri, Jun 21, 2024 at 05:16:51PM GMT, Gokul Sriram Palanisamy wrote: > IPQ8074 needs support for secure pil as well. Could you please settle on 'pil' or 'PIL'. Just use one of them. Explain, what is secure PIL. > Also, currently only unified firmware is supported. What is unified firmware? What is split firmware? Why do I have so many questions after reading the cover letter for what claims to be v9? > IPQ8074 supports split firmware for q6 and m3, so > adding support for that. Ok. After reading through the first few patches. Is WCSS support on IPQ8074 broken? > > changes since v8: > - Rebased on top of Linux 6.10-rc4 Previous changelog has wanished? > > Gokul Sriram Palanisamy (8): > remoteproc: qcom: Add PRNG proxy clock > remoteproc: qcom: Add secure PIL support > remoteproc: qcom: Add support for split q6 + m3 wlan firmware > remoteproc: qcom: Add ssr subdevice identifier > remoteproc: qcom: Update regmap offsets for halt register > dt-bindings: clock: qcom: Add reset for WCSSAON > clk: qcom: Add WCSSAON reset > arm64: dts: qcom: Enable Q6v5 WCSS for ipq8074 SoC > > arch/arm64/boot/dts/qcom/ipq8074.dtsi| 80 + > drivers/clk/qcom/gcc-ipq8074.c | 1 + > drivers/remoteproc/qcom_q6v5_wcss.c | 162 +++ > include/dt-bindings/clock/qcom,gcc-ipq8074.h | 1 + > 4 files changed, 212 insertions(+), 32 deletions(-) > > -- > 2.34.1 > -- With best wishes Dmitry
Re: [PATCH v9 2/8] remoteproc: qcom: Add secure PIL support
On Fri, Jun 21, 2024 at 05:16:53PM GMT, Gokul Sriram Palanisamy wrote:
> IPQ8074 uses secure PIL. Hence, adding the support for the same.
See Documentation/process/submitting-patches.rst
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> drivers/remoteproc/qcom_q6v5_wcss.c | 43 +++--
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
> b/drivers/remoteproc/qcom_q6v5_wcss.c
> index 366b19cbd994..e45e79d80238 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include "qcom_common.h"
> #include "qcom_pil_info.h"
> #include "qcom_q6v5.h"
> @@ -86,6 +87,9 @@
> #define TCSR_WCSS_CLK_ENABLE 0x14
>
> #define MAX_HALT_REG 3
> +
> +#define WCNSS_PAS_ID 6
> +
> enum {
> WCSS_IPQ8074,
> WCSS_QCS404,
> @@ -134,6 +138,7 @@ struct q6v5_wcss {
> unsigned int crash_reason_smem;
> u32 version;
> bool requires_force_stop;
> + bool need_mem_protection;
needs
>
> struct qcom_rproc_glink glink_subdev;
> struct qcom_rproc_ssr ssr_subdev;
> @@ -152,6 +157,7 @@ struct wcss_data {
> int ssctl_id;
> const struct rproc_ops *ops;
> bool requires_force_stop;
> + bool need_mem_protection;
needs
> };
>
> static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
> @@ -251,6 +257,15 @@ static int q6v5_wcss_start(struct rproc *rproc)
>
> qcom_q6v5_prepare(&wcss->q6v5);
>
> + if (wcss->need_mem_protection) {
> + ret = qcom_scm_pas_auth_and_reset(WCNSS_PAS_ID);
> + if (ret) {
> + dev_err(wcss->dev, "wcss_reset failed\n");
> + return ret;
> + }
> + goto wait_for_reset;
> + }
Use if/else instead of a goto.
> +
> /* Release Q6 and WCSS reset */
> ret = reset_control_deassert(wcss->wcss_reset);
> if (ret) {
> @@ -285,6 +300,7 @@ static int q6v5_wcss_start(struct rproc *rproc)
> if (ret)
> goto wcss_q6_reset;
>
> +wait_for_reset:
This is more like wait_for_start
> ret = qcom_q6v5_wait_for_start(&wcss->q6v5, 5 * HZ);
> if (ret == -ETIMEDOUT)
> dev_err(wcss->dev, "start timed out\n");
> @@ -718,6 +734,15 @@ static int q6v5_wcss_stop(struct rproc *rproc)
> struct q6v5_wcss *wcss = rproc->priv;
> int ret;
>
> + if (wcss->need_mem_protection) {
> + ret = qcom_scm_pas_shutdown(WCNSS_PAS_ID);
> + if (ret) {
> + dev_err(wcss->dev, "not able to shutdown\n");
> + return ret;
> + }
> + goto pas_done;
> + }
if/else. Or abstract this to functions.
> +
> /* WCSS powerdown */
> if (wcss->requires_force_stop) {
> ret = qcom_q6v5_request_stop(&wcss->q6v5, NULL);
> @@ -742,6 +767,7 @@ static int q6v5_wcss_stop(struct rproc *rproc)
> return ret;
> }
>
> +pas_done:
> clk_disable_unprepare(wcss->prng_clk);
> qcom_q6v5_unprepare(&wcss->q6v5);
>
> @@ -765,9 +791,15 @@ static int q6v5_wcss_load(struct rproc *rproc, const
> struct firmware *fw)
> struct q6v5_wcss *wcss = rproc->priv;
> int ret;
>
> - ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
> - 0, wcss->mem_region, wcss->mem_phys,
> - wcss->mem_size, &wcss->mem_reloc);
> + if (wcss->need_mem_protection)
> + ret = qcom_mdt_load(wcss->dev, fw, rproc->firmware,
> + WCNSS_PAS_ID, wcss->mem_region,
> + wcss->mem_phys, wcss->mem_size,
> + &wcss->mem_reloc);
> + else
> + ret = qcom_mdt_load_no_init(wcss->dev, fw, rproc->firmware,
> + 0, wcss->mem_region, wcss->mem_phys,
> + wcss->mem_size, &wcss->mem_reloc);
> if (ret)
> return ret;
>
> @@ -1035,6 +1067,9 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
> if (!desc)
> return -EINVAL;
>
> + if (desc->need_mem_protection && !qcom_scm_is_available())
> + return -EPROBE_DEFER;
> +
> rproc = devm_rproc_alloc(&pdev->dev, pdev->name, desc->ops,
>desc->firmware_name, sizeof(*wcss));
> if (!rproc) {
> @@ -1048,6 +1083,7 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
>
> wcss->version = desc->version;
> wcss->requires_force_stop = desc->requires_force_stop;
> + wcss->need_mem_protection = desc->need_mem_protection;
>
> ret = q6v5_wcss_init_mmio(wcss, pdev);
> if (ret)
> @@ -,6 +1147,7 @@ static const struct wcss_dat
Re: [PATCH v9 1/8] remoteproc: qcom: Add PRNG proxy clock
On Fri, Jun 21, 2024 at 05:16:52PM GMT, Gokul Sriram Palanisamy wrote:
> PRNG clock is needed by the secure PIL, support for the same
> is added in subsequent patches.
Which 'same'?
What is 'secure PIL'?
>
> Signed-off-by: Nikhil Prakash V
> Signed-off-by: Sricharan R
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> drivers/remoteproc/qcom_q6v5_wcss.c | 65 +
> 1 file changed, 47 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c
> b/drivers/remoteproc/qcom_q6v5_wcss.c
> index 94f68c919ee6..366b19cbd994 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -91,19 +91,6 @@ enum {
> WCSS_QCS404,
> };
>
> -struct wcss_data {
> - const char *firmware_name;
> - unsigned int crash_reason_smem;
> - u32 version;
> - bool aon_reset_required;
> - bool wcss_q6_reset_required;
> - const char *ssr_name;
> - const char *sysmon_name;
> - int ssctl_id;
> - const struct rproc_ops *ops;
> - bool requires_force_stop;
> -};
> -
> struct q6v5_wcss {
> struct device *dev;
>
> @@ -128,6 +115,7 @@ struct q6v5_wcss {
> struct clk *qdsp6ss_xo_cbcr;
> struct clk *qdsp6ss_core_gfmux;
> struct clk *lcc_bcr_sleep;
> + struct clk *prng_clk;
> struct regulator *cx_supply;
> struct qcom_sysmon *sysmon;
>
> @@ -151,6 +139,21 @@ struct q6v5_wcss {
> struct qcom_rproc_ssr ssr_subdev;
> };
>
> +struct wcss_data {
> + int (*init_clock)(struct q6v5_wcss *wcss);
> + int (*init_regulator)(struct q6v5_wcss *wcss);
> + const char *firmware_name;
> + unsigned int crash_reason_smem;
> + u32 version;
> + bool aon_reset_required;
> + bool wcss_q6_reset_required;
> + const char *ssr_name;
> + const char *sysmon_name;
> + int ssctl_id;
> + const struct rproc_ops *ops;
> + bool requires_force_stop;
> +};
Move this back and use forward-declaration of struct q6v5_wcss.
> +
> static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
> {
> int ret;
--
With best wishes
Dmitry
Re: [PATCH 2/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Configure PM8008 regulators
On Fri, Jun 21, 2024 at 10:42:31AM GMT, Luca Weiss wrote: > PM8008 regulators are used for the cameras found on FP5. Configure the > chip and its voltages. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 105 > - > 1 file changed, 104 insertions(+), 1 deletion(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 1/2] arm64: dts: qcom: sm7225-fairphone-fp4: Configure PM8008 regulators
On Fri, Jun 21, 2024 at 10:42:30AM GMT, Luca Weiss wrote: > PM8008 regulators are used for the cameras found on FP4. Configure the > chip and its voltages. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 109 > +- > 1 file changed, 108 insertions(+), 1 deletion(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 1/3] ARM: dts: qcom: Add Sony Xperia Z3 Compact smartphone
On Fri, Jun 21, 2024 at 11:14:46AM GMT, Valeriy Klimin wrote: > Add the dts for the Z3 Compact. This is currently almost the same > as the plain Z3 as they share almost the same hardware and > nothing device-specific is currently supported. > > Signed-off-by: Valeriy Klimin > --- > arch/arm/boot/dts/qcom/Makefile| 1 + > .../qcom-msm8974pro-sony-xperia-shinano-aries.dts | 44 > ++ > 2 files changed, 45 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 3/3] ARM: dts: qcom: msm8974-sony-shinano: increase load on l21 for sdhc2
On Fri, Jun 21, 2024 at 11:14:48AM GMT, Valeriy Klimin wrote:
> SD cards would exhibit errors similar to ones described in commit
> 27fe0fc05f35 ("ARM: dts: msm8974-FP2: Increase load on l20 for sdhci")
>
> This patch applies the same change to the regulator for sdhc2.
>
> Signed-off-by: Valeriy Klimin
> ---
> arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
> a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
> b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
> index e129bb1bd6ec..6af7c71c7158 100644
> --- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
> @@ -380,6 +380,8 @@ pm8941_l20: l20 {
> pm8941_l21: l21 {
> regulator-min-microvolt = <295>;
> regulator-max-microvolt = <295>;
> + regulator-system-load = <50>;
> + regulator-allow-set-load;
> regulator-boot-on;
> };
>
Just out of pure interest, how the value was choosen? Do you have any
reference to the vendor kernel or DT?
--
With best wishes
Dmitry
Re: [PATCH v3 3/4] remoteproc: qcom_q6v5_pas: Add support to attach a DSP
On Thu, Jun 20, 2024 at 05:31:42PM GMT, Komal Bajaj wrote:
> From: Melody Olvera
>
> Some chipsets will have DSPs which will have begun running prior
> to linux booting, so add support to late attach these DSPs by
> adding support for:
> - run-time checking of an offline or running DSP via rmb register
> - a late attach framework to attach to the running DSP
> - a handshake mechanism to ensure full and proper booting via rmb
>
> Signed-off-by: Melody Olvera
> Signed-off-by: Komal Bajaj
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 102 +
> 1 file changed, 102 insertions(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
> b/drivers/remoteproc/qcom_q6v5_pas.c
> index b9759f6b2283..32d45c18e15e 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -258,6 +259,94 @@ static int adsp_load(struct rproc *rproc, const struct
> firmware *fw)
> return ret;
> }
>
> +static int adsp_signal_q6v5(struct qcom_adsp *adsp)
> +{
> + unsigned int val;
> + int ret;
> +
> + if (adsp->q6v5.rmb_base) {
> + ret = readl_poll_timeout(adsp->q6v5.rmb_base +
> RMB_BOOT_WAIT_REG,
> + val, val, 2,
> + RMB_POLL_MAX_TIMES * 2);
> + if (ret < 0)
> + return ret;
> +
> + writel_relaxed(1, adsp->q6v5.rmb_base + RMB_BOOT_CONT_REG);
> + }
> +
> + return 0;
> +}
> +
> +static int adsp_attach(struct rproc *rproc)
> +{
> + struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
> + int ret;
> +
> + ret = qcom_q6v5_prepare(&adsp->q6v5);
> + if (ret)
> + return ret;
> +
> + ret = adsp_pds_enable(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
> + if (ret < 0)
> + goto disable_irqs;
> +
> + ret = clk_prepare_enable(adsp->xo);
> + if (ret)
> + goto disable_proxy_pds;
> +
> + ret = clk_prepare_enable(adsp->aggre2_clk);
> + if (ret)
> + goto disable_xo_clk;
> +
> + if (adsp->cx_supply) {
> + ret = regulator_enable(adsp->cx_supply);
> + if (ret)
> + goto disable_aggre2_clk;
> + }
> +
> + if (adsp->px_supply) {
> + ret = regulator_enable(adsp->px_supply);
> + if (ret)
> + goto disable_cx_supply;
> + }
Don't c&p code from adsp_start(). Extract common function instead.
> +
> + /* if needed, signal Q6 to continute booting */
> + ret = adsp_signal_q6v5(adsp);
> + if (ret < 0) {
> + dev_err(adsp->dev, "Didn't get rmb signal from %s\n",
> rproc->name);
> + goto disable_px_supply;
> + };
> +
> + ret = qcom_q6v5_wait_for_start(&adsp->q6v5, msecs_to_jiffies(5000));
> + if (ret == -ETIMEDOUT) {
> + dev_err(adsp->dev, "start timed out\n");
> + qcom_scm_pas_shutdown(adsp->pas_id);
> + goto disable_px_supply;
> + }
> +
> + return 0;
> +
> +disable_px_supply:
> + if (adsp->px_supply)
> + regulator_disable(adsp->px_supply);
> +disable_cx_supply:
> + if (adsp->cx_supply)
> + regulator_disable(adsp->cx_supply);
> +disable_aggre2_clk:
> + clk_disable_unprepare(adsp->aggre2_clk);
> +disable_xo_clk:
> + clk_disable_unprepare(adsp->xo);
> +disable_proxy_pds:
> + adsp_pds_disable(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
> +disable_irqs:
> + qcom_q6v5_unprepare(&adsp->q6v5);
> +
> + /* Remove pointer to the loaded firmware, only valid in adsp_load() &
> adsp_start() */
> + adsp->firmware = NULL;
> +
> + return ret;
> +}
> +
> static int adsp_start(struct rproc *rproc)
> {
> struct qcom_adsp *adsp = rproc->priv;
> @@ -320,6 +409,13 @@ static int adsp_start(struct rproc *rproc)
> goto release_pas_metadata;
> }
>
> + /* if needed, signal Q6 to continute booting */
> + ret = adsp_signal_q6v5(adsp);
> + if (ret < 0) {
> + dev_err(adsp->dev, "Didn't get rmb signal from %s\n",
> rproc->name);
Move the error message to adsp_signal_q6v5(). Make the call conditional.
> + goto release_pas_metadata;
> + }
> +
> ret = qcom_q6v5_wait_for_start(&adsp->q6v5, msecs_to_jiffies(5000));
> if (ret == -ETIMEDOUT) {
> dev_err(adsp->dev, "start timed out\n");
> @@ -432,6 +528,7 @@ static unsigned long adsp_panic(struct rproc *rproc)
> static const struct rproc_ops adsp_ops = {
> .unprepare = adsp_unprepare,
> .start = adsp_start,
> + .attach = adsp_attach,
> .stop = adsp_stop,
> .da_to_va = adsp_da_to_va,
> .parse_fw = qcom_register_dump_segments,
> @@ -442,6 +539,7 @@ static const struct rproc_ops adsp_ops = {
> static const struct rproc_ops adsp_minidump_ops = {
>
Re: [PATCH v3 2/4] remoteproc: qcom: q6v5: Add support for q6 rmb registers
On Thu, Jun 20, 2024 at 05:31:41PM GMT, Komal Bajaj wrote:
> From: Melody Olvera
>
> When attaching a running Q6, the remoteproc driver needs a way
> to communicate with the Q6 using rmb registers, so allow the
> rmb register to be gotten from the device tree if present.
rmb or RMB? And what is it?
>
> Signed-off-by: Melody Olvera
> Signed-off-by: Komal Bajaj
> ---
> drivers/remoteproc/qcom_q6v5.h | 8
> drivers/remoteproc/qcom_q6v5_pas.c | 4
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 5a859c41896e..95824d5b64ce 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -7,6 +7,12 @@
> #include
> #include
>
> +#define RMB_BOOT_WAIT_REG 0x8
> +#define RMB_BOOT_CONT_REG 0xC
> +#define RMB_Q6_BOOT_STATUS_REG 0x10
> +
> +#define RMB_POLL_MAX_TIMES 250
> +
> struct icc_path;
> struct rproc;
> struct qcom_smem_stat;
> @@ -16,6 +22,8 @@ struct qcom_q6v5 {
> struct device *dev;
> struct rproc *rproc;
>
> + void __iomem *rmb_base;
> +
Why is this a part of the common structure and is not a part of the _pas
struct?
> struct qcom_smem_state *state;
> struct qmp *qmp;
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
> b/drivers/remoteproc/qcom_q6v5_pas.c
> index 8458bcfe9e19..b9759f6b2283 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -770,6 +770,10 @@ static int adsp_probe(struct platform_device *pdev)
> goto free_rproc;
> adsp->proxy_pd_count = ret;
>
> + adsp->q6v5.rmb_base = devm_platform_ioremap_resource_byname(pdev,
> "rmb");
> + if (IS_ERR(adsp->q6v5.rmb_base))
> + adsp->q6v5.rmb_base = NULL;
> +
> ret = qcom_q6v5_init(&adsp->q6v5, pdev, rproc, desc->crash_reason_smem,
> desc->load_state,
>qcom_pas_handover);
> if (ret)
> --
> 2.42.0
>
--
With best wishes
Dmitry
Re: [PATCH 7/7] ARM: dts: qcom: msm8226: Convert APCS usages to mbox interface
On Wed, Jun 19, 2024 at 11:02:51PM GMT, Luca Weiss wrote: > Since we now have the apcs set up as a mailbox provider, let's use the > interface for all drivers where possible. > > Signed-off-by: Luca Weiss > --- > arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 6/7] ARM: dts: qcom: msm8226: Hook up CPU cooling
On Wed, Jun 19, 2024 at 11:02:50PM GMT, Luca Weiss wrote: > Add cooling-maps for the CPU thermal zones so the driver can actually do > something when the CPU temperature rises too much. > > Signed-off-by: Luca Weiss > --- > arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 25 + > 1 file changed, 25 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 5/7] ARM: dts: qcom: msm8226: Add CPU frequency scaling support
On Wed, Jun 19, 2024 at 11:02:49PM GMT, Luca Weiss wrote: > Add a node for the a7pll with its frequencies. With this we can use the > apcs-kpss-global driver for the apcs node and use the apcs to scale the > CPU frequency according to the opp-table. > > At the same time unfortunately we need to provide the gcc node xo_board > instead of the XO via rpmcc since otherwise we'll have a circular > dependency between apcs, gcc and the rpm. But it should be fine, isn't it? Clock controllers can handle orphaned clocks. The xo_board is really a hack and should eventually be removed. > > Signed-off-by: Luca Weiss > --- -- With best wishes Dmitry
Re: [PATCH 5/5] arm64: dts: qcom: msm8976: Use mboxes in smsm node
On Wed, Jun 19, 2024 at 06:42:31PM GMT, Luca Weiss wrote: > With the smsm bindings and driver finally supporting mboxes, switch to > that and stop using apcs as syscon. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/msm8976.dtsi | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 4/5] arm64: dts: qcom: msm8953: Use mboxes in smsm node
On Wed, Jun 19, 2024 at 06:42:30PM GMT, Luca Weiss wrote: > With the smsm bindings and driver finally supporting mboxes, switch to > that and stop using apcs as syscon. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/msm8953.dtsi | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 3/5] arm64: dts: qcom: msm8939: Use mboxes in smsm node
On Wed, Jun 19, 2024 at 06:42:29PM GMT, Luca Weiss wrote: > With the smsm bindings and driver finally supporting mboxes, switch to > that and stop using apcs as syscon. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/msm8939.dtsi | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 2/5] arm64: dts: qcom: msm8916: Use mboxes in smsm node
On Wed, Jun 19, 2024 at 06:42:28PM GMT, Luca Weiss wrote: > With the smsm bindings and driver finally supporting mboxes, switch to > that and stop using apcs as syscon. > > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 1/5] ARM: dts: qcom: msm8974: Use mboxes in smsm node
On Wed, Jun 19, 2024 at 06:42:27PM GMT, Luca Weiss wrote: > With the smsm bindings and driver finally supporting mboxes, switch to > that and stop using apcs as syscon. > > Signed-off-by: Luca Weiss > --- > arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [v4 2/3] leds: sy7802: Add support for Silergy SY7802 flash LED controller
On Mon, Jun 17, 2024 at 12:18:11PM GMT, Markus Elfring wrote: > >> Would you become interested to apply a statement like > >> “guard(mutex)(&chip->mutex);”? > >> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/mutex.h#L196 > > > > This does not look like real improvement for code this trivial. > > Various source code places can be updated also according to referenced > programming interfaces. > https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L8 > > Will corresponding collateral evolution become better supported? Plesae stop this. cleanup.h might be a nice thing, but it should not be used to make code less obvious or worse. -- With best wishes Dmitry
Re: [PATCH v2 4/5] arm64: dts: qcom: sdx75: Add remoteproc node
On Mon, Jun 17, 2024 at 03:04:27PM GMT, Naina Mehta wrote: > Add MPSS remoteproc node for SDX75 SoC. > > Signed-off-by: Naina Mehta > --- > arch/arm64/boot/dts/qcom/sdx75.dtsi | 47 + > 1 file changed, 47 insertions(+) > Reviewed-by: Dmitry Baryshkov > -- With best wishes Dmitry
Re: [PATCH v2 5/5] arm64: dts: qcom: sdx75-idp: enable MPSS remoteproc node
On Mon, Jun 17, 2024 at 03:04:28PM GMT, Naina Mehta wrote: > Enable MPSS remoteproc node on sdx75-idp platform. > > Signed-off-by: Naina Mehta > --- > arch/arm64/boot/dts/qcom/sdx75-idp.dts | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v5 2/2] misc: fastrpc: use coherent pool for untranslated Compute Banks
On Fri, May 24, 2024 at 06:14:03PM +0200, Dylan Van Assche wrote: > Use fastrpc_remote_heap_alloc to allocate from the FastRPC device > instead of the Compute Bank when the session ID is 0. This ensures > that the allocation is inside the coherent DMA pool which is already > accessible to the DSP. This is necessary to support FastRPC devices > which do not have dedicated Compute Banks such as the SLPI on the SDM845. > The latter uses an allocated CMA region instead of FastRPC Compute Banks. > > Signed-off-by: Dylan Van Assche > Reviewed-by: Caleb Connolly > --- > drivers/misc/fastrpc.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v5 1/2] misc: fastrpc: support complete DMA pool access to the DSP
On Fri, May 24, 2024 at 06:14:02PM +0200, Dylan Van Assche wrote:
> To support FastRPC Context Banks which aren't mapped via the SMMU,
> make the whole reserved memory region available to the DSP to allow
> access to coherent buffers.
>
> This is performed by assigning the memory to the DSP via a hypervisor
> call to set the correct permissions for the Virtual Machines on the DSP.
> This is only necessary when a memory region is provided for SLPI DSPs
> so guard this with a domain ID check.
>
> Signed-off-by: Dylan Van Assche
> Reviewed-by: Caleb Connolly
> ---
> drivers/misc/fastrpc.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index 4c67e2c5a82e..c06667b29055 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -2255,6 +2255,8 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device
> *rpdev)
> int i, err, domain_id = -1, vmcount;
> const char *domain;
> bool secure_dsp;
> + struct device_node *rmem_node;
> + struct reserved_mem *rmem;
> unsigned int vmids[FASTRPC_MAX_VMIDS];
>
> err = of_property_read_string(rdev->of_node, "label", &domain);
> @@ -2297,6 +2299,23 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device
> *rpdev)
> }
> }
>
> + rmem_node = of_parse_phandle(rdev->of_node, "memory-region", 0);
> + if (domain_id == SDSP_DOMAIN_ID && rmem_node) {
I think we can drop the domain_id check here.
The rest looks good to me.
Reviewed-by: Dmitry Baryshkov
> + u64 src_perms;
> +
> + rmem = of_reserved_mem_lookup(rmem_node);
> + if (!rmem) {
> + err = -EINVAL;
> + goto fdev_error;
> + }
> +
> + src_perms = BIT(QCOM_SCM_VMID_HLOS);
> +
> + qcom_scm_assign_mem(rmem->base, rmem->size, &src_perms,
> + data->vmperms, data->vmcount);
> +
> + }
> +
> secure_dsp = !(of_property_read_bool(rdev->of_node,
> "qcom,non-secure-domain"));
> data->secure = secure_dsp;
>
> --
> 2.45.1
>
--
With best wishes
Dmitry
Re: [PATCH v2] rpmsg: qcom_smd: Improve error handling for qcom_smd_parse_edge
On Thu, Jun 06, 2024 at 09:01:36PM +0200, Luca Weiss wrote: > When the mailbox driver has not probed yet, the error message "failed to > parse smd edge" is just going to confuse users, so improve the error > prints a bit. > > Cover the last remaining exits from qcom_smd_parse_edge with proper > error prints, especially the one for the mbox_chan deserved > dev_err_probe to handle EPROBE_DEFER nicely. And add one for ipc_regmap > also to be complete. > > With this done, we can remove the outer print completely. > > Signed-off-by: Luca Weiss > --- > Changes in v2: > - Rebase on qcom for-next, drop dts patches which have been applied > - Improve error printing situation (Bjorn) > - Link to v1: > https://lore.kernel.org/r/20240424-apcs-mboxes-v1-0-6556c47cb...@z3ntu.xyz > --- > drivers/rpmsg/qcom_smd.c | 8 ---- > 1 file changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v8 1/5] soc: qcom: pdr: protect locator_addr with the main mutex
On Thu, 6 Jun 2024 at 01:48, Chris Lew wrote:
>
> Hi Dmitry,
>
> On 5/11/2024 2:56 PM, Dmitry Baryshkov wrote:
> ...
> > @@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle
> > *qmi,
> > locator_hdl);
> > struct pdr_service *pds;
> >
> > + mutex_lock(&pdr->lock);
> > /* Create a local client port for QMI communication */
> > pdr->locator_addr.sq_family = AF_QIPCRTR;
> > pdr->locator_addr.sq_node = svc->node;
> > pdr->locator_addr.sq_port = svc->port;
> >
> > - mutex_lock(&pdr->lock);
> > pdr->locator_init_complete = true;
> > mutex_unlock(&pdr->lock);
> >
> > @@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle
> > *qmi,
> >
> > mutex_lock(&pdr->lock);
> > pdr->locator_init_complete = false;
> > - mutex_unlock(&pdr->lock);
> >
> > pdr->locator_addr.sq_node = 0;
> > pdr->locator_addr.sq_port = 0;
> > + mutex_unlock(&pdr->lock);
> > }
> >
> > static const struct qmi_ops pdr_locator_ops = {
> > @@ -365,6 +365,7 @@ static int pdr_get_domain_list(struct
> > servreg_get_domain_list_req *req,
> > if (ret < 0)
> > return ret;
> >
> > + mutex_lock(&pdr->lock);
> > ret = qmi_send_request(&pdr->locator_hdl,
> > &pdr->locator_addr,
> > &txn, SERVREG_GET_DOMAIN_LIST_REQ,
> > @@ -373,15 +374,16 @@ static int pdr_get_domain_list(struct
> > servreg_get_domain_list_req *req,
> > req);
> > if (ret < 0) {
> > qmi_txn_cancel(&txn);
> > - return ret;
> > + goto err_unlock;
> > }
> >
> > ret = qmi_txn_wait(&txn, 5 * HZ);
> > if (ret < 0) {
> > pr_err("PDR: %s get domain list txn wait failed: %d\n",
> > req->service_name, ret);
> > - return ret;
> > + goto err_unlock;
> > }
> > + mutex_unlock(&pdr->lock);
>
> I'm not sure it is necessary to hold the the mutex during the
> qmi_txn_wait() since the only variable we are trying to protect is
> locator_addr.
>
> Wouldn't this delay other work like new/del server notifications if this
> qmi service is delayed or non-responsive?
>
I've verified, the addr is stored inside the message data by the
enqueueing functions, so the locator_addr isn't referenced after the
function returns. I'll reduce the locking scope.
--
With best wishes
Dmitry
Re: [PATCH v3 3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable USB role switching
On Thu, May 30, 2024 at 05:05:49PM +0200, Luca Weiss wrote: > Configure the Type-C and VBUS regulator on PM7250B and wire it up to the > USB PHY, so that USB role and orientation switching works. > > For now USB Power Delivery properties are skipped / disabled, so that > the (presumably) bootloader-configured charger doesn't get messed with >From my understanding the no-pd, typec-power-opmode disable PD negotiation over the USB-C. If a device gets connected to the power supply, it will still negotiate something like 5V / 1.5A. > and we can charge the phone with at least some amount of power. > > Reviewed-by: Konrad Dybcio > Signed-off-by: Luca Weiss > --- > .../dts/qcom/sm6350-sony-xperia-lena-pdx213.dts| 1 + > arch/arm64/boot/dts/qcom/sm6350.dtsi | 50 +++ > arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 58 > +- > 3 files changed, 108 insertions(+), 1 deletion(-) > Usually the SoC changes come in a separate patch, but I won't insist on that. Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 2/3] arm64: dts: qcom: pm7250b: Add a TCPM description
On Thu, May 30, 2024 at 05:05:48PM +0200, Luca Weiss wrote: > Type-C port management functionality lives inside of the PMIC block on > pm7250b. > > The Type-C port management logic controls orientation detection, > vbus/vconn sense and to send/receive Type-C Power Domain messages. > > Reviewed-by: Bryan O'Donoghue > Reviewed-by: Konrad Dybcio > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/pm7250b.dtsi | 40 > +++ > 1 file changed, 40 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 1/3] arm64: dts: qcom: pm7250b: Add node for PMIC VBUS booster
On Thu, May 30, 2024 at 05:05:47PM +0200, Luca Weiss wrote: > Add the required DTS node for the USB VBUS output regulator, which is > available on PM7250B. This will provide the VBUS source to connected > peripherals. > > Reviewed-by: Bryan O'Donoghue > Signed-off-by: Luca Weiss > --- > arch/arm64/boot/dts/qcom/pm7250b.dtsi | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 01/12] soc: qcom: add firmware name helper
On Thu, 23 May 2024 at 01:48, Bjorn Andersson wrote: > > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote: > > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote: > > > > > > Dmitry Baryshkov writes: > > > > > > > On Tue, 21 May 2024 at 12:52, wrote: > > > >> > > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote: > > > >> > Qualcomm platforms have different sets of the firmware files, which > > > >> > differ from platform to platform (and from board to board, due to the > > > >> > embedded signatures). Rather than listing all the firmware files, > > > >> > including full paths, in the DT, provide a way to determine firmware > > > >> > path based on the root DT node compatible. > > > >> > > > >> Ok this looks quite over-engineered but necessary to handle the legacy, > > > >> but I really think we should add a way to look for a board-specific > > > >> path > > > >> first and fallback to those SoC specific paths. > > > > > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays. > > > > > > To me this also looks like very over-engineered, can you elaborate more > > > why this is needed? Concrete examples would help to understand better. > > > > Sure. During the meeting last week Arnd suggested evaluating if we can > > drop firmware-name from the board DT files. Several reasons for that: > > - DT should describe the hardware, not the Linux-firmware locations > > - having firmware name in DT complicates updating the tree to use > > different firmware API (think of mbn vs mdt vs any other format) > > - If the DT gets supplied by the vendor (e.g. for > > SystemReady-certified devices), there should be a sync between the > > vendor's DT, linux kernel and the rootfs. Dropping firmware names from > > DT solves that by removing one piece of the equation > > > > Now for the complexity of the solution. Each SoC family has their own > > firmware set. This includes firmware for the DSPs, for modem, WiFi > > bits, GPU shader, etc. > > For the development boards these devices are signed by the testing key > > and the actual signature is not validated against the root of trust > > certificate. > > For the end-user devices the signature is actually validated against > > the bits fused to the SoC during manufacturing process. CA certificate > > (and thus the fuses) differ from vendor to vendor (and from the device > > to device) > > > > Not all of the firmware files are a part of the public linux-firmware > > tree. However we need to support the rootfs bundled with the firmware > > for different platforms (both public and vendor). The non-signed files > > come from the Adreno GPU and can be shared between platforms. All > > other files are SoC-specific and in some cases device-specific. > > > > So for example the SDM845 db845c (open device) loads following firmware > > files: > > Not signed: > > - qcom/a630_sqe.fw > > - qcom/a630_gmu.bin > > > > Signed, will work for any non-secured sdm845 device: > > - qcom/sdm845/a630_zap.mbn > > - qcom/sdm845/adsp.mbn > > - qcom/sdm845/cdsp.mbn > > - qcom/sdm485/mba.mbn > > - qcom/sdm845/modem.mbn > > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP) > > - qcom/venus-5.2/venus.mbn > > > > Signed, works only for DB845c. > > - qcom/sdm845/Thundercomm/db845c/slpi.mbn > > > > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the > > following firmware files: > > - qcom/a630_sqe.fw (the same, non-signed file) > > - qcom/a630_gmu.bin (the same, non-signed file) > > - qcom/sdm845/Google/blueline/a630_zap.mbn > > How do you get from "a630_zap.mbn" to this? By extending the lookup > table for every target, or what am I missing? More or less so. Matching the root OF node gives us the firmware location, then it gets prepended to all firmware targets. Not an ideal solution, as there is no fallback support, but at least it gives us some points to discuss (and to decide whether to move to some particular direction or to abandon the idea completely, making Arnd unhappy again). > > Regards, > Bjorn > > > - qcom/sdm845/Google/blueline/adsp.mbn > > - qcom/sdm845/Google/blueline/cdsp.mbn > > - qcom/sdm845/Google/blueline/ipa_fws.mbn > > - qcom/sdm845/Google/blueline/mba.mbn > > - qcom/sdm845/Google/blueline/modem.mbn > > - qcom/sdm845/Google/blueline/venus.mbn > > - qcom/sdm845/Google/blueline/wlanmdsp.mbn &
Re: [PATCH v2 5/5] arm64: dts: qcom: sa8775p-ride: enable remoteprocs
On Mon, May 27, 2024 at 10:43:52AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Enable all remoteproc nodes on the sa8775p-ride board and point to the > appropriate firmware files. > > Signed-off-by: Bartosz Golaszewski > --- > arch/arm64/boot/dts/qcom/sa8775p-ride.dts | 25 + > 1 file changed, 25 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 4/5] arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes
On Mon, May 27, 2024 at 10:43:51AM +0200, Bartosz Golaszewski wrote: > From: Tengfei Fan > > Add nodes for remoteprocs: ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 for > SA8775p SoCs. > > Signed-off-by: Tengfei Fan > Co-developed-by: Bartosz Golaszewski > Signed-off-by: Bartosz Golaszewski > --- > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 332 > ++ > 1 file changed, 332 insertions(+) > With nsp0 vs nsp1 vs nsp sorted out: Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 3/5] remoteproc: qcom_q6v5_pas: Add support for SA8775p ADSP, CDSP and GPDSP
On Mon, May 27, 2024 at 10:43:50AM +0200, Bartosz Golaszewski wrote:
> From: Tengfei Fan
>
> Add support for PIL loading on ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 on
> SA8775p SoCs.
>
> Signed-off-by: Tengfei Fan
> Co-developed-by: Bartosz Golaszewski
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 92
> ++
> 1 file changed, 92 insertions(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
> b/drivers/remoteproc/qcom_q6v5_pas.c
> index 54d8005d40a3..16053aa99298 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -820,6 +820,23 @@ static const struct adsp_data adsp_resource_init = {
> .ssctl_id = 0x14,
> };
>
> +static const struct adsp_data sa8775p_adsp_resource = {
> + .crash_reason_smem = 423,
> + .firmware_name = "adsp.mdt",
mbn please.
Other than that LGTM
> + .pas_id = 1,
> + .minidump_id = 5,
> + .auto_boot = true,
> + .proxy_pd_names = (char*[]){
> + "lcx",
> + "lmx",
> + NULL
> + },
> + .load_state = "adsp",
> + .ssr_name = "lpass",
> + .sysmon_name = "adsp",
> + .ssctl_id = 0x14,
> +};
> +
> static const struct adsp_data sdm845_adsp_resource_init = {
> .crash_reason_smem = 423,
> .firmware_name = "adsp.mdt",
> @@ -933,6 +950,42 @@ static const struct adsp_data cdsp_resource_init = {
> .ssctl_id = 0x17,
> };
>
> +static const struct adsp_data sa8775p_cdsp0_resource = {
> + .crash_reason_smem = 601,
> + .firmware_name = "cdsp0.mdt",
> + .pas_id = 18,
> + .minidump_id = 7,
> + .auto_boot = true,
> + .proxy_pd_names = (char*[]){
> + "cx",
> + "mxc",
> + "nsp0",
> + NULL
> + },
> + .load_state = "cdsp",
> + .ssr_name = "cdsp",
> + .sysmon_name = "cdsp",
> + .ssctl_id = 0x17,
> +};
> +
> +static const struct adsp_data sa8775p_cdsp1_resource = {
> + .crash_reason_smem = 633,
> + .firmware_name = "cdsp1.mdt",
> + .pas_id = 30,
> + .minidump_id = 20,
> + .auto_boot = true,
> + .proxy_pd_names = (char*[]){
> + "cx",
> + "mxc",
> + "nsp1",
> + NULL
> + },
> + .load_state = "nsp",
> + .ssr_name = "cdsp1",
> + .sysmon_name = "cdsp1",
> + .ssctl_id = 0x20,
> +};
> +
> static const struct adsp_data sdm845_cdsp_resource_init = {
> .crash_reason_smem = 601,
> .firmware_name = "cdsp.mdt",
> @@ -1074,6 +1127,40 @@ static const struct adsp_data sm8350_cdsp_resource = {
> .ssctl_id = 0x17,
> };
>
> +static const struct adsp_data sa8775p_gpdsp0_resource = {
> + .crash_reason_smem = 640,
> + .firmware_name = "gpdsp0.mdt",
> + .pas_id = 39,
> + .minidump_id = 21,
> + .auto_boot = true,
> + .proxy_pd_names = (char*[]){
> + "cx",
> + "mxc",
> + NULL
> + },
> + .load_state = "gpdsp0",
> + .ssr_name = "gpdsp0",
> + .sysmon_name = "gpdsp0",
> + .ssctl_id = 0x21,
> +};
> +
> +static const struct adsp_data sa8775p_gpdsp1_resource = {
> + .crash_reason_smem = 641,
> + .firmware_name = "gpdsp1.mdt",
> + .pas_id = 40,
> + .minidump_id = 22,
> + .auto_boot = true,
> + .proxy_pd_names = (char*[]){
> + "cx",
> + "mxc",
> + NULL
> + },
> + .load_state = "gpdsp1",
> + .ssr_name = "gpdsp1",
> + .sysmon_name = "gpdsp1",
> + .ssctl_id = 0x22,
> +};
> +
> static const struct adsp_data mpss_resource_init = {
> .crash_reason_smem = 421,
> .firmware_name = "modem.mdt",
> @@ -1315,6 +1402,11 @@ static const struct of_device_id adsp_of_match[] = {
> { .compatible = "qcom,qcs404-adsp-pas", .data = &adsp_resource_init },
> { .compatible = "qcom,qcs404-cdsp-pas", .data = &cdsp_resource_init },
> { .compatible = "qcom,qcs404-wcss-pas", .data = &wcss_resource_init },
> + { .compatible = "qcom,sa8775p-adsp-pas", .data =
> &sa8775p_adsp_resource},
> + { .compatible = "qcom,sa8775p-cdsp0-pas", .data =
> &sa8775p_cdsp0_resource},
> + { .compatible = "qcom,sa8775p-cdsp1-pas", .data =
> &sa8775p_cdsp1_resource},
> + { .compatible = "qcom,sa8775p-gpdsp0-pas", .data =
> &sa8775p_gpdsp0_resource},
> + { .compatible = "qcom,sa8775p-gpdsp1-pas", .data =
> &sa8775p_gpdsp1_resource},
> { .compatible = "qcom,sc7180-adsp-pas", .data = &sm8250_adsp_resource},
> { .compatible = "qcom,sc7180-mpss-pas", .data = &mpss_resource_init},
> { .compatible = "qcom,sc7280-adsp-pas", .data = &sm8350_adsp_resource},
>
> --
> 2.43.0
>
--
With best wishes
Dmitry
Re: [PATCH 09/12] remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER
On Wed, 22 May 2024 at 22:22, Jeff Johnson wrote:
>
> On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> > Make the driver use qcom_fw_helper to autodetect the path to the
> > calibration data file.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/remoteproc/qcom_wcnss.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/remoteproc/qcom_wcnss.c
> > b/drivers/remoteproc/qcom_wcnss.c
> > index 421a3943a90d..45fc578ae30b 100644
> > --- a/drivers/remoteproc/qcom_wcnss.c
> > +++ b/drivers/remoteproc/qcom_wcnss.c
> > @@ -23,6 +23,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -555,8 +556,13 @@ static int wcnss_probe(struct platform_device *pdev)
> > if (ret < 0 && ret != -EINVAL)
> > return ret;
> >
> > + fw_name = qcom_get_board_fw(fw_name);
> > + if (!fw_name)
> > + return -ENOMEM;
> > +
> > rproc = devm_rproc_alloc(&pdev->dev, pdev->name, &wcnss_ops,
> >fw_name, sizeof(*wcnss));
> > + kfree(fw_name);
> > if (!rproc) {
> > dev_err(&pdev->dev, "unable to allocate remoteproc\n");
> > return -ENOMEM;
> >
>
> can you cleanly bisect to this patch? seems it depends upon patch 10.
> should 09 & 10 be swapped, or perhaps squashed?
Yes. I think I got this mixed during rebasing and squashing of the
changes. For v2, if the approach is found to be generally acceptable,
I'll squash them.
--
With best wishes
Dmitry
Re: [PATCH 01/12] soc: qcom: add firmware name helper
On Tue, 21 May 2024 at 13:20, Kalle Valo wrote: > > Dmitry Baryshkov writes: > > > On Tue, 21 May 2024 at 12:52, wrote: > >> > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote: > >> > Qualcomm platforms have different sets of the firmware files, which > >> > differ from platform to platform (and from board to board, due to the > >> > embedded signatures). Rather than listing all the firmware files, > >> > including full paths, in the DT, provide a way to determine firmware > >> > path based on the root DT node compatible. > >> > >> Ok this looks quite over-engineered but necessary to handle the legacy, > >> but I really think we should add a way to look for a board-specific path > >> first and fallback to those SoC specific paths. > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays. > > To me this also looks like very over-engineered, can you elaborate more > why this is needed? Concrete examples would help to understand better. Sure. During the meeting last week Arnd suggested evaluating if we can drop firmware-name from the board DT files. Several reasons for that: - DT should describe the hardware, not the Linux-firmware locations - having firmware name in DT complicates updating the tree to use different firmware API (think of mbn vs mdt vs any other format) - If the DT gets supplied by the vendor (e.g. for SystemReady-certified devices), there should be a sync between the vendor's DT, linux kernel and the rootfs. Dropping firmware names from DT solves that by removing one piece of the equation Now for the complexity of the solution. Each SoC family has their own firmware set. This includes firmware for the DSPs, for modem, WiFi bits, GPU shader, etc. For the development boards these devices are signed by the testing key and the actual signature is not validated against the root of trust certificate. For the end-user devices the signature is actually validated against the bits fused to the SoC during manufacturing process. CA certificate (and thus the fuses) differ from vendor to vendor (and from the device to device) Not all of the firmware files are a part of the public linux-firmware tree. However we need to support the rootfs bundled with the firmware for different platforms (both public and vendor). The non-signed files come from the Adreno GPU and can be shared between platforms. All other files are SoC-specific and in some cases device-specific. So for example the SDM845 db845c (open device) loads following firmware files: Not signed: - qcom/a630_sqe.fw - qcom/a630_gmu.bin Signed, will work for any non-secured sdm845 device: - qcom/sdm845/a630_zap.mbn - qcom/sdm845/adsp.mbn - qcom/sdm845/cdsp.mbn - qcom/sdm485/mba.mbn - qcom/sdm845/modem.mbn - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP) - qcom/venus-5.2/venus.mbn Signed, works only for DB845c. - qcom/sdm845/Thundercomm/db845c/slpi.mbn In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the following firmware files: - qcom/a630_sqe.fw (the same, non-signed file) - qcom/a630_gmu.bin (the same, non-signed file) - qcom/sdm845/Google/blueline/a630_zap.mbn - qcom/sdm845/Google/blueline/adsp.mbn - qcom/sdm845/Google/blueline/cdsp.mbn - qcom/sdm845/Google/blueline/ipa_fws.mbn - qcom/sdm845/Google/blueline/mba.mbn - qcom/sdm845/Google/blueline/modem.mbn - qcom/sdm845/Google/blueline/venus.mbn - qcom/sdm845/Google/blueline/wlanmdsp.mbn - qcom/sdm845/Google/blueline/slpi.mbn The Lenovo Yoga C630 WoS laptop (SDM850 is a variant of SDM845) uses another set of files: - qcom/a630_sqe.fw (the same, non-signed file) - qcom/a630_gmu.bin (the same, non-signed file) - qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn - qcom/sdm850/LENOVO/81JL/qcadsp850.mbn - qcom/sdm850/LENOVO/81JL/qccdsp850.mbn - qcom/sdm850/LENOVO/81JL/ipa_fws.elf - qcom/sdm850/LENOVO/81JL/qcdsp1v2850.mbn - qcom/sdm850/LENOVO/81JL/qcdsp2850.mbn - qcom/sdm850/LENOVO/81JL/qcvss850.mbn - qcom/sdm850/LENOVO/81JL/wlanmdsp.mbn - qcom/sdm850/LENOVO/81JL/qcslpi850.mbn If we look at one of the recent platforms, e.g. SM8650-QRD, this list also grows up: - qcom/gen70900_sqe.fw (generic, non-signed) - qcom/gmu_gen70900.bin (generic, non-signed) - qcom/sm8650/gen70900_zap.mbn - qcom/sm8650/adsp.mbn - qcom/sm8650/adsp_dtb.mbn - qcom/sm8650/cdsp.mbn - qcom/sm8650/cdsp_dtb.mbn - qcom/sm8650/ipa_fws.mbn - qcom/sm8650/modem.mbn - qcom/sm8650/modem_dtb.mbn - qcom/sm8650/vpu33_4v.mbn (or maybe qcom/vpu-33/vpu_4v.mbn) -- With best wishes Dmitry
Re: [PATCH 01/12] soc: qcom: add firmware name helper
On Tue, 21 May 2024 at 12:52, wrote:
>
> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > Qualcomm platforms have different sets of the firmware files, which
> > differ from platform to platform (and from board to board, due to the
> > embedded signatures). Rather than listing all the firmware files,
> > including full paths, in the DT, provide a way to determine firmware
> > path based on the root DT node compatible.
>
> Ok this looks quite over-engineered but necessary to handle the legacy,
> but I really think we should add a way to look for a board-specific path
> first and fallback to those SoC specific paths.
Again, CONFIG_FW_LOADER_USER_HELPER => delays.
>
> Neil
>
> >
> > Suggested-by: Arnd Bergmann
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/soc/qcom/Kconfig | 5 +++
> > drivers/soc/qcom/Makefile | 1 +
> > drivers/soc/qcom/qcom_fw_helper.c | 86
> > ++
> > include/linux/soc/qcom/fw_helper.h | 10 +
> > 4 files changed, 102 insertions(+)
> >
> > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> > index 5af33b0e3470..b663774d65f8 100644
> > --- a/drivers/soc/qcom/Kconfig
> > +++ b/drivers/soc/qcom/Kconfig
> > @@ -62,6 +62,11 @@ config QCOM_MDT_LOADER
> > tristate
> > select QCOM_SCM
> >
> > +config QCOM_FW_HELPER
> > + tristate "NONE FW HELPER"
> > + help
> > + Helpers to return platform-specific location for the firmware files.
> > +
> > config QCOM_OCMEM
> > tristate "Qualcomm On Chip Memory (OCMEM) driver"
> > depends on ARCH_QCOM
> > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> > index ca0bece0dfff..e612bee5b955 100644
> > --- a/drivers/soc/qcom/Makefile
> > +++ b/drivers/soc/qcom/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
> > obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> > obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
> > obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
> > +obj-$(CONFIG_QCOM_FW_HELPER) += qcom_fw_helper.o
> > obj-$(CONFIG_QCOM_OCMEM)+= ocmem.o
> > obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
> > obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
> > diff --git a/drivers/soc/qcom/qcom_fw_helper.c
> > b/drivers/soc/qcom/qcom_fw_helper.c
> > new file mode 100644
> > index ..13123c2514b8
> > --- /dev/null
> > +++ b/drivers/soc/qcom/qcom_fw_helper.c
> > @@ -0,0 +1,86 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Qualcomm Firmware loading data
> > + *
> > + * Copyright (C) 2024 Linaro Ltd
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static DEFINE_MUTEX(qcom_fw_mutex);
> > +static const char *fw_path;
> > +
> > +static const struct of_device_id qcom_fw_paths[] = {
> > + /* device-specific entries */
> > + { .compatible = "thundercomm,db845c", .data =
> > "qcom/sdm845/Thundercomm/db845c", },
> > + { .compatible = "qcom,qrb5165-rb5", .data =
> > "qcom/sm8250/Thundercomm/RB5", },
> > + /* SoC default entries */
> > + { .compatible = "qcom,apq8016", .data = "qcom/apq8016", },
> > + { .compatible = "qcom,apq8096", .data = "qcom/apq8096", },
> > + { .compatible = "qcom,sdm845", .data = "qcom/sdm845", },
> > + { .compatible = "qcom,sm8250", .data = "qcom/sm8250", },
> > + { .compatible = "qcom,sm8350", .data = "qcom/sm8350", },
> > + { .compatible = "qcom,sm8450", .data = "qcom/sm8450", },
> > + { .compatible = "qcom,sm8550", .data = "qcom/sm8550", },
> > + { .compatible = "qcom,sm8650", .data = "qcom/sm8650", },
> > + {},
> > +};
> > +
> > +static int qcom_fw_ensure_init(void)
> > +{
> > + const struct of_device_id *match;
> > + struct device_node *root;
> > +
> > + if (fw_path)
> > + return 0;
> > +
> > + root = of_find_node_by_path("/");
> > + if (!root)
> > + return -ENODEV;
> > +
> > + match = of_match_node(qcom_fw_paths, root);
> > + of_node_put(root);
> > + if (!match || !match->data) {
> > + pr_no
Re: [PATCH 06/12] remoteproc: qcom_q6v5_pas: switch to mbn files by default
On Tue, 21 May 2024 at 12:49, wrote: > > On 21/05/2024 11:45, Dmitry Baryshkov wrote: > > We have been pushing userspace to use mbn files by default for ages. > > As a preparation for making the firmware-name optional, make the driver > > use .mbn instead of .mdt files by default. > > I think we should have a mechanism to fallback to .mdt since downstream > uses split mdt on the devices filesystem. > > Perhaps only specify .firmware_name = "adsp" and add a list of allowed > extension > it will try in a loop ? Such loops can cause unnecessary delays if the CONFIG_FW_LOADER_USER_HELPER is enabled. Since it is not possible to use vendor's firmware partition as is (you have to either bind-mount a subdir or use a plenty of symlinks) one might as well symlink .mbn to .mdt file. Another option is to explicitly specify something like `firmware-name = "./adsp.mdt";' But yes, this whole series is a balance of pros and cons, as it was discussed last week. -- With best wishes Dmitry
[PATCH 12/12] arm64: dts: qcom: apq8096-db820c: drop firmware-name properties
As the drivers default to loading the firmware from the board-specific
location, drop the firmware-name properties.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
index e8148b3d6c50..2c8a77401aa3 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
@@ -161,7 +161,6 @@ bluetooth {
&adsp_pil {
status = "okay";
- firmware-name = "qcom/apq8096/adsp.mbn";
};
&blsp2_i2c1 {
@@ -253,7 +252,6 @@ &mmcc {
&mss_pil {
status = "okay";
pll-supply = <&vreg_l12a_1p8>;
- firmware-name = "qcom/apq8096/mba.mbn", "qcom/apq8096/modem.mbn";
};
&pm8994_resin {
--
2.39.2
[PATCH 11/12] arm64: dts: qcom: apq8016-sbc: drop firmware-name properties
As the drivers default to loading the firmware from the board-specific
location, drop the firmware-name properties. In case of the WCNSS
calibration data drop the path to the file, retaining just the file
name.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dts | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
index aba08424aa38..24779238cc18 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
@@ -260,8 +260,6 @@ &mdss_dsi0_out {
&mpss {
status = "okay";
-
- firmware-name = "qcom/apq8016/mba.mbn", "qcom/apq8016/modem.mbn";
};
&mpss_mem {
@@ -388,11 +386,10 @@ &venus_mem {
&wcnss {
status = "okay";
- firmware-name = "qcom/apq8016/wcnss.mbn";
};
&wcnss_ctrl {
- firmware-name = "qcom/apq8016/WCNSS_qcom_wlan_nv_sbc.bin";
+ firmware-name = "WCNSS_qcom_wlan_nv_sbc.bin";
};
&wcnss_iris {
--
2.39.2
[PATCH 10/12] remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER
Make the driver use qcom_fw_helper to autodetect the path to the calibration data file. Signed-off-by: Dmitry Baryshkov --- drivers/remoteproc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 7bb22fdb64e4..e0ffcaeca03d 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -279,6 +279,7 @@ config QCOM_WCNSS_PIL depends on QCOM_SMEM depends on QCOM_SYSMON || QCOM_SYSMON=n depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n + select QCOM_FW_HELPER select QCOM_MDT_LOADER select QCOM_PIL_INFO select QCOM_RPROC_COMMON -- 2.39.2
[PATCH 09/12] remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_wcnss.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 421a3943a90d..45fc578ae30b 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -555,8 +556,13 @@ static int wcnss_probe(struct platform_device *pdev)
if (ret < 0 && ret != -EINVAL)
return ret;
+ fw_name = qcom_get_board_fw(fw_name);
+ if (!fw_name)
+ return -ENOMEM;
+
rproc = devm_rproc_alloc(&pdev->dev, pdev->name, &wcnss_ops,
fw_name, sizeof(*wcnss));
+ kfree(fw_name);
if (!rproc) {
dev_err(&pdev->dev, "unable to allocate remoteproc\n");
return -ENOMEM;
--
2.39.2
[PATCH 08/12] remoteproc: qcom_wcnss: switch to mbn files by default
We have been pushing userspace to use mbn files by default for ages. As a preparation for making the firmware-name optional, make the driver use .mbn instead of .mdt files by default. Signed-off-by: Dmitry Baryshkov --- drivers/remoteproc/qcom_wcnss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c index a7bb9da27029..421a3943a90d 100644 --- a/drivers/remoteproc/qcom_wcnss.c +++ b/drivers/remoteproc/qcom_wcnss.c @@ -32,7 +32,7 @@ #include "qcom_wcnss.h" #define WCNSS_CRASH_REASON_SMEM422 -#define WCNSS_FIRMWARE_NAME"wcnss.mdt" +#define WCNSS_FIRMWARE_NAME"wcnss.mbn" #define WCNSS_PAS_ID 6 #define WCNSS_SSCTL_ID 0x13 -- 2.39.2
[PATCH 07/12] remoteproc: qcom_q6v5_pas: make use of QCOM_FW_HELPER
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 884e1e69bbb6..7bb22fdb64e4 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -223,6 +223,7 @@ config QCOM_Q6V5_PAS
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
select MFD_SYSCON
+ select QCOM_FW_HELPER
select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index 4694ec4f038d..893fda54b598 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -705,11 +706,19 @@ static int adsp_probe(struct platform_device *pdev)
&dtb_fw_name);
if (ret < 0 && ret != -EINVAL)
return ret;
+
+ dtb_fw_name = devm_qcom_get_board_fw(&pdev->dev, dtb_fw_name);
+ if (!dtb_fw_name)
+ return -ENOMEM;
}
if (desc->minidump_id)
ops = &adsp_minidump_ops;
+ fw_name = qcom_get_board_fw(fw_name);
+ if (!fw_name)
+ return -ENOMEM;
+
rproc = devm_rproc_alloc(&pdev->dev, pdev->name, ops, fw_name,
sizeof(*adsp));
if (!rproc) {
--
2.39.2
[PATCH 06/12] remoteproc: qcom_q6v5_pas: switch to mbn files by default
We have been pushing userspace to use mbn files by default for ages.
As a preparation for making the firmware-name optional, make the driver
use .mbn instead of .mdt files by default.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_q6v5_pas.c | 76 +++---
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index 54d8005d40a3..4694ec4f038d 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -812,7 +812,7 @@ static void adsp_remove(struct platform_device *pdev)
static const struct adsp_data adsp_resource_init = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.ssr_name = "lpass",
@@ -822,7 +822,7 @@ static const struct adsp_data adsp_resource_init = {
static const struct adsp_data sdm845_adsp_resource_init = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.load_state = "adsp",
@@ -833,7 +833,7 @@ static const struct adsp_data sdm845_adsp_resource_init = {
static const struct adsp_data sm6350_adsp_resource = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -849,7 +849,7 @@ static const struct adsp_data sm6350_adsp_resource = {
static const struct adsp_data sm6375_mpss_resource = {
.crash_reason_smem = 421,
- .firmware_name = "modem.mdt",
+ .firmware_name = "modem.mbn",
.pas_id = 4,
.minidump_id = 3,
.auto_boot = false,
@@ -864,7 +864,7 @@ static const struct adsp_data sm6375_mpss_resource = {
static const struct adsp_data sm8150_adsp_resource = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -879,7 +879,7 @@ static const struct adsp_data sm8150_adsp_resource = {
static const struct adsp_data sm8250_adsp_resource = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -895,7 +895,7 @@ static const struct adsp_data sm8250_adsp_resource = {
static const struct adsp_data sm8350_adsp_resource = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -911,7 +911,7 @@ static const struct adsp_data sm8350_adsp_resource = {
static const struct adsp_data msm8996_adsp_resource = {
.crash_reason_smem = 423,
- .firmware_name = "adsp.mdt",
+ .firmware_name = "adsp.mbn",
.pas_id = 1,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -925,7 +925,7 @@ static const struct adsp_data msm8996_adsp_resource = {
static const struct adsp_data cdsp_resource_init = {
.crash_reason_smem = 601,
- .firmware_name = "cdsp.mdt",
+ .firmware_name = "cdsp.mbn",
.pas_id = 18,
.auto_boot = true,
.ssr_name = "cdsp",
@@ -935,7 +935,7 @@ static const struct adsp_data cdsp_resource_init = {
static const struct adsp_data sdm845_cdsp_resource_init = {
.crash_reason_smem = 601,
- .firmware_name = "cdsp.mdt",
+ .firmware_name = "cdsp.mbn",
.pas_id = 18,
.auto_boot = true,
.load_state = "cdsp",
@@ -946,7 +946,7 @@ static const struct adsp_data sdm845_cdsp_resource_init = {
static const struct adsp_data sm6350_cdsp_resource = {
.crash_reason_smem = 601,
- .firmware_name = "cdsp.mdt",
+ .firmware_name = "cdsp.mbn",
.pas_id = 18,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -962,7 +962,7 @@ static const struct adsp_data sm6350_cdsp_resource = {
static const struct adsp_data sm8150_cdsp_resource = {
.crash_reason_smem = 601,
- .firmware_name = "cdsp.mdt",
+ .firmware_name = "cdsp.mbn",
.pas_id = 18,
.auto_boot = true,
.proxy_pd_names = (char*[]){
@@ -977,7 +977,7 @@ static const struct adsp_data sm8150_cdsp_resource = {
static const struct adsp_data sm8250_cdsp_resource = {
.crash_reason_smem = 601,
- .firmware_name = "cdsp.mdt",
+ .firmware_name = "cdsp.
[PATCH 05/12] remoteproc: qcom_q6v5_mss: make use of QCOM_FW_HELPER
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_mss.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa85..884e1e69bbb6 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -202,6 +202,7 @@ config QCOM_Q6V5_MSS
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
select MFD_SYSCON
+ select QCOM_FW_HELPER
select QCOM_MDT_LOADER
select QCOM_PIL_INFO
select QCOM_Q6V5_COMMON
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index eeaae2505352..1ccd5bb92952 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1990,8 +1991,13 @@ static int q6v5_probe(struct platform_device *pdev)
return ret;
}
+ mba_image = qcom_get_board_fw(mba_image);
+ if (!mba_image)
+ return -ENOMEM;
+
rproc = devm_rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
mba_image, sizeof(*qproc));
+ kfree(mba_image);
if (!rproc) {
dev_err(&pdev->dev, "failed to allocate rproc\n");
return -ENOMEM;
@@ -2011,6 +2017,10 @@ static int q6v5_probe(struct platform_device *pdev)
return ret;
}
+ qproc->hexagon_mdt_image = devm_qcom_get_board_fw(&pdev->dev,
qproc->hexagon_mdt_image);
+ if (!qproc->hexagon_mdt_image)
+ return -ENOMEM;
+
platform_set_drvdata(pdev, qproc);
qproc->has_qaccept_regs = desc->has_qaccept_regs;
--
2.39.2
[PATCH 04/12] remoteproc: qcom_q6v5_mss: switch to mbn files by default
We have been pushing userspace to use mbn files by default for ages.
As a preparation for making the firmware-name optional, make the driver
use .mbn instead of .mdt files by default.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_q6v5_mss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 1779fc890e10..eeaae2505352 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -2003,7 +2003,7 @@ static int q6v5_probe(struct platform_device *pdev)
qproc = rproc->priv;
qproc->dev = &pdev->dev;
qproc->rproc = rproc;
- qproc->hexagon_mdt_image = "modem.mdt";
+ qproc->hexagon_mdt_image = "modem.mbn";
ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
1, &qproc->hexagon_mdt_image);
if (ret < 0 && ret != -EINVAL) {
--
2.39.2
[PATCH 03/12] soc: qcom: wcnss_ctrl: make use of QCOM_FW_HELPER
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 1 +
drivers/soc/qcom/wcnss_ctrl.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index b663774d65f8..3af3f15175e4 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -238,6 +238,7 @@ config QCOM_WCNSS_CTRL
tristate "Qualcomm WCNSS control driver"
depends on ARCH_QCOM || COMPILE_TEST
depends on RPMSG
+ select QCOM_FW_HELPER
help
Client driver for the WCNSS_CTRL SMD channel, used to download nv
firmware to a newly booted WCNSS chip.
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
index 148bcbac332d..7d1a4536226a 100644
--- a/drivers/soc/qcom/wcnss_ctrl.c
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#define WCNSS_REQUEST_TIMEOUT (5 * HZ)
#define WCNSS_CBC_TIMEOUT (10 * HZ)
@@ -214,11 +215,19 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss,
bool *expect_cbc)
if (ret < 0 && ret != -EINVAL)
goto free_req;
+ nvbin = qcom_get_board_fw(nvbin);
+ if (!nvbin) {
+ ret = -ENOMEM;
+ goto free_req;
+ }
+
ret = request_firmware(&fw, nvbin, dev);
if (ret < 0) {
dev_err(dev, "Failed to load nv file %s: %d\n", nvbin, ret);
+ kfree(nvbin);
goto free_req;
}
+ kfree(nvbin);
data = fw->data;
left = fw->size;
--
2.39.2
[PATCH 02/12] wifi: wcn36xx: make use of QCOM_FW_HELPER
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/net/wireless/ath/wcn36xx/Kconfig | 1 +
drivers/net/wireless/ath/wcn36xx/main.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/wcn36xx/Kconfig
b/drivers/net/wireless/ath/wcn36xx/Kconfig
index 5832c7ef9352..90239c89676a 100644
--- a/drivers/net/wireless/ath/wcn36xx/Kconfig
+++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
@@ -4,6 +4,7 @@ config WCN36XX
depends on MAC80211 && HAS_DMA
depends on QCOM_WCNSS_CTRL || QCOM_WCNSS_CTRL=n
depends on RPMSG || RPMSG=n
+ select QCOM_FW_HELPER
help
This module adds support for wireless adapters based on
Qualcomm Atheros WCN3660 and WCN3680 mobile chipsets.
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index e760d8002e09..8d25db81c1d0 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1609,6 +1610,10 @@ static int wcn36xx_probe(struct platform_device *pdev)
goto out_wq;
}
+ wcn->nv_file = devm_qcom_get_board_fw(wcn->dev, wcn->nv_file);
+ if (!wcn->nv_file)
+ return -ENOMEM;
+
wcn->smd_channel = qcom_wcnss_open_channel(wcnss, "WLAN_CTRL",
wcn36xx_smd_rsp_process, hw);
if (IS_ERR(wcn->smd_channel)) {
wcn36xx_err("failed to open WLAN_CTRL channel\n");
--
2.39.2
[PATCH 01/12] soc: qcom: add firmware name helper
Qualcomm platforms have different sets of the firmware files, which
differ from platform to platform (and from board to board, due to the
embedded signatures). Rather than listing all the firmware files,
including full paths, in the DT, provide a way to determine firmware
path based on the root DT node compatible.
Suggested-by: Arnd Bergmann
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 5 +++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/qcom_fw_helper.c | 86 ++
include/linux/soc/qcom/fw_helper.h | 10 +
4 files changed, 102 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 5af33b0e3470..b663774d65f8 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -62,6 +62,11 @@ config QCOM_MDT_LOADER
tristate
select QCOM_SCM
+config QCOM_FW_HELPER
+ tristate "NONE FW HELPER"
+ help
+ Helpers to return platform-specific location for the firmware files.
+
config QCOM_OCMEM
tristate "Qualcomm On Chip Memory (OCMEM) driver"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ca0bece0dfff..e612bee5b955 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
+obj-$(CONFIG_QCOM_FW_HELPER) += qcom_fw_helper.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
diff --git a/drivers/soc/qcom/qcom_fw_helper.c
b/drivers/soc/qcom/qcom_fw_helper.c
new file mode 100644
index ..13123c2514b8
--- /dev/null
+++ b/drivers/soc/qcom/qcom_fw_helper.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm Firmware loading data
+ *
+ * Copyright (C) 2024 Linaro Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static DEFINE_MUTEX(qcom_fw_mutex);
+static const char *fw_path;
+
+static const struct of_device_id qcom_fw_paths[] = {
+ /* device-specific entries */
+ { .compatible = "thundercomm,db845c", .data =
"qcom/sdm845/Thundercomm/db845c", },
+ { .compatible = "qcom,qrb5165-rb5", .data =
"qcom/sm8250/Thundercomm/RB5", },
+ /* SoC default entries */
+ { .compatible = "qcom,apq8016", .data = "qcom/apq8016", },
+ { .compatible = "qcom,apq8096", .data = "qcom/apq8096", },
+ { .compatible = "qcom,sdm845", .data = "qcom/sdm845", },
+ { .compatible = "qcom,sm8250", .data = "qcom/sm8250", },
+ { .compatible = "qcom,sm8350", .data = "qcom/sm8350", },
+ { .compatible = "qcom,sm8450", .data = "qcom/sm8450", },
+ { .compatible = "qcom,sm8550", .data = "qcom/sm8550", },
+ { .compatible = "qcom,sm8650", .data = "qcom/sm8650", },
+ {},
+};
+
+static int qcom_fw_ensure_init(void)
+{
+ const struct of_device_id *match;
+ struct device_node *root;
+
+ if (fw_path)
+ return 0;
+
+ root = of_find_node_by_path("/");
+ if (!root)
+ return -ENODEV;
+
+ match = of_match_node(qcom_fw_paths, root);
+ of_node_put(root);
+ if (!match || !match->data) {
+ pr_notice("Platform not supported by qcom_fw_helper\n");
+ return -ENODEV;
+ }
+
+ fw_path = match->data;
+
+ return 0;
+}
+
+const char *qcom_get_board_fw(const char *firmware)
+{
+ if (strchr(firmware, '/'))
+ return kstrdup(firmware, GFP_KERNEL);
+
+ scoped_guard(mutex, &qcom_fw_mutex) {
+ if (!qcom_fw_ensure_init())
+ return kasprintf(GFP_KERNEL, "%s/%s", fw_path,
firmware);
+ }
+
+ return kstrdup(firmware, GFP_KERNEL);
+}
+EXPORT_SYMBOL_GPL(qcom_get_board_fw);
+
+const char *devm_qcom_get_board_fw(struct device *dev, const char *firmware)
+{
+ if (strchr(firmware, '/'))
+ return devm_kstrdup(dev, firmware, GFP_KERNEL);
+
+ scoped_guard(mutex, &qcom_fw_mutex) {
+ if (!qcom_fw_ensure_init())
+ return devm_kasprintf(dev, GFP_KERNEL, "%s/%s",
fw_path, firmware);
+ }
+
+ return devm_kstrdup(dev, firmware, GFP_KERNEL);
+}
+EXPORT_SYMBOL_GPL(devm_qcom_get_board_fw);
+
+MODULE_DESCRIPTION("Firmware helpers for Qualcomm devices");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/soc/qcom/fw_helper.h
b/include/linux/soc/qcom/fw_helper.h
new file mode 100644
index 0
[PATCH 00/12] arm64: qcom: autodetect firmware paths
This is a followup to the discussion during the Linaro Connect. Remove most of the firmware-name properties from the board DT by using root node compatible to detect firmware path. The most obvious change is that the drivers now have to look for the MBN firmware files by default, so this might break the case of the user simply mounting vendor's firmware partition to /lib/firmware and expecting it to work. Also things are slightly more complex for the platforms like DB845c and Qualcomm RB5. These platforms have generic SoC firmware in qcom/sdm845 and qcom/sm8250 and also the board-specific firmware at qcom/sdm845/Thundercomm/DB845C and qcom/sm8250/Thundercomm/RB5 respectively. Making these boards follow up the scheme would require additional symlinks in the firmware dir. +Link: qcom/sdm845/Thundercomm/db845c/a630_zap.mbn -> ../../a630_zap.mbn +Link: qcom/sm8250/Thundercomm/RB5/a650_zap.mbn -> ../../a650_zap.mbn +Link: qcom/sdm845/Thundercomm/db845c/adsp.mbn -> ../../adsp.mbn +Link: qcom/sdm845/Thundercomm/db845c/adspr.jsn -> ../../adspr.jsn +Link: qcom/sdm845/Thundercomm/db845c/adspua.jsn -> ../../adspua.jsn +Link: qcom/sdm845/Thundercomm/db845c/cdsp.mbn -> ../../cdsp.mbn +Link: qcom/sdm845/Thundercomm/db845c/cdspr.jsn -> ../../cdspr.jsn +Link: qcom/sm8250/Thundercomm/RB5/adsp.mbn -> ../../adsp.mbn +Link: qcom/sm8250/Thundercomm/RB5/adspr.jsn -> ../../adspr.jsn +Link: qcom/sm8250/Thundercomm/RB5/adspua.jsn -> ../../adspua.jsn +Link: qcom/sm8250/Thundercomm/RB5/cdsp.mbn -> ../../cdsp.mbn +Link: qcom/sm8250/Thundercomm/RB5/cdspr.jsn -> ../../cdspr.jsn Suggested-by: Arnd Bergmann Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (12): soc: qcom: add firmware name helper wifi: wcn36xx: make use of QCOM_FW_HELPER soc: qcom: wcnss_ctrl: make use of QCOM_FW_HELPER remoteproc: qcom_q6v5_mss: switch to mbn files by default remoteproc: qcom_q6v5_mss: make use of QCOM_FW_HELPER remoteproc: qcom_q6v5_pas: switch to mbn files by default remoteproc: qcom_q6v5_pas: make use of QCOM_FW_HELPER remoteproc: qcom_wcnss: switch to mbn files by default remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER arm64: dts: qcom: apq8016-sbc: drop firmware-name properties arm64: dts: qcom: apq8096-db820c: drop firmware-name properties arch/arm64/boot/dts/qcom/apq8016-sbc.dts| 5 +- arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 2 - drivers/net/wireless/ath/wcn36xx/Kconfig| 1 + drivers/net/wireless/ath/wcn36xx/main.c | 5 ++ drivers/remoteproc/Kconfig | 3 + drivers/remoteproc/qcom_q6v5_mss.c | 12 +++- drivers/remoteproc/qcom_q6v5_pas.c | 85 +++- drivers/remoteproc/qcom_wcnss.c | 8 ++- drivers/soc/qcom/Kconfig| 6 ++ drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qcom_fw_helper.c | 86 + drivers/soc/qcom/wcnss_ctrl.c | 9 +++ include/linux/soc/qcom/fw_helper.h | 10 13 files changed, 187 insertions(+), 46 deletions(-) --- base-commit: 632483ea8004edfadd035de36e1ab2c7c4f53158 change-id: 20240520-qcom-firmware-name-aeef265a753a Best regards, -- Dmitry Baryshkov
[PATCH v8 3/5] soc: qcom: pdr: extract PDR message marshalling data
The in-kernel PD mapper is going to use same message structures as the
QCOM_PDR_HELPERS module. Extract message marshalling data to separate
module that can be used by both PDR helpers and by PD mapper.
Reviewed-by: Bryan O'Donoghue
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig| 4 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/pdr_internal.h | 306 ++
drivers/soc/qcom/qcom_pdr_msg.c | 319
4 files changed, 334 insertions(+), 296 deletions(-)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 5af33b0e3470..95973c6b828f 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -75,8 +75,12 @@ config QCOM_OCMEM
config QCOM_PDR_HELPERS
tristate
select QCOM_QMI_HELPERS
+ select QCOM_PDR_MSG
depends on NET
+config QCOM_PDR_MSG
+ tristate
+
config QCOM_PMIC_PDCHARGER_ULOG
tristate "Qualcomm PMIC PDCharger ULOG driver"
depends on RPMSG
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ca0bece0dfff..3110ac3288bc 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
+obj-$(CONFIG_QCOM_PDR_MSG) += qcom_pdr_msg.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink_altmode.o
obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG) += pmic_pdcharger_ulog.o
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 03c282b7f17e..7e5bb5a95275 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -28,83 +28,12 @@ struct servreg_location_entry {
u32 instance;
};
-static const struct qmi_elem_info servreg_location_entry_ei[] = {
- {
- .data_type = QMI_STRING,
- .elem_len = SERVREG_NAME_LENGTH + 1,
- .elem_size = sizeof(char),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- name),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- instance),
- },
- {
- .data_type = QMI_UNSIGNED_1_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u8),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- service_data_valid),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- service_data),
- },
- {}
-};
-
struct servreg_get_domain_list_req {
char service_name[SERVREG_NAME_LENGTH + 1];
u8 domain_offset_valid;
u32 domain_offset;
};
-static const struct qmi_elem_info servreg_get_domain_list_req_ei[] = {
- {
- .data_type = QMI_STRING,
- .elem_len = SERVREG_NAME_LENGTH + 1,
- .elem_size = sizeof(char),
- .array_type = NO_ARRAY,
- .tlv_type = 0x01,
- .offset = offsetof(struct servreg_get_domain_list_req,
- service_name),
- },
- {
- .data_type = QMI_OPT_FLAG,
- .elem_len = 1,
- .elem_size = sizeof(u8),
- .array_type = NO_ARRAY,
- .tlv_type = 0x10,
- .offset = offsetof(struct servreg_get_domain_list_req,
- domain_offset_valid),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0x10,
- .offset = offsetof(struct servreg_get_domain_list_req,
- domain_offset),
- },
- {
[PATCH v8 4/5] soc: qcom: add pd-mapper implementation
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted later), etc.
Provide in-kernel service implementing protection domain mapping
required to work with several services, which are provided by the DSP
firmware.
This module is loaded automatically by the remoteproc drivers when
necessary via the symbol dependency. It uses a root node to match a
protection domains map for a particular board. It is not possible to
implement it as a 'driver' as there is no corresponding device.
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 11 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/pdr_internal.h | 14 +
drivers/soc/qcom/qcom_pd_mapper.c | 676 ++
drivers/soc/qcom/qcom_pdr_msg.c | 34 ++
5 files changed, 736 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 95973c6b828f..0a2f2bfd7863 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -72,6 +72,17 @@ config QCOM_OCMEM
requirements. This is typically used by the GPU, camera/video, and
audio components on some Snapdragon SoCs.
+config QCOM_PD_MAPPER
+ tristate "Qualcomm Protection Domain Mapper"
+ select QCOM_QMI_HELPERS
+ depends on NET && QRTR
+ default QCOM_RPROC_COMMON
+ help
+ The Protection Domain Mapper maps registered services to the domains
+ and instances handled by the remote DSPs. This is a kernel-space
+ implementation of the service. It is a simpler alternative to the
+ userspace daemon.
+
config QCOM_PDR_HELPERS
tristate
select QCOM_QMI_HELPERS
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 3110ac3288bc..d3560f861085 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
+obj-$(CONFIG_QCOM_PD_MAPPER) += qcom_pd_mapper.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
obj-$(CONFIG_QCOM_PDR_MSG) += qcom_pdr_msg.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 7e5bb5a95275..8d17f7fb79e7 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -13,6 +13,8 @@
#define SERVREG_SET_ACK_REQ0x23
#define SERVREG_RESTART_PD_REQ 0x24
+#define SERVREG_LOC_PFR_REQ0x24
+
#define SERVREG_DOMAIN_LIST_LENGTH 32
#define SERVREG_RESTART_PD_REQ_MAX_LEN 67
#define SERVREG_REGISTER_LISTENER_REQ_LEN 71
@@ -20,6 +22,7 @@
#define SERVREG_GET_DOMAIN_LIST_REQ_MAX_LEN74
#define SERVREG_STATE_UPDATED_IND_MAX_LEN 79
#define SERVREG_GET_DOMAIN_LIST_RESP_MAX_LEN 2389
+#define SERVREG_LOC_PFR_RESP_MAX_LEN 10
struct servreg_location_entry {
char name[SERVREG_NAME_LENGTH + 1];
@@ -79,6 +82,15 @@ struct servreg_set_ack_resp {
struct qmi_response_type_v01 resp;
};
+struct servreg_loc_pfr_req {
+ char service[SERVREG_NAME_LENGTH + 1];
+ char reason[257];
+};
+
+struct servreg_loc_pfr_resp {
+ struct qmi_response_type_v01 rsp;
+};
+
extern const struct qmi_elem_info servreg_location_entry_ei[];
extern const struct qmi_elem_info servreg_get_domain_list_req_ei[];
extern const struct qmi_elem_info servreg_get_domain_list_resp_ei[];
@@ -89,5 +101,7 @@ extern const struct qmi_elem_info
servreg_restart_pd_resp_ei[];
extern const struct qmi_elem_info servreg_state_updated_ind_ei[];
extern const struct qmi_elem_info servreg_set_ack_req_ei[];
extern const struct qmi_elem_info servreg_set_ack_resp_ei[];
+extern const struct qmi_elem_info servreg_loc_pfr_req_ei[];
+extern const struct qmi_elem_info servreg_loc_pfr_resp_ei[];
#endif
diff --git a/drivers/soc/qcom/qcom_pd_mapper.c
b/drivers/soc/qcom/qcom_pd_mapper.c
new file mode 100644
index ..ecb64f06527f
--- /dev/null
+++ b/drivers/soc/qcom/qcom_pd_mapper.c
@@ -0,0 +1,676 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm Protection Domain mapper
+ *
+ * Copyright (c) 2023 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pdr_internal.h"
+
+#define SERVREG_QMI_VERSION 0x101
+#define SERVREG_QMI_INSTANCE 0
+
+#define TMS_SERVREG_SERVICE "tms/servreg"
+
+struct qcom_pdm_domain_
[PATCH v8 5/5] remoteproc: qcom: enable in-kernel PD mapper
Request in-kernel protection domain mapper to be started before starting
Qualcomm DSP and release it once DSP is stopped. Once all DSPs are
stopped, the PD mapper will be stopped too.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_common.c| 87 +
drivers/remoteproc/qcom_common.h| 10 +
drivers/remoteproc/qcom_q6v5_adsp.c | 3 ++
drivers/remoteproc/qcom_q6v5_mss.c | 3 ++
drivers/remoteproc/qcom_q6v5_pas.c | 3 ++
drivers/remoteproc/qcom_q6v5_wcss.c | 3 ++
6 files changed, 109 insertions(+)
diff --git a/drivers/remoteproc/qcom_common.c b/drivers/remoteproc/qcom_common.c
index 03e5f5d533eb..8c8688f99f0a 100644
--- a/drivers/remoteproc/qcom_common.c
+++ b/drivers/remoteproc/qcom_common.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,6 +26,7 @@
#define to_glink_subdev(d) container_of(d, struct qcom_rproc_glink, subdev)
#define to_smd_subdev(d) container_of(d, struct qcom_rproc_subdev, subdev)
#define to_ssr_subdev(d) container_of(d, struct qcom_rproc_ssr, subdev)
+#define to_pdm_subdev(d) container_of(d, struct qcom_rproc_pdm, subdev)
#define MAX_NUM_OF_SS 10
#define MAX_REGION_NAME_LENGTH 16
@@ -519,5 +521,90 @@ void qcom_remove_ssr_subdev(struct rproc *rproc, struct
qcom_rproc_ssr *ssr)
}
EXPORT_SYMBOL_GPL(qcom_remove_ssr_subdev);
+static void pdm_dev_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ kfree(adev);
+}
+
+static int pdm_notify_prepare(struct rproc_subdev *subdev)
+{
+ struct qcom_rproc_pdm *pdm = to_pdm_subdev(subdev);
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc(sizeof(*adev), GFP_KERNEL);
+ if (!adev)
+ return -ENOMEM;
+
+ adev->dev.parent = pdm->dev;
+ adev->dev.release = pdm_dev_release;
+ adev->name = "pd-mapper";
+ adev->id = pdm->index;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ kfree(adev);
+ return ret;
+ }
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ pdm->adev = adev;
+
+ return 0;
+}
+
+
+static void pdm_notify_unprepare(struct rproc_subdev *subdev)
+{
+ struct qcom_rproc_pdm *pdm = to_pdm_subdev(subdev);
+
+ if (!pdm->adev)
+ return;
+
+ auxiliary_device_delete(pdm->adev);
+ auxiliary_device_uninit(pdm->adev);
+ pdm->adev = NULL;
+}
+
+/**
+ * qcom_add_pdm_subdev() - register PD Mapper subdevice
+ * @rproc: rproc handle
+ * @pdm: PDM subdevice handle
+ *
+ * Register @pdm so that Protection Device mapper service is started when the
+ * DSP is started too.
+ */
+void qcom_add_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm)
+{
+ pdm->dev = &rproc->dev;
+ pdm->index = rproc->index;
+
+ pdm->subdev.prepare = pdm_notify_prepare;
+ pdm->subdev.unprepare = pdm_notify_unprepare;
+
+ rproc_add_subdev(rproc, &pdm->subdev);
+}
+EXPORT_SYMBOL_GPL(qcom_add_pdm_subdev);
+
+/**
+ * qcom_remove_pdm_subdev() - remove PD Mapper subdevice
+ * @rproc: rproc handle
+ * @pdm: PDM subdevice handle
+ *
+ * Remove the PD Mapper subdevice.
+ */
+void qcom_remove_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm)
+{
+ rproc_remove_subdev(rproc, &pdm->subdev);
+}
+EXPORT_SYMBOL_GPL(qcom_remove_pdm_subdev);
+
MODULE_DESCRIPTION("Qualcomm Remoteproc helper driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/remoteproc/qcom_common.h b/drivers/remoteproc/qcom_common.h
index 9ef4449052a9..b07fbaa091a0 100644
--- a/drivers/remoteproc/qcom_common.h
+++ b/drivers/remoteproc/qcom_common.h
@@ -34,6 +34,13 @@ struct qcom_rproc_ssr {
struct qcom_ssr_subsystem *info;
};
+struct qcom_rproc_pdm {
+ struct rproc_subdev subdev;
+ struct device *dev;
+ int index;
+ struct auxiliary_device *adev;
+};
+
void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
void (*rproc_dumpfn_t)(struct rproc *rproc,
struct rproc_dump_segment *segment, void *dest,
size_t offset,
@@ -52,6 +59,9 @@ void qcom_add_ssr_subdev(struct rproc *rproc, struct
qcom_rproc_ssr *ssr,
const char *ssr_name);
void qcom_remove_ssr_subdev(struct rproc *rproc, struct qcom_rproc_ssr *ssr);
+void qcom_add_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm);
+void qcom_remove_pdm_subdev(struct rproc *rproc, struct qcom_rproc_pdm *pdm);
+
#if IS_ENABLED(CONFIG_QCOM_SYSMON)
struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
const char *name,
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/d
[PATCH v8 2/5] soc: qcom: pdr: fix parsing of domains lists
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/pdr_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index e014dd2d8ab3..d495ee736519 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -422,7 +422,7 @@ static int pdr_locate_service(struct pdr_handle *pdr,
struct pdr_service *pds)
if (ret < 0)
goto out;
- for (i = domains_read; i < resp->domain_list_len; i++) {
+ for (i = 0; i < resp->domain_list_len; i++) {
entry = &resp->domain_list[i];
if (strnlen(entry->name, sizeof(entry->name)) ==
sizeof(entry->name))
--
2.39.2
[PATCH v8 0/5] soc: qcom: add in-kernel pd-mapper implementation
Protection domain mapper is a QMI service providing mapping between 'protection domains' and services supported / allowed in these domains. For example such mapping is required for loading of the WiFi firmware or for properly starting up the UCSI / altmode / battery manager support. The existing userspace implementation has several issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't reread the JSON files if the firmware location is changed (or if the firmware was not available at the time pd-mapper was started but the corresponding directory is mounted later), etc. However this configuration is largely static and common between different platforms. Provide in-kernel service implementing static per-platform data. To: Bjorn Andersson To: Konrad Dybcio To: Sibi Sankar To: Mathieu Poirier Cc: linux-arm-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-remotep...@vger.kernel.org Cc: Johan Hovold Cc: Xilin Wu Cc: "Bryan O'Donoghue" Cc: Steev Klimaszewski Cc: Alexey Minnekhanov -- Changes in v8: - Reworked pd-mapper to register as an rproc_subdev / auxdev - Dropped Tested-by from Steev and Alexey from the last patch since the implementation was changed significantly. - Add sensors, cdsp and mpss_root domains to 660 config (Alexey Minnekhanov) - Added platform entry for sm4250 (used for qrb4210 / RB2) - Added locking to the pdr_get_domain_list() (Chris Lew) - Remove the call to qmi_del_server() and corresponding API (Chris Lew) - In qmi_handle_init() changed 1024 to a defined constant (Chris Lew) - Link to v7: https://lore.kernel.org/r/20240424-qcom-pd-mapper-v7-0-05f7fc646...@linaro.org Changes in v7: - Fixed modular build (Steev) - Link to v6: https://lore.kernel.org/r/20240422-qcom-pd-mapper-v6-0-f96957d01...@linaro.org Changes in v6: - Reworked mutex to fix lockdep issue on deregistration - Fixed dependencies between PD-mapper and remoteproc to fix modular builds (Krzysztof) - Added EXPORT_SYMBOL_GPL to fix modular builds (Krzysztof) - Fixed kerneldocs (Krzysztof) - Removed extra pr_debug messages (Krzysztof) - Fixed wcss build (Krzysztof) - Added platforms which do not require protection domain mapping to silence the notice on those platforms - Link to v5: https://lore.kernel.org/r/20240419-qcom-pd-mapper-v5-0-e35b6f847...@linaro.org Changes in v5: - pdr: drop lock in pdr_register_listener, list_lock is already held (Chris Lew) - pd_mapper: reworked to provide static configuration per platform (Bjorn) - Link to v4: https://lore.kernel.org/r/20240311-qcom-pd-mapper-v4-0-24679cca5...@linaro.org Changes in v4: - Fixed missing chunk, reenabled kfree in qmi_del_server (Konrad) - Added configuration for sm6350 (Thanks to Luca) - Removed RFC tag (Konrad) - Link to v3: https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-0-6858fa1ac...@linaro.org Changes in RFC v3: - Send start / stop notifications when PD-mapper domain list is changed - Reworked the way PD-mapper treats protection domains, register all of them in a single batch - Added SC7180 domains configuration based on TCL Book 14 GO - Link to v2: https://lore.kernel.org/r/20240301-qcom-pd-mapper-v2-0-5d12a081d...@linaro.org Changes in RFC v2: - Swapped num_domains / domains (Konrad) - Fixed an issue with battery not working on sc8280xp - Added missing configuration for QCS404 --- Dmitry Baryshkov (5): soc: qcom: pdr: protect locator_addr with the main mutex soc: qcom: pdr: fix parsing of domains lists soc: qcom: pdr: extract PDR message marshalling data soc: qcom: add pd-mapper implementation remoteproc: qcom: enable in-kernel PD mapper drivers/remoteproc/qcom_common.c| 87 + drivers/remoteproc/qcom_common.h| 10 + drivers/remoteproc/qcom_q6v5_adsp.c | 3 + drivers/remoteproc/qcom_q6v5_mss.c | 3 + drivers/remoteproc/qcom_q6v5_pas.c | 3 + drivers/remoteproc/qcom_q6v5_wcss.c | 3 + drivers/soc/qcom/Kconfig| 15 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/pdr_interface.c| 17 +- drivers/soc/qcom/pdr_internal.h | 318 ++--- drivers/soc/qcom/qcom_pd_mapper.c | 676 drivers/soc/qcom/qcom_pdr_msg.c | 353 +++ 12 files changed, 1190 insertions(+), 300 deletions(-) --- base-commit: e5119bbdaca76cd3c15c3c975d51d840bbfb2488 change-id: 20240301-qcom-pd-mapper-e12d622d4ad0 Best regards, -- Dmitry Baryshkov
[PATCH v8 1/5] soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Steev Klimaszewski
Tested-by: Alexey Minnekhanov
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/pdr_interface.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index a1b6a4081dea..e014dd2d8ab3 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle *qmi,
locator_hdl);
struct pdr_service *pds;
+ mutex_lock(&pdr->lock);
/* Create a local client port for QMI communication */
pdr->locator_addr.sq_family = AF_QIPCRTR;
pdr->locator_addr.sq_node = svc->node;
pdr->locator_addr.sq_port = svc->port;
- mutex_lock(&pdr->lock);
pdr->locator_init_complete = true;
mutex_unlock(&pdr->lock);
@@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle *qmi,
mutex_lock(&pdr->lock);
pdr->locator_init_complete = false;
- mutex_unlock(&pdr->lock);
pdr->locator_addr.sq_node = 0;
pdr->locator_addr.sq_port = 0;
+ mutex_unlock(&pdr->lock);
}
static const struct qmi_ops pdr_locator_ops = {
@@ -365,6 +365,7 @@ static int pdr_get_domain_list(struct
servreg_get_domain_list_req *req,
if (ret < 0)
return ret;
+ mutex_lock(&pdr->lock);
ret = qmi_send_request(&pdr->locator_hdl,
&pdr->locator_addr,
&txn, SERVREG_GET_DOMAIN_LIST_REQ,
@@ -373,15 +374,16 @@ static int pdr_get_domain_list(struct
servreg_get_domain_list_req *req,
req);
if (ret < 0) {
qmi_txn_cancel(&txn);
- return ret;
+ goto err_unlock;
}
ret = qmi_txn_wait(&txn, 5 * HZ);
if (ret < 0) {
pr_err("PDR: %s get domain list txn wait failed: %d\n",
req->service_name, ret);
- return ret;
+ goto err_unlock;
}
+ mutex_unlock(&pdr->lock);
if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
pr_err("PDR: %s get domain list failed: 0x%x\n",
@@ -390,6 +392,11 @@ static int pdr_get_domain_list(struct
servreg_get_domain_list_req *req,
}
return 0;
+
+err_unlock:
+ mutex_unlock(&pdr->lock);
+
+ return ret;
}
static int pdr_locate_service(struct pdr_handle *pdr, struct pdr_service *pds)
--
2.39.2
Re: [PATCH v7 1/6] soc: qcom: pdr: protect locator_addr with the main mutex
On Thu, 25 Apr 2024 at 22:30, Chris Lew wrote:
>
>
> On 4/24/2024 2:27 AM, Dmitry Baryshkov wrote:
> > If the service locator server is restarted fast enough, the PDR can
> > rewrite locator_addr fields concurrently. Protect them by placing
> > modification of those fields under the main pdr->lock.
> >
> > Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart
> > helpers")
> > Tested-by: Neil Armstrong # on SM8550-QRD
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/soc/qcom/pdr_interface.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/qcom/pdr_interface.c
> > b/drivers/soc/qcom/pdr_interface.c
> > index a1b6a4081dea..19cfe4b41235 100644
> > --- a/drivers/soc/qcom/pdr_interface.c
> > +++ b/drivers/soc/qcom/pdr_interface.c
> > @@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle
> > *qmi,
> > locator_hdl);
> > struct pdr_service *pds;
> >
> > + mutex_lock(&pdr->lock);
> > /* Create a local client port for QMI communication */
> > pdr->locator_addr.sq_family = AF_QIPCRTR;
> > pdr->locator_addr.sq_node = svc->node;
> > pdr->locator_addr.sq_port = svc->port;
> >
> > - mutex_lock(&pdr->lock);
> > pdr->locator_init_complete = true;
> > mutex_unlock(&pdr->lock);
> >
> > @@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle
> > *qmi,
> >
> > mutex_lock(&pdr->lock);
> > pdr->locator_init_complete = false;
> > - mutex_unlock(&pdr->lock);
> >
> > pdr->locator_addr.sq_node = 0;
> > pdr->locator_addr.sq_port = 0;
> > + mutex_unlock(&pdr->lock);
> > }
> >
> > static const struct qmi_ops pdr_locator_ops = {
> >
>
> These two functions are provided as qmi_ops handlers in pdr_locator_ops.
> Aren't they serialized in the qmi handle's workqueue since it as an
> ordered_workqueue? Even in a fast pdr scenario I don't think we would
> see a race condition between these two functions.
>
> The other access these two functions do race against is in the
> pdr_notifier_work. I think you would need to protect locator_addr in
> pdr_get_domain_list since the qmi_send_request there uses
> 'pdr->locator_addr'.
Thanks, I missed it initially. I think I'd keep the rest of the
changes and expand the lock to cover pdr_get_domain_list().
>
> Thanks!
> Chris
--
With best wishes
Dmitry
