Re: [PATCH 0/3] Fix up qcom,halt-regs definition in various schemas
On Sun, 07 Apr 2024 11:58:29 +0200, Luca Weiss wrote: > The original motivation is that a bunch of other schemas fail to > validate qcom,halt-regs, for example like in the following examples: > > arch/arm64/boot/dts/qcom/apq8016-sbc.dtb: remoteproc@408: > qcom,halt-regs:0: [20] is too short > from schema $id: > http://devicetree.org/schemas/remoteproc/qcom,msm8916-mss-pil.yaml# > arch/arm64/boot/dts/qcom/apq8096-ifc6640.dtb: remoteproc@208: > qcom,halt-regs:0: [82] is too short > from schema $id: > http://devicetree.org/schemas/remoteproc/qcom,msm8996-mss-pil.yaml# > arch/arm64/boot/dts/qcom/apq8039-t2.dtb: remoteproc@408: > qcom,halt-regs:0: [32] is too short > from schema $id: > http://devicetree.org/schemas/remoteproc/qcom,msm8916-mss-pil.yaml# > > [...] Applied, thanks! [1/3] dt-bindings: remoteproc: qcom,qcs404-cdsp-pil: Fix qcom,halt-regs definition commit: a0bcbce661216b9d9d00fb652b35f35da77b2287 [2/3] dt-bindings: remoteproc: qcom,sc7280-wpss-pil: Fix qcom,halt-regs definition commit: 16e204e958096d649aa1617433f31995a9c60809 [3/3] dt-bindings: remoteproc: qcom,sdm845-adsp-pil: Fix qcom,halt-regs definition commit: 4d5ba6ead1dc9fa298d727e92db40cd98564d1ac Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/2] Mark qcom,ipc as deprecated in two schemas
On Thu, 25 Apr 2024 21:14:29 +0200, Luca Weiss wrote: > The mboxes property has been supported in those bindings since a while > and was always meant to the replace qcom,ipc properties, so let's mark > qcom,ipc as deprecated - and update the examples to use mboxes. > > Related: > https://lore.kernel.org/linux-arm-msm/20240424-apcs-mboxes-v1-0-6556c47cb...@z3ntu.xyz/ > > [...] Applied, thanks! [1/2] dt-bindings: remoteproc: qcom,smd-edge: Mark qcom,ipc as deprecated commit: 335617f0d502f80c9b9410c518222b2cb33878e8 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/3] arm64: dts: qcom: msm8996: enable fastrpc and glink-edge
On Thu, 18 Apr 2024 09:44:19 +0300, Dmitry Baryshkov wrote: > Enable the FastRPC and glink-edge nodes on MSM8996 platform. Tested on > APQ8096 Dragonboard820c. > > Applied, thanks! [1/3] dt-bindings: remoteproc: qcom,msm8996-mss-pil: allow glink-edge on msm8996 commit: a0acdef561d1699b020ab932a0edb556c4829533 Best regards, -- Bjorn Andersson
Re: [PATCH V1] soc: qcom: smp2p: Introduce tracepoint support
On Tue, Apr 30, 2024 at 04:18:27PM -0700, Chris Lew wrote: > On 4/29/2024 12:55 AM, Sudeepgoud Patil wrote: > > Introduce tracepoint support for smp2p providing useful logging > > for communication between clients. > > > > Let's add some more description as to why these tracepoint are useful. Do > they help us track latency? debugging information for us? for clients? +1 > > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile [..] > > diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c > > index a21241cbeec7..dde8513641ae 100644 > > --- a/drivers/soc/qcom/smp2p.c > > +++ b/drivers/soc/qcom/smp2p.c > > @@ -20,6 +20,9 @@ > > #include > > #include > > +#define CREATE_TRACE_POINTS > > +#include "trace-smp2p.h" > > + > > /* > >* The Shared Memory Point to Point (SMP2P) protocol facilitates > > communication > >* of a single 32-bit value between two processors. Each value has a > > single > > @@ -191,6 +194,7 @@ static void qcom_smp2p_do_ssr_ack(struct qcom_smp2p > > *smp2p) > > struct smp2p_smem_item *out = smp2p->out; > > u32 val; > > + trace_smp2p_ssr_ack(smp2p->remote_pid); > > smp2p->ssr_ack = !smp2p->ssr_ack; > > val = out->flags & ~BIT(SMP2P_FLAGS_RESTART_ACK_BIT); > > @@ -213,6 +217,7 @@ static void qcom_smp2p_negotiate(struct qcom_smp2p > > *smp2p) > > smp2p->ssr_ack_enabled = true; > > smp2p->negotiation_done = true; > > + trace_smp2p_negotiate(smp2p->remote_pid, > > smp2p->ssr_ack_enabled); > > since this tracepoint is for negotiating, maybe we should capture all of the > features (out->features) instead of just the ssr_ack feature. > Perhaps we can use __print_flags() in TP_printk() for that, it will attempt to resolve the bits and if it fails include the numeric value. > > } > > } [..] > > diff --git a/drivers/soc/qcom/trace-smp2p.h b/drivers/soc/qcom/trace-smp2p.h [..] > > +TRACE_EVENT(smp2p_ssr_ack, > > + TP_PROTO(unsigned int remote_pid), > > Is there any way we can map the remote pid's to a string? I feel like the > tracepoints would be more useful if they called out modem, adsp, etc instead > of an integer value. > And __print_symbolic() for this one. Regards, Bjorn
Re: [PATCH v9 1/3] soc: qcom: Add qcom_rproc_minidump module
On Tue, Mar 26, 2024 at 07:43:12PM +0530, Mukesh Ojha wrote:
> Add qcom_rproc_minidump module in a preparation to remove
> minidump specific code from driver/remoteproc/qcom_common.c
> and provide needed exported API, this as well helps to
> abstract minidump specific data layout from qualcomm's
> remoteproc driver.
>
> It is just a copying of qcom_minidump() functionality from
> driver/remoteproc/qcom_common.c into a separate file under
> qcom_rproc_minidump().
>
I'd prefer to see this enter the git history as one patch, extracting
this logic from the remoteproc into its own driver - rather than as
presented here give a sense that it's a new thing added. (I'll take care
of the maintainer sync...)
I also would prefer for this to include a problem description,
documenting why this is done.
I've not compared patch 1 and 3, but I'd also like a statement in the
commit message telling if there are any changes, or if the functions are
cleanly moved from one place to another.
Regards,
Bjorn
> Signed-off-by: Mukesh Ojha
> ---
> Changes in v9:
> - Added source file driver/remoteproc/qcom_common.c copyright
>to qcom_rproc_minidump.c
> - Dissociated it from minidump series as this can go separately
>and minidump can put it dependency for the data structure files.
>
> Nothing much changed in these three patches from previous version,
> However, giving the link of their older versions.
>
> v8:
> https://lore.kernel.org/lkml/20240131105734.13090-1-quic_mo...@quicinc.com/
> v7:
> https://lore.kernel.org/lkml/20240109153200.12848-1-quic_mo...@quicinc.com/
> v6:
> https://lore.kernel.org/lkml/1700864395-1479-1-git-send-email-quic_mo...@quicinc.com/
> v5:
> https://lore.kernel.org/lkml/1694429639-21484-1-git-send-email-quic_mo...@quicinc.com/
> v4:
> https://lore.kernel.org/lkml/1687955688-20809-1-git-send-email-quic_mo...@quicinc.com/
>
> drivers/soc/qcom/Kconfig | 10 +++
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/qcom_minidump_internal.h | 64 +
> drivers/soc/qcom/qcom_rproc_minidump.c| 115
> ++
> include/soc/qcom/qcom_minidump.h | 23 ++
> 5 files changed, 213 insertions(+)
> create mode 100644 drivers/soc/qcom/qcom_minidump_internal.h
> create mode 100644 drivers/soc/qcom/qcom_rproc_minidump.c
> create mode 100644 include/soc/qcom/qcom_minidump.h
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 5af33b0e3470..ed23e0275c22 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -277,4 +277,14 @@ config QCOM_PBS
> This module provides the APIs to the client drivers that wants to
> send the
> PBS trigger event to the PBS RAM.
>
> +config QCOM_RPROC_MINIDUMP
> + tristate "QCOM Remoteproc Minidump Support"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on QCOM_SMEM
> + help
> + Enablement of core Minidump feature is controlled from boot firmware
> + side, so if it is enabled from firmware, this config allow Linux to
> + query predefined Minidump segments associated with the remote
> processor
> + and check its validity and end up collecting the dump on remote
> processor
> + crash during its recovery.
> endmenu
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ca0bece0dfff..44664589263d 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_QCOM_ICC_BWMON)+= icc-bwmon.o
> qcom_ice-objs+= ice.o
> obj-$(CONFIG_QCOM_INLINE_CRYPTO_ENGINE) += qcom_ice.o
> obj-$(CONFIG_QCOM_PBS) +=qcom-pbs.o
> +obj-$(CONFIG_QCOM_RPROC_MINIDUMP)+= qcom_rproc_minidump.o
> diff --git a/drivers/soc/qcom/qcom_minidump_internal.h
> b/drivers/soc/qcom/qcom_minidump_internal.h
> new file mode 100644
> index ..71709235b196
> --- /dev/null
> +++ b/drivers/soc/qcom/qcom_minidump_internal.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_MINIDUMP_INTERNAL_H_
> +#define _QCOM_MINIDUMP_INTERNAL_H_
> +
> +#define MAX_NUM_OF_SS 10
> +#define MAX_REGION_NAME_LENGTH 16
> +#define SBL_MINIDUMP_SMEM_ID 602
> +#define MINIDUMP_REGION_VALID ('V' << 24 | 'A' << 16 | 'L' << 8 |
> 'I' << 0)
> +#define MINIDUMP_SS_ENCR_DONE ('D' << 24 | 'O' << 16 | 'N' << 8 |
> 'E' << 0)
> +#define MINIDUMP_SS_ENABLED ('E' << 24 | 'N' << 16 | 'B' << 8 | 'L' << 0)
> +
> +/**
> + * struct minidump_region - Minidump region
> + * @name : Name of the region to be dumped
> + * @seq_num: : Use to differentiate regions with same name.
> + * @valid: This entry to be dumped (if set to 1)
> + * @address : Physical address of region to be dumped
> + * @size : Size of the region
> +
Re: (subset) [PATCH v2 0/3] Convert qcom,hfpll documentation to yaml + related changes
On Sun, 18 Feb 2024 21:57:24 +0100, Luca Weiss wrote: > Finally touch the hfpll doc and convert it to yaml, and do some related > changes along the way. > > Applied, thanks! [1/3] dt-bindings: clock: qcom,hfpll: Convert to YAML commit: 849ed9d414d04e369bccc2278d75becde9e40e0f [2/3] clk: qcom: hfpll: Add QCS404-specific compatible commit: 3db0f3b9ff5adb6a5e8564a32fadb2af1216810d Best regards, -- Bjorn Andersson
Re: [PATCH 0/7] Use mboxes instead of syscon for APCS (arm32 & arm64)
On Wed, Apr 24, 2024 at 06:23:53PM +0200, Luca Weiss wrote: > The first patch is for removing a bogus error warning I've noticed while > developing this on msm8226 - there the patches are also coming later for > this SoC since apcs is getting hooked up to cpufreq there also. > > Apart from usages from the qcom,smsm driver (patches coming!) all other > usages of the apcs mailbox now go via the mailbox driver - where one is > used, so some arm32 boards will continue using "qcom,ipc*" properties in > the short or long term. > Very nice, thank you for cleaning this up. Regards, Bjorn > Only compile-tested apart from msm8953 (tested on sdm632-fairphone-fp3) > and msm8974 (tested on msm8974pro-fairphone-fp2), but I don't expect any > complications with this. > > Signed-off-by: Luca Weiss > --- > Luca Weiss (7): > rpmsg: qcom_smd: Don't print error during probe deferral > ARM: dts: qcom: msm8974: Use mboxes properties for APCS > arm64: dts: qcom: msm8916: Use mboxes properties for APCS > arm64: dts: qcom: msm8939: Use mboxes properties for APCS > arm64: dts: qcom: msm8953: Use mboxes properties for APCS > arm64: dts: qcom: msm8976: Use mboxes properties for APCS > arm64: dts: qcom: msm8994: Use mboxes properties for APCS > > arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 14 +++--- > arch/arm64/boot/dts/qcom/msm8916.dtsi| 10 +- > arch/arm64/boot/dts/qcom/msm8939.dtsi| 4 ++-- > arch/arm64/boot/dts/qcom/msm8953.dtsi| 10 +- > arch/arm64/boot/dts/qcom/msm8976.dtsi| 8 > arch/arm64/boot/dts/qcom/msm8994.dtsi| 6 +++--- > drivers/rpmsg/qcom_smd.c | 3 ++- > 7 files changed, 28 insertions(+), 27 deletions(-) > --- > base-commit: 43173e6dbaa227f3107310d4df4a3bacd5e0df33 > change-id: 20240423-apcs-mboxes-12ee6c01a5b3 > > Best regards, > -- > Luca Weiss >
Re: [PATCH 1/7] rpmsg: qcom_smd: Don't print error during probe deferral
On Wed, Apr 24, 2024 at 06:23:54PM +0200, Luca Weiss wrote:
> When the mailbox driver has not probed yet, skip printing the error
> message since it's just going to confuse users.
>
> Signed-off-by: Luca Weiss
> ---
> drivers/rpmsg/qcom_smd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index 43f601c84b4f..6fc299657adf 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -1502,7 +1502,8 @@ struct qcom_smd_edge *qcom_smd_register_edge(struct
> device *parent,
>
> ret = qcom_smd_parse_edge(>dev, node, edge);
> if (ret) {
> - dev_err(>dev, "failed to parse smd edge\n");
> + if (ret != -EPROBE_DEFER)
> + dev_err(>dev, "failed to parse smd edge\n");
In the described case, this error message would not be entirely
accurate, and the cause is not accurately captured in devices_deferred.
Unless I'm mistaken, it seems like qcom_smd_parse_edge() will also print
a more useful error in every other case, except after the mbox_chan !=
-ENODEV check..
How about making that:
if (PTR_ERR(edge->mbox_chan) != -ENODEV) {
ret = dev_err_probe(dev, PTR_ERR(edge->mbox_chan),
"failed to acquire IPC mailbox\n");
goto put_node;
}
And then drop the error print here in qcom_smd_register_edge().
It would bring us the devices_deferred tracking, and it would avoid the
double print in all other cases.
Regards,
Bjorn
> goto unregister_dev;
> }
>
>
> --
> 2.44.0
>
Re: [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Add USB-C orientation GPIO
On Thu, 11 Apr 2024 09:06:11 +0200, Luca Weiss wrote: > Define the USB-C orientation GPIOs so that the USB-C ports orientation > is known without having to resort to the altmode notifications. > > On PCB level this is the signal from PM7250B (pin CC_OUT) which is > called USB_PHY_PS. > > > [...] Applied, thanks! [1/1] arm64: dts: qcom: qcm6490-fairphone-fp5: Add USB-C orientation GPIO commit: e788ef2bdac7fdbd61b626f65fdf7528a1c6fd3b Best regards, -- Bjorn Andersson
Re: [PATCH] ARM: dts: qcom: msm8974-sony-shinano: Enable vibrator
On Sat, 06 Apr 2024 17:27:20 +0200, Luca Weiss wrote: > Enable the vibrator connected to PM8941 found on the Sony shinano > platform. > > Applied, thanks! [1/1] ARM: dts: qcom: msm8974-sony-shinano: Enable vibrator commit: 5c94b0b906436aad74e559195007afdd328211f4 Best regards, -- Bjorn Andersson
Re: [PATCH v2 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU
On Mon, Apr 01, 2024 at 07:21:52PM +0200, Adam Skladowski wrote:
> Add Adreno GPU node.
>
> Signed-off-by: Adam Skladowski
> ---
> arch/arm64/boot/dts/qcom/msm8976.dtsi | 65 +++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
> b/arch/arm64/boot/dts/qcom/msm8976.dtsi
> index 6be310079f5b..77670fce9b8f 100644
> --- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
> @@ -1074,6 +1074,71 @@ mdss_dsi1_phy: phy@1a96a00 {
> };
> };
>
> + adreno_gpu: gpu@1c0 {
> + compatible = "qcom,adreno-510.0", "qcom,adreno";
> +
> + reg = <0x01c0 0x4>;
> + reg-names = "kgsl_3d0_reg_memory";
> +
> + interrupts = ;
> + interrupt-names = "kgsl_3d0_irq";
> +
> + clocks = < GCC_GFX3D_OXILI_CLK>,
> + < GCC_GFX3D_OXILI_AHB_CLK>,
> + < GCC_GFX3D_OXILI_GMEM_CLK>,
> + < GCC_GFX3D_BIMC_CLK>,
> + < GCC_GFX3D_OXILI_TIMER_CLK>,
> + < GCC_GFX3D_OXILI_AON_CLK>;
> + clock-names = "core",
> + "iface",
> + "mem",
> + "mem_iface",
> + "rbbmtimer",
> + "alwayson";
> +
> + power-domains = < OXILI_GX_GDSC>;
> +
> + iommus = <_iommu 0>;
> +
> + status = "disabled";
Make status the last property of the node, please.
Regards,
Bjorn
> +
> + operating-points-v2 = <_opp_table>;
> +
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
Re: [PATCH v2 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes
On Mon, Apr 01, 2024 at 07:21:51PM +0200, Adam Skladowski wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
> b/arch/arm64/boot/dts/qcom/msm8976.dtsi
[..]
> + mdss: display-subsystem@1a0 {
[..]
> + mdss_dsi0: dsi@1a94000 {
> + compatible = "qcom,msm8976-dsi-ctrl",
> "qcom,mdss-dsi-ctrl";
> + reg = <0x01a94000 0x25c>;
> + reg-names = "dsi_ctrl";
> +
> + interrupt-parent = <>;
> + interrupts = <4>;
> +
> + clocks = < GCC_MDSS_MDP_CLK>,
> + < GCC_MDSS_AHB_CLK>,
> + < GCC_MDSS_AXI_CLK>,
> + < GCC_MDSS_BYTE0_CLK>,
> + < GCC_MDSS_PCLK0_CLK>,
> + < GCC_MDSS_ESC0_CLK>;
> + clock-names = "mdp_core",
> + "iface",
> + "bus",
> + "byte",
> + "pixel",
> + "core";
> +
> + assigned-clocks = < GCC_MDSS_BYTE0_CLK_SRC>,
> + < GCC_MDSS_PCLK0_CLK_SRC>;
> + assigned-clock-parents = <_dsi0_phy 0>,
> + <_dsi0_phy 1>;
> +
> + phys = <_dsi0_phy>;
> +
> + operating-points-v2 = <_opp_table>;
> + power-domains = < MDSS_GDSC>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
Seems reasonable to keep this disabled as well. Further more _dsi0
depends on _dsi0_phy which is disabled.
> + ports {
[..]
> + mdss_dsi0_phy: phy@1a94a00 {
> + compatible = "qcom,dsi-phy-28nm-hpm-fam-b";
> + reg = <0x01a94a00 0xd4>,
> + <0x01a94400 0x280>,
> + <0x01a94b80 0x30>;
> + reg-names = "dsi_pll",
> + "dsi_phy",
> + "dsi_phy_regulator";
> +
> + #clock-cells = <1>;
> + #phy-cells = <0>;
> +
> + clocks = < GCC_MDSS_AHB_CLK>,
> + < RPM_SMD_XO_CLK_SRC>;
> + clock-names = "iface", "ref";
> +
> + status = "disabled";
> + };
PS. Leave _mdp enabled...
Regards,
Bjorn
Re: (subset) [PATCH v3 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
On Sun, 07 Apr 2024 11:05:10 +0200, Stanislav Jakubek wrote: > Document the Motorola Moto G (2013), which is a smartphone based > on the Qualcomm MSM8226 SoC. > > Applied, thanks! [1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013) commit: 4785ec47ec890fe66f31ee886a767dbdf2ea6bae [2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013) commit: 49481b6a8f35017af23e9fdfb644095f50a474e3 Best regards, -- Bjorn Andersson
Re: [PATCH 0/2] Small fixes for MSM8974 SoC dtsi
On Mon, 18 Mar 2024 10:24:40 +0100, Luca Weiss wrote: > One fix for dt schema validation, one for the /chosen node. > > Applied, thanks! [1/2] ARM: dts: qcom: msm8974: Add @0 to memory node name commit: cad23ffd46e2205582f5a9e9014b3d78ec0256db [2/2] ARM: dts: qcom: msm8974: Add empty chosen node commit: 7018981366d496db4b7d5f6a5c2673683d2b1639 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/3] Split sony-castor into shinano-common and add Sony Xperia Z3
On Thu, 14 Mar 2024 19:56:21 +0100, Luca Weiss wrote: > Prepare for adding sony-leo dts by splitting common parts into a > separate dtsi file. > > Then add the dts for Sony Xperia Z3. > > Depends on: > https://lore.kernel.org/linux-arm-msm/20240306-castor-changes-v1-0-2286eaf85...@z3ntu.xyz/T/ > > [...] Applied, thanks! [1/3] ARM: dts: qcom: msm8974-sony-castor: Split into shinano-common commit: 53426f53eda5e4a17197a8bc7dd1045601db407e [3/3] ARM: dts: qcom: Add Sony Xperia Z3 smartphone commit: 8d91a5a4a6f5aff714a14ac4a86931aa789655d8 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 1/1] clk: qcom: smd-rpm: Restore msm8976 num_clk
On Mon, 01 Apr 2024 19:16:39 +0200, Adam Skladowski wrote: > During rework somehow msm8976 num_clk got removed, restore it. > > Applied, thanks! [1/1] clk: qcom: smd-rpm: Restore msm8976 num_clk commit: 0d4ce2458cd7d1d66a5ee2f3c036592fb663d5bc Best regards, -- Bjorn Andersson
Re: [PATCH 64/64] i2c: reword i2c_algorithm in drivers according to newest specification
On Fri, Mar 22, 2024 at 02:25:57PM +0100, Wolfram Sang wrote: > Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C > v7, SMBus 3.2, I3C specifications and replace "master/slave" with more > appropriate terms. For some drivers, this means no more conversions are > needed. For the others more work needs to be done but this will be > performed incrementally along with API changes/improvements. All these > changes here are simple search/replace results. > > Signed-off-by: Wolfram Sang Reviewed-by: Bjorn Andersson Regards, Bjorn
Re: [GIT PULL] remoteproc updates for v6.9
On Thu, Mar 21, 2024 at 05:55:13AM -0700, Bjorn Andersson wrote:
> I'm sorry for the late pull request, I apparently had managed to get git
> send-email to only deliver my mail to /dev/null on the machine where I
> prepared
> this.
>
I was further notified that this conflicts with your tree, Linus. Below
is the resolution for this conflict.
Please let me know if you'd like me to create some form of merge commit
for this.
Regards,
Bjorn
diff --cc drivers/remoteproc/imx_dsp_rproc.c
index d73727a5828a,56a799cb8b36..087506e21508
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@@ -1090,9 -1154,7 +1090,7 @@@ static int imx_dsp_rproc_probe(struct p
return 0;
err_detach_domains:
- imx_dsp_detach_pm_domains(priv);
+ dev_pm_domain_detach_list(priv->pd_list);
- err_put_rproc:
- rproc_free(rproc);
return ret;
}
@@@ -1104,8 -1166,7 +1102,7 @@@ static void imx_dsp_rproc_remove(struc
pm_runtime_disable(>dev);
rproc_del(rproc);
- imx_dsp_detach_pm_domains(priv);
+ dev_pm_domain_detach_list(priv->pd_list);
- rproc_free(rproc);
}
/* pm runtime functions */
diff --cc drivers/remoteproc/qcom_q6v5_adsp.c
index 93f9a1537ec6,34ac996a93b2..1d24c9b656a8
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@@ -704,13 -713,15 +704,13 @@@ static int adsp_probe(struct platform_d
ret = adsp_init_clock(adsp, desc->clk_ids);
if (ret)
- goto free_rproc;
+ return ret;
- ret = qcom_rproc_pds_attach(adsp->dev, adsp,
- desc->proxy_pd_names);
+ ret = qcom_rproc_pds_attach(adsp, desc->pd_names, desc->num_pds);
if (ret < 0) {
dev_err(>dev, "Failed to attach proxy power domains\n");
- goto free_rproc;
+ return ret;
}
- adsp->proxy_pd_count = ret;
ret = adsp_init_reset(adsp);
if (ret)
@@@ -742,11 -753,8 +742,8 @@@
return 0;
disable_pm:
- qcom_rproc_pds_detach(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
+ qcom_rproc_pds_detach(adsp);
- free_rproc:
- rproc_free(rproc);
-
return ret;
}
@@@ -760,8 -768,7 +757,7 @@@ static void adsp_remove(struct platform
qcom_remove_glink_subdev(adsp->rproc, >glink_subdev);
qcom_remove_sysmon_subdev(adsp->sysmon);
qcom_remove_ssr_subdev(adsp->rproc, >ssr_subdev);
- qcom_rproc_pds_detach(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
+ qcom_rproc_pds_detach(adsp);
- rproc_free(adsp->rproc);
}
static const struct adsp_pil_data adsp_resource_init = {
[GIT PULL] hwspinlock updates for v6.9
The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d: Linux 6.8-rc1 (2024-01-21 14:11:32 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/hwlock-v6.9 for you to fetch changes up to cebaa386d5ee1a44a58c12f1d220f62cc567fdb0: hwspinlock: omap: Use index to get hwspinlock pointer (2024-03-05 20:01:14 -0800) hwspinlock updates for v6.9 This provides some code cleanup for the OMAP hwspinlock driver. Andrew Davis (4): hwspinlock: omap: Remove unneeded check for OF node hwspinlock: omap: Use devm_pm_runtime_enable() helper hwspinlock: omap: Use devm_hwspin_lock_register() helper hwspinlock: omap: Use index to get hwspinlock pointer drivers/hwspinlock/omap_hwspinlock.c | 57 +++- 1 file changed, 10 insertions(+), 47 deletions(-)
[GIT PULL] rpmsg updates for v6.9
The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d: Linux 6.8-rc1 (2024-01-21 14:11:32 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rpmsg-v6.9 for you to fetch changes up to b03aa6d4e9a74c4289929b6cf3c6bcc80270682d: rpmsg: core: Make rpmsg_bus const (2024-02-05 13:43:22 -0700) rpmsg updates for v6.9 This transitions rpmsg_ctrl and rpmsg_char drivers away from the deprecated ida_simple_*() API. It also makes the rpmsg_bus const. Christophe JAILLET (1): rpmsg: Remove usage of the deprecated ida_simple_xx() API Ricardo B. Marliere (1): rpmsg: core: Make rpmsg_bus const drivers/rpmsg/rpmsg_char.c | 12 ++-- drivers/rpmsg/rpmsg_core.c | 2 +- drivers/rpmsg/rpmsg_ctrl.c | 12 ++-- 3 files changed, 13 insertions(+), 13 deletions(-)
[GIT PULL] remoteproc updates for v6.9
I'm sorry for the late pull request, I apparently had managed to get git send-email to only deliver my mail to /dev/null on the machine where I prepared this. Regards, Bjorn The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d: Linux 6.8-rc1 (2024-01-21 14:11:32 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rproc-v6.9 for you to fetch changes up to 62210f7509e13a2caa7b080722a45229b8f17a0a: remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSP (2024-03-05 20:02:07 -0800) remoteproc updates for v6.9 Qualcomm SM8650 audio, compute and modem remoteproc are added. Qualcomm X1 Elite audio and compute remoteprocs are added, after support for shutting down the bootloader-loaded firmware loaded into the audio DSP.. A dozen drivers in the subsystem are transitioned to use devres helpers for remoteproc and memory allocations. It makes it possible to acquire in-kernel handle to individual remoteproc instances in a cluster. The release of DMA memory for remoteproc virtio is corrected to ensure that restarting due to a watchdog bite doesn't attempt to allocate the memory again without first freeing it. Last, but not least, a couple of DeviceTree binding cleanups. Abel Vesa (1): dt-bindings: remoteproc: qcom,sm8550-pas: document the X1E80100 aDSP & cDSP Andrew Davis (17): remoteproc: k3-dsp: Use devm_rproc_alloc() helper remoteproc: k3-dsp: Add devm action to release reserved memory remoteproc: k3-dsp: Use devm_kcalloc() helper remoteproc: imx_dsp_rproc: Use devm_rproc_alloc() helper remoteproc: imx_rproc: Use devm_rproc_alloc() helper remoteproc: st: Use devm_rproc_alloc() helper remoteproc: stm32: Use devm_rproc_alloc() helper remoteproc: k3-dsp: Use devm_ti_sci_get_by_phandle() helper remoteproc: k3-dsp: Use devm_kzalloc() helper remoteproc: k3-dsp: Add devm action to release tsp remoteproc: k3-dsp: Use devm_ioremap_wc() helper remoteproc: k3-dsp: Use devm_rproc_add() helper remoteproc: qcom_q6v5_adsp: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_mss: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_pas: Use devm_rproc_alloc() helper remoteproc: qcom_q6v5_wcss: Use devm_rproc_alloc() helper remoteproc: qcom_wcnss: Use devm_rproc_alloc() helper Arnaud Pouliquen (2): remoteproc: stm32: Fix incorrect type in assignment for va remoteproc: stm32: Fix incorrect type assignment returned by stm32_rproc_get_loaded_rsc_tablef Dmitry Baryshkov (1): remoteproc: qcom: pas: correct data indentation Joakim Zhang (1): remoteproc: virtio: Fix wdg cannot recovery remote processor Krzysztof Kozlowski (2): dt-bindings: remoteproc: qcom,glink-rpm-edge: drop redundant type from label dt-bindings: remoteproc: do not override firmware-name $ref Mathieu Poirier (1): remoteproc: Make rproc_get_by_phandle() work for clusters Neil Armstrong (3): dt-bindings: remoteproc: qcom,sm8550-pas: document the SM8650 PAS remoteproc: qcom: pas: make region assign more generic remoteproc: qcom: pas: Add SM8650 remoteproc support Sibi Sankar (2): remoteproc: qcom_q6v5_pas: Add support for X1E80100 ADSP/CDSP remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSP .../devicetree/bindings/remoteproc/mtk,scp.yaml| 4 +- .../bindings/remoteproc/qcom,glink-rpm-edge.yaml | 1 - .../bindings/remoteproc/qcom,qcs404-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sc7180-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml | 2 +- .../bindings/remoteproc/qcom,sc8180x-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sm6115-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sm6350-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sm6375-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sm8150-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sm8350-pas.yaml | 2 +- .../bindings/remoteproc/qcom,sm8550-pas.yaml | 51 +++- .../bindings/remoteproc/qcom,wcnss-pil.yaml| 2 +- drivers/remoteproc/imx_dsp_rproc.c | 11 +- drivers/remoteproc/imx_rproc.c | 16 +- drivers/remoteproc/qcom_q6v5_adsp.c| 14 +- drivers/remoteproc/qcom_q6v5_mss.c | 28 +- drivers/remoteproc/qcom_q6v5_pas.c | 326 ++--- drivers/remoteproc/qcom_q6v5_wcss.c| 24 +- drivers/remoteproc/qcom_wcnss.c| 17 +- drivers/remoteproc/remoteproc_core.c | 29 +- drivers/remoteproc/remoteproc_virtio.c | 6 +- drivers/remoteproc/st_remoteproc.c | 15 +- drivers/remoteproc/stm32_rproc.c |
Re: [PATCH 0/5] Some devicetree cleanup for MSM8974 Sony Xperia Z2 Tablet
On Wed, 06 Mar 2024 00:18:03 +0100, Luca Weiss wrote: > The sony-castor dts has been around for a while, clean up some things to > prepare for further changes including the introduction of the > shinano-based Sony Xperia Z3. > > Applied, thanks! [1/5] ARM: dts: qcom: msm8974pro-castor: Clean up formatting commit: c0b9c616e881a1ea6b158dcad73e2198c483a56a [2/5] ARM: dts: qcom: msm8974pro-castor: Add mmc aliases commit: 0268bfec8ae06bc1091c2b9058287391872f8853 [3/5] ARM: dts: qcom: msm8974pro-castor: Remove camera button definitions commit: 26b950f2af40bd6cc36c3ac8ee6643ff3e905753 [4/5] ARM: dts: qcom: msm8974pro-castor: Add debounce-interval for keys commit: ead56f2e68b874c3549a67c6ae0c6186f780bf2f [5/5] ARM: dts: qcom: msm8974pro-castor: Rename wifi node name commit: b756001175b1145a4855c8cfa77ceec78350c36a Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On Thu, 08 Feb 2024 10:52:31 +0100, Luca Weiss wrote: > This series adds all the necessary bits to enable USB-C role switching, > charger and fuel gauge (all via pmic-glink) on Fairphone 5. > > Applied, thanks! [1/2] dt-bindings: soc: qcom: qcom,pmic-glink: document QCM6490 compatible commit: a5b150af2c6ad2749aee51edc36f9f9883869f5b Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sdm632-fairphone-fp3: enable USB-C port handling
On Tue, 20 Feb 2024 13:01:22 +0100, Luca Weiss wrote: > Add the definition for the USB-C connector found on this phone and hook > up the relevant bits. This enables USB role switching. > > Applied, thanks! [1/1] arm64: dts: qcom: sdm632-fairphone-fp3: enable USB-C port handling commit: 90053b1574f8cff3a3b53accc496246ad2e0aec3 Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: Fix type of "wdog" IRQs for remoteprocs
On Mon, 19 Feb 2024 15:33:27 +0100, Luca Weiss wrote: > The code in qcom_q6v5_init() requests the "wdog" IRQ as > IRQF_TRIGGER_RISING. If dt defines the interrupt type as LEVEL_HIGH then > the driver will have issues getting the IRQ again after probe deferral > with an error like: > > irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b22! > > [...] Applied, thanks! [1/1] arm64: dts: qcom: Fix type of "wdog" IRQs for remoteprocs commit: dd6943ef8edde3c6b8aee06cb142c9a41086e3b3 Best regards, -- Bjorn Andersson
Re: [PATCH V4] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
On Wed, Dec 20, 2023 at 11:25:11AM +0530, Vignesh Viswanathan wrote:
> 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.
>
> Signed-off-by: Vignesh Viswanathan
No concerns with the patch now, but as this depends on the mpd driver,
which is being refactored, please resubmit this once the driver is being
accepted.
> ---
> 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.
Please review go/upstream and start using b4.
Regards,
Bjorn
>
> This patch depends on [1] which adds support for IPQ9574 and IPQ5332
> remoteproc q5v5_mpd driver.
>
> [1]:
> https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@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_mpd.c | 13 ---
> drivers/remoteproc/qcom_q6v5_mss.c | 5 ++-
> drivers/remoteproc/qcom_q6v5_pas.c | 59 +++--
> drivers/remoteproc/qcom_q6v5_wcss.c | 12 +++---
> 7 files changed, 66 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 0e32f13c196d..e4a28bf25130 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, );
> + msg = qcom_smem_get(q6v5->crash_reason_partition,
> q6v5->crash_reason_item, );
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "watchdog received: %s\n", msg);
> else
> @@ -121,7 +121,7 @@ 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, );
> + msg = qcom_smem_get(q6v5->crash_reason_partition,
> q6v5->crash_reason_item, );
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
> else
> @@ -279,14 +279,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 = >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(>start_done);
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 4e1bb1a68284..cd02372e9856 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -40,7 +40,8 @@ struct qcom_q6v5 {
> struct completion stop_done;
> struct completion spawn_done;
>
> - int crash_reason;
> + int crash_reason_partition;
> + int crash_reason_item;
>
> bool running;
>
> @@ -49,7 +50,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 6c67514cc493..055764aa201c 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -62,7 +62,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;
> @@ -98,7
Re: [PATCH v5 0/4] Add samsung-matisselte and common matisse dtsi
On Tue, 31 Oct 2023 15:00:54 +0100, Stefan Hansson wrote: > This series adds a common samsung-matisse dtsi and reworks > samsung-matisse-wifi to use it, and introduces samsung-matisselte. I > choose matisselte over matisse-lte as this is how most other devices > (klte, s3ve3g) do it and it is the codename that Samsung gave the > device. See individual commits for more information. > Applied, thanks! [1/4] ARM: dts: qcom: samsung-matisse-common: Add initial common device tree (no commit info) [2/4] dt-bindings: arm: qcom: Add Samsung Galaxy Tab 4 10.1 LTE commit: 2a478a521876d9daea016be3e9513a67871169b5 [3/4] ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 LTE (SM-T535) (no commit info) [4/4] ARM: dts: qcom: samsung-matisse-common: Add UART (no commit info) Best regards, -- Bjorn Andersson
Re: [PATCH v2] ARM: dts: qcom: msm8226: Add watchdog node
On Wed, 14 Feb 2024 22:46:28 +0100, Luca Weiss wrote: > Add watchdog for MSM8226 platform. > > Applied, thanks! [1/1] ARM: dts: qcom: msm8226: Add watchdog node commit: 9e9c906ede3b7dcf7bf7df61ac712613c7d6c2da Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sm6350: Add interconnect for MDSS
On Fri, 16 Feb 2024 14:11:20 +0100, Luca Weiss wrote: > Add the definition for the interconnect used in the display subsystem. > > Applied, thanks! [1/1] arm64: dts: qcom: sm6350: Add interconnect for MDSS commit: fc48bb313513d140026e4d0c441f290ab9c08577 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/3] Add PPG support for PMI632 LPG dtsi
On Mon, 05 Feb 2024 10:51:37 +0100, Luca Weiss wrote: > Hook up the PBS & SDAM to the PMI632 LPG so that we can use the > hw_pattern for the LEDs. > > Applied, thanks! [3/3] arm64: defconfig: Enable QCOM PBS commit: 9c5c14c066f353ac1f4e3b4dd6e19451eac61e0c Best regards, -- Bjorn Andersson
Re: [PATCH 1/3] dt-bindings: mfd: qcom,spmi-pmic: Add pbs to SPMI device types
On Mon, Feb 05, 2024 at 10:51:38AM +0100, Luca Weiss wrote: > Add the PBS (Programmable Boot Sequencer) to the list of devices. > > Signed-off-by: Luca Weiss Reviewed-by: Bjorn Andersson Regards, Bjorn > --- > Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml > b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml > index 8103fb61a16c..b7f01cbb8fff 100644 > --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml > @@ -160,6 +160,10 @@ patternProperties: > type: object > $ref: /schemas/nvmem/qcom,spmi-sdam.yaml# > > + "^pbs@[0-9a-f]+$": > +type: object > +$ref: /schemas/soc/qcom/qcom,pbs.yaml# > + >"phy@[0-9a-f]+$": > type: object > $ref: /schemas/phy/qcom,snps-eusb2-repeater.yaml# > > -- > 2.43.0 >
Re: [PATCH 0/2] Bring up more CPU cores on MSM8226
On Sun, 03 Dec 2023 23:38:16 +0100, Luca Weiss wrote: > Add some nodes to bring up SMP on msm8226 SoC. Another commit to fix the > sorting of the nodes is also included since the ordering is currently a > bit all over the place. > > Applied, thanks! [1/2] ARM: dts: qcom: msm8226: Sort and clean up nodes commit: 70d6c14f52ff14742d5260b825fd76d047166a75 [2/2] ARM: dts: qcom: msm8226: Add CPU and SAW/ACC nodes commit: 74851b7f180a0534f25c3d0b744a92b2e3cb6dd2 Best regards, -- Bjorn Andersson
Re: [PATCH v3] ARM: dts: qcom: msm8974: correct qfprom node size
On Sat, 10 Feb 2024 17:45:40 +0100, Luca Weiss wrote: > The qfprom actually is bigger than 0x1000, so adjust the reg. > > Note that the non-ECC-corrected qfprom can be found at 0xfc4b8000 > (-0x4000). The current reg points to the ECC-corrected qfprom block > which should have equivalent values at all offsets compared to the > non-corrected version. > > [...] Applied, thanks! [1/1] ARM: dts: qcom: msm8974: correct qfprom node size commit: 724c4bf0e4bf81dba77736afb93964c986c3c123 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/3] Bring up more CPU cores on MSM8226
On Sat, 10 Feb 2024 17:28:51 +0100, Luca Weiss wrote: > Add some nodes to bring up SMP on msm8226 SoC. Another commit to fix the > sorting of the nodes is also included since the ordering is currently a > bit all over the place. > > The bindings patch depends on the following series: > https://lore.kernel.org/linux-arm-msm/20240102-saw2-spm-regulator-v7-0-0472ec237...@linaro.org/ > > [...] Applied, thanks! [2/3] ARM: dts: qcom: msm8226: Sort and clean up nodes commit: 70d6c14f52ff14742d5260b825fd76d047166a75 [3/3] ARM: dts: qcom: msm8226: Add CPU and SAW/ACC nodes commit: 74851b7f180a0534f25c3d0b744a92b2e3cb6dd2 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v7 0/4] remoteproc: qcom: Introduce DSP support for SM8650
On Tue, 23 Jan 2024 09:51:01 +0100, Neil Armstrong wrote: > Add the bindings and driver changes for DSP support on the > SM8650 platform in order to enable the aDSP, cDSP and MPSS > subsystems to boot. > > Compared to SM8550, where SM8650 uses the same dual firmware files, > (dtb file and main firmware) the memory zones requirement has changed: > - cDSP: now requires 2 memory zones to be configured as shared > between the cDSP and the HLOS subsystem > - MPSS: In addition to the memory zone required for the SM8550 > MPSS, two more are required to be configured for MPSS > usage only. > > [...] Applied, thanks! [4/4] arm64: dts: qcom: sm8650: add missing qlink_logging reserved memory for mpss commit: af53ecef19ffab5eed346032a0e79110cb82cc1d Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/3] Add MDSS_BCR reset (+some more) for MSM8953
On Thu, 25 Jan 2024 22:35:11 +0100, Luca Weiss wrote: > Add the MDSS_BCR reset that is found in the GCC of MSM8953 so we can > make sure the MDSS gets properly reset before Linux starts using it. > > Also add some others that have been found in the LK sources. > > Applied, thanks! [3/3] arm64: dts: qcom: msm8953: add reset for display subsystem commit: 9b4dec638c9cd1e881125894e263b0f824b8f75e Best regards, -- Bjorn Andersson
Re: [PATCH RFC 0/2] Add GPU support to MSM8953 SoC
On Thu, 25 Jan 2024 22:56:24 +0100, Luca Weiss wrote: > Add the GPU IOMMU and GPU nodes to the msm8953 dtsi so GPU can work. > > First of all, functionally this series looks fine, tested on > sdm632-fairphone-fp3. > > Secondly and the reason this is marked RFC for now is basically just dt > bindings check fail, and some questions regarding IOMMU compatible. > > [...] Applied, thanks! [1/2] arm64: dts: qcom: msm8953: Add GPU IOMMU commit: 1e48ad0d85f05fb4f383cba006525aa3f253472b [2/2] arm64: dts: qcom: msm8953: Add GPU commit: 655815649fcd9bf80b21bcac071633ce80c358c0 Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sm6350: Add tsens thermal zones
On Wed, 24 Jan 2024 16:31:43 +0100, Luca Weiss wrote: > Add the definitions for the various thermal zones found on the SM6350 > SoC. Hooking up GPU and CPU cooling can limit the clock speeds there to > reduce the temperature again to good levels. > > Most thermal zones only have one critical temperature configured at > 125°C which can be mostly considered a placeholder until those zones can > be hooked up to cooling. > > [...] Applied, thanks! [1/1] arm64: dts: qcom: sm6350: Add tsens thermal zones commit: 646287950b165b8396a697f7e18e2267b9466149 Best regards, -- Bjorn Andersson
Re: [PATCH 2/4] hwspinlock: omap: Use devm_pm_runtime_enable() helper
On Tue, Jan 23, 2024 at 10:04:03AM -0600, Andrew Davis wrote:
> This disables runtime PM on module exit, allowing us to simplify
> the probe exit path and remove callbacks. Do that here.
As with the later patch, unless I'm misreading the code, you already do
disable runtime PM in omap_hwspinlock_remove().
>
> Signed-off-by: Andrew Davis
> ---
> drivers/hwspinlock/omap_hwspinlock.c | 26 --
> 1 file changed, 8 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/hwspinlock/omap_hwspinlock.c
> b/drivers/hwspinlock/omap_hwspinlock.c
[..]
> @@ -129,16 +125,12 @@ static int omap_hwspinlock_probe(struct platform_device
> *pdev)
> ret = hwspin_lock_register(bank, >dev, _hwspinlock_ops,
> base_id, num_locks);
> if (ret)
> - goto runtime_err;
> + return ret;
>
> dev_dbg(>dev, "Registered %d locks with HwSpinlock core\n",
> num_locks);
I don't fancy these debug information messages, there are other ways to
confirm that the device probed successfully etc.
Now that you don't need the goto runtime_err, I'd prefer the tail of
this function:
return hwspin_lock_register(...);
Regards,
Bjorn
>
> return 0;
> -
> -runtime_err:
> - pm_runtime_disable(>dev);
> - return ret;
> }
>
> static void omap_hwspinlock_remove(struct platform_device *pdev)
> @@ -151,8 +143,6 @@ static void omap_hwspinlock_remove(struct platform_device
> *pdev)
> dev_err(>dev, "%s failed: %d\n", __func__, ret);
> return;
> }
> -
> - pm_runtime_disable(>dev);
> }
>
> static const struct of_device_id omap_hwspinlock_of_match[] = {
> --
> 2.39.2
>
Re: [PATCH 3/4] hwspinlock: omap: Use devm_hwspin_lock_register() helper
On Tue, Jan 23, 2024 at 10:04:04AM -0600, Andrew Davis wrote:
> This unregister the HW spinlock on module exit, allowing us to
> remove the remove callback. Do this here.
>
I interpret this as stating that the driver currently doesn't unregister
the spinlocks, but as far as I can see it does, and that the patch has
no functional change.
Can you please rewrite this commit message to clearly express which
"problem" you're solving, and unless I'm mistaken clarify that there's
no functional change.
Patch itself looks good.
Regards,
Bjorn
> Signed-off-by: Andrew Davis
> ---
> drivers/hwspinlock/omap_hwspinlock.c | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/drivers/hwspinlock/omap_hwspinlock.c
> b/drivers/hwspinlock/omap_hwspinlock.c
> index 2f18ea6c05e3f..1b0a1bea2b24a 100644
> --- a/drivers/hwspinlock/omap_hwspinlock.c
> +++ b/drivers/hwspinlock/omap_hwspinlock.c
> @@ -117,12 +117,10 @@ static int omap_hwspinlock_probe(struct platform_device
> *pdev)
> if (!bank)
> return -ENOMEM;
>
> - platform_set_drvdata(pdev, bank);
> -
> for (i = 0, hwlock = >lock[0]; i < num_locks; i++, hwlock++)
> hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
>
> - ret = hwspin_lock_register(bank, >dev, _hwspinlock_ops,
> + ret = devm_hwspin_lock_register(>dev, bank, _hwspinlock_ops,
> base_id, num_locks);
> if (ret)
> return ret;
> @@ -133,18 +131,6 @@ static int omap_hwspinlock_probe(struct platform_device
> *pdev)
> return 0;
> }
>
> -static void omap_hwspinlock_remove(struct platform_device *pdev)
> -{
> - struct hwspinlock_device *bank = platform_get_drvdata(pdev);
> - int ret;
> -
> - ret = hwspin_lock_unregister(bank);
> - if (ret) {
> - dev_err(>dev, "%s failed: %d\n", __func__, ret);
> - return;
> - }
> -}
> -
> static const struct of_device_id omap_hwspinlock_of_match[] = {
> { .compatible = "ti,omap4-hwspinlock", },
> { .compatible = "ti,am64-hwspinlock", },
> @@ -155,7 +141,6 @@ MODULE_DEVICE_TABLE(of, omap_hwspinlock_of_match);
>
> static struct platform_driver omap_hwspinlock_driver = {
> .probe = omap_hwspinlock_probe,
> - .remove_new = omap_hwspinlock_remove,
> .driver = {
> .name = "omap_hwspinlock",
> .of_match_table = omap_hwspinlock_of_match,
> --
> 2.39.2
>
Re: [PATCH] ARM: dts: qcom: apq8026-lg-lenok: Add vibrator support
On Sun, 21 Jan 2024 11:09:57 +0100, Luca Weiss wrote: > This device has a vibrator attached to the CAMSS_GP0_CLK, use clk-pwm > and pwm-vibrator to make the vibrator work. > > Applied, thanks! [1/1] ARM: dts: qcom: apq8026-lg-lenok: Add vibrator support commit: 4d679e3c29e3609962de43e51c8c1abda34e Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sm7225-fairphone-fp4: Switch firmware ext to .mbn
On Wed, 10 Jan 2024 16:21:19 +0100, Luca Weiss wrote: > Specify the file name for the squashed/non-split firmware with the .mbn > extension instead of the split .mdt. The kernel can load both but the > squashed version is preferred in dts nowadays. > > Applied, thanks! [1/1] arm64: dts: qcom: sm7225-fairphone-fp4: Switch firmware ext to .mbn commit: 410dd97e3f394a1bac444f1964754968557f844d Best regards, -- Bjorn Andersson
Re: [PATCH] ARM: dts: qcom: msm8926-htc-memul: Add rmtfs memory node
On Sun, 21 Jan 2024 11:21:54 +0100, Luca Weiss wrote: > Add the rmtfs-mem node which was part of one of the "unknown" memory > reservation. Split that one, make sure the reserved-memory in total > still covers the same space. > > Applied, thanks! [1/1] ARM: dts: qcom: msm8926-htc-memul: Add rmtfs memory node commit: 713bc594c6334a36d0caf4b98510ba3b6795616a Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sc7280: Add static properties to cryptobam
On Fri, 29 Dec 2023 09:51:37 +0100, Luca Weiss wrote: > When the properties num-channels & qcom,num-ees are not specified, the > driver tries to read the values from registers, but this read fails and > resets the device if the interconnect from the qcom,qce node is not > already active when that happens. > > Add the static properties to not touch any registers during probe, the > rest of the time when the BAM is used by QCE then the interconnect will > be active already. > > [...] Applied, thanks! [1/1] arm64: dts: qcom: sc7280: Add static properties to cryptobam commit: 521cb01e12750fe290a3819cfe9334c8ac0d1fb0 Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Add missing reserved-memory
On Fri, 29 Dec 2023 13:53:17 +0100, Luca Weiss wrote: > It seems we also need to reserve a region of 81 MiB called "removed_mem" > otherwise we can easily hit the following error with higher RAM usage: > > [ 1467.809274] Internal error: synchronous external abort: 9610 > [#2] SMP > > Applied, thanks! [1/1] arm64: dts: qcom: qcm6490-fairphone-fp5: Add missing reserved-memory commit: acc38e600c52c6d423b374ec6642e5acfaea4710 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On Wed, 20 Dec 2023 11:02:55 +0100, Luca Weiss wrote: > This series adds all the necessary bits to enable USB-C role switching, > charger and fuel gauge (all via pmic-glink) on Fairphone 5. > > One thing that could be made different is the pmic-glink compatible. > I've chosen to use qcm6490 compatible for it and not sc7280 since > there's plenty of firmware variety on sc7280-based platforms and they > might require different quirks in the future, so limit this PDOS quirk > to just qcm6490 for now. > > [...] Applied, thanks! [3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PMIC GLINK commit: 4cc920ed7899de91ea39b6c9bdb0ebb6860e8b47 Best regards, -- Bjorn Andersson
Re: [PATCH] ARM: dts: qcom: apq8026-samsung-matissewifi: Configure touch keys
On Mon, 04 Dec 2023 11:46:49 +0200, Matti Lehtimäki wrote: > Add touch keys which are handled in touchscreen driver. > Use KEY_APPSELECT for the left button because other devices use that > even though downstream kernel uses KEY_RECENT. > > Applied, thanks! [1/1] ARM: dts: qcom: apq8026-samsung-matissewifi: Configure touch keys commit: ffb05e91b68bc58484b94b5d3d1aa8e559278fd6 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 0/3] Enable venus on Fairphone 5 / non-ChromeOS sc7280 venus support
On Fri, 01 Dec 2023 10:33:17 +0100, Luca Weiss wrote: > Devices with Qualcomm firmware (compared to ChromeOS firmware) need some > changes in the venus driver and dts layout so that venus can initialize. > > Do these changes, similar to sc7180. > > Applied, thanks! [2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common commit: 82066cdb17608abc95192632fd5c702be8e57ab5 [3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable venus node commit: 2aa72de2fc9230c54048e3555d04e945ec4f8891 Best regards, -- Bjorn Andersson
Re: [PATCH v3 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On Fri, Dec 01, 2023 at 10:33:19AM +0100, Luca Weiss wrote:
> If the video-firmware node is present, the venus driver assumes we're on
> a system that doesn't use TZ for starting venus, like on ChromeOS
> devices.
>
> Move the video-firmware node to chrome-common.dtsi so we can use venus
> on a non-ChromeOS devices. We also need to move the secure SID 0x2184
> for iommu since (on some boards) we cannot touch that.
>
> At the same time also disable the venus node by default in the dtsi,
> like it's done on other SoCs.
>
> Reviewed-by: Bryan O'Donoghue
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 11 +++
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 +++--
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> index 5d462ae14ba1..459ff877df54 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> @@ -104,6 +104,17 @@ {
> dma-coherent;
> };
>
> + {
> + iommus = <_smmu 0x2180 0x20>,
> + <_smmu 0x2184 0x20>;
> +
> + status = "okay";
> +
> + video-firmware {
> + iommus = <_smmu 0x21a2 0x0>;
> + };
> +};
> +
> {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 326897af117a..0ff9a2484096 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -3836,10 +3836,11 @@ venus: video-codec@aa0 {
> <_noc MASTER_VIDEO_P0 0 _virt
> SLAVE_EBI1 0>;
> interconnect-names = "cpu-cfg", "video-mem";
>
> - iommus = <_smmu 0x2180 0x20>,
> - <_smmu 0x2184 0x20>;
> + iommus = <_smmu 0x2180 0x20>;
qcom,sc7280-venus expects 2 items here. Please follow up with a patch to
the binding, if you haven't send one already.
Thanks,
Bjorn
> memory-region = <_mem>;
>
> + status = "disabled";
> +
> video-decoder {
> compatible = "venus-decoder";
> };
> @@ -3848,10 +3849,6 @@ video-encoder {
> compatible = "venus-encoder";
> };
>
> - video-firmware {
> - iommus = <_smmu 0x21a2 0x0>;
> - };
> -
> venus_opp_table: opp-table {
> compatible = "operating-points-v2";
>
>
> --
> 2.43.0
>
Re: [PATCH v4 2/2] remoteproc: enhance rproc_put() for clusters
On Wed, Jan 03, 2024 at 02:11:25PM -0800, Tanmay Shah wrote:
> This patch enhances rproc_put() to support remoteproc clusters
> with multiple child nodes as in rproc_get_by_phandle().
>
> Signed-off-by: Tarak Reddy
> Signed-off-by: Tanmay Shah
As described in the first patch, this documents that Tarak first
certified the origin of this patch, then you certify the origin as you
handle the patch.
But according to From: you're the author, so how could Tarak have
certified the origin before you authored the patch?
Either correct the author, or add Co-developed-by, if that's what
happened.
> ---
> drivers/remoteproc/remoteproc_core.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 0b3b34085e2f..f276956f2c5c 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -2554,7 +2554,11 @@ EXPORT_SYMBOL(rproc_free);
> */
> void rproc_put(struct rproc *rproc)
> {
> - module_put(rproc->dev.parent->driver->owner);
> + if (rproc->dev.parent->driver)
> + module_put(rproc->dev.parent->driver->owner);
> + else
> + module_put(rproc->dev.parent->parent->driver->owner);
> +
This does however highlight a bug that was introduced by patch 1, please
avoid this by squashing the two patches together (and use
Co-developed-by as needed).
Regards,
Bjorn
> put_device(>dev);
> }
> EXPORT_SYMBOL(rproc_put);
> --
> 2.25.1
>
Re: [PATCH v4 1/2] remoteproc: Make rproc_get_by_phandle() work for clusters
On Wed, Jan 03, 2024 at 02:11:24PM -0800, Tanmay Shah wrote:
> From: Mathieu Poirier
>
> Multi-cluster remoteproc designs typically have the following DT
> declaration:
>
> remoteproc_cluster {
> compatible = "soc,remoteproc-cluster";
>
> core0: core0 {
> compatible = "soc,remoteproc-core"
> memory-region;
> sram;
> };
>
> core1: core1 {
> compatible = "soc,remoteproc-core"
> memory-region;
> sram;
> }
> };
The indention of this snippet looks weird in my client, because it
contains a mixture of tabs and spaces. Please clean that up, and while
at it, '_' is not a valid character in DT node names...
>
> A driver exists for the cluster rather than the individual cores
> themselves so that operation mode and HW specific configurations
> applicable to the cluster can be made.
>
> Because the driver exists at the cluster level and not the individual
> core level, function rproc_get_by_phandle() fails to return the
> remoteproc associated with the phandled it is called for.
>
> This patch enhances rproc_get_by_phandle() by looking for the cluster's
> driver when the driver for the immediate remoteproc's parent is not
> found.
>
> Reported-by: Ben Levinsky
> Signed-off-by: Mathieu Poirier
The s-o-b is used to certify the origin of the patch, Mathieu provided
his signature here, then as you handle the patch you need to append your
s-o-b to provide the same certification.
The for appropriate tracking of reality, Mathieu should append his s-o-b
when/if he applies the patch.
TL;DR please add your S-o-b after Mathieu's.
Change itself looks good to me.
Regards,
Bjorn
> ---
> drivers/remoteproc/remoteproc_core.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 695cce218e8c..0b3b34085e2f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2112,6 +2113,7 @@ EXPORT_SYMBOL(rproc_detach);
> struct rproc *rproc_get_by_phandle(phandle phandle)
> {
> struct rproc *rproc = NULL, *r;
> + struct device_driver *driver;
> struct device_node *np;
>
> np = of_find_node_by_phandle(phandle);
> @@ -2122,7 +2124,26 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
> list_for_each_entry_rcu(r, _list, node) {
> if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
> /* prevent underlying implementation from being removed
> */
> - if (!try_module_get(r->dev.parent->driver->owner)) {
> +
> + /*
> + * If the remoteproc's parent has a driver, the
> + * remoteproc is not part of a cluster and we can use
> + * that driver.
> + */
> + driver = r->dev.parent->driver;
> +
> + /*
> + * If the remoteproc's parent does not have a driver,
> + * look for the driver associated with the cluster.
> + */
> + if (!driver) {
> + if (r->dev.parent->parent)
> + driver = r->dev.parent->parent->driver;
> + if (!driver)
> + break;
> + }
> +
> + if (!try_module_get(driver->owner)) {
> dev_err(>dev, "can't get owner\n");
> break;
> }
> --
> 2.25.1
>
[GIT PULL] hwspinlock updates to v6.8
The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/hwlock-v6.8 for you to fetch changes up to bcd0f5d18b0b1134ccf9ef68e7a0cf637aab380d: hwspinlock/core: fix kernel-doc warnings (2023-12-07 14:51:38 -0800) hwspinlock updates to v6.8 Correct kernel-doc through the hwspinlock core, to address build warnings (and improve the documentation). Drop unused compatible in the Qualcomm TCSR mutex driver. Randy Dunlap (1): hwspinlock/core: fix kernel-doc warnings Vignesh Viswanathan (1): hwspinlock: qcom: Remove IPQ6018 SOC specific compatible drivers/hwspinlock/hwspinlock_core.c | 53 drivers/hwspinlock/qcom_hwspinlock.c | 1 - 2 files changed, 29 insertions(+), 25 deletions(-)
[GIT PULL] remoteproc updates for v6.8
The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rproc-v6.8 for you to fetch changes up to 300ed425dfa99f6926299ec196a1eedf05f47b21: remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS (2023-12-17 10:06:32 -0800) remoteproc updates for v6.8 The i.MX DSP remoteproc driver adds support for providing a resource table, in order to enable IPC with the core. The TI K3 DSP driver is transitioned to remove_new, error messages are changed to use symbolic error codes, and dev_err_probe() is used where applicable. Support for the Qualcomm SC7280 audio, compute and WiFi co-processors are added to the Qualcomm TrustZone based remoteproc driver. Iuliana Prodan (2): remoteproc: imx_dsp_rproc: Add mandatory find_loaded_rsc_table op arm64: dts: imx8mp: Add reserve-memory nodes for DSP Luca Weiss (3): dt-bindings: remoteproc: qcom: sc7180-pas: Fix SC7280 MPSS PD-names dt-bindings: remoteproc: qcom: sc7180-pas: Add SC7280 compatibles remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS Uwe Kleine-König (3): remoteproc: k3-dsp: Suppress duplicate error message in .remove() remoteproc: k3-dsp: Use symbolic error codes in error messages remoteproc: k3-dsp: Convert to platform remove callback returning void .../bindings/remoteproc/qcom,sc7180-pas.yaml | 21 ++ arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 22 ++ drivers/remoteproc/imx_dsp_rproc.c | 1 + drivers/remoteproc/qcom_q6v5_pas.c | 19 + drivers/remoteproc/ti_k3_dsp_remoteproc.c | 87 ++ 5 files changed, 101 insertions(+), 49 deletions(-)
[GIT PULL] rpmsg updates for v6.8
The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rpmsg-v6.8 for you to fetch changes up to d5362c37e1f8a40096452fc201c30e705750e687: rpmsg: virtio: Free driver_override when rpmsg_remove() (2023-12-18 10:56:03 -0700) rpmsg updates for v6.8 This make virtio free driver_override upon removal. It also updates the rpmsg documentation after earlier API updates. Adrien Leravat (1): doc: rmpsg: Update with rpmsg_endpoint Xiaolei Wang (1): rpmsg: virtio: Free driver_override when rpmsg_remove() Documentation/staging/rpmsg.rst | 50 ++-- drivers/rpmsg/virtio_rpmsg_bus.c | 1 + 2 files changed, 28 insertions(+), 23 deletions(-)
Re: [PATCH] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
On Sat, Nov 25, 2023 at 12:20:59AM +0530, Vignesh Viswanathan wrote:
> 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_smem_id 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.
>
> This patch depends on [1] which adds support for IPQ9574 and IPQ5332
> remoteproc q5v5_mpd driver.
This is solely here to ensure things are applied in appropriate order,
there's no benefit in documenting it in the eternal git history. So
please move this comment below the "---" line.
>
> [1]:
> https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
>
> Signed-off-by: Vignesh Viswanathan
> ---
> drivers/remoteproc/qcom_q6v5.c | 10 +++---
> drivers/remoteproc/qcom_q6v5.h | 4 +++-
> drivers/remoteproc/qcom_q6v5_adsp.c | 3 ++-
> drivers/remoteproc/qcom_q6v5_mpd.c | 2 +-
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
> drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
> drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
> 7 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 0e32f13c196d..072e41730110 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -100,7 +100,8 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void
> *data)
> return IRQ_HANDLED;
> }
>
> - msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, );
> + msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
> + );
No need to break lines that are just slightly over 80 characters...
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "watchdog received: %s\n", msg);
> else
> @@ -121,7 +122,8 @@ 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, );
> + msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
> + );
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
> else
> @@ -279,7 +281,8 @@ 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,
> +int crash_reason_smem_id, const char *load_state,
> void (*handover)(struct qcom_q6v5 *q6v5))
> {
> int ret;
> @@ -287,6 +290,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
> platform_device *pdev,
> q6v5->rproc = rproc;
> q6v5->dev = >dev;
> q6v5->crash_reason = crash_reason;
> + q6v5->crash_reason_smem_id = crash_reason_smem_id;
> q6v5->handover = handover;
>
> init_completion(>start_done);
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 4e1bb1a68284..21cd879e6e1e 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -41,6 +41,7 @@ struct qcom_q6v5 {
> struct completion spawn_done;
>
> int crash_reason;
> + int crash_reason_smem_id;
While this is called "smem_id" in some places, you refer to it as SMEM
partition in the commit message - and that's much less confusing.
So please rename this.
>
> bool running;
>
> @@ -49,7 +50,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,
> +int crash_reason_smem_id, const char *load_state,
To me it would be more natural if the most significant specifier was
given before the least significant specifier. Please swap the partition
and item parameters...
Regards,
Bjorn
> 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 6c67514cc493..30d91205f199 100644
> --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> +++ b/drivers/remoteproc/qcom_q6v5_adsp.c
> @@ -732,7 +732,8 @@ static int adsp_probe(struct platform_device *pdev)
> goto disable_pm;
>
> ret = qcom_q6v5_init(>q6v5, pdev, rproc, desc->crash_reason_smem,
> -
Re: [PATCH 0/3] Several smaller msm8974 fixes
On Sun, 17 Dec 2023 16:22:52 +0100, Luca Weiss wrote: > Send some smaller fixes that have been sitting around in my tree for > some time. > > Applied, thanks! [1/3] ARM: dts: qcom: msm8974-klte: Remove unused property commit: 32b075f8a2d4fefb8d791431606930883a5d5f15 [2/3] ARM: dts: qcom: msm8974: Remove bogus cd-gpio pinctrl commit: 1522b3bb306986e2f3923152a05939176b2a8a0c [3/3] ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards commit: 648002a27c6b3ae293cc415e1fbf20aaa6af8bd3 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 00/11] Remoteprocs (ADSP, CDSP, WPSS) for SC7280
On Fri, 08 Dec 2023 16:07:56 +0100, Luca Weiss wrote: > This series adds support for the ADSP, CDSP and WPSS remoteprocs found > on SC7280. And finally enable them and WiFi on the QCM6490-based > Fairphone 5 smartphone. > > The first two patches are fixes for the MPSS to fix some dt validation > issues. They're included in this series to avoid conflicts with the > later patches and keep it simpler. > > [...] Applied, thanks! [02/11] arm64: dts: qcom: sc7280: Remove unused second MPSS reg commit: 419618bd90f6b2c3adec87beb0d62adfcae619eb [03/11] arm64: dts: qcom: sc7280: Rename reserved-memory nodes commit: 6615713c10c974d13a13297e95acd304e419dfba [04/11] arm64: dts: qcom: sc7280*: move MPSS and WPSS memory to dtsi commit: 5037ca35ce42a962ea1b03895effd632a516b3b7 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 00/11] Remoteprocs (ADSP, CDSP, WPSS) for SC7280
On Fri, 08 Dec 2023 16:07:56 +0100, Luca Weiss wrote: > This series adds support for the ADSP, CDSP and WPSS remoteprocs found > on SC7280. And finally enable them and WiFi on the QCM6490-based > Fairphone 5 smartphone. > > The first two patches are fixes for the MPSS to fix some dt validation > issues. They're included in this series to avoid conflicts with the > later patches and keep it simpler. > > [...] Applied, thanks! [01/11] dt-bindings: remoteproc: qcom: sc7180-pas: Fix SC7280 MPSS PD-names commit: 9d598fab9731055638c6e9333c4f21aa0d174a48 [05/11] dt-bindings: remoteproc: qcom: sc7180-pas: Add SC7280 compatibles commit: 11eff1020440060c53d2261531432927c9fb4ee3 [06/11] remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS commit: 300ed425dfa99f6926299ec196a1eedf05f47b21 Best regards, -- Bjorn Andersson
Re: [PATCH v3 1/3] media: venus: core: Set up secure memory ranges for SC7280
On Fri, Dec 01, 2023 at 10:33:18AM +0100, Luca Weiss wrote:
> Not all SC7280 devices ship with ChromeOS firmware. Other devices need
> PAS for image authentication. That requires the predefined virtual
> address ranges to be passed via scm calls. Define them to enable Venus
> on non-CrOS SC7280 devices.
>
> Reviewed-by: Konrad Dybcio
> Reviewed-by: Bryan O'Donoghue
> Reviewed-by: Vikash Garodia
> Signed-off-by: Luca Weiss
Mauro, this series looks ready to be picked up. Can you please merge
this driver patch, so I can pick the two dts changes?
Thanks,
Bjorn
> ---
> drivers/media/platform/qcom/venus/core.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index 9cffe975581b..a712dd4f02a5 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -881,6 +881,10 @@ static const struct venus_resources sc7280_res = {
> .vmem_size = 0,
> .vmem_addr = 0,
> .dma_mask = 0xe000 - 1,
> + .cp_start = 0,
> + .cp_size = 0x2580,
> + .cp_nonpixel_start = 0x100,
> + .cp_nonpixel_size = 0x2480,
> .fwname = "qcom/vpu-2.0/venus.mbn",
> };
>
>
> --
> 2.43.0
>
Re: [PATCH] dt-bindings: arm: qcom: Fix up htc-memul compatible
On Mon, 11 Dec 2023 20:28:07 +0100, Luca Weiss wrote: > While applying the original patch, some things got messed up and it > didn't apply to the correct section. Move the compatible to the correct > location to fix that. > > Applied, thanks! [1/1] dt-bindings: arm: qcom: Fix up htc-memul compatible commit: 82d8c1e49c1be63c6927842a7c3042d4d53fe8b2 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree
On Thu, 14 Dec 2023 21:59:32 +0100, André Apitzsch wrote: > This dts adds support for Motorola Moto G 4G released in 2013. > > Add a device tree with initial support for: > > - GPIO keys > - Hall sensor > - SDHCI > - Vibrator > > [...] Applied, thanks! [2/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree commit: 690e367e0e75a46a0b3d76ae42a14f7f31f451dd Best regards, -- Bjorn Andersson
Re: [PATCH] rpmsg: glink: Fix buffer overflow
On Wed, Dec 13, 2023 at 03:15:15PM +, Hardevsinh Palaniya wrote: >Hello [1]@Bjorn Andersson, Please use appropriate mail list etiquette, and avoid HTML and top-posting in your responses. > >"strscpy_pad" itself takes care of null-terminated strings. So, there >will be no leak. Your strscpy_pad() will NUL-terminate and zero-pad up to 32 bytes. Following this the next line will write strlen(name) + sizeof(hdr) bytes to the FIFO. So if strlen(name) >= 32 you will read beyond the end of the zero-padded string. Regards, Bjorn > ______ > >From: Bjorn Andersson >Sent: Tuesday, December 12, 2023 12:10 AM >To: Hardevsinh Palaniya >Cc: agr...@kernel.org ; anders...@kernel.org >; Konrad Dybcio ; >Mathieu Poirier ; >linux-arm-...@vger.kernel.org ; >linux-remotep...@vger.kernel.org ; >linux-kernel@vger.kernel.org >Subject: Re: [PATCH] rpmsg: glink: Fix buffer overflow > >On Mon, Dec 11, 2023 at 09:32:20PM +0530, Hardevsinh Palaniya wrote: >> In qcom_glink_send_open_req() remove error: strcpy() 'channel->name' >> too large for 'req.name' (1010102 vs 32) >> >As far as I can tell, channel->name comes from the struct >rpmsg_channel_info->name, which is a 32-byte array, and all code paths >I >can find either uses strscpy() or explicitly NUL-terminates this >string. >I'm curious to know which path took us here. >> Signed-off-by: Hardevsinh Palaniya > >> >> diff --git a/drivers/rpmsg/qcom_glink_native.c >b/drivers/rpmsg/qcom_glink_native.c >> index 82d460ff4777..2d6a592e1c72 100644 >> --- a/drivers/rpmsg/qcom_glink_native.c >> +++ b/drivers/rpmsg/qcom_glink_native.c >> @@ -479,7 +479,7 @@ static int qcom_glink_send_open_req(struct >qcom_glink *glink, >>req.msg.cmd = cpu_to_le16(GLINK_CMD_OPEN); >>req.msg.param1 = cpu_to_le16(channel->lcid); >>req.msg.param2 = cpu_to_le32(name_len); >> - strcpy(req.name, channel->name); >> + strscpy_pad(req.name, channel->name, sizeof(req.name)); >I think this patch is incomplete. While it makes sure we don't >overwrite >the stack. name_len is strlen(channel->name) + 1 and the amount of data >sent out is based on name_len. >As such, if you can get here with a @name of arbitrary length, then you >can control how much of the stack we're going to now leak to the >recipient. >Regards, >Bjorn >> >>ret = qcom_glink_tx(glink, , req_len, NULL, 0, true); >>if (ret) >> -- >> 2.25.1 >> >> > > References > >1. mailto:quic_bjora...@quicinc.com
Re: [PATCH] rpmsg: glink: Fix buffer overflow
On Mon, Dec 11, 2023 at 09:32:20PM +0530, Hardevsinh Palaniya wrote: > In qcom_glink_send_open_req() remove error: strcpy() 'channel->name' > too large for 'req.name' (1010102 vs 32) > As far as I can tell, channel->name comes from the struct rpmsg_channel_info->name, which is a 32-byte array, and all code paths I can find either uses strscpy() or explicitly NUL-terminates this string. I'm curious to know which path took us here. > Signed-off-by: Hardevsinh Palaniya > > diff --git a/drivers/rpmsg/qcom_glink_native.c > b/drivers/rpmsg/qcom_glink_native.c > index 82d460ff4777..2d6a592e1c72 100644 > --- a/drivers/rpmsg/qcom_glink_native.c > +++ b/drivers/rpmsg/qcom_glink_native.c > @@ -479,7 +479,7 @@ static int qcom_glink_send_open_req(struct qcom_glink > *glink, > req.msg.cmd = cpu_to_le16(GLINK_CMD_OPEN); > req.msg.param1 = cpu_to_le16(channel->lcid); > req.msg.param2 = cpu_to_le32(name_len); > - strcpy(req.name, channel->name); > + strscpy_pad(req.name, channel->name, sizeof(req.name)); I think this patch is incomplete. While it makes sure we don't overwrite the stack. name_len is strlen(channel->name) + 1 and the amount of data sent out is based on name_len. As such, if you can get here with a @name of arbitrary length, then you can control how much of the stack we're going to now leak to the recipient. Regards, Bjorn > > ret = qcom_glink_tx(glink, , req_len, NULL, 0, true); > if (ret) > -- > 2.25.1 > >
Re: [PATCH] ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default
On Sun, 03 Dec 2023 15:19:18 +0100, Luca Weiss wrote: > Some platforms don't use the built-in charging hardware (e.g. milletwifi). > As this is an optional peripheral, default it to off. > > Keep it enabled for all other boards that use smbb. > > Applied, thanks! [1/1] ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default commit: c9c8179d0ccdf024ce467b4c9cf5de8821bc02cb Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Small dtsi fixes for msm8953 SoC
On Sat, 25 Nov 2023 13:19:26 +0100, Luca Weiss wrote: > Fix some small things in the qcom/msm8953.dtsi file to make dtbs_check > happier than before. > > Applied, thanks! [1/2] arm64: dts: qcom: msm8953: Set initial address for memory commit: 24187868e195202c67c38bcc3ae28f9c6a663fb4 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v6 0/3] Add UFS host controller and Phy nodes for sc7280
On Tue, 05 Dec 2023 15:38:53 +0100, Luca Weiss wrote: > This patch adds UFS host controller and Phy nodes for Qualcomm sc7280 > SoC and enable it on some sc7280-based boards. > > Pick up the patchset from Nitin since the last revision (v4) has been > sent end of September and is blocking qcm6490-fairphone-fp5 UFS. > Applied, thanks! [2/3] arm64: dts: qcom: sc7280: Add UFS nodes for sc7280 soc commit: c8a074789d71c1e26920f9333125590fac84f8c7 [3/3] arm64: dts: qcom: sc7280: Add UFS nodes for sc7280 IDP board commit: 9b07340c55a8e918f2667fb911e9b2edc428793c Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 00/11] Remoteprocs (ADSP, CDSP, WPSS) for SC7280
On Fri, 08 Dec 2023 16:07:56 +0100, Luca Weiss wrote: > This series adds support for the ADSP, CDSP and WPSS remoteprocs found > on SC7280. And finally enable them and WiFi on the QCM6490-based > Fairphone 5 smartphone. > > The first two patches are fixes for the MPSS to fix some dt validation > issues. They're included in this series to avoid conflicts with the > later patches and keep it simpler. > > [...] Applied, thanks! [07/11] arm64: dts: qcom: sc7280: Use WPSS PAS instead of PIL commit: 0bcbf092560cc1c163156af67176cbb4b8a327f9 [08/11] arm64: dts: qcom: sc7280: Add ADSP node commit: 3658e411efcbb4df882763b09ae49efaa86585b4 [09/11] arm64: dts: qcom: sc7280: Add CDSP node commit: df62402e5ff9df1960622b4d7bc5dd43dc8e7b75 [10/11] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable various remoteprocs commit: 5ffc529fa5dfe428ab9a7866b58b964a376dd953 [11/11] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi commit: 16e84c137919dd91c1cb1102a3d536fce2d6ee94 Best regards, -- Bjorn Andersson
Re: [PATCH v2] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable UFS
On Mon, 02 Oct 2023 14:30:41 +0200, Luca Weiss wrote: > Enable the UFS phy and controller so that we can access the internal > storage of the phone. > > At the same time we need to bump the minimum voltage used for UFS VCC, > otherwise it doesn't initialize properly. The 2.952V is taken from the > vcc-voltage-level property downstream. > > [...] Applied, thanks! [1/1] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable UFS commit: cad7c46ae2d75b42aa8f1e3f741b203ed796eee9 Best regards, -- Bjorn Andersson
Re: [PATCH V1] rpmsg: glink: smem: validate index before fifo read write
On Fri, Dec 01, 2023 at 04:36:31PM +0530, Deepak Kumar Singh wrote:
> Fifo head and tail index can be modified with wrong values from
> untrusted remote procs. Glink smem is not validating these index
> before using to read or write fifo. This can result in out of
> bound memory access if head and tail have incorrect values.
>
> Add check for validation of head and tail index. This check will
> put index within fifo boundaries, so that no invalid memory access
> is made. Further this may result in certain packet drops unless
> glink finds a valid packet header in fifo again and recovers.
>
> Crash signature and calltrace with wrong head and tail values:
>
> Internal error: Oops: 9607 [#1] PREEMPT SMP
> pc : __memcpy_fromio+0x34/0xb4
> lr : glink_smem_rx_peak+0x68/0x94
>
> __memcpy_fromio+0x34/0xb4
> glink_smem_rx_peak+0x68/0x94
> qcom_glink_native_intr+0x90/0x888
>
> Signed-off-by: Deepak Kumar Singh
> ---
> drivers/rpmsg/qcom_glink_smem.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
> index 7a982c60a8dd..9eba0aaae916 100644
> --- a/drivers/rpmsg/qcom_glink_smem.c
> +++ b/drivers/rpmsg/qcom_glink_smem.c
> @@ -86,9 +86,14 @@ static size_t glink_smem_rx_avail(struct qcom_glink_pipe
> *np)
> tail = le32_to_cpu(*pipe->tail);
>
> if (head < tail)
> - return pipe->native.length - tail + head;
> + len = pipe->native.length - tail + head;
> else
> - return head - tail;
> + len = head - tail;
> +
> + if (WARN_ON_ONCE(len > pipe->native.length))
> + len = 0;
> +
> + return len;
> }
>
> static void glink_smem_rx_peek(struct qcom_glink_pipe *np,
> @@ -99,6 +104,10 @@ static void glink_smem_rx_peek(struct qcom_glink_pipe *np,
> u32 tail;
>
> tail = le32_to_cpu(*pipe->tail);
> +
> + if (WARN_ON_ONCE(tail > pipe->native.length))
> + return;
Just returning here will leave the caller with garbage in @data, which
they will act upon. It does avoid the out of bounds read, but I'm not
confident in what happens next.
> +
> tail += offset;
> if (tail >= pipe->native.length)
> tail -= pipe->native.length;
> @@ -121,7 +130,7 @@ static void glink_smem_rx_advance(struct qcom_glink_pipe
> *np,
>
> tail += count;
> if (tail >= pipe->native.length)
> - tail -= pipe->native.length;
> + tail %= pipe->native.length;
If @tail had a bogus value before we incremented then we now have a
completely random value. The next time the FIFO is read these values
will be OK and we will return some random values to the caller.
>
> *pipe->tail = cpu_to_le32(tail);
> }
> @@ -146,6 +155,9 @@ static size_t glink_smem_tx_avail(struct qcom_glink_pipe
> *np)
> else
> avail -= FIFO_FULL_RESERVE + TX_BLOCKED_CMD_RESERVE;
>
> + if (WARN_ON_ONCE(avail > pipe->native.length))
> + avail = 0;
> +
> return avail;
> }
>
> @@ -155,6 +167,9 @@ static unsigned int glink_smem_tx_write_one(struct
> glink_smem_pipe *pipe,
> {
> size_t len;
>
> + if (WARN_ON_ONCE(head > pipe->native.length))
> + return head;
As above, but with less probability, this might end up adjusting
pipe->head (in glink_smem_tx_write()) to a random position within the
FIFO - which then upon next access will corrupt the data.
This shouldn't cause any direct issues on the Linux side though, we will
just corrupt the outgoing FIFO (which probably don't matter given that
things are already broken).
Regards,
Bjorn
> +
> len = min_t(size_t, count, pipe->native.length - head);
> if (len)
> memcpy(pipe->fifo + head, data, len);
> --
> 2.34.1
>
Re: (subset) [PATCH 1/2] dt-bindings: arm: qcom: Add Huawei Honor 5X / GR5 (2016)
On Sat, 21 Oct 2023 16:30:24 +0200, Lukas Walter wrote: > Add a compatible for Huawei Honor 5X / GR5 (2016). > > Applied, thanks! [1/2] dt-bindings: arm: qcom: Add Huawei Honor 5X / GR5 (2016) commit: 01a3c3739183003640f8468ecf75d7eeb15f808a [2/2] arm64: dts: qcom: msm8939-huawei-kiwi: Add initial device tree commit: cff9a76f306bfb6262153c0da2029071036b9a04 Best regards, -- Bjorn Andersson
Re: [PATCH v3 0/3] Add support for HTC One Mini 2 smartphone
On Sat, 25 Nov 2023 13:05:32 +0100, Luca Weiss wrote: > Add support for this smartphone from HTC which is based on the MSM8926 > SoC and codenamed "memul". > > Depends on, runtime-only, bootloader enables watchdog so we need to pet > it to stay alive: > https://lore.kernel.org/linux-arm-msm/20231011-msm8226-msm8974-watchdog-v1-0-2c472818f...@z3ntu.xyz/T/ > > [...] Applied, thanks! [1/3] dt-bindings: vendor-prefixes: document HTC Corporation commit: d69e34675a8be0affe8c55dbf50f795dac521933 [2/3] dt-bindings: arm: qcom: Add HTC One Mini 2 commit: bfccc195192ea6ae72a4a49a85c94f1ad8ee7a13 [3/3] ARM: dts: qcom: Add support for HTC One Mini 2 commit: be0061dcbac1b6a5a1cf681f7cabbb2681ab0e2c Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Fix typos
On Sun, 26 Nov 2023 10:28:48 +0800, Jianhua Lu wrote: > There are two typos in this dtsi, so fix it. > classis -> chassis. > 8070 -> 8060 > > Applied, thanks! [1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Fix typos commit: 608168b4d6079f2c43944bdfd64fd6c405d9a767 [2/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8150b type-c node and enable usb otg commit: 69652787279d64b0b0cc350fdfb34c503e40653c Best regards, -- Bjorn Andersson
Re: [PATCH v2] arm64: dts: qcom: sdm632-fairphone-fp3: Enable WiFi/Bluetooth
On Mon, 27 Nov 2023 22:55:38 +0100, Luca Weiss wrote: > Configure and enable the WCNSS which provides WiFi and Bluetooth on this > device using the WCN3680B chip. > > Applied, thanks! [1/1] arm64: dts: qcom: sdm632-fairphone-fp3: Enable WiFi/Bluetooth commit: 5b006a82a2bbc0ce18bc6b084fc8d8d9cc110001 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/3] Add watchdog nodes to msm8226 & msm8974
On Wed, 11 Oct 2023 18:33:12 +0200, Luca Weiss wrote: > Document the compatible for the watchdog found on both SoCs, and add > them to the SoC dtsi file. And especially for the case where the > bootloader has already enabled the watchdog we need to start petting it > on time, otherwise the system gets rebooted. > > It's worth noting that the watchdog behaves a bit unexpectedly. > It appears the watchdog counts down significantly slower when there's no > load on the system and can last far longer than 30 seconds until they > bark. Only when putting load on the system, e.g. with stress-ng does the > watchdog interrupt fire and kill the system within an expected amount of > time. > > [...] Applied, thanks! [3/3] ARM: dts: qcom: msm8974: Add watchdog node commit: 95053f6bc8ffca438a261400d7c06bd74e3f106e Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Small dtsi fixes for msm8953 SoC
On Sat, 25 Nov 2023 13:19:26 +0100, Luca Weiss wrote: > Fix some small things in the qcom/msm8953.dtsi file to make dtbs_check > happier than before. > > Applied, thanks! [2/2] arm64: dts: qcom: msm8953: Use non-deprecated qcom,domain in LPASS commit: 2e0dcbf164fb02d2558bd08b9609a30ef5935912 Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sdm632-fairphone-fp3: Enable LPASS
On Sun, 15 Oct 2023 22:06:56 +0200, Luca Weiss wrote: > Enable the LPASS/ADSP found on the phone. > > Applied, thanks! [1/1] arm64: dts: qcom: sdm632-fairphone-fp3: Enable LPASS commit: 2dee68e77cb5322d7cfe44f3c84ff8ae2eaf4aee Best regards, -- Bjorn Andersson
Re: [PATCH 0/4] Add Fairphone 5 thermals (PMK7325, PM7250B, PM7325)
On Fri, 13 Oct 2023 10:09:52 +0200, Luca Weiss wrote: > Configure the necessary components to register some thermal zones in > Linux for the different thermistors found on the Fairphone 5. > > The names for the thermal zones and ADCs were taken from the downstream > kernel but double checked against hardware schematics. > > > [...] Applied, thanks! [1/4] iio: adc: Add PM7325 PMIC7 ADC bindings commit: 18c74d56fe6070c7c38058d7b43ccf2102abebcd [2/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7250B thermals commit: 4c343fe9b68adeca1aa3a851bd06e62ecdaed180 [3/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PMK7325 thermals commit: 46a2f77e1eb81990d303a94ab62f1bf79d0c9926 [4/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals commit: ae1122c375707a36c8fecebba745421a1e0ff93f Best regards, -- Bjorn Andersson
Re: [PATCH v2] arm64: dts: qcom: msm8939-longcheer-l9100: Add proximity-near-level
On Sun, 26 Nov 2023 22:46:20 +0100, André Apitzsch wrote: > Consider an object near to the sensor when their distance is about 4 cm > or below. > > Applied, thanks! [1/1] arm64: dts: qcom: msm8939-longcheer-l9100: Add proximity-near-level commit: fbe0870c48ac84f117860096048055a4f078a976 Best regards, -- Bjorn Andersson
Re: [PATCH v2] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable UFS
On Mon, Oct 02, 2023 at 02:30:41PM +0200, Luca Weiss wrote: > Enable the UFS phy and controller so that we can access the internal > storage of the phone. > > At the same time we need to bump the minimum voltage used for UFS VCC, > otherwise it doesn't initialize properly. The 2.952V is taken from the > vcc-voltage-level property downstream. > > See also the following link for more information about the VCCQ/VCCQ2: > https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/1590a3739e7dc29d2597307881553236d492f188/fp5/yupik-idp-pm7250b.dtsi#207 > > Signed-off-by: Luca Weiss > --- > Depends on: > https://lore.kernel.org/linux-arm-msm/20230927081858.15961-1-quic_nitir...@quicinc.com/ I'd love to merge this patch, but this dependency doesn't seem to make progress, please consider fixing up the outstanding feedback and posting v5. Regards, Bjorn
Re: [PATCH v2 1/2] arm64: dts: qcom: msm8953: Set initial address for memory
On Sat, Nov 25, 2023 at 01:19:27PM +0100, Luca Weiss wrote:
> The dtbs_check really doesn't like having memory without reg set.
>
> The base address depends on the amount of RAM you have:
>
> <= 2.00 GiB RAM: 0x8000
>= 3.00 GiB RAM: 0x4000
>= 3.75 GiB RAM: 0x1000
> (more does not fit into the 32-bit physical address space)
>
> So, let's pick one of the values, 0x1000 which is used on devices
> with 3.75 GiB RAM. Since the bootloader will update it to what's present
> on the device it doesn't matter too much.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/msm8953.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> index e7de7632669a..a3ba24ca599b 100644
> --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> @@ -174,10 +174,10 @@ scm: scm {
> };
> };
>
> - memory {
Wouldn't it be sufficient to add @0 here, to please dtbs_check?
Regards,
Bjorn
> + memory@1000 {
> device_type = "memory";
> /* We expect the bootloader to fill in the reg */
> - reg = <0 0 0 0>;
> + reg = <0 0x1000 0 0>;
> };
>
> pmu {
>
> --
> 2.43.0
>
Re: [RESEND PATCH v3 1/2] remoteproc: Make rproc_get_by_phandle() work for clusters
On Sat, Oct 14, 2023 at 04:15:47PM -0700, Tanmay Shah wrote:
> From: Mathieu Poirier
>
> Multi-cluster remoteproc designs typically have the following DT
> declaration:
>
> remoteproc_cluster {
> compatible = "soc,remoteproc-cluster";
>
> core0: core0 {
> compatible = "soc,remoteproc-core"
> memory-region;
> sram;
> };
>
> core1: core1 {
> compatible = "soc,remoteproc-core"
> memory-region;
> sram;
> }
> };
>
> A driver exists for the cluster rather than the individual cores
> themselves so that operation mode and HW specific configurations
> applicable to the cluster can be made.
>
> Because the driver exists at the cluster level and not the individual
> core level, function rproc_get_by_phandle() fails to return the
> remoteproc associated with the phandled it is called for.
>
> This patch enhances rproc_get_by_phandle() by looking for the cluster's
> driver when the driver for the immediate remoteproc's parent is not
> found.
>
> Reported-by: Ben Levinsky
> Signed-off-by: Mathieu Poirier
> Tested-by: Ben Levinsky
> ---
> drivers/remoteproc/remoteproc_core.c | 28 +++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 695cce218e8c..3a8191803885 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2111,7 +2112,9 @@ EXPORT_SYMBOL(rproc_detach);
> #ifdef CONFIG_OF
> struct rproc *rproc_get_by_phandle(phandle phandle)
> {
> + struct platform_device *cluster_pdev;
> struct rproc *rproc = NULL, *r;
> + struct device_driver *driver;
> struct device_node *np;
>
> np = of_find_node_by_phandle(phandle);
> @@ -2122,7 +2125,30 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
> list_for_each_entry_rcu(r, _list, node) {
> if (r->dev.parent && device_match_of_node(r->dev.parent, np)) {
> /* prevent underlying implementation from being removed
> */
> - if (!try_module_get(r->dev.parent->driver->owner)) {
> +
> + /*
> + * If the remoteproc's parent has a driver, the
> + * remoteproc is not part of a cluster and we can use
> + * that driver.
> + */
> + driver = r->dev.parent->driver;
> +
> + /*
> + * If the remoteproc's parent does not have a driver,
> + * look for the driver associated with the cluster.
> + */
> + if (!driver) {
> + cluster_pdev =
> of_find_device_by_node(np->parent);
Both the Ti and Xilinx drivers are using of_platform_populate(), so
their r->dev.parent should have a parent reference to the cluster
device.
Unless I'm reading the code wrong, I think we should follow that
pointer, rather than taking the detour in the DeviceTree data.
Regards,
Bjorn
> + if (!cluster_pdev) {
> + dev_err(>dev, "can't get parent\n");
> + break;
> + }
> +
> + driver = cluster_pdev->dev.driver;
> + put_device(_pdev->dev);
> + }
> +
> + if (!try_module_get(driver->owner)) {
> dev_err(>dev, "can't get owner\n");
> break;
> }
> --
> 2.25.1
>
[GIT PULL] remoteproc updates for v6.7
The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d: Linux 6.6-rc1 (2023-09-10 16:28:41 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rproc-v6.7 for you to fetch changes up to 3d8a18697ad834436d088d65cc66165947cfe600: remoteproc: st: Fix sometimes uninitialized ret in st_rproc_probe() (2023-10-16 11:24:34 -0600) remoteproc updates for v6.7 Support for controlling the second core in Mediatek's SCP dual-core setup is introduced. Support for audio, compute and modem DSPs on Qualcomm SM6375, and the audio DSP in SC7180 are introduced. The peripheral NoC clock is dropped from MSM8996 modem DSP, as this is handled through the interconnect provider. In the zynqmp driver the setup for TCM memory, and device address translation thereof, when operating in lockstep mode is corrected. A few bug fixes and cleanups are introduces across the ST and STM32 remoteproc drivers. AngeloGioacchino Del Regno (1): remoteproc: mediatek: Refactor single core check and fix retrocompatibility Chen Jiahao (1): remoteproc: stm32: Clean up redundant dev_err_probe() Konrad Dybcio (6): dt-bindings: remoteproc: qcom,sm6375-pas: Document remoteprocs remoteproc: qcom: pas: Add SM6375 ADSP & CDSP remoteproc: qcom: pas: Add SM6375 MPSS dt-bindings: remoteproc: qcom,adsp: Remove AGGRE2 clock dt-bindings: remoteproc: qcom,msm8996-mss-pil: Remove PNoC clock remoteproc: qcom: q6v5-mss: Remove PNoC clock from 8996 MSS MD Danish Anwar (1): dt-bindings: remoteproc: pru: Add Interrupt property Nathan Chancellor (1): remoteproc: st: Fix sometimes uninitialized ret in st_rproc_probe() Nikita Travkin (2): dt-bindings: remoteproc: qcom: sc7180-pas: Add ADSP compatible remoteproc: qcom: pas: Add sc7180 adsp Rob Herring (1): remoteproc: st: Use device_get_match_data() Tanmay Shah (2): remoteproc: zynqmp: fix TCM carveouts in lockstep mode remoteproc: zynqmp: Change tcm address translation method Tinghan Shen (13): dt-bindings: remoteproc: mediatek: Improve the rpmsg subnode definition dt-bindings: remoteproc: mediatek: Support MT8195 dual-core SCP remoteproc: mediatek: Add MT8195 SCP core 1 operations remoteproc: mediatek: Extract SCP common registers remoteproc: mediatek: Revise SCP rproc initialization flow for multi-core SCP remoteproc: mediatek: Probe SCP cluster on single-core SCP remoteproc: mediatek: Probe SCP cluster on multi-core SCP remoteproc: mediatek: Remove dependency of MT8195 SCP L2TCM power control on dual-core SCP remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset remoteproc: mediatek: Handle MT8195 SCP core 1 watchdog timeout remoteproc: mediatek: Report watchdog crash to all cores remoteproc: mediatek: Refine ipi handler error message arm64: dts: mediatek: Update the node name of SCP rpmsg subnode .../devicetree/bindings/remoteproc/mtk,scp.yaml| 176 ++- .../devicetree/bindings/remoteproc/qcom,adsp.yaml | 20 +- .../bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 2 - .../bindings/remoteproc/qcom,sc7180-pas.yaml | 81 +++- .../bindings/remoteproc/qcom,sm6375-pas.yaml | 145 ++ .../bindings/remoteproc/ti,pru-rproc.yaml | 23 + arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 2 +- arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 2 +- drivers/remoteproc/mtk_common.h| 39 +- drivers/remoteproc/mtk_scp.c | 536 - drivers/remoteproc/mtk_scp_ipi.c | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 1 - drivers/remoteproc/qcom_q6v5_pas.c | 19 + drivers/remoteproc/st_remoteproc.c | 16 +- drivers/remoteproc/stm32_rproc.c | 4 +- drivers/remoteproc/xlnx_r5_remoteproc.c| 110 ++--- 16 files changed, 932 insertions(+), 248 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,sm6375-pas.yaml
[GIT PULL] rpmsg updates for v6.7
The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d: Linux 6.6-rc1 (2023-09-10 16:28:41 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rpmsg-v6.7 for you to fetch changes up to 2a6e483ad047654a220c798080d0fc861ead2e07: rpmsg: virtio: Replace deprecated strncpy with strscpy/_pad (2023-10-23 13:11:07 -0600) rpmsg updates for v6.7 This replaces a number of strncpy() instances with strscpy() strscpy_pad() through the rpmsg core and virtio implementation. Justin Stitt (3): rpmsg: core: Replace deprecated strncpy with strscpy rpmsg: Replace deprecated strncpy with strscpy_pad rpmsg: virtio: Replace deprecated strncpy with strscpy/_pad drivers/rpmsg/rpmsg_core.c | 2 +- drivers/rpmsg/rpmsg_ns.c | 2 +- drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-)
Re: [PATCH] ARM: dts: qcom: msm8226: provide dsi phy clocks to mmcc
On Wed, 12 Jul 2023 09:52:07 +0200, Luca Weiss wrote: > Some mmcc clocks have dsi0pll & dsi0pllbyte as clock parents so we > should provide them in the dt, which I missed in the commit adding the > mdss nodes. > > Applied, thanks! [1/1] ARM: dts: qcom: msm8226: provide dsi phy clocks to mmcc commit: 836d083524888069cd358776a4e6c4ceec04962e Best regards, -- Bjorn Andersson
Re: [PATCH v2] soc: qcom: pmic_glink_altmode: Print return value on error
On Tue, 17 Oct 2023 10:00:23 +0200, Luca Weiss wrote: > It can be useful to know with which return value for example the > typec_retimer_set call failed, so include this info in the dev_err > prints. > > Applied, thanks! [1/1] soc: qcom: pmic_glink_altmode: Print return value on error commit: 723d346173e748c4fdb145b84f572b871ab4011a Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Small updates / fixups for PMIC spmi-gpio
On Mon, 02 Oct 2023 09:00:10 +0200, Luca Weiss wrote: > Update the schema to use plural _gpios label in the example. And fix a > dtbs_check warning in pm7250b.dtsi. > > Applied, thanks! [2/2] arm64: dts: qcom: pm7250b: Use correct node name for gpios commit: 6cd8621758004d98f7c622c2d756c116c6888127 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Add CCI support for SC7280
On Mon, 02 Oct 2023 08:55:29 +0200, Luca Weiss wrote: > Add the dts nodes for the camera control interface found on the SC7280 > SoC. And then enable the CCI nodes in the Fairphone 5 dts. > > Applied, thanks! [2/2] arm64: dts: qcom: sc7280: Add Camera Control Interface busses commit: 0c149ca7653286496130e872f47a4b834348ea10 Best regards, -- Bjorn Andersson
Re: [PATCH 0/2] Small style fixes in msm8974.dtsi
On Tue, 27 Jun 2023 21:45:12 +0200, Luca Weiss wrote: > While making sure the nodes are sorted correctly, I also noticed that > some lines are wrongly indented. Fix both. > > Applied, thanks! [1/2] ARM: dts: qcom: msm8974: replace incorrect indentation in interconnect commit: 207f4ce365819ac68b634153d074252338d00ef6 [2/2] ARM: dts: qcom: msm8974: sort nodes by reg commit: 4960e06d386ecc5307bc2e66a77d5f06df1e2a6f Best regards, -- Bjorn Andersson
Re: [PATCH v2 00/14] arm64: dts: qcom: msm8916/39: Enable sound and modem with QDSP6
On Tue, 03 Oct 2023 15:18:18 +0200, Stephan Gerhold wrote: > Enable sound and modem on most of the MSM8916/MSM8939 > smartphones/tablets supported upstream by: > > - Adding the BAM-DMUX DT nodes to msm8939.dtsi for WWAN Internet > - Adding the QDSP6 DT nodes to both msm8916.dtsi and msm8939.dtsi. >This is needed because audio must be routed through the QDSP6 >services provided by the modem firmware when the modem is active. > - Setting up the sound/codec related nodes for all the devices. > > [...] Applied, thanks! [01/14] arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN commit: 32f963412a2d8cb65ff2737e6763f88ed15a2efb [02/14] arm64: dts: qcom: msm8916: Add QDSP6 commit: 861aa8e6829cf2f1a9c5a52dd9cebc722cf7ca44 [03/14] arm64: dts: qcom: msm8939: Add QDSP6 commit: 0718ff7185cf42f8e817e39552feb9d6ed901aff [04/14] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi commit: 8abbd235b2ecbfba0a445ccd400a54af8fd83bc2 [05/14] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem commit: f276411d0f8286c7ff3e1bd6917ea7ee61152d24 [06/14] arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem commit: 6b66abd5858e025b2715b1efb193124dd7cc17c5 [07/14] arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem commit: 5db767ae36255c0301ede64ee8993e0909efa73f [08/14] arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem commit: 5d1cec28fd4d09e82e028903423829f59a033965 [09/14] arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem commit: 462cdffaa83df28d5fbd0c1771eaa85954114c77 [10/14] arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem commit: 1ab407193d38c775261d7beccd080e88f68c7243 [11/14] arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem commit: 2821c34a996b4a0991d33bead5caa84267e2dccd [12/14] arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem commit: 4f6b5edbcfbaa1061c29e6259cc5653f44b673da [13/14] arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem commit: cf12268e1b632c6ac16185bd1230af6e1ca517fb [14/14] arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem commit: dd5ab5d2ca722110c82459a571e367df7ee6d821 Best regards, -- Bjorn Andersson
Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails
On Mon, Oct 16, 2023 at 08:56:31AM +0200, Luca Weiss wrote: > On Mon Oct 16, 2023 at 5:18 AM CEST, Bjorn Andersson wrote: > > On Fri, Oct 13, 2023 at 03:56:40PM +0200, Luca Weiss wrote: > > > It can be useful to know with which return value the retimer_set call > > > failed, so include this info in the dev_err print. > > > > > > > Is this useful during development, or during normal execution etc. How > > about using kretprobe or similar tools? > > Hi Bjorn, > > IIRC I encountered this during development of my retimer driver, where > the op in that driver failed for some reason and it was very useful to > get the return value to debug that. > > And sure, I guess kretprobe might be also useful here but I think it's > very common to include the return value in the error message when > something fails, no? > The problem with the error message is that you often get some generic error code, but don't know where it came from anyway. So, I typically use function_graph and set_graph_function to capture the path through the called function(s)... But that said, it is fairly common to include the error value, so I am not against it. > > If you insist, could you please make sure that the style matches across > > the various typec_*_set() calls in the driver? > > Do you mean adding the return value to the other dev_err prints after > typec_*_set() calls also? > I mean that we should be consistent across the error prints, and either include the error value in all or none of the typec error prints. Regards, Bjorn
Re: [PATCH v2] arm64: dts: qcom: sc7280: Add ports subnodes in usb/dp qmpphy node
On Fri, 29 Sep 2023 14:51:22 +0200, Luca Weiss wrote: > Add the USB3+DP Combo QMP PHY port subnodes to facilitate the > description of the connection between the hardware blocks. > > Put it in the SoC DTSI to avoid duplication in the device DTs. > > Applied, thanks! [1/1] arm64: dts: qcom: sc7280: Add ports subnodes in usb/dp qmpphy node commit: 2278b16f12a9cc33b95a980e05d4d8f3f8e0abfa Best regards, -- Bjorn Andersson
Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails
On Fri, Oct 13, 2023 at 03:56:40PM +0200, Luca Weiss wrote: > It can be useful to know with which return value the retimer_set call > failed, so include this info in the dev_err print. > Is this useful during development, or during normal execution etc. How about using kretprobe or similar tools? If you insist, could you please make sure that the style matches across the various typec_*_set() calls in the driver? Regards, Bjorn > Signed-off-by: Luca Weiss > --- > drivers/soc/qcom/pmic_glink_altmode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/qcom/pmic_glink_altmode.c > b/drivers/soc/qcom/pmic_glink_altmode.c > index 9569d999391d..136713e1155e 100644 > --- a/drivers/soc/qcom/pmic_glink_altmode.c > +++ b/drivers/soc/qcom/pmic_glink_altmode.c > @@ -168,7 +168,7 @@ static void pmic_glink_altmode_enable_dp(struct > pmic_glink_altmode *altmode, > > ret = typec_retimer_set(port->typec_retimer, >retimer_state); > if (ret) > - dev_err(altmode->dev, "failed to setup retimer to DP\n"); > + dev_err(altmode->dev, "failed to setup retimer to DP: %d\n", > ret); > } > > static void pmic_glink_altmode_enable_usb(struct pmic_glink_altmode *altmode, > > --- > base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b > change-id: 20231013-glink-altmode-ret-3911e6c1eab5 > > Best regards, > -- > Luca Weiss >
Re: [PATCH] bus: mhi: host: Add tracing support
On Thu, Oct 05, 2023 at 03:55:20PM +0530, Krishna chaitanya chundru wrote:
> This change adds ftrace support for following:
> 1. mhi_intvec_threaded_handler
> 2. mhi_process_data_event_ring
> 3. mhi_process_ctrl_ev_ring
> 4. mhi_gen_tre
> 5. mhi_update_channel_state
> 6. mhi_tryset_pm_state
> 7. mhi_pm_st_worker
This is not the best "problem description".
>
> Usage:
> echo 1 > /sys/kernel/debug/tracing/events/mhi_host/enable
> cat /sys/kernel/debug/tracing/trace
This does not need to be included in the commit message, how to use the
tracing framework is documented elsewhere.
[..]
> diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
> index dcf627b36e82..499590437e9b 100644
> --- a/drivers/bus/mhi/host/main.c
> +++ b/drivers/bus/mhi/host/main.c
> @@ -491,11 +491,10 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number,
> void *priv)
>
> state = mhi_get_mhi_state(mhi_cntrl);
> ee = mhi_get_exec_env(mhi_cntrl);
> - dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
> - TO_MHI_EXEC_STR(mhi_cntrl->ee),
> - mhi_state_str(mhi_cntrl->dev_state),
> - TO_MHI_EXEC_STR(ee), mhi_state_str(state));
>
> + trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name,
> TO_MHI_EXEC_STR(mhi_cntrl->ee),
> + mhi_state_str(mhi_cntrl->dev_state),
> + TO_MHI_EXEC_STR(ee),
> mhi_state_str(state));
All these helper functions that translates a state to a string, pass the
raw state into the trace event and use __print_symbolic() in your
TP_printk() instead.
This will allow you to read the state, but you can have tools act of the
numerical value.
(This comment applies to all the trace events)
> if (state == MHI_STATE_SYS_ERR) {
> dev_dbg(dev, "System error detected\n");
> pm_state = mhi_tryset_pm_state(mhi_cntrl,
[..]
> diff --git a/include/trace/events/mhi_host.h b/include/trace/events/mhi_host.h
[..]
> +
> +TRACE_EVENT(mhi_pm_st_worker,
Why is this trace event called "worker", isn't the event a
"mhi_pm_state_transition"?
Don't just name your trace event based on the function that triggers
them, but what they represent and make sure they carry useful
information to understand the system.
If you want to trace the flow through your functions, you can use e.g.
ftrace.
Regards,
Bjorn
Re: [PATCH] ARM: dts: qcom: apq8026-samsung-matisse-wifi: Fix inverted hall sensor
On Fri, 22 Sep 2023 04:12:11 +0300, Matti Lehtimäki wrote: > Fix hall sensor GPIO polarity and also allow disabling the sensor. > Remove unneeded interrupt. > > Applied, thanks! [1/1] ARM: dts: qcom: apq8026-samsung-matisse-wifi: Fix inverted hall sensor commit: 0b73519790d29e4bc71afc4882a9aa9ea649bcf7 Best regards, -- Bjorn Andersson
Re: [PATCH 0/2] Add rpm-master-stats nodes for MSM8226 and MSM8974
On Fri, 22 Sep 2023 03:35:31 +0300, Matti Lehtimäki wrote: > Add rpm-master-stats nodes and the required RPM MSG RAM slices > for MSM8226 and MSM8974. > > Matti Lehtimäki (2): > ARM: qcom: msm8226: Add rpm-master-stats node > ARM: qcom: msm8974: Add rpm-master-stats node > > [...] Applied, thanks! [1/2] ARM: qcom: msm8226: Add rpm-master-stats node commit: bd837be0ff3879209df6fb85cf9e22fd1ba7f79b [2/2] ARM: qcom: msm8974: Add rpm-master-stats node commit: 02c58ac774a03ffefd3708f9c17ea4d911e0ade7 Best regards, -- Bjorn Andersson
Re: [PATCH] ARM: dts: qcom: sdx65-mtp: Specify PM7250B SID to use
On Thu, 21 Sep 2023 08:34:02 +0200, Luca Weiss wrote:
> Now that the pm7250b.dtsi can be configured to be on a different SID, we
> also need to specify it for this dts file. Set it to the SID 2/3 like it
> was before commit 8e2d56f64572 ("arm64: dts: qcom: pm7250b: make SID
> configurable").
>
>
Applied, thanks!
[1/1] ARM: dts: qcom: sdx65-mtp: Specify PM7250B SID to use
commit: 4d8b5d7171722d2cdccc880d8e449f7ca9c7b6bf
Best regards,
--
Bjorn Andersson
Re: (subset) [PATCH v2 0/7] Initial support for the Fairphone 5 smartphone
On Tue, 19 Sep 2023 14:45:54 +0200, Luca Weiss wrote: > Add support to boot up mainline kernel on the QCM6490-based Fairphone 5 > smartphone. > > These patches only cover a part of the functionality brought up on > mainline so far, with the rest needing larger dts and driver changes or > depend on patches that are not yet merged. I will work on sending those > once these base patches here have settled. > > [...] Applied, thanks! [1/7] arm64: dts: qcom: sc7280: Mark some nodes as 'reserved' commit: 6da24ba932082bae110feb917a64bb54637fa7c0 [3/7] arm64: dts: qcom: pm7250b: make SID configurable commit: 8e2d56f64572e0432c355093a7601bde29677490 [4/7] arm64: dts: qcom: pm8350c: Add flash led node commit: bfd4412a023b2a3a2f858f2ffc13705aaeef5737 [6/7] dt-bindings: arm: qcom: Add QCM6490 Fairphone 5 commit: 4b1a16d776b474345b12f834de1fd42bca226d90 [7/7] arm64: dts: qcom: qcm6490: Add device-tree for Fairphone 5 commit: eee9602ad6498eee9ddab1b7eb6aede288f0b934 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 00/14] Clean up RPM bus clocks remnants
On Tue, 12 Sep 2023 15:31:38 +0200, Konrad Dybcio wrote: > After the recent cleanups ([1], [2]) some in-tree abusers that directly > accessed the RPM bus clocks, effectively circumventing and working > against the efforts of the interconnect framework, were found. > > Patches 1-5 drop deprecated references and the rest attempt to stop > direct bus clock abuses. > > [...] Applied, thanks! [08/14] dt-bindings: remoteproc: qcom,adsp: Remove AGGRE2 clock commit: c4c5b47958529bc1de10260df0c583710853b516 [09/14] dt-bindings: remoteproc: qcom,msm8996-mss-pil: Remove PNoC clock commit: e7781901449cbcff129d80a5d9021e9e96084ec4 [10/14] remoteproc: qcom: q6v5-mss: Remove PNoC clock from 8996 MSS commit: e1592981c51bac38ea2041b642777b3ba30606a8 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 0/7] MSM8976 PLL,RPMPD and DTS changes
On Sat, 12 Aug 2023 13:24:43 +0200, Adam Skladowski wrote: > This patch series fixes introduce support for msm8976 pll, > also brings some adjustments and fixes domains setup and few dts nitpicks. > > Changes since v1 > > 1. Fixed few styling issues > 2. Changed compatibles for plls > 3. Added fixes: tag to first patch > > [...] Applied, thanks! [6/7] arm64: dts: qcom: msm8976: Split lpass region commit: 31c133b4a07e3db456a7e661c96653cd65a25bc6 [7/7] arm64: dts: qcom: msm8976: Fix ipc bit shifts commit: 684277525c70f329300cc687e27248e405a4ff9e Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 0/4] sc7180: Add ADSP
On Thu, 07 Sep 2023 15:02:33 +0500, Nikita Travkin wrote: > sc7180 has an ADSP remoteproc that can be used to control the sound > hardware. This remoteproc has to be used on those devices that use > Qualcomm firmware and thus are locked out of driving the lpass directly. > > Introducing the ADSP would allow multiple WoA laptops such as Aspire 1 > to provide sound. It's also useful for the sm7125 devices that are to be > included to the kernel [1] > > [...] Applied, thanks! [3/4] arm64: dts: qcom: sc7180: Add tertiary mi2s pinctrl commit: 828298a9efb237b76fa667bb74a6450d1df3eeed [4/4] arm64: dts: qcom: sc7180: Add ADSP commit: a3d5fb3b084c0c67f9918a866b92cbe09b9e1d77 Best regards, -- Bjorn Andersson
