Re: (subset) [PATCH 0/2] Add HTC One (M8) support
On Mon, 03 Jun 2024 02:28:55 -0400, Alexandre Messier wrote: > Add an initial device tree to support the HTC One (M8) smartphone, > aka "htc,m8". > > Applied, thanks! [2/2] ARM: dts: qcom: Add initial support for HTC One (M8) commit: 0e8a41e511c98f5f5796c0dca8ff983d1c967b93 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/7] Use mboxes instead of syscon for APCS (arm32 & arm64)
On Wed, 24 Apr 2024 18:23:53 +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. > > [...] Applied, thanks! [3/7] arm64: dts: qcom: msm8916: Use mboxes properties for APCS commit: 3e971470619d80dd343e3abd80cb997bcb48f200 [4/7] arm64: dts: qcom: msm8939: Use mboxes properties for APCS commit: 22e4e43484c4dd1f29a72cc62411072758e0681a [5/7] arm64: dts: qcom: msm8953: Use mboxes properties for APCS commit: 11dff973ebe21950c7c5221919141fb0cb16354e [6/7] arm64: dts: qcom: msm8976: Use mboxes properties for APCS commit: a3d5570d8c8c6efc3d15d015b517f4e8bd11898f [7/7] arm64: dts: qcom: msm8994: Use mboxes properties for APCS commit: ba5d9a91f8c3caf6867b3b87dce080d056222561 Best regards, -- Bjorn Andersson
Re: [PATCH v4] drivers: remoteproc: xlnx: add attach detach support
On Mon, Jun 03, 2024 at 01:34:38PM -0700, Tanmay Shah wrote: > It is possible that remote processor is already running before > linux boot or remoteproc platform driver probe. Implement required > remoteproc framework ops to provide resource table address and > connect or disconnect with remote processor in such case. > I know if changes the current style for this driver, but could we drop "drivers: " from the subject prefix, to align changes to this driver with others? Regards, Bjorn
Re: [PATCH v3 0/3] Add TCPM support for PM7250B and Fairphone 4
On Thu, 30 May 2024 17:05:46 +0200, Luca Weiss wrote: > This series adds support for Type-C Port Management on the Fairphone 4 > which enables USB role switching and orientation switching. > > This enables a user for example to plug in a USB stick or a USB keyboard > to the Type-C port. > > To: Bjorn Andersson > To: Konrad Dybcio > To: Rob Herring > To: Krzysztof Kozlowski > To: Conor Dooley > Cc: ~postmarketos/upstream...@lists.sr.ht > Cc: phone-de...@vger.kernel.org > Cc: linux-arm-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Luca Weiss > > [...] Applied, thanks! [1/3] arm64: dts: qcom: pm7250b: Add node for PMIC VBUS booster commit: 37ff5d0d75fece536cc493d0979e09f33edb75c4 [2/3] arm64: dts: qcom: pm7250b: Add a TCPM description commit: 6b5b15a1d785d5fb484d3a662b01776066d33137 [3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable USB role switching commit: 6814d454c26b552f0009c803ffc0ce3434eaed7e Best regards, -- Bjorn Andersson
Re: [PATCH v2 0/3] Add TCPM support for PM7250B and Fairphone 4
On Fri, 29 Mar 2024 13:26:18 +0100, Luca Weiss wrote: > This series adds support for Type-C Port Management on the Fairphone 4 > which enables USB role switching and orientation switching. > > This enables a user for example to plug in a USB stick or a USB keyboard > to the Type-C port. > > To: Bjorn Andersson > To: Konrad Dybcio > To: Rob Herring > To: Krzysztof Kozlowski > To: Conor Dooley > Cc: ~postmarketos/upstream...@lists.sr.ht > Cc: phone-de...@vger.kernel.org > Cc: linux-arm-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Luca Weiss > > [...] Applied, thanks! [1/3] arm64: dts: qcom: pm7250b: Add node for PMIC VBUS booster commit: 37ff5d0d75fece536cc493d0979e09f33edb75c4 [2/3] arm64: dts: qcom: pm7250b: Add a TCPM description commit: 6b5b15a1d785d5fb484d3a662b01776066d33137 [3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable USB role switching commit: 6814d454c26b552f0009c803ffc0ce3434eaed7e Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sm8550-samsung-q5q: fix typo
On Fri, 31 May 2024 14:05:59 +0200, David Wronek wrote: > It looks like "cdsp_mem" was pasted in the license header by accident. > Fix the typo by removing it. > > Applied, thanks! [1/1] arm64: dts: qcom: sm8550-samsung-q5q: fix typo commit: a5c84d2dde8089ece5e13f264359c6117ea3186b Best regards, -- Bjorn Andersson
Re: [PATCH 01/12] soc: qcom: add firmware name helper
On Mon, May 27, 2024 at 02:42:44PM GMT, Dmitry Baryshkov wrote: > On Thu, 23 May 2024 at 01:48, Bjorn Andersson > wrote: > > > > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote: > > > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote: > > > > > > > > Dmitry Baryshkov writes: > > > > > > > > > On Tue, 21 May 2024 at 12:52, wrote: > > > > >> > > > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote: > > > > >> > Qualcomm platforms have different sets of the firmware files, which > > > > >> > differ from platform to platform (and from board to board, due to > > > > >> > the > > > > >> > embedded signatures). Rather than listing all the firmware files, > > > > >> > including full paths, in the DT, provide a way to determine > > > > >> > firmware > > > > >> > path based on the root DT node compatible. > > > > >> > > > > >> Ok this looks quite over-engineered but necessary to handle the > > > > >> legacy, > > > > >> but I really think we should add a way to look for a board-specific > > > > >> path > > > > >> first and fallback to those SoC specific paths. > > > > > > > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays. > > > > > > > > To me this also looks like very over-engineered, can you elaborate more > > > > why this is needed? Concrete examples would help to understand better. > > > > > > Sure. During the meeting last week Arnd suggested evaluating if we can > > > drop firmware-name from the board DT files. Several reasons for that: > > > - DT should describe the hardware, not the Linux-firmware locations > > > - having firmware name in DT complicates updating the tree to use > > > different firmware API (think of mbn vs mdt vs any other format) > > > - If the DT gets supplied by the vendor (e.g. for > > > SystemReady-certified devices), there should be a sync between the > > > vendor's DT, linux kernel and the rootfs. Dropping firmware names from > > > DT solves that by removing one piece of the equation > > > > > > Now for the complexity of the solution. Each SoC family has their own > > > firmware set. This includes firmware for the DSPs, for modem, WiFi > > > bits, GPU shader, etc. > > > For the development boards these devices are signed by the testing key > > > and the actual signature is not validated against the root of trust > > > certificate. > > > For the end-user devices the signature is actually validated against > > > the bits fused to the SoC during manufacturing process. CA certificate > > > (and thus the fuses) differ from vendor to vendor (and from the device > > > to device) > > > > > > Not all of the firmware files are a part of the public linux-firmware > > > tree. However we need to support the rootfs bundled with the firmware > > > for different platforms (both public and vendor). The non-signed files > > > come from the Adreno GPU and can be shared between platforms. All > > > other files are SoC-specific and in some cases device-specific. > > > > > > So for example the SDM845 db845c (open device) loads following firmware > > > files: > > > Not signed: > > > - qcom/a630_sqe.fw > > > - qcom/a630_gmu.bin > > > > > > Signed, will work for any non-secured sdm845 device: > > > - qcom/sdm845/a630_zap.mbn > > > - qcom/sdm845/adsp.mbn > > > - qcom/sdm845/cdsp.mbn > > > - qcom/sdm485/mba.mbn > > > - qcom/sdm845/modem.mbn > > > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP) > > > - qcom/venus-5.2/venus.mbn > > > > > > Signed, works only for DB845c. > > > - qcom/sdm845/Thundercomm/db845c/slpi.mbn > > > > > > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the > > > following firmware files: > > > - qcom/a630_sqe.fw (the same, non-signed file) > > > - qcom/a630_gmu.bin (the same, non-signed file) > > > - qcom/sdm845/Google/blueline/a630_zap.mbn > > > > How do you get from "a630_zap.mbn" to this? By extending the lookup > > table for every target, or what am I missing? > > More or less so. Matching the root OF node gives us the firmware > location, then it gets prepended to all firmware targets. Not an ideal > solution, as there is no fallback support, but at least it gives us > some points to discuss (and to decide whether to move to some > particular direction or to abandon the idea completely, making Arnd > unhappy again). > I understand the desire to not put linux-firmware-specific paths in the DeviceTree, but I think I'm less keen on having a big lookup table in the kernel... Regards, Bjorn
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! [3/3] arm64: dts: qcom: qcs404: Use qcs404-hfpll compatible for hfpll commit: 839936d9676bdc2e4dde63631131feb8870fa4d2 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! [2/2] dt-bindings: soc: qcom,smp2p: Mark qcom,ipc as deprecated commit: 7ce966eb6f1288eb92bc2eb5df8933acee1ae6ed Best regards, -- Bjorn Andersson
Re: [PATCH] clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents
On Wed, 08 May 2024 10:12:53 +0200, Luca Weiss wrote: > Both gpll6 and gpll7 are parented to CXO at 19.2 MHz and not to GPLL0 > which runs at 600 MHz. Also gpll6_out_even should have the parent gpll6 > and not gpll0. > > Adjust the parents of these clocks to make Linux report the correct rate > and not absurd numbers like gpll7 at ~25 GHz or gpll6 at 24 GHz. > > [...] Applied, thanks! [1/1] clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents commit: 3414f41a13eb41db15c558fbc695466203dca4fa Best regards, -- Bjorn Andersson
Re: [PATCH 0/2] Enable vibrator on PMI632 + Fairphone 3
On Thu, 18 Apr 2024 08:36:53 +0200, Luca Weiss wrote: > With the patches to add vibration support for PMI632 finally applied, > let's enable this for the PMI632 PMIC and Fairphone 3 smartphone. > > https://lore.kernel.org/linux-arm-msm/20240416-pm8xxx-vibrator-new-design-v11-0-7b1c951e1...@quicinc.com/ > > Patches have landed in the input tree: > https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/ > > [...] Applied, thanks! [1/2] arm64: dts: qcom: pmi632: Add vibrator commit: bbb1dd6402f9c67ea00bc6bf0e2a01d71db4c7fd [2/2] arm64: dts: qcom: sdm632-fairphone-fp3: Enable vibrator commit: ffaa4b5d5d07aed600d82929d8862263ce341a71 Best regards, -- Bjorn Andersson
Re: [PATCH DNM 2/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Add DisplayPort sound support
On Fri, May 10, 2024 at 02:27:09PM GMT, Luca Weiss wrote:
> Add the required nodes for sound playback via a connected external
> display (DisplayPort over USB-C).
>
> Signed-off-by: Luca Weiss
> ---
> Depends on a bunch of patches upstream doing bringup of Display (DSI),
> DisplayPort, GPU, and then finally audio could land. But we're blocked
> on DPU 1:1:1 topology for all of that unfortunately.
>
> And also machine driver for sound just exists a bit hackily.
Thanks for sharing this, Luca. Can you please resubmit this once it's
ready to be merged, so that I don't need to keep track of it?
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 36
> ++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 05bbf1da5cb8..2bbbcaeff95e 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "sc7280.dtsi"
> #include "pm7250b.dtsi"
> #include "pm7325.dtsi"
> @@ -774,6 +776,12 @@ _resin {
> status = "okay";
> };
>
> + {
> + dai@104 {
> + reg = ;
> + };
> +};
> +
> _spi13_cs {
> drive-strength = <6>;
> bias-disable;
> @@ -847,6 +855,34 @@ _2 {
> status = "okay";
> };
>
> + {
> + compatible = "fairphone,fp5-sndcard";
> + model = "Fairphone 5";
> +
> + mm1-dai-link {
> + link-name = "MultiMedia1";
> + cpu {
> + sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA1>;
> + };
> + };
> +
> + displayport-rx-dai-link {
> + link-name = "DisplayPort Playback";
> +
> + cpu {
> + sound-dai = < DISPLAY_PORT_RX>;
> + };
> +
> + platform {
> + sound-dai = <>;
> + };
> +
> + codec {
> + sound-dai = <_dp>;
> + };
> + };
> +};
> +
> {
> status = "okay";
>
>
> --
> 2.45.0
>
Re: [PATCH v10] remoteproc: qcom: Move minidump related layout and API to soc/qcom directory
On Fri, May 03, 2024 at 01:48:07PM GMT, Mukesh Ojha wrote:
> Currently, Qualcomm Minidump is being used to collect mini version of
> remoteproc coredump with the help of boot firmware however, Minidump
> as a feature is not limited to be used only for remote processor and
> can also be used for Application processors. So, in preparation of
> using it move the Minidump related data structure and its function
> to its own file under drivers/soc/qcom with qcom_rproc_minidump.c
> which clearly says it is only for remoteproc minidump.
>
> Extra changes made apart from the movement is,
> 1. Adds new config, kernel headers and module macros to get this
>module compiled.
> 2. Guards the qcom_minidump() with CONFIG_QCOM_RPROC_MINIDUMP.
> 3. Selects this QCOM_RPROC_MINIDUMP config when QCOM_RPROC_COMMON
>enabled.
> 4. Added new header qcom_minidump.h .
>
> Signed-off-by: Mukesh Ojha
I wouldn't be able to merge this without anything depending on it...
[..]
> diff --git a/drivers/soc/qcom/qcom_rproc_minidump.c
> b/drivers/soc/qcom/qcom_rproc_minidump.c
[..]
> +void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
> + void (*rproc_dumpfn_t)(struct rproc *rproc,
> + struct rproc_dump_segment *segment, void *dest, size_t offset,
> + size_t size))
> +{
> + int ret;
> + struct minidump_subsystem *subsystem;
> + struct minidump_global_toc *toc;
> +
> + /* Get Global minidump ToC*/
> + toc = qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, NULL);
> +
> + /* check if global table pointer exists and init is set */
> + if (IS_ERR(toc) || !toc->status) {
> + dev_err(>dev, "Minidump TOC not found in SMEM\n");
> + return;
> + }
> +
> + /* Get subsystem table of contents using the minidump id */
> + subsystem = >subsystems[minidump_id];
> +
> + /**
> + * Collect minidump if SS ToC is valid and segment table
> + * is initialized in memory and encryption status is set.
> + */
> + if (subsystem->regions_baseptr == 0 ||
> + le32_to_cpu(subsystem->status) != 1 ||
> + le32_to_cpu(subsystem->enabled) != MINIDUMP_SS_ENABLED) {
> + return rproc_coredump(rproc);
> + }
> +
> + if (le32_to_cpu(subsystem->encryption_status) != MINIDUMP_SS_ENCR_DONE)
> {
> + dev_err(>dev, "Minidump not ready, skipping\n");
> + return;
> + }
> +
> + /**
> + * Clear out the dump segments populated by parse_fw before
> + * re-populating them with minidump segments.
> + */
> + rproc_coredump_cleanup(rproc);
I don't think this should be invoked outside drivers/remoteproc, and the
comment talks about a remoteproc-internal concern...
> +
> + ret = qcom_add_minidump_segments(rproc, subsystem, rproc_dumpfn_t);
This function changes the internal state of the remoteproc and relies on
other operations to clean things up.
I think we could come up with a better design of this, and I don't think
we should spread this outside of the remoteproc framework.
Regards,
Bjorn
> + if (ret) {
> + dev_err(>dev, "Failed with error: %d while adding
> minidump entries\n", ret);
> + goto clean_minidump;
> + }
> + rproc_coredump_using_sections(rproc);
> +clean_minidump:
> + qcom_minidump_cleanup(rproc);
> +}
> +EXPORT_SYMBOL_GPL(qcom_minidump);
> +
> +MODULE_DESCRIPTION("Qualcomm Remoteproc Minidump helper module");
> +MODULE_LICENSE("GPL");
> diff --git a/include/soc/qcom/qcom_minidump.h
> b/include/soc/qcom/qcom_minidump.h
> new file mode 100644
> index ..0fe156066bc0
> --- /dev/null
> +++ b/include/soc/qcom/qcom_minidump.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_MINIDUMP_H_
> +#define _QCOM_MINIDUMP_H_
> +
> +struct rproc;
> +struct rproc_dump_segment;
> +
> +#if IS_ENABLED(CONFIG_QCOM_RPROC_MINIDUMP)
> +void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
> +void (*rproc_dumpfn_t)(struct rproc *rproc,
> +struct rproc_dump_segment *segment, void *dest, size_t
> offset,
> +size_t size));
> +#else
> +static inline void qcom_minidump(struct rproc *rproc, unsigned int
> minidump_id,
> +void (*rproc_dumpfn_t)(struct rproc *rproc,
> +struct rproc_dump_segment *segment, void *dest, size_t
> offset,
> +size_t size)) { }
> +#endif /* CONFIG_QCOM_RPROC_MINIDUMP */
> +#endif /* _QCOM_MINIDUMP_H_ */
> --
> 2.7.4
>
Re: (subset) [PATCH v2 0/2] Allow gpio-hog nodes in qcom,pmic-gpio bindings (& dt fixup)
On Tue, 09 Apr 2024 20:36:35 +0200, Luca Weiss wrote: > Resolve the dt validation failure on Nexus 5. > > Applied, thanks! [2/2] ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node name commit: 92b9ce5b11d7ba281f5bf0029185d5c891b29344 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/2] Fix msm8974 apcs syscon compatible
On Mon, 08 Apr 2024 21:32:02 +0200, Luca Weiss wrote: > Finally fix a warning about the apcs-global syscon used on msm8974 that > has been around forever. > > Applied, thanks! [2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon commit: c133cfc12cd717b72ce534477415446e1c33de47 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! [2/3] arm64: dts: qcom: msm8996: add glink-edge nodes commit: 56ae780a4387d71dd709895acd95112d01f37fb4 [3/3] arm64: dts: msm8996: add fastrpc nodes commit: 1b80b83f893dd69efe3c3bf84cd9f661218ccfc0 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Add Samsung Galaxy Note 3 support
On Thu, 14 Mar 2024 20:00:13 +0100, Luca Weiss wrote: > Add the dts for "hlte" which is a phablet from 2013. > > Applied, thanks! [2/2] ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3 commit: b4f6c63bf34d8da1b769483bb1f4a603c53896ce Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/2] Add basic APR sound support for SC7280 SoC
On Fri, 10 May 2024 14:27:07 +0200, Luca Weiss wrote: > Validated on Fairphone 5 (QCM6490) smartphone by using DisplayPort over > USB-C audio, connected to a TV, with a basic UCM to enable > 'DISPLAY_PORT_RX Audio Mixer MultiMedia1': > https://gitlab.com/postmarketOS/pmaports/-/tree/master/device/testing/device-fairphone-fp5/ucm > > Unfortunately all the device-specific things can't be enabled yet > upstream as detailed in the second patch, but the SoC parts should be > good to go. > > [...] Applied, thanks! [1/2] arm64: dts: qcom: sc7280: Add APR nodes for sound commit: f44da5d8722de348ff2eb8b206c69b52809c1772 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v3 0/2] Add samsung-milletwifi
On Mon, 19 Feb 2024 22:43:15 +0100, Bryant Mairs wrote: > This series adds support for samsung-milletwifi, the smaller cousin > to samsung-matisselte. I've used the manufacturer's naming convention > for consistency. > > Hardware currently supported: > - Display > - Cover detection > - Physical buttons > - Touchscreen and touchkeys > - Accelerometer > > [...] Applied, thanks! [2/2] ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 8.0 Wi-Fi commit: 49b9981a0ecae2bbb298d8b0c2b8058220038691 Best regards, -- Bjorn Andersson
Re: [PATCH v4 0/4] MSM8976 MDSS/GPU/WCNSS support
On Wed, 08 May 2024 18:34:33 +0200, Adam Skladowski wrote: > This patch series provide support for display subsystem, gpu > and also adds wireless connectivity subsystem support. > > Changes since v3 > > 1. Minor styling fixes > 2. Converted qcom,ipc into mailbox on wcnss patch > > [...] Applied, thanks! [1/4] arm64: dts: qcom: msm8976: Add IOMMU nodes commit: 418c2ffd7df9bfc25c21172bd881b78d7569fb4d [2/4] arm64: dts: qcom: msm8976: Add MDSS nodes commit: b0516dbf8e218dede2fd2837ca82dccd9cdcdafc [3/4] arm64: dts: qcom: msm8976: Add Adreno GPU commit: 00e67d8e80f06bb848a3dd516d06e2f040b7d8f2 [4/4] arm64: dts: qcom: msm8976: Add WCNSS node commit: 45878973229a93f0f42aa048ac8c6223af010082 Best regards, -- Bjorn Andersson
Re: [PATCH v2 2/3] arm64: dts: qcom: pm7250b: Add a TCPM description
On Fri, Mar 29, 2024 at 01:26:20PM GMT, Luca Weiss wrote:
> Type-C port management functionality lives inside of the PMIC block on
> pm7250b.
>
> The Type-C port management logic controls orientation detection,
> vbus/vconn sense and to send/receive Type-C Power Domain messages.
>
pm7250b is found in devices where USB Type-C port management is
performed in firmware, presumably using this hardware block.
As such, it seems reasonable to leave this node disabled and only enable
it on the targets that doesn't do this in firmware.
Regards,
Bjorn
> Reviewed-by: Bryan O'Donoghue
> Reviewed-by: Konrad Dybcio
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/pm7250b.dtsi | 39
> +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> index 4faed25a787f..0205c2669093 100644
> --- a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> @@ -51,6 +51,45 @@ pm7250b_vbus: usb-vbus-regulator@1100 {
> status = "disabled";
> };
>
> + pm7250b_typec: typec@1500 {
> + compatible = "qcom,pm7250b-typec", "qcom,pm8150b-typec";
> + reg = <0x1500>,
> + <0x1700>;
> + interrupts = IRQ_TYPE_EDGE_RISING>,
> + ,
> + IRQ_TYPE_EDGE_RISING>,
> + ,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + ,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>,
> + IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "or-rid-detect-change",
> + "vpd-detect",
> + "cc-state-change",
> + "vconn-oc",
> + "vbus-change",
> + "attach-detach",
> + "legacy-cable-detect",
> + "try-snk-src-detect",
> + "sig-tx",
> + "sig-rx",
> + "msg-tx",
> + "msg-rx",
> + "msg-tx-failed",
> + "msg-tx-discarded",
> + "msg-rx-discarded",
> + "fr-swap";
> + vdd-vbus-supply = <_vbus>;
> + };
> +
> pm7250b_temp: temp-alarm@2400 {
> compatible = "qcom,spmi-temp-alarm";
> reg = <0x2400>;
>
> --
> 2.44.0
>
Re: [PATCH 01/12] soc: qcom: add firmware name helper
On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote: > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote: > > > > Dmitry Baryshkov writes: > > > > > On Tue, 21 May 2024 at 12:52, wrote: > > >> > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote: > > >> > Qualcomm platforms have different sets of the firmware files, which > > >> > differ from platform to platform (and from board to board, due to the > > >> > embedded signatures). Rather than listing all the firmware files, > > >> > including full paths, in the DT, provide a way to determine firmware > > >> > path based on the root DT node compatible. > > >> > > >> Ok this looks quite over-engineered but necessary to handle the legacy, > > >> but I really think we should add a way to look for a board-specific path > > >> first and fallback to those SoC specific paths. > > > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays. > > > > To me this also looks like very over-engineered, can you elaborate more > > why this is needed? Concrete examples would help to understand better. > > Sure. During the meeting last week Arnd suggested evaluating if we can > drop firmware-name from the board DT files. Several reasons for that: > - DT should describe the hardware, not the Linux-firmware locations > - having firmware name in DT complicates updating the tree to use > different firmware API (think of mbn vs mdt vs any other format) > - If the DT gets supplied by the vendor (e.g. for > SystemReady-certified devices), there should be a sync between the > vendor's DT, linux kernel and the rootfs. Dropping firmware names from > DT solves that by removing one piece of the equation > > Now for the complexity of the solution. Each SoC family has their own > firmware set. This includes firmware for the DSPs, for modem, WiFi > bits, GPU shader, etc. > For the development boards these devices are signed by the testing key > and the actual signature is not validated against the root of trust > certificate. > For the end-user devices the signature is actually validated against > the bits fused to the SoC during manufacturing process. CA certificate > (and thus the fuses) differ from vendor to vendor (and from the device > to device) > > Not all of the firmware files are a part of the public linux-firmware > tree. However we need to support the rootfs bundled with the firmware > for different platforms (both public and vendor). The non-signed files > come from the Adreno GPU and can be shared between platforms. All > other files are SoC-specific and in some cases device-specific. > > So for example the SDM845 db845c (open device) loads following firmware files: > Not signed: > - qcom/a630_sqe.fw > - qcom/a630_gmu.bin > > Signed, will work for any non-secured sdm845 device: > - qcom/sdm845/a630_zap.mbn > - qcom/sdm845/adsp.mbn > - qcom/sdm845/cdsp.mbn > - qcom/sdm485/mba.mbn > - qcom/sdm845/modem.mbn > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP) > - qcom/venus-5.2/venus.mbn > > Signed, works only for DB845c. > - qcom/sdm845/Thundercomm/db845c/slpi.mbn > > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the > following firmware files: > - qcom/a630_sqe.fw (the same, non-signed file) > - qcom/a630_gmu.bin (the same, non-signed file) > - qcom/sdm845/Google/blueline/a630_zap.mbn How do you get from "a630_zap.mbn" to this? By extending the lookup table for every target, or what am I missing? Regards, Bjorn > - qcom/sdm845/Google/blueline/adsp.mbn > - qcom/sdm845/Google/blueline/cdsp.mbn > - qcom/sdm845/Google/blueline/ipa_fws.mbn > - qcom/sdm845/Google/blueline/mba.mbn > - qcom/sdm845/Google/blueline/modem.mbn > - qcom/sdm845/Google/blueline/venus.mbn > - qcom/sdm845/Google/blueline/wlanmdsp.mbn > - qcom/sdm845/Google/blueline/slpi.mbn > > The Lenovo Yoga C630 WoS laptop (SDM850 is a variant of SDM845) uses > another set of files: > - qcom/a630_sqe.fw (the same, non-signed file) > - qcom/a630_gmu.bin (the same, non-signed file) > - qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn > - qcom/sdm850/LENOVO/81JL/qcadsp850.mbn > - qcom/sdm850/LENOVO/81JL/qccdsp850.mbn > - qcom/sdm850/LENOVO/81JL/ipa_fws.elf > - qcom/sdm850/LENOVO/81JL/qcdsp1v2850.mbn > - qcom/sdm850/LENOVO/81JL/qcdsp2850.mbn > - qcom/sdm850/LENOVO/81JL/qcvss850.mbn > - qcom/sdm850/LENOVO/81JL/wlanmdsp.mbn > - qcom/sdm850/LENOVO/81JL/qcslpi850.mbn > > If we look at one of the recent platforms, e.g. SM8650-QRD, this list > also grows up: > - qcom/gen70900_sqe.fw (generic, non-signed) > - qcom/gmu_gen70900.bin (generic, non-signed) > - qcom/sm8650/gen70900_zap.mbn > - qcom/sm8650/adsp.mbn > - qcom/sm8650/adsp_dtb.mbn > - qcom/sm8650/cdsp.mbn > - qcom/sm8650/cdsp_dtb.mbn > - qcom/sm8650/ipa_fws.mbn > - qcom/sm8650/modem.mbn > - qcom/sm8650/modem_dtb.mbn > - qcom/sm8650/vpu33_4v.mbn (or maybe qcom/vpu-33/vpu_4v.mbn) > > -- > With best wishes > Dmitry > > > > > > > > >
Re: [PATCH 06/12] remoteproc: qcom_q6v5_pas: switch to mbn files by default
On Tue, May 21, 2024 at 11:49:42AM +0200, neil.armstr...@linaro.org wrote: > On 21/05/2024 11:45, Dmitry Baryshkov wrote: > > We have been pushing userspace to use mbn files by default for ages. > > As a preparation for making the firmware-name optional, make the driver > > use .mbn instead of .mdt files by default. > > I think we should have a mechanism to fallback to .mdt since downstream > uses split mdt on the devices filesystem. > Let's ignore and continue to move away from the split .mdt files. Combining split files is trivial and removes a class of problems where people mix and match their parts. (And worst case you can rename/symlink your downstream firmware to match the requested filename) Regards, Bjorn
[GIT PULL] remoteproc updates for v6.10
The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rproc-v6.10 for you to fetch changes up to 4d5ba6ead1dc9fa298d727e92db40cd98564d1ac: dt-bindings: remoteproc: qcom,sdm845-adsp-pil: Fix qcom,halt-regs definition (2024-05-06 19:41:38 -0700) remoteproc updates for v6.10 This makes the remoteproc core rproc_class const. DeviceTree bindings for a few different Qualcomm remoteprocs are updated to remove a range of validation warnings/errors. The Qualcomm SMD binding marks qcom,ipc deprecated, in favor or the mailbox interface. The TI K3 R5 remoteproc driver is updated to ensure that cores are powered up in the appropriate order. The driver also see a couple of fixes related to cleanups in error paths during probe. The Mediatek remoteproc driver is extended to support the MT8188 SCP core 1. Support for varying DRAM and IPI shared buffer sizes are introduced. This together with a couple of bug fixes and improvements to the driver. Support for the AMD-Xilinx Versal and Versal-NET platforms are added. Coredump support and support for parsing TCM information from DeviceTree is added to the Xilinx R5F remoteproc driver. AngeloGioacchino Del Regno (1): remoteproc: mediatek: Make sure IPI buffer fits in L2TCM Apurva Nandan (1): remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi (2): remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs remoteproc: k3-r5: Jump to error handling labels in start/stop errors Dan Carpenter (1): remoteproc: mediatek: Fix error code in scp_rproc_init() Dmitry Baryshkov (1): dt-bindings: remoteproc: qcom,msm8996-mss-pil: allow glink-edge on msm8996 Leonard Crestez (1): remoteproc: zynqmp: Add coredump support Luca Weiss (4): dt-bindings: remoteproc: qcom,smd-edge: Mark qcom,ipc as deprecated dt-bindings: remoteproc: qcom,qcs404-cdsp-pil: Fix qcom,halt-regs definition dt-bindings: remoteproc: qcom,sc7280-wpss-pil: Fix qcom,halt-regs definition dt-bindings: remoteproc: qcom,sdm845-adsp-pil: Fix qcom,halt-regs definition Olivia Wen (4): dt-bindings: remoteproc: mediatek: Support MT8188 dual-core SCP remoteproc: mediatek: Support MT8188 SCP core 1 remoteproc: mediatek: Support setting DRAM and IPI shared buffer sizes remoteproc: mediatek: Add IMGSYS IPI command Radhey Shyam Pandey (1): dt-bindings: remoteproc: Add Tightly Coupled Memory (TCM) bindings Ricardo B. Marliere (1): remoteproc: Make rproc_class constant Tanmay Shah (5): remoteproc: zynqmp: fix lockstep mode memory region remoteproc: zynqmp: parse TCM from device tree drivers: remoteproc: xlnx: Add Versal and Versal-NET support drivers: remoteproc: xlnx: Fix uninitialized variable use drivers: remoteproc: xlnx: Fix uninitialized tcm mode .../devicetree/bindings/remoteproc/mtk,scp.yaml| 2 + .../bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 1 - .../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 +- .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml | 6 +- .../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml | 6 +- .../bindings/remoteproc/qcom,smd-edge.yaml | 3 +- .../bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 279 +++-- drivers/remoteproc/mtk_common.h| 11 +- drivers/remoteproc/mtk_scp.c | 241 +-- drivers/remoteproc/mtk_scp_ipi.c | 7 +- drivers/remoteproc/remoteproc_internal.h | 2 +- drivers/remoteproc/remoteproc_sysfs.c | 2 +- drivers/remoteproc/ti_k3_r5_remoteproc.c | 58 +++- drivers/remoteproc/xlnx_r5_remoteproc.c| 329 ++--- include/linux/remoteproc/mtk_scp.h | 1 + 15 files changed, 721 insertions(+), 233 deletions(-)
[GIT PULL] rpmsg updates for v6.10
The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git tags/rpmsg-v6.10 for you to fetch changes up to bcbab579f968ffd63236d90227212e689ddbd600: rpmsg: qcom_glink_ssr: fix module autoloading (2024-05-06 19:26:28 -0700) rpmsg updates for v6.10 This makes core rpmsg_class const and it ensures automatic module loading of the Qualcomm glink_ssr driver happens. Krzysztof Kozlowski (1): rpmsg: qcom_glink_ssr: fix module autoloading Ricardo B. Marliere (1): rpmsg: core: Make rpmsg_class constant drivers/rpmsg/qcom_glink_ssr.c | 1 + drivers/rpmsg/rpmsg_char.c | 2 +- drivers/rpmsg/rpmsg_core.c | 16 +--- drivers/rpmsg/rpmsg_ctrl.c | 2 +- drivers/rpmsg/rpmsg_internal.h | 2 +- 5 files changed, 13 insertions(+), 10 deletions(-)
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
