Re: [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Use .mbn firmware for IPA
On 6.06.2024 11:09 AM, 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. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/2] ARM: dts: qcom: Add initial support for HTC One (M8)
On 6/3/24 08:28, Alexandre Messier via B4 Relay wrote: From: Alexandre Messier Add initial device tree for the HTC One (M8) smartphone. Initial support includes: - eMMC - Power button - USB - Vibrator - Volume buttons (GPIO) - Wi-Fi Signed-off-by: Alexandre Messier --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v3 1/3] arm64: dts: qcom: pm7250b: Add node for PMIC VBUS booster
On 30.05.2024 5:05 PM, Luca Weiss wrote: > Add the required DTS node for the USB VBUS output regulator, which is > available on PM7250B. This will provide the VBUS source to connected > peripherals. > > Reviewed-by: Bryan O'Donoghue > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/5] dt-bindings: remoteproc: qcom,sm8550-pas: Document the SA8775p ADSP, CDSP and GPDSP
On 22.05.2024 3:08 PM, Bartosz Golaszewski wrote: > On Wed, May 22, 2024 at 3:06 PM wrote: >> >> On 22/05/2024 15:04, Bartosz Golaszewski wrote: >>> On Wed, May 22, 2024 at 2:42 PM wrote: On 22/05/2024 14:08, Bartosz Golaszewski wrote: > From: Tengfei Fan > > Document the compatibles for the components used to boot the ADSP, CDSP0, > CDSP1, GPDSP0 and GPDSP1 on the SA8775p SoC. > > Signed-off-by: Tengfei Fan > Co-developed-by: Bartosz Golaszewski > Signed-off-by: Bartosz Golaszewski > --- >.../bindings/remoteproc/qcom,sm8550-pas.yaml | 76 > +- >1 file changed, 75 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > index 73fda7565cd1..9d3a862c39e1 100644 > --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > @@ -16,6 +16,11 @@ description: >properties: > compatible: >enum: > + - qcom,sa8775p-adsp-pas > + - qcom,sa8775p-cdsp0-pas > + - qcom,sa8775p-cdsp1-pas > + - qcom,sa8775p-gpdsp0-pas > + - qcom,sa8775p-gpdsp1-pas > - qcom,sm8550-adsp-pas > - qcom,sm8550-cdsp-pas > - qcom,sm8550-mpss-pas > @@ -44,12 +49,13 @@ properties: > > firmware-name: >$ref: /schemas/types.yaml#/definitions/string-array > +minItems: 1 This will allow a single firmware name for all compatible, which is wrong >>> >>> So increasing the limit from the default under allOf doesn't seem to >>> work, should I instead keep this and make the lower limit stricter for >>> all other models? >> >> Yes add minItems in all the allOf:if: and add the missing allOf:if: for >> the new compatibles to set the minItems, same for memory-region. >> >> Or you may simply spin off a new yaml, this one is getting quite large. >> > > Yeah, maybe that's a better idea. + if you get rid of the 0/1 in "nsp0/nsp1" you save a couple more lines Konrad
Re: [PATCH 6/7] arm64: dts: qcom: msm8976: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 7/7] arm64: dts: qcom: msm8994: Use mboxes properties for APCS
On 4/24/24 18:24, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 5/7] arm64: dts: qcom: msm8953: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 4/7] arm64: dts: qcom: msm8939: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/7] arm64: dts: qcom: msm8916: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/7] ARM: dts: qcom: msm8974: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH RFC 2/2] soc: qcom: smsm: Support using mailbox interface
On 4/24/24 19:21, Luca Weiss wrote: Add support for using the mbox interface instead of manually writing to the syscon. With this change the driver will attempt to get the mailbox first, and if that fails it will fall back to the existing way of using qcom,ipc-* properties and converting to syscon. Signed-off-by: Luca Weiss --- Looks good! Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v3 4/4] arm64: dts: qcom: msm8976: Add WCNSS node
On 4/13/24 19:03, Adam Skladowski wrote:
Add node describing wireless connectivity subsystem.
Signed-off-by: Adam Skladowski
---
[...]
+ wcnss_wifi: wifi {
+ compatible = "qcom,wcnss-wlan";
+
+ interrupts = ,
+;
+ interrupt-names = "tx", "rx";
+
+ qcom,smem-states = <_smsm 10>,
<_smsm 9>;
+ qcom,smem-state-names =
"tx-enable",
+
"tx-rings-empty";
Since you're already going to resend, please keep one entry per line,
this fragment is very inconsistent
looks good otherwise
Konrad
Re: [PATCH v3 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU
On 4/13/24 19:03, Adam Skladowski wrote:
Add Adreno GPU node.
Signed-off-by: Adam Skladowski
---
[...]
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ required-opps = <_opp_low_svs>;
+ opp-supported-hw = <0xff>;
Doesn't look like this platform had any speed binning going on, can drop?
Konrad
Re: [PATCH v3 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes
On 4/13/24 19:03, Adam Skladowski wrote:
Add MDSS nodes to support displays on MSM8976 SoC.
Signed-off-by: Adam Skladowski
---
[...]
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-17778 {
+ opp-hz = /bits/ 64 <17778>;
+ required-opps =
<_opp_svs>;
+ };
+
+ opp-27000 {
+ opp-hz = /bits/ 64 <27000>;
+ required-opps =
<_opp_svs_plus>;
+ };
+
+ opp-32000 {
+ opp-hz = /bits/ 64 <32000>;
+ required-opps =
<_opp_nom>;
+ };
+ opp-36000 {
Missing a newline above
[...]
+ dsi0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-12500 {
+ opp-hz = /bits/ 64 <12500>;
+ required-opps =
<_opp_svs>;
+
+ };
You can borrow it from here
Looks reasonable otherwise
Konrad
Re: [PATCH v2 3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable USB role switching
On 3/29/24 13:26, Luca Weiss wrote: Configure the Type-C and VBUS regulator on PM7250B and wire it up to the USB PHY, so that USB role and orientation switching works. For now USB Power Delivery properties are skipped / disabled, so that the (presumably) bootloader-configured charger doesn't get messed with and we can charge the phone with at least some amount of power. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio nits: + usb-role-switch; this is a common property of the dwc3 host [...] vdda-phy-supply = <_l22a>; vdda-pll-supply = <_l16a>; + orientation-switch; and this is a common property of the QMPPHY Could you move them to the node definition? Konrad
Re: [PATCH 1/2] arm64: dts: qcom: pmi632: Add vibrator
On 4/18/24 12:03, Luca Weiss wrote: On Thu Apr 18, 2024 at 12:01 PM CEST, Konrad Dybcio wrote: On 18.04.2024 8:36 AM, Luca Weiss wrote: Add a node for the vibrator module found inside the PMI632. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio On a side note, this is a totally configuration-free peripheral that doesn't do anything crazy until manually configured. In the slow quest to be (hopefully) more sane about the defaults, should we keep them enabled by default? Bjorn? But many (most?) devices don't have a vibration motor connected to PMI632, some (like devboards) don't have anything, and other phones have a separate chip that controls the vibration motor. Enabling this by default would mean all devices with PMI632 would get an input device for the vibrator that probably doesn't work? Fair Konrad
Re: [PATCH v2 3/3] arm64: dts: msm8996: add fastrpc nodes
On 18.04.2024 8:44 AM, Dmitry Baryshkov wrote: > From: Srinivas Kandagatla > > The ADSP provides fastrpc/compute capabilities. Enable support for the > fastrpc on this DSP. > > Signed-off-by: Srinivas Kandagatla > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/2] arm64: dts: qcom: pmi632: Add vibrator
On 18.04.2024 8:36 AM, Luca Weiss wrote: > Add a node for the vibrator module found inside the PMI632. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio On a side note, this is a totally configuration-free peripheral that doesn't do anything crazy until manually configured. In the slow quest to be (hopefully) more sane about the defaults, should we keep them enabled by default? Bjorn? Konrad
Re: [PATCH] rpmsg: qcom_glink_ssr: fix module autoloading
On 4/10/24 18:40, Krzysztof Kozlowski wrote: Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Krzysztof Kozlowski --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/2] dt-bindings: pinctrl: qcom,pmic-gpio: Allow gpio-hog nodes
On 4/8/24 18:39, Luca Weiss wrote: Allow specifying a GPIO hog, as already used on qcom-msm8974-lge-nexus5-hammerhead.dts. Signed-off-by: Luca Weiss --- .../devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index a786357ed1af..510a05369dbb 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -424,6 +424,10 @@ patternProperties: $ref: "#/$defs/qcom-pmic-gpio-state" additionalProperties: false + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": I see a couple bindings do this, but I'm not sure if we want two allow two styles for no reason.. Rob? Konrad
Re: [PATCH 1/1] clk: qcom: smd-rpm: Restore msm8976 num_clk
On 1.04.2024 7:16 PM, Adam Skladowski wrote:
> During rework somehow msm8976 num_clk got removed, restore it.
>
> Fixes: d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus
> clocks")
> Signed-off-by: Adam Skladowski
> ---
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH 3/3] arm64: dts: msm8996: add fastrpc nodes
On 31.03.2024 11:10 PM, Dmitry Baryshkov wrote:
> From: Srinivas Kandagatla
>
> The ADSP provides fastrpc/compute capabilities. Enable support for the
> fastrpc on this DSP.
>
> Signed-off-by: Srinivas Kandagatla
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 57
> +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 7ae499fa7d91..cf7ab01f3af6 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -3545,6 +3545,63 @@ q6routing: routing {
> };
> };
> };
> +
> + fastrpc {
> + compatible = "qcom,fastrpc";
> + qcom,smd-channels =
> "fastrpcsmd-apps-dsp";
> + label = "adsp";
> + qcom,non-secure-domain;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cb@8 {
> + compatible =
> "qcom,fastrpc-compute-cb";
> + reg = <8>;
> + iommus = <_q6_smmu 8>;
> + };
> +
> + cb@9 {
> + compatible =
> "qcom,fastrpc-compute-cb";
> + reg = <9>;
> + iommus = <_q6_smmu 9>;
> + };
> +
> + cb@10 {
> + compatible =
> "qcom,fastrpc-compute-cb";
> + reg = <10>;
> + iommus = <_q6_smmu 10>;
> + };
> +
> + cb@11 {
> + compatible =
> "qcom,fastrpc-compute-cb";
> + reg = <11>;
> + iommus = <_q6_smmu 11>;
> + };
> +
> + cb@12 {
> + compatible =
> "qcom,fastrpc-compute-cb";
> + reg = <12>;
> + iommus = <_q6_smmu 12>;
> + };
> +
> + cb@5 {
> + compatible =
> "qcom,fastrpc-compute-cb";
> + reg = <5>;
No need to copy downstream's creative alphabetical-but-not-numerical
sorting.. The entries look OK though.. although, any reason we have
such a weird binding including faux child nodes and not just an array
of iommus? Is the only way to discover the fastrpc nodes' properties
such as qcom,non-secure-domain or vmid belonging through hardcoding?
Konrad
Konrad
Re: [PATCH 2/3] arm64: dts: qcom: msm8996: add glink-edge nodes
On 31.03.2024 11:10 PM, Dmitry Baryshkov wrote: > MSM8996 provides limited glink support, so add corresponding device tree > nodes. For example the following interfaces are provided on db820c: > > modem: > 208.remoteproc:glink-edge.LOOPBACK_CTL_MPSS.-1.-1 > 208.remoteproc:glink-edge.glink_ssr.-1.-1 > 208.remoteproc:glink-edge.rpmsg_chrdev.0.0 > > adsp: > 930.remoteproc:glink-edge.LOOPBACK_CTL_LPASS.-1.-1 > 930.remoteproc:glink-edge.glink_ssr.-1.-1 > 930.remoteproc:glink-edge.rpmsg_chrdev.0.0 > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH RFT] arm64: dts: qcom: sm8350: Reenable crypto & cryptobam
On 16.02.2024 11:36 AM, Luca Weiss wrote:
> On Mon Jan 8, 2024 at 11:45 PM CET, Dmitry Baryshkov wrote:
>> On Mon, 8 Jan 2024 at 16:23, Luca Weiss wrote:
>>>
>>> On Mon Jan 8, 2024 at 3:18 PM CET, Konrad Dybcio wrote:
>>>> On 8.01.2024 14:49, Luca Weiss wrote:
>>>>> When num-channels and qcom,num-ees is not provided in devicetree, the
>>>>> driver will try to read these values from the registers during probe but
>>>>> this fails if the interconnect is not on and then crashes the system.
>>>>>
>>>>> So we can provide these properties in devicetree (queried after patching
>>>>> BAM driver to enable the necessary interconnect) so we can probe
>>>>> cryptobam without reading registers and then also use the QCE as
>>>>> expected.
>>>>
>>>> This really feels a bit backwards.. Enable the resource to query the
>>>> hardware for numbers, so that said resource can be enabled, but
>>>> slightly later :/
>>>
>>> If you think adding interconnect support to driver and dtsi is better,
>>> let me know.
>>
>> I'd say, adding the proper interconnect is a better option. Otherwise
>> we just depend on the QCE itself to set up the vote for us.
>
> Yes, currently we depend on that.
>
>>
>>>
>>> Stephan (+CC) mentioned it should be okay like this *shrug*
>>>
>>> For the record, this is the same way I got the values for sc7280[0] and
>>> sm6350[1].
>>>
>>> [0]
>>> https://lore.kernel.org/linux-arm-msm/20231229-sc7280-cryptobam-fixup-v1-1-bd8f68589...@fairphone.com/
>>> [1]
>>> https://lore.kernel.org/linux-arm-msm/20240105-sm6350-qce-v1-0-416e5c731...@fairphone.com/
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> b/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> index b46236235b7f..cd4dd9852d9e 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
>>> @@ -1756,8 +1756,8 @@ cryptobam: dma-controller@1dc4000 {
>>> qcom,controlled-remotely;
>>> iommus = <_smmu 0x594 0x0011>,
>>> <_smmu 0x596 0x0011>;
>>> - /* FIXME: Probing BAM DMA causes some abort and
>>> system hang */
>>> - status = "fail";
>>> + interconnects = <_noc MASTER_CRYPTO 0
>>> _virt SLAVE_EBI1 0>;
>>> + interconnect-names = "memory";
>>> };
>>>
>>> crypto: crypto@1dfa000 {
>>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>>> index 5e7d332731e0..9de28f615639 100644
>>> --- a/drivers/dma/qcom/bam_dma.c
>>> +++ b/drivers/dma/qcom/bam_dma.c
>>> @@ -40,6 +40,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> #include "../dmaengine.h"
>>> @@ -394,6 +395,7 @@ struct bam_device {
>>> const struct reg_offset_data *layout;
>>>
>>> struct clk *bamclk;
>>> + struct icc_path *mem_path;
>>> int irq;
>>>
>>> /* dma start transaction tasklet */
>>> @@ -1206,6 +1208,7 @@ static int bam_init(struct bam_device *bdev)
>>> bdev->num_channels = val & BAM_NUM_PIPES_MASK;
>>> }
>>>
>>> + printk(KERN_ERR "%s:%d DBG num_ees=%u num_channels=%u\n", __func__,
>>> __LINE__, bdev->num_ees, bdev->num_channels);
>>> /* Reset BAM now if fully controlled locally */
>>> if (!bdev->controlled_remotely && !bdev->powered_remotely)
>>> bam_reset(bdev);
>>> @@ -1298,6 +1301,14 @@ static int bam_dma_probe(struct platform_device
>>> *pdev)
>>> return ret;
>>> }
>>>
>>> + bdev->mem_path = devm_of_icc_get(bdev->dev, "memory");
>>> + if (IS_ERR(bdev->mem_path))
>>> + return PTR_ERR(bdev->mem_path);
>>> +
>>> + ret = icc_set_bw(bdev->mem_path, 1, 1);
>>
>> Probably this needs some more sensible value.
>
> So downstream qcedev driver uses 384 for the interconnect. But this is
> crypto-specific and probably different BAMs have different minimum
> requirements?
>
> #define CRYPTO_AVG_BW 384
> #define CRYPTO_PEAK_BW384
> https://github.com/xiaomi-sm8450-kernel/android_kernel_platform_msm-kernel/blob/lineage-20/drivers/crypto/msm/qce.h#L57
>
> Do you have any suggestion what to use here?
I'dve expected this to mean anything, but apparently not.
My immediate guess is that the 384 was the lowest magic value that didn't
result in the bus getting kicked offline.. 1 should be fine upstream due
to commit 91e045b93db7 ("interconnect: qcom: Fix small BW votes being
truncated to zero").
>
> Also I'd assume that with pm_runtime suspended we'd need to clear the
> votes in the driver so we don't keep the interconnect alive
> unnecessarily?
My naive understanding is that the power should only be necessary when
the thing is in use, so early probe and pm-active sounds about sane..
Konrad
Re: [PATCH v2 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
On 26.03.2024 1:11 PM, Stanislav Jakubek wrote: > Add a device tree for the Motorola Moto G (2013) smartphone based > on the Qualcomm MSM8226 SoC. > > Initially supported features: > - Buttons (Volume Down/Up, Power) > - eMMC > - Hall Effect Sensor > - SimpleFB display > - TMP108 temperature sensor > - Vibrator > > Note: the dhob and shob reserved-memory regions are seemingly a part of some > Motorola specific (firmware?) mechanism, see [1]. > > [1] > https://github.com/LineageOS/android_kernel_motorola_msm8226/blob/cm-14.1/Documentation/devicetree/bindings/misc/hob_ram.txt > > Signed-off-by: Stanislav Jakubek > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
On 25.03.2024 9:25 PM, Stanislav Jakubek wrote:
> On Mon, Mar 25, 2024 at 08:28:27PM +0100, Konrad Dybcio wrote:
>> On 24.03.2024 3:04 PM, Stanislav Jakubek wrote:
>>> Add a device tree for the Motorola Moto G (2013) smartphone based
>>> on the Qualcomm MSM8226 SoC.
>>>
>>> Initially supported features:
>>> - Buttons (Volume Down/Up, Power)
>>> - eMMC
>>> - Hall Effect Sensor
>>> - SimpleFB display
>>> - TMP108 temperature sensor
>>> - Vibrator
>>>
>>> Signed-off-by: Stanislav Jakubek
>>> ---
>>
>> [...]
>>
>>> + hob-ram@f50 {
>>> + reg = <0x0f50 0x4>,
>>> + <0x0f54 0x2000>;
>>> + no-map;
>>> + };
>>
>> Any reason it's in two parts? Should it be one contiguous region, or
>> two separate nodes?
>>
>> lgtm otherwise
>
> Hi Konrad, I copied this from downstream as-is.
> According to the downstream docs [1]:
>
> HOB RAM MMAP Device provides ability for userspace to access the
> hand over block memory to read out modem related parameters.
>
> And the two regs are the "DHOB partition" and "SHOB partition".
Oh right, motorola made some inventions here..
>
> I suppose this is something Motorola (firmware?) specific (since the
> downstream compatible is mmi,hob_ram [2]).
> Should I split this into 2 nodes - dhob@f50 and shob@f54?
Yes please and add the downstream txt link to the commit message in case
somebody was curious down the line.
Konrad
Re: [PATCH 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
On 24.03.2024 3:04 PM, Stanislav Jakubek wrote:
> Add a device tree for the Motorola Moto G (2013) smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Initially supported features:
> - Buttons (Volume Down/Up, Power)
> - eMMC
> - Hall Effect Sensor
> - SimpleFB display
> - TMP108 temperature sensor
> - Vibrator
>
> Signed-off-by: Stanislav Jakubek
> ---
[...]
> + hob-ram@f50 {
> + reg = <0x0f50 0x4>,
> + <0x0f54 0x2000>;
> + no-map;
> + };
Any reason it's in two parts? Should it be one contiguous region, or
two separate nodes?
lgtm otherwise
Re: [PATCH 4/5] arm64: dts: qcom: pm7250b: Add a TCPM description
On 22.03.2024 09:01, 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. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/5] arm64: dts: qcom: pm7250b: Add node for PMIC VBUS booster
On 22.03.2024 09:01, Luca Weiss wrote:
> Add the required DTS node for the USB VBUS output regulator, which is
> available on PM7250B. This will provide the VBUS source to connected
> peripherals.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/pm7250b.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> index 3bf7cf5d1700..91a046b3529c 100644
> --- a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
> @@ -45,6 +45,12 @@ pmic@PM7250B_SID {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + pm7250b_vbus: usb-vbus-regulator@1100 {
> + compatible = "qcom,pm7250b-vbus-reg",
> "qcom,pm8150b-vbus-reg";
> + status = "disabled";
> + reg = <0x1100>;
Could you fix the ordering here?
Konrad
Re: [PATCH 2/2] ARM: dts: qcom: msm8974: Add empty chosen node
On 18.03.2024 10:24, Luca Weiss wrote: > Add an empty /chosen node to the dtsi like is common on most other > Qualcomm SoC files, so that various pieces of software expecting this > node to exist don't complain. > > Signed-off-by: Luca Weiss > --- Kinda weird dtc doesn't add it automatically or complain about its absence at this point.. perhaps it could be taught about the latter Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/2] ARM: dts: qcom: msm8974: Add @0 to memory node name
On 18.03.2024 10:24, Luca Weiss wrote:
> Add the @0 from reg to the node name, so that both dtc warning and dt
> validation failure get resolved.
>
> arch/arm/boot/dts/qcom/qcom-msm8974.dtsi:106.9-109.4: Warning
> (unit_address_vs_reg): /memory: node has a reg or ranges property, but no
> unit name
>
> [..]/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dtb: /: memory:
> False schema does not allow {'device_type': ['memory'], 'reg': [[0, 0]]}
> from schema $id: http://devicetree.org/schemas/root-node.yaml#
>
> Signed-off-by: Luca Weiss
> ---
Looks like it's indeed the start of RAM
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH v2 3/3] ARM: dts: qcom: Add Sony Xperia Z3 smartphone
On 14.03.2024 19:56, Luca Weiss wrote:
> Add the dts for the Xperia Z3 smartphone which is based on Sony's
> shinano platform, so at the moment there's little device-specific dts to
> add on top of the common parts.
>
> Signed-off-by: Luca Weiss
> ---
[...]
> +
> + {
> + usb-charge-current-limit = <150>;
> + qcom,fast-charge-safe-current = <300>;
> + qcom,fast-charge-current-limit = <215>;
> + qcom,fast-charge-safe-voltage = <440>;
> + qcom,fast-charge-high-threshold-voltage = <435>;
> + qcom,auto-recharge-threshold-voltage = <428>;
> + qcom,minimum-input-voltage = <420>;
I took a quick look and without going deep into downstream code,
these values look sane, so
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH v2 2/2] ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3
On 14.03.2024 20:00, Luca Weiss wrote: > From: Adam Honse > > Add the devicetree for this "phablet" using the Snapdragon 800 SoC. > > Signed-off-by: Adam Honse > [l...@z3ntu.xyz: clean up, prepare for upstream] > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/2] ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3
On 3/10/24 15:13, Luca Weiss wrote:
From: Adam Honse
Add the devicetree for this "phablet" using the Snapdragon 800 SoC.
Signed-off-by: Adam Honse
[l...@z3ntu.xyz: clean up, prepare for upstream]
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/Makefile| 1 +
.../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts| 403 +
2 files changed, 404 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index 9cc1e14e6cd0..845af12d15a2 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8960-cdp.dtb \
qcom-msm8960-samsung-expressatt.dtb \
qcom-msm8974-lge-nexus5-hammerhead.dtb \
+ qcom-msm8974-samsung-hlte.dtb \
qcom-msm8974-sony-xperia-rhine-amami.dtb \
qcom-msm8974-sony-xperia-rhine-honami.dtb \
qcom-msm8974pro-fairphone-fp2.dtb \
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
new file mode 100644
index ..e03227a49b67
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "qcom-msm8974.dtsi"
+#include "pm8841.dtsi"
+#include "pm8941.dtsi"
+#include
+#include
+#include
+
+/ {
+ model = "Samsung Galaxy Note 3";
+ compatible = "samsung,hlte", "qcom,msm8974";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = _1; /* SDC1 eMMC slot */
+ mmc1 = _3; /* SDC3 SD card slot */
+ serial0 = _uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_keys_pin_a>;
property-n
property-names
+
+ key-home {
+ label = "home_key";
"Home Key" etc.
+
+ pm8941_l20: l20 {
+ regulator-min-microvolt = <295>;
+ regulator-max-microvolt = <295>;
+
+ regulator-allow-set-load;
+ regulator-system-load = <20>;
regulator-min-microvolt = <295>;
regulator-max-microvolt = <295>;
regulator-system-load = <20>;
regulator-allow-set-load;
[...]
Konrad
Re: [PATCH 1/3] ARM: dts: qcom: msm8974-sony-castor: Split into shinano-common
On 3/10/24 12:41, Luca Weiss wrote: In preparation for adding the Sony Xperia Z3 smartphone, split the common parts into shinano-common.dtsi. No functional change intended. Signed-off-by: Luca Weiss --- I give you the green light to also add newlines between subsequent subnodes (e.g. under blsp2_i2c5) while at it ;) Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/3] ARM: dts: qcom: Add Sony Xperia Z3 smartphone
On 3/10/24 12:41, Luca Weiss wrote: Add the dts for the Xperia Z3 smartphone which is based on Sony's shinano platform, so at the moment there's little device-specific dts to add on top of the common parts. Signed-off-by: Luca Weiss --- modulo missing makfile, this looks good
Re: [PATCH v3 2/2] ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 8.0 Wi-Fi
On 19.02.2024 22:43, Bryant Mairs wrote: > Add support for this tablet based on the MSM8226 SoC, codenamed > "milletwifi". > > Acked-by: Linus Walleij > Reviewed-by: Luca Weiss > Signed-off-by: Bryant Mairs > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/5] ARM: dts: qcom: msm8974pro-castor: Clean up formatting
On 3/6/24 00:18, Luca Weiss wrote: Clean up some easy things do prepare the dts for further changes. * Move pinctrl-names below pinctrl-* * Move status as last property * Remove default linux,input-type value Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/5] ARM: dts: qcom: msm8974pro-castor: Remove camera button definitions
On 3/6/24 00:18, Luca Weiss wrote:
From what I can tell, the camera buttons are not part of Z2 Tablet
hardware even though other devices based on 'shinano' do have them.
Fixes: ab80661883de ("ARM: dts: qcom: msm8974: Add Sony Xperia Z2 Tablet")
Signed-off-by: Luca Weiss
---
https://3dmodels.org/360-view/?id=82800
Doesn't look like!
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH] arm64: dts: qcom: sm6350: Add interconnect for MDSS
On 16.02.2024 14:11, Luca Weiss wrote: > Add the definition for the interconnect used in the display subsystem. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v3] ARM: dts: qcom: msm8974: correct qfprom node size
On 10.02.2024 17:45, Luca Weiss wrote:
> From: Craig Tatlor
>
> 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.
>
> [l...@z3ntu.xyz: extract to standalone patch and adjust for review
> comments]
>
> Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and qfprom
> nodes")
> Signed-off-by: Craig Tatlor
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH v2 2/3] ARM: dts: qcom: msm8226: Sort and clean up nodes
On 2/10/24 17:28, Luca Weiss wrote: From: Matti Lehtimäki Quite a few nodes haven't been sorted correctly by reg, so let's do this now so that future nodes can be added at the correct place. Also at the same time, move the status property last. No functional change intended. Signed-off-by: Matti Lehtimäki [luca: add more text to commit message] Acked-by: Konrad Dybcio Signed-off-by: Luca Weiss --- Due to the nature of this change, it's hard to thoroughly review, but nothing screams nuclear breakage, so: Acked-by: Konrad Dybcio Konrad
Re: [PATCH v2 3/3] ARM: dts: qcom: msm8226: Add CPU and SAW/ACC nodes
On 2/10/24 17:28, Luca Weiss wrote: From: Ivaylo Ivanov Add CPU and SAW/ACC nodes to enable SMP on MSM8226. Signed-off-by: Ivaylo Ivanov [luca: update some nodes to fix dtbs_check errors, reorder, cleanup] Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 3/3] pmdomain: qcom: rpmpd: Add MSM8974PRO+PMA8084 power domains
On 2/10/24 17:38, Luca Weiss wrote: Add the power domains CX & GFX found on MSM8974 devices that use PMA8084 instead of the standard PM8841+PM8941 combo. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 2/3] pmdomain: qcom: rpmpd: Add MSM8974+PM8841 power domains
On 2/10/24 17:38, Luca Weiss wrote: Add the power domains CX & GFX found on devices with MSM8974 and PM8841. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/3] pmdomain: qcom: rpmpd: Add MSM8974PRO+PMA8084 power domains
On 2/10/24 15:12, Luca Weiss wrote: Add the power domains CX & GFX found on MSM8974 devices that use PMA8084 instead of the standard PM8841+PM8941 combo. Signed-off-by: Luca Weiss --- Same comment as p2, gfx_ao may not make much sense on this platform Konrad
Re: [PATCH 2/3] pmdomain: qcom: rpmpd: Add MSM8974+PM8841 power domains
On 2/10/24 15:12, Luca Weiss wrote:
Add the power domains CX & GFX found on devices with MSM8974 and PM8841.
Signed-off-by: Luca Weiss
---
[...]
+static struct rpmpd gfx_s4b_corner_ao;
+static struct rpmpd gfx_s4b_corner = {
+ .pd = { .name = "gfx", },
+ .peer = _s4b_corner_ao,
+ .res_type = RPMPD_SMPB,
+ .res_id = 4,
+ .key = KEY_CORNER,
+};
+
+static struct rpmpd gfx_s4b_corner_ao = {
+ .pd = { .name = "gfx_ao", },
+ .peer = _s4b_corner,
+ .active_only = true,
+ .res_type = RPMPD_SMPB,
+ .res_id = 4,
+ .key = KEY_CORNER,
+};
I don't see a s4b_ao downstream.. Though it's very unfortunate we
didn't choose to add power-domain-cells or sth and set the bucket
through that..
Konrad
Re: [PATCH RFC 2/2] arm64: dts: qcom: msm8953: Add GPU
On 27.01.2024 18:32, Luca Weiss wrote:
> On Freitag, 26. Jänner 2024 00:50:43 CET Konrad Dybcio wrote:
>> On 1/25/24 22:56, Luca Weiss wrote:
>>> From: Vladimir Lypak
>>>
>>> Add the GPU node for the Adreno 506 found on this family of SoCs. The
>>> clock speeds are a bit different per SoC variant, SDM450 maxes out at
>>> 600MHz while MSM8953 (= SDM625) goes up to 650MHz and SDM632 goes up to
>>> 725MHz.
>>>
>>> To achieve this, create a new sdm450.dtsi to hold the 600MHz OPP and
>>> use the new dtsi for sdm450-motorola-ali.
>>>
>>> Signed-off-by: Vladimir Lypak
>>> Co-developed-by: Luca Weiss
>>> Signed-off-by: Luca Weiss
>>> ---
>>>
>>> arch/arm64/boot/dts/qcom/msm8953.dtsi| 115
>>> +++
>>> arch/arm64/boot/dts/qcom/sdm450-motorola-ali.dts | 2 +-
>>> arch/arm64/boot/dts/qcom/sdm450.dtsi | 14 +++
>>> arch/arm64/boot/dts/qcom/sdm632.dtsi | 8 ++
>>> 4 files changed, 138 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
>>> b/arch/arm64/boot/dts/qcom/msm8953.dtsi index 91d083871ab0..1fe0c0c4fd15
>>> 100644
>>> --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
>>> @@ -1046,6 +1046,94 @@ mdss_dsi1_phy: phy@1a96400 {
>>>
>>> };
>>>
>>> };
>>>
>>> + gpu: gpu@1c0 {
>>> + compatible = "qcom,adreno-506.0", "qcom,adreno";
>>> + reg = <0x01c0 0x4>;
>>> + reg-names = "kgsl_3d0_reg_memory";
>>> + interrupts = ;
>>> +
>>> + clocks = < GCC_OXILI_GFX3D_CLK>,
>>> +< GCC_OXILI_AHB_CLK>,
>>> +< GCC_BIMC_GFX_CLK>,
>>> +< GCC_BIMC_GPU_CLK>,
>>> +< GCC_OXILI_TIMER_CLK>,
>>> +< GCC_OXILI_AON_CLK>;
>>> + clock-names = "core",
>>> + "iface",
>>> + "mem_iface",
>>> + "alt_mem_iface",
>>> + "rbbmtimer",
>>> + "alwayson";
>>> + power-domains = < OXILI_GX_GDSC>;
>>> +
>>> + iommus = <_iommu 0>;
>>> + operating-points-v2 = <_opp_table>;
>>> +
>>> + #cooling-cells = <2>;
>>> +
>>> + status = "disabled";
>>> +
>>> + zap-shader {
>>> + memory-region = <_shader_region>;
>>> + };
>>> +
>>> + gpu_opp_table: opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-1920 {
>>> + opp-hz = /bits/ 64 <1920>;
>>> + opp-supported-hw = <0xff>;
>>> + required-opps = <_opp_min_svs>;
>>> + };
>>
>> If you remove all OPPs but this one, can the GPU still spit out pixels?
>
> Yep, phosh is starting and is rendering at a few fps.
>
> fairphone-fp3:~$ cat
> /sys/devices/platform/soc@0/1c0.gpu/devfreq/1c0.gpu/min_freq
> 1920
> fairphone-fp3:~$ cat
> /sys/devices/platform/soc@0/1c0.gpu/devfreq/1c0.gpu/max_freq
> 1920
> fairphone-fp3:~$ cat
> /sys/devices/platform/soc@0/1c0.gpu/devfreq/1c0.gpu/cur_freq
> 1920
Interesting..
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH RFC 1/2] arm64: dts: qcom: msm8953: Add GPU IOMMU
On 27.01.2024 18:24, Luca Weiss wrote:
> On Freitag, 26. Jänner 2024 00:49:55 CET Konrad Dybcio wrote:
>> On 1/25/24 23:24, Dmitry Baryshkov wrote:
>>> On 25/01/2024 23:56, Luca Weiss wrote:
>>>> From: Vladimir Lypak
>>>>
>>>> Add the IOMMU used for the GPU on MSM8953.
>>>>
>>>> Signed-off-by: Vladimir Lypak
>>>> ---
>>>> arch/arm64/boot/dts/qcom/msm8953.dtsi | 31
>>>> +++ 1 file changed, 31 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
>>>> b/arch/arm64/boot/dts/qcom/msm8953.dtsi index dcb5c98b793c..91d083871ab0
>>>> 100644
>>>> --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
>>>> @@ -1046,6 +1046,37 @@ mdss_dsi1_phy: phy@1a96400 {
>>>> };
>>>> };
>>>> +gpu_iommu: iommu@1c48000 {
>>>
>>> Nit: most of the platforms use the adreno_smmu label. But maybe the
>>> msm-iommu vs arm-smmu makes difference here.
>> Not really :)
>>
>> Please keep the labels unified
>
> Ack, renaming to adreno_smmu
>
>>
>>> Nevertheless:
>>>
>>> Reviewed-by: Dmitry Baryshkov
>>>
>>>> +compatible = "qcom,msm8953-iommu", "qcom,msm-iommu-v2";
>>>> +ranges = <0 0x01c48000 0x8000>;
>>>> +
>>>> +clocks = < GCC_OXILI_AHB_CLK>,
>>>> + < GCC_BIMC_GFX_CLK>;
>>
>> And align these
>
> They are?
Not in my email client :P, anyway..
>
> Also any comment about the issues listed in the cover letter?
I think v2 on all smmus on this platform is right
Konrad
Re: [PATCH RFC 2/2] arm64: dts: qcom: msm8953: Add GPU
On 1/25/24 22:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the GPU node for the Adreno 506 found on this family of SoCs. The
clock speeds are a bit different per SoC variant, SDM450 maxes out at
600MHz while MSM8953 (= SDM625) goes up to 650MHz and SDM632 goes up to
725MHz.
To achieve this, create a new sdm450.dtsi to hold the 600MHz OPP and
use the new dtsi for sdm450-motorola-ali.
Signed-off-by: Vladimir Lypak
Co-developed-by: Luca Weiss
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8953.dtsi| 115 +++
arch/arm64/boot/dts/qcom/sdm450-motorola-ali.dts | 2 +-
arch/arm64/boot/dts/qcom/sdm450.dtsi | 14 +++
arch/arm64/boot/dts/qcom/sdm632.dtsi | 8 ++
4 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 91d083871ab0..1fe0c0c4fd15 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -1046,6 +1046,94 @@ mdss_dsi1_phy: phy@1a96400 {
};
};
+ gpu: gpu@1c0 {
+ compatible = "qcom,adreno-506.0", "qcom,adreno";
+ reg = <0x01c0 0x4>;
+ reg-names = "kgsl_3d0_reg_memory";
+ interrupts = ;
+
+ clocks = < GCC_OXILI_GFX3D_CLK>,
+< GCC_OXILI_AHB_CLK>,
+< GCC_BIMC_GFX_CLK>,
+< GCC_BIMC_GPU_CLK>,
+< GCC_OXILI_TIMER_CLK>,
+< GCC_OXILI_AON_CLK>;
+ clock-names = "core",
+ "iface",
+ "mem_iface",
+ "alt_mem_iface",
+ "rbbmtimer",
+ "alwayson";
+ power-domains = < OXILI_GX_GDSC>;
+
+ iommus = <_iommu 0>;
+ operating-points-v2 = <_opp_table>;
+
+ #cooling-cells = <2>;
+
+ status = "disabled";
+
+ zap-shader {
+ memory-region = <_shader_region>;
+ };
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-1920 {
+ opp-hz = /bits/ 64 <1920>;
+ opp-supported-hw = <0xff>;
+ required-opps = <_opp_min_svs>;
+ };
If you remove all OPPs but this one, can the GPU still spit out pixels?
Konrad
Re: [PATCH RFC 1/2] arm64: dts: qcom: msm8953: Add GPU IOMMU
On 1/25/24 23:24, Dmitry Baryshkov wrote:
On 25/01/2024 23:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the IOMMU used for the GPU on MSM8953.
Signed-off-by: Vladimir Lypak
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index dcb5c98b793c..91d083871ab0 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -1046,6 +1046,37 @@ mdss_dsi1_phy: phy@1a96400 {
};
};
+ gpu_iommu: iommu@1c48000 {
Nit: most of the platforms use the adreno_smmu label. But maybe the msm-iommu
vs arm-smmu makes difference here.
Not really :)
Please keep the labels unified
Nevertheless:
Reviewed-by: Dmitry Baryshkov
+ compatible = "qcom,msm8953-iommu", "qcom,msm-iommu-v2";
+ ranges = <0 0x01c48000 0x8000>;
+
+ clocks = < GCC_OXILI_AHB_CLK>,
+ < GCC_BIMC_GFX_CLK>;
And align these
Konrad
Re: [PATCH] ARM: dts: qcom: apq8026-lg-lenok: Add vibrator support
On 1/21/24 11:09, 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. Signed-off-by: Luca Weiss --- now your mainlined smartwatch can wake you up! Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH] arm64: dts: qcom: sm6350: Add tsens thermal zones
On 1/24/24 16:31, 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.
Signed-off-by: Luca Weiss
---
[...]
+ cpuss0-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors = < 7>;
cpuss0-thermal and cpuss1-thermal are very likely the sensors for
cluster0/1, can you test that out, perhaps with corepinning+stress?
You can then assign multiple cpu cooling devices.
LGTM otherwise!
Konrad
Re: [PATCH 3/3] arm64: dts: qcom: msm8953: add reset for display subsystem
On 1/23/24 22:03, Luca Weiss wrote: From: Vladimir Lypak With this reset we can avoid situations like IRQ storms from DSI host before it even started probing (because boot-loader left DSI IRQs on). Signed-off-by: Vladimir Lypak Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/3] clk: qcom: gcc-msm8953: add MDSS_BCR reset
On 1/23/24 22:03, Luca Weiss wrote: From: Vladimir Lypak Add an entry in the gcc driver for the MDSS_BCR reset found on MSM8953. Signed-off-by: Vladimir Lypak [luca: expand commit message, move entry] Signed-off-by: Luca Weiss --- I found some more definitions in lk2nd 88:#define GCC_CRYPTO_BCR(CLK_CTL_BASE + 0x16000) 106:#define SDCC1_BCR (CLK_CTL_BASE + 0x42000) /* block reset*/ 125:#define SDCC2_BCR (CLK_CTL_BASE + 0x43000) /* block reset */ 150:#define USB_HS_BCR (CLK_CTL_BASE + 0x41000) 155:#define GCC_QUSB2_PHY_BCR (CLK_CTL_BASE + 0x4103C) 168:#define USB_30_BCR (CLK_CTL_BASE + 0x3F070) 189:#define USB3_PHY_BCR(CLK_CTL_BASE + 0x3F034) 190:#define USB3PHY_PHY_BCR (CLK_CTL_BASE + 0x3F03C) Couldn't find this one though, did you confirm that MDSS goes off when you assert it? Konrad
Re: [PATCH] ARM: dts: qcom: msm8926-htc-memul: Add rmtfs memory node
On 21.01.2024 11:21, 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. > > Signed-off-by: Luca Weiss > --- Could you please test dynamic rmtfs alloc, which should be possible on some (most?) boards after 9265bc6bce6919c771970e5a425a66551a1c78a0? Konrad
Re: [PATCH 2/2] arm64: dts: qcom: sm7225-fairphone-fp4: Add PM6150L thermals
On 1/9/24 12:24, Luca Weiss wrote:
On Tue Jan 9, 2024 at 11:09 AM CET, Konrad Dybcio wrote:
On 1/5/24 15:54, Luca Weiss wrote:
Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0,
RFC_CAM_THERM, CAM_FLASH_THERM and QUIET_THERM thermistors connected to
PM6150L.
Due to hardware constraints we can only register 4 zones with
pm6150l_adc_tm, the other 2 we can register via generic-adc-thermal.
Ugh.. so the ADC can support more inputs than the ADC_TM that was
designed to ship alongside it can?
And that's why the "generic-adc-thermal"-provided zones need to
be polled?
This part of the code from qcom-spmi-adc-tm5.c was trigerring if I
define more than 4 channels, and looking at downstream I can also see
that only 4 zones are registered properly with adc_tm, the rest is
registered with "qcom,adc-tm5-iio" which skips from what I could tell
basically all the HW bits and only registering the thermal zone.
ret = adc_tm5_read(chip, ADC_TM5_NUM_BTM,
_available, sizeof(channels_available));
if (ret) {
dev_err(chip->dev, "read failed for BTM channels\n");
return ret;
}
for (i = 0; i < chip->nchannels; i++) {
if (chip->channels[i].channel >= channels_available) {
dev_err(chip->dev, "Invalid channel %d\n",
chip->channels[i].channel);
return -EINVAL;
}
}
The trip points can really only be considered as placeholders, more
configuration with cooling etc. can be added later.
Signed-off-by: Luca Weiss
---
[...]
I've read the sentence above, but..
+ sdm-skin-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <_therm_sensor>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
I don't fancy burnt fingers for dinner!
With passive trip point it wouldn't even do anything now, but at what
temp do you think it should do what? I'd definitely need more time to
understand more of how the thermal setup works in downstream Android,
and then replicate a sane configuration for mainline with proper
temperatures, cooling, etc.
If "skin therm" means "the temperature of some part of the phone's
body that can be felt with a human hand", then definitely some
throttling should happen at 40ish with heavy throttling at 50
and crit at 55 or so..
We should probably make this a broader topic and keep a single
policy for all supported phones.
+ CC AGdR, may be interested in where this leads
Konrad
Re: [PATCH 1/2] arm64: dts: qcom: sm7225-fairphone-fp4: Add PMK8003 thermals
On 1/5/24 15:54, Luca Weiss wrote:
Configure the thermals for the XO_THERM thermistor connected to the
PMK8003 (which is called PMK8350 in software).
The ADC configuration for PMK8350_ADC7_AMUX_THM1_100K_PU has already
been added in the past.
The trip points can really only be considered as placeholders, more
configuration with cooling etc. can be added later.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 25 +++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
index ade619805519..b7ccfe4011bb 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -112,6 +112,20 @@ active-config0 {
};
};
};
+
+ xo-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
};
};
@@ -490,6 +504,17 @@ conn-therm@1 {
};
};
+_adc_tm {
+ status = "okay";
+
+ xo-therm@0 {
+ reg = <0>;
+ io-channels = <_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
My ocd would rather see the boolean property at the end
anyway
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH] arm64: dts: qcom: sm7225-fairphone-fp4: Switch firmware ext to .mbn
On 1/10/24 16:21, 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. Signed-off-by: Luca Weiss --- Thanks! Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/2] arm64: dts: qcom: sm7225-fairphone-fp4: Add PM6150L thermals
On 1/5/24 15:54, Luca Weiss wrote:
Configure the thermals for the PA_THERM1, MSM_THERM, PA_THERM0,
RFC_CAM_THERM, CAM_FLASH_THERM and QUIET_THERM thermistors connected to
PM6150L.
Due to hardware constraints we can only register 4 zones with
pm6150l_adc_tm, the other 2 we can register via generic-adc-thermal.
Ugh.. so the ADC can support more inputs than the ADC_TM that was
designed to ship alongside it can?
And that's why the "generic-adc-thermal"-provided zones need to
be polled?
The trip points can really only be considered as placeholders, more
configuration with cooling etc. can be added later.
Signed-off-by: Luca Weiss
---
[...]
I've read the sentence above, but..
+ sdm-skin-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <_therm_sensor>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
I don't fancy burnt fingers for dinner!
Konrad
Re: [PATCH RFT] arm64: dts: qcom: sm8350: Reenable crypto & cryptobam
On 8.01.2024 14:49, Luca Weiss wrote: > When num-channels and qcom,num-ees is not provided in devicetree, the > driver will try to read these values from the registers during probe but > this fails if the interconnect is not on and then crashes the system. > > So we can provide these properties in devicetree (queried after patching > BAM driver to enable the necessary interconnect) so we can probe > cryptobam without reading registers and then also use the QCE as > expected. This really feels a bit backwards.. Enable the resource to query the hardware for numbers, so that said resource can be enabled, but slightly later :/ Konrad
Re: [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Add missing reserved-memory
On 29.12.2023 13:53, 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
>
> Fixes: eee9602ad649 ("arm64: dts: qcom: qcm6490: Add device-tree for
> Fairphone 5")
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On 21.12.2023 11:34, Dmitry Baryshkov wrote: > On Thu, 21 Dec 2023 at 09:33, Luca Weiss wrote: >> >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote: >>> On 20.12.2023 11:02, 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. >>>> >>>> If someone thinks it should be qcom,sc7280-pmic-glink, please let me >>>> know :) >>> IMO it's best to continue using the "base soc" (which just so happened >>> to fall onto sc7280 this time around) for all compatibles, unless the >>> derivatives actually had changes >> >> Hi Konrad, >> >> I think at some point I asked Dmitry what he thought and he mentioned >> qcm6490. Even found the message again: >> >>> well, since it is a firmware thing, you might want to emphasise that. >>> So from my POV qcm6490 makes more sense >> >> But yeah since it's likely that sc7280 firmware behaves the same as >> qcm6490 firmware it's probably okay to use sc7280 compatible, worst case >> we change it later :) I'll send a v2 with those changes. > > Worst case we end up with sc7280 which has yet another slightly > different UCSI / PMIC GLINK implementation, but the compatible string > is already taken. > I still suppose that this should be a qcm6490-related string. Right, let's keep qcm then Konrad
Re: [PATCH 0/3] Fairphone 5 PMIC-GLINK support (USB-C, charger, fuel gauge)
On 20.12.2023 11:02, 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. > > If someone thinks it should be qcom,sc7280-pmic-glink, please let me > know :) IMO it's best to continue using the "base soc" (which just so happened to fall onto sc7280 this time around) for all compatibles, unless the derivatives actually had changes as far as firmware goes, I *think* CrOS doesn't even have PMIC_GLINK? There are however WoA 7280 laptops which totally should have it.. Would be nice to hunt some down and see if they report different stuff to what's there on android firmware Konrad
Re: [PATCH v2 2/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree
On 12/14/23 21:59, 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
Signed-off-by: André Apitzsch
---
Excellent, thanks!
Reviewed-by: Konrad Dybcio
[...]
+ pm8226_lvs1: lvs1 {
+ /* Pull-up for I2C lines */
+ regulator-always-on;
+ };
just one q: is this intended to stay a-on, or will it be bound
to some i2c host (presumably camera)?
Konrad
Re: [PATCH 0/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree
On 12/14/23 09:18, André Apitzsch wrote: Am Mittwoch, dem 13.12.2023 um 21:44 +0100 schrieb Konrad Dybcio: On 12/13/23 21:33, André Apitzsch wrote: This dts adds support for Motorola Moto G 4G released in 2013. I have a similar one in my drawer.. not the 4g kind, titan IIRC? Wasn't this one codenamed thea? Konrad Yes, thea is the 2nd generation of Moto G 4G, released in 2014. pregrine is the first generation, from 2013. Should model = "Motorola Moto G 4G"; be updated, to reflect that it is 1st gen or should only "thea" (if it is added at all) have an addition in the model name? I *think* it'd be good to make it "Motorola Moto G 4G (2014)" as I think it's what it was called anyway Konrad
Re: [PATCH 0/2] ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree
On 12/13/23 21:33, André Apitzsch wrote: This dts adds support for Motorola Moto G 4G released in 2013. I have a similar one in my drawer.. not the 4g kind, titan IIRC? Wasn't this one codenamed thea? Konrad
Re: [PATCH v4 2/3] remoteproc: qcom: pas: make region assign more generic
On 11.12.2023 10:37, Neil Armstrong wrote:
> On 09/12/2023 19:06, Konrad Dybcio wrote:
>> On 8.12.2023 16:04, Neil Armstrong wrote:
>>> The current memory region assign only supports a single
>>> memory region.
>>>
>>> But new platforms introduces more regions to make the
>>> memory requirements more flexible for various use cases.
>>> Those new platforms also shares the memory region between the
>>> DSP and HLOS.
>>>
>>> To handle this, make the region assign more generic in order
>>> to support more than a single memory region and also permit
>>> setting the regions permissions as shared.
>>>
>>> Reviewed-by: Mukesh Ojha
>>> Signed-off-by: Neil Armstrong
>>> ---
>> [...]
>>
>>> + for (offset = 0; offset < adsp->region_assign_count; ++offset) {
>>> + struct reserved_mem *rmem = NULL;
>>> +
>>> + node = of_parse_phandle(adsp->dev->of_node, "memory-region",
>>> + adsp->region_assign_idx + offset);
>>> + if (node)
>>> + rmem = of_reserved_mem_lookup(node);
>>> + of_node_put(node);
>> Shouldn't this only be called when parse_phandle succeeds? (separate
>> patch with a fix + cc stable if so?)
>
> It's not a bug, it was added like that because of_node_put() already
> checks for a NULL pointer:
> https://elixir.bootlin.com/linux/v6.7-rc5/source/drivers/of/dynamic.c#L45
Ack
>
>>
>>> + if (!rmem) {
>>> + dev_err(adsp->dev, "unable to resolve shareable memory-region
>>> index %d\n",
>>> + offset);
>>> + return -EINVAL;
>>> + }
>>> - perm.vmid = QCOM_SCM_VMID_MSS_MSA;
>>> - perm.perm = QCOM_SCM_PERM_RW;
>>> + if (adsp->region_assign_shared) {
>>> + perm[0].vmid = QCOM_SCM_VMID_HLOS;
>>> + perm[0].perm = QCOM_SCM_PERM_RW;
>>> + perm[1].vmid = adsp->region_assign_vmid;
>>> + perm[1].perm = QCOM_SCM_PERM_RW;
>>> + perm_size = 2;
>>> + } else {
>>> + perm[0].vmid = adsp->region_assign_vmid;
>>> + perm[0].perm = QCOM_SCM_PERM_RW;
>>> + perm_size = 1;
>>> + }
>>> - adsp->region_assign_phys = rmem->base;
>>> - adsp->region_assign_size = rmem->size;
>>> - adsp->region_assign_perms = BIT(QCOM_SCM_VMID_HLOS);
>>> + adsp->region_assign_phys[offset] = rmem->base;
>>> + adsp->region_assign_size[offset] = rmem->size;
>>> + adsp->region_assign_perms[offset] = BIT(QCOM_SCM_VMID_HLOS);
>>> - ret = qcom_scm_assign_mem(adsp->region_assign_phys,
>>> - adsp->region_assign_size,
>>> - >region_assign_perms,
>> I think this should be renamed to region_assign_owner(s)
>
> Why ? this bitfield is names "perms" everywhere qcom_scm_assign_mem is used
And IMO that's not correct - there's the qcom_scm_vmperm.perm field which
is oneOf r/w/x/rw/rwx and this one is filled with ORed BIT()-ed elements
allowed in qcom_scm_vmperm.vmid (QCOM_SCM_VMID_...)
Konrad
Re: [PATCH v4 2/3] remoteproc: qcom: pas: make region assign more generic
On 8.12.2023 16:04, Neil Armstrong wrote:
> The current memory region assign only supports a single
> memory region.
>
> But new platforms introduces more regions to make the
> memory requirements more flexible for various use cases.
> Those new platforms also shares the memory region between the
> DSP and HLOS.
>
> To handle this, make the region assign more generic in order
> to support more than a single memory region and also permit
> setting the regions permissions as shared.
>
> Reviewed-by: Mukesh Ojha
> Signed-off-by: Neil Armstrong
> ---
[...]
> + for (offset = 0; offset < adsp->region_assign_count; ++offset) {
> + struct reserved_mem *rmem = NULL;
> +
> + node = of_parse_phandle(adsp->dev->of_node, "memory-region",
> + adsp->region_assign_idx + offset);
> + if (node)
> + rmem = of_reserved_mem_lookup(node);
> + of_node_put(node);
Shouldn't this only be called when parse_phandle succeeds? (separate
patch with a fix + cc stable if so?)
> + if (!rmem) {
> + dev_err(adsp->dev, "unable to resolve shareable
> memory-region index %d\n",
> + offset);
> + return -EINVAL;
> + }
>
> - perm.vmid = QCOM_SCM_VMID_MSS_MSA;
> - perm.perm = QCOM_SCM_PERM_RW;
> + if (adsp->region_assign_shared) {
> + perm[0].vmid = QCOM_SCM_VMID_HLOS;
> + perm[0].perm = QCOM_SCM_PERM_RW;
> + perm[1].vmid = adsp->region_assign_vmid;
> + perm[1].perm = QCOM_SCM_PERM_RW;
> + perm_size = 2;
> + } else {
> + perm[0].vmid = adsp->region_assign_vmid;
> + perm[0].perm = QCOM_SCM_PERM_RW;
> + perm_size = 1;
> + }
>
> - adsp->region_assign_phys = rmem->base;
> - adsp->region_assign_size = rmem->size;
> - adsp->region_assign_perms = BIT(QCOM_SCM_VMID_HLOS);
> + adsp->region_assign_phys[offset] = rmem->base;
> + adsp->region_assign_size[offset] = rmem->size;
> + adsp->region_assign_perms[offset] = BIT(QCOM_SCM_VMID_HLOS);
>
> - ret = qcom_scm_assign_mem(adsp->region_assign_phys,
> - adsp->region_assign_size,
> - >region_assign_perms,
I think this should be renamed to region_assign_owner(s)
> - , 1);
> - if (ret < 0) {
> - dev_err(adsp->dev, "assign memory failed\n");
> - return ret;
> + ret = qcom_scm_assign_mem(adsp->region_assign_phys[offset],
> + adsp->region_assign_size[offset],
> + >region_assign_perms[offset],
> + perm, perm_size);
> + if (ret < 0) {
> + dev_err(adsp->dev, "assign memory %d failed\n", offset);
> + return ret;
> + }
> }
>
> return 0;
> @@ -629,20 +653,23 @@ static int adsp_assign_memory_region(struct qcom_adsp
> *adsp)
> static void adsp_unassign_memory_region(struct qcom_adsp *adsp)
> {
> struct qcom_scm_vmperm perm;
> + int offset;
> int ret;
>
> - if (!adsp->region_assign_idx)
> + if (!adsp->region_assign_idx || adsp->region_assign_shared)
So when it's *shared*, we don't want to un-assign it?
Konrad
Re: [PATCH 1/2] ARM: dts: qcom: msm8226: Sort and clean up nodes
On 3.12.2023 23:38, Luca Weiss wrote: > From: Matti Lehtimäki > > Quite a few nodes haven't been sorted correctly by reg, so let's do this > now so that future nodes can be added at the correct place. > > Also at the same time, move the status property last. > > No functional change intended. > > Signed-off-by: Matti Lehtimäki > [luca: add more text to commit message] > Signed-off-by: Luca Weiss > --- Acked-by: Konrad Dybcio Konrad
Re: [PATCH] ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default
On 3.12.2023 15:19, Luca Weiss wrote: > From: Bryant Mairs > > 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. > > Signed-off-by: Bryant Mairs > Signed-off-by: Luca Weiss > --- Acked-by: Konrad Dybcio Konrad
Re: [PATCH] ARM: dts: qcom: apq8026-samsung-matissewifi: Configure touch keys
On 4.12.2023 10:46, 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. > > Signed-off-by: Matti Lehtimäki > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/2] ARM: dts: qcom: msm8226: Add CPU and SAW/ACC nodes
On 3.12.2023 23:38, Luca Weiss wrote: > From: Ivaylo Ivanov > > Add CPU and SAW/ACC nodes to enable SMP on MSM8226. > > Signed-off-by: Ivaylo Ivanov > [luca: update some nodes to fix dtbs_check errors, reorder, cleanup] > Signed-off-by: Luca Weiss > --- Looks like L2 SAW (@ 0xf9012000) is missing.. but then it's present on 8974.. but it's not bound by any driver :) The nodes you added here look correct FWIW Konrad
Re: [PATCH v2 3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Enable usb_1 otg
On 25.11.2023 03:33, Jianhua Lu wrote: > Change dr_mode to otg and set usb_role_swith property to enable switch > usb otg. > > Signed-off-by: Jianhua Lu > --- Guess this should be squashed with p1 but okay.. Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8150b type-c node
On 25.11.2023 03:33, Jianhua Lu wrote: > Add type-c node to feature otg function. > > Signed-off-by: Jianhua Lu > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Fix typos
On 25.11.2023 03:33, Jianhua Lu wrote: > There are two typos in this dtsi, so fix it. > classis -> chassis. > 8070 -> 8060 > > Signed-off-by: Jianhua Lu > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 11/11] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi
On 11/13/23 09:56, Luca Weiss wrote: Now that the WPSS remoteproc is enabled, enable wifi so we can use it. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 10/11] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable various remoteprocs
On 11/13/23 09:56, Luca Weiss wrote: Enable the ADSP, CDSP, MPSS and WPSS that are found on the SoC. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2 09/11] arm64: dts: qcom: sc7280: Add CDSP node
On 11/13/23 09:56, Luca Weiss wrote: Add the node for the ADSP found on the SC7280 SoC, using standard Qualcomm firmware. Remove the reserved-memory node from sc7280-chrome-common since CDSP is currently not used there. Signed-off-by: Luca Weiss --- Acked-by: Konrad Dybcio [...] + interconnects = <_noc MASTER_CDSP_PROC 0 _virt SLAVE_EBI1 0>; QCOM_ICC_TAG_ALWAYS Konrad
Re: [PATCH v2 08/11] arm64: dts: qcom: sc7280: Add ADSP node
On 11/13/23 09:56, Luca Weiss wrote: Add the node for the ADSP found on the SC7280 SoC, using standard Qualcomm firmware. Signed-off-by: Luca Weiss --- Acked-by: Konrad Dybcio Konrad
Re: [PATCH v2 06/11] remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS
On 11/13/23 09:56, Luca Weiss wrote:
Add support for the ADSP, CDSP and WPSS remoteprocs found on the SC7280
SoC using the q6v5-pas driver.
This driver can be used on regular LA ("Linux Android") based releases,
however the SC7280 ChromeOS devices need different driver support due to
firmware differences.
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
Re: [PATCH v2 03/11] arm64: dts: qcom: sc7280: Rename reserved-memory nodes
On 11/13/23 09:56, Luca Weiss wrote: It was clarified a while ago that reserved-memory nodes shouldn't be called memory@ but should have a descriptive name. Update sc7280.dtsi to follow that. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v3 3/4] ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 LTE (SM-T535)
On 25.10.2023 10:37, Stefan Hansson wrote:
> Add a device tree for the Samsung Galaxy Tab 4 10.1 (SM-T535) LTE tablet
> based on the MSM8926 platform.
>
> Signed-off-by: Stefan Hansson
> ---
> arch/arm/boot/dts/qcom/Makefile | 1 +
> .../qcom/qcom-msm8926-samsung-matisselte.dts | 36 +++
> 2 files changed, 37 insertions(+)
> create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8926-samsung-matisselte.dts
>
> diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
> index a3d293e40820..cab35eeb30f6 100644
> --- a/arch/arm/boot/dts/qcom/Makefile
> +++ b/arch/arm/boot/dts/qcom/Makefile
> @@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
> qcom-msm8916-samsung-serranove.dtb \
> qcom-msm8926-microsoft-superman-lte.dtb \
> qcom-msm8926-microsoft-tesla.dtb \
> + qcom-msm8926-samsung-matisselte.dtb \
> qcom-msm8960-cdp.dtb \
> qcom-msm8960-samsung-expressatt.dtb \
> qcom-msm8974-lge-nexus5-hammerhead.dtb \
> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8926-samsung-matisselte.dts
> b/arch/arm/boot/dts/qcom/qcom-msm8926-samsung-matisselte.dts
> new file mode 100644
> index ..6e25b1a74ce5
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8926-samsung-matisselte.dts
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2022, Matti Lehtimäki
> + * Copyright (c) 2023, Stefan Hansson
> + */
> +
> +/dts-v1/;
> +
> +#include "qcom-msm8226-samsung-matisse-common.dtsi"
> +
> +/ {
> + model = "Samsung Galaxy Tab 4 10.1 LTE";
> + compatible = "samsung,matisselte", "qcom,msm8926", "qcom,msm8226";
> + chassis-type = "tablet";
> +};
> +
> +_l3 {
> + regulator-max-microvolt = <135>;
> +};
> +
> +_s4 {
> + regulator-max-microvolt = <220>;
> +};
> +
> +_tsp_3p3v {
> + gpio = < 32 GPIO_ACTIVE_HIGH>;
> +};
> +
> +_2 {
> + /* SD card fails to probe with error -110 */
> + status = "disabled";
Can you give us some logs?
Konrad
Re: [PATCH v3 4/4] ARM: dts: qcom: samsung-matisse-common: Add UART
On 25.10.2023 10:37, Stefan Hansson wrote: > This was not enabled in the matisse-wifi tree. Without this, it is not > possible to use the USB port for serial debugging via a "Carkit debug > cable". > > Signed-off-by: Stefan Hansson > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 9/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi
On 31.10.2023 11:31, Luca Weiss wrote:
> On Mon Oct 30, 2023 at 8:26 PM CET, Konrad Dybcio wrote:
>> On 27.10.2023 16:20, Luca Weiss wrote:
>>> Now that the WPSS remoteproc is enabled, enable wifi so we can use it.
>>>
>>> Signed-off-by: Luca Weiss
>>> ---
>>> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> index d65eef30091b..e7e20f73cbe6 100644
>>> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> @@ -713,3 +713,7 @@ {
>>> firmware-name = "qcom/qcm6490/fairphone5/venus.mbn";
>>> status = "okay";
>>> };
>>> +
>>> + {
>>> + status = "okay";
>> qcom,ath11k-calibration-variant?
>
> What value would I put there for my device? Based on existing usages
> (mostly for ath10k) I'd say "Fairphone_5"?
>
> And you mean I should add this property in dts before even looking into
> the firmware/calibration side of it?
This is basically a "compatible" for the board file, I think Fairphone_5
makes sense here, perhaps Dmitry can confirm
Konrad
Re: [PATCH 9/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi
On 27.10.2023 16:20, Luca Weiss wrote:
> Now that the WPSS remoteproc is enabled, enable wifi so we can use it.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index d65eef30091b..e7e20f73cbe6 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -713,3 +713,7 @@ {
> firmware-name = "qcom/qcm6490/fairphone5/venus.mbn";
> status = "okay";
> };
> +
> + {
> + status = "okay";
qcom,ath11k-calibration-variant?
Konrad
Re: [PATCH 8/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable various remoteprocs
On 27.10.2023 16:20, Luca Weiss wrote:
> Enable the ADSP, CDSP, MPSS and WPSS that are found on the SoC.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index cc092735ce17..d65eef30091b 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -490,6 +490,26 @@ _id_1 {
> status = "okay";
> };
>
> +_adsp {
> + firmware-name = "qcom/qcm6490/fairphone5/adsp.mdt";
> + status = "okay";
> +};
> +
> +_cdsp {
> + firmware-name = "qcom/qcm6490/fairphone5/cdsp.mdt";
> + status = "okay";
> +};
> +
> +_mpss {
> + firmware-name = "qcom/qcm6490/fairphone5/modem.mdt";
> + status = "okay";
> +};
> +
> +_wpss {
> + firmware-name = "qcom/qcm6490/fairphone5/wpss.mdt";
mbn?
Konrad
Re: [PATCH 2/2] arm64: dts: qcom: msm8939-huawei-kiwi: Add initial device tree
On 10/21/23 16:30, Lukas Walter wrote: This dts adds support for Huawei Honor 5X / GR5 (2016) smartphone released in 2015. Add device tree with initial support for: - GPIO keys - Hall sensor - SDHCI (internal and external storage) - WCNSS (BT/WIFI) - Sensors (accelerometer and proximity) - Vibrator - Touchscreen Signed-off-by: Raymond Hackley Signed-off-by: Lukas Walter --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 4/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals
On 10/20/23 13:31, Luca Weiss wrote:
On Wed Oct 18, 2023 at 10:28 PM CEST, Konrad Dybcio wrote:
On 10/14/23 19:52, Luca Weiss wrote:
On Samstag, 14. Oktober 2023 01:13:29 CEST Konrad Dybcio wrote:
On 13.10.2023 10:09, Luca Weiss wrote:
Configure the thermals for the QUIET_THERM, CAM_FLASH_THERM, MSM_THERM
and RFC_CAM_THERM thermistors connected to PM7325.
With this PMIC the software communication to the ADC is going through
PMK7325 (= PMK8350).
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 117
+ 1 file changed, 117 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts index
2c01f799a6b2..d0b1e4e507ff 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -9,6 +9,7 @@
#define PM7250B_SID 8
#define PM7250B_SID1 9
+#include
#include
#include
#include
@@ -137,6 +138,20 @@ afvdd_2p8: regulator-afvdd-2p8 {
};
thermal-zones {
+ camera-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 2>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
are
+ rear-cam-thermal {
+ temperature = <125000>;
you
+ sdm-skin-thermal {
+ temperature = <125000>;
sure
about these temps?
(email from my other address, quicker right now)
Well yes and no.
Yes as in those are the temps specified in downstream dtb.
No as in I'm 99% sure there's user space with definitely lower threshold that
actually does something in response to the temps.
I didn't look too much into this but does the kernel even do something when it
hits one of these trip points? I assume when there's a cooling device thing
specified then it can actually tell the driver to do something, but without
(and most drivers don't support this?) I'm assuming the kernel can't do much
anyways?
So e.g. when the temperature for the flash led is reached I'm assuming
downstream (+Android) either dims the led or turns it off? But I'd have to dig
quite a bit into the thermal setup there to check what it's really doing.
I think reaching "critical" shuts down the platform, unless something
registering the thermal zone explicitly overrides the behavior.
Should probably be easy to test, especially the camera flash thermal
zone heats up *very* quickly when the flash is on, so should be trivial
to set the trip point down from 125degC to e.g. 45degC and see what
happens.
So I did this and... nothing happened.
I watched /sys/class/thermal/thermal_zone34/temp climb above 45degC and
nothing happened.
I guess trip type being "passive" and no cooling-device makes it not do
anything.
==> /sys/class/thermal/thermal_zone34/trip_point_0_hyst <==
1000
==> /sys/class/thermal/thermal_zone34/trip_point_0_temp <==
45000
==> /sys/class/thermal/thermal_zone34/trip_point_0_type <==
passive
From Documentation/devicetree/bindings/thermal/thermal-zones.yaml:
- active # enable active cooling e.g. fans
- passive # enable passive cooling e.g. throttling cpu
- hot # send notification to driver
- critical # send notification to driver, trigger shutdown
So unless we want to just shut down the system (with "critical"), I
don't think thermal can't really do anything else right now, since e.g.
leds-qcom-flash.c driver doesn't have any cooling support to lower the
brightness or turn off the LED.
So.. in essence not much we can do right now.
Yeah.. crashing the phone because the LED is too hot is sorta
suboptimal! Though I mainly had the skin temp in mind..
But seems we also cannot remove this (kinda useless) trip since we need
at least one trip point in the dts if I read the bindings yaml
correctly.
Right
But for now I think it's okay to put this current thermal config into dts and
we'll improve it later when 1. I understand more and 2. maybe some useful
drivers support the cooling bits?
Yeah it's better than nothing, but ultimately we should probably move
the values that userspace daemon operates on here in the dt..
For sure.. I spent a bit of time looking into the proprietary Qualcomm
thermal-daemon sources but didn't really see much interesting things
there for this platform, maybe some of this thermal handling is
somewhere else - or half of these thermal zones aren't even used with
Android.
So.. good to get the current patch upstream or not? :)
Yep, just having the ability to read out thing is always good ;)
Konrad
Re: [PATCH 2/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7250B thermals
On 10/13/23 10:09, Luca Weiss wrote:
Configure the thermals for the CHARGER_SKIN_THERM and USB_CONN_THERM
thermistors connected to PM7250B.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 66 ++
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 2de0b8c26c35..7fe19b556e6a 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -134,6 +134,36 @@ afvdd_2p8: regulator-afvdd-2p8 {
enable-active-high;
vin-supply = <_bob>;
};
+
+ thermal-zones {
+ chg-skin-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
I guess looking at skin-temp-thermal in x13s dts for starters
is a good idea.. we should probably then adjust it to something
more pocketable..
Konrad
Re: [PATCH 4/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals
On 10/14/23 19:52, Luca Weiss wrote:
On Samstag, 14. Oktober 2023 01:13:29 CEST Konrad Dybcio wrote:
On 13.10.2023 10:09, Luca Weiss wrote:
Configure the thermals for the QUIET_THERM, CAM_FLASH_THERM, MSM_THERM
and RFC_CAM_THERM thermistors connected to PM7325.
With this PMIC the software communication to the ADC is going through
PMK7325 (= PMK8350).
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 117
+ 1 file changed, 117 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts index
2c01f799a6b2..d0b1e4e507ff 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -9,6 +9,7 @@
#define PM7250B_SID 8
#define PM7250B_SID1 9
+#include
#include
#include
#include
@@ -137,6 +138,20 @@ afvdd_2p8: regulator-afvdd-2p8 {
};
thermal-zones {
+ camera-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 2>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
are
+ rear-cam-thermal {
+ temperature = <125000>;
you
+ sdm-skin-thermal {
+ temperature = <125000>;
sure
about these temps?
(email from my other address, quicker right now)
Well yes and no.
Yes as in those are the temps specified in downstream dtb.
No as in I'm 99% sure there's user space with definitely lower threshold that
actually does something in response to the temps.
I didn't look too much into this but does the kernel even do something when it
hits one of these trip points? I assume when there's a cooling device thing
specified then it can actually tell the driver to do something, but without
(and most drivers don't support this?) I'm assuming the kernel can't do much
anyways?
So e.g. when the temperature for the flash led is reached I'm assuming
downstream (+Android) either dims the led or turns it off? But I'd have to dig
quite a bit into the thermal setup there to check what it's really doing.
I think reaching "critical" shuts down the platform, unless something
registering the thermal zone explicitly overrides the behavior.
But for now I think it's okay to put this current thermal config into dts and
we'll improve it later when 1. I understand more and 2. maybe some useful
drivers support the cooling bits?
Yeah it's better than nothing, but ultimately we should probably move
the values that userspace daemon operates on here in the dt..
Konrad
Re: [PATCH 2/2] arm64: dts: qcom: msm8939-longcheer-l9100: Enable RGB LED
On 10/13/23 22:51, André Apitzsch wrote: l9100 uses KTD2026 LED driver. Add it to the device tree. Signed-off-by: André Apitzsch --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 1/2] arm64: dts: qcom: msm8916-longcheer-l8910: Enable RGB LED
On 10/13/23 22:51, André Apitzsch wrote: l8910 uses KTD2026 LED driver. Add it to the device tree. Tested-by: Stephan Gerhold Signed-off-by: André Apitzsch --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH] arm64: dts: qcom: msm8939-longcheer-l9100: Add proximity-near-level
On 10/17/23 22:03, André Apitzsch wrote: Am Dienstag, dem 17.10.2023 um 18:25 +0200 schrieb Konrad Dybcio: On 10/16/23 22:18, André Apitzsch wrote: Consider an object near to the sensor when their distance is about 4 cm or below. Signed-off-by: André Apitzsch --- Reviewed-by: Konrad Dybcio Out of interest, what is it set to by default? Konrad The default value is 0. That much I could guess :) I was wondering if it meant more like "it can detect movement from 1km away" or "disabled" Konrad
Re: [PATCH 1/2] arm64: dts: qcom: msm8953: Set initial address for memory
On 10/16/23 09:37, Stephan Gerhold wrote: On Sun, Oct 15, 2023 at 10:26:01PM +0200, Luca Weiss wrote: The dtbs_check really doesn't like having memory without reg set. Address this by setting it to 0x1000 which seems to be the value filled in by the bootloader. Looks like MSM8953 has the same RAM setup as MSM8916, where the base address depends on the amount of RAM you have: <= 2.00 GiB RAM: 0x8000 = 3.00 GiB RAM: 0x4000 = 3.75 GiB RAM: 0x1000 What a royal mess Konrad
Re: [PATCH] arm64: dts: qcom: msm8939-longcheer-l9100: Add proximity-near-level
On 10/16/23 22:18, André Apitzsch wrote: Consider an object near to the sensor when their distance is about 4 cm or below. Signed-off-by: André Apitzsch --- Reviewed-by: Konrad Dybcio Out of interest, what is it set to by default? Konrad
Re: [PATCH 4/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals
On 13.10.2023 10:09, Luca Weiss wrote:
> Configure the thermals for the QUIET_THERM, CAM_FLASH_THERM, MSM_THERM
> and RFC_CAM_THERM thermistors connected to PM7325.
>
> With this PMIC the software communication to the ADC is going through
> PMK7325 (= PMK8350).
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 117
> +
> 1 file changed, 117 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 2c01f799a6b2..d0b1e4e507ff 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -9,6 +9,7 @@
> #define PM7250B_SID 8
> #define PM7250B_SID1 9
>
> +#include
> #include
> #include
> #include
> @@ -137,6 +138,20 @@ afvdd_2p8: regulator-afvdd-2p8 {
> };
>
> thermal-zones {
> + camera-thermal {
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + thermal-sensors = <_adc_tm 2>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
are
> + rear-cam-thermal {
> + temperature = <125000>;
you
> + sdm-skin-thermal {
> + temperature = <125000>;
sure
about these temps?
Konrad
Re: [PATCH 2/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7250B thermals
On 13.10.2023 10:09, Luca Weiss wrote:
> Configure the thermals for the CHARGER_SKIN_THERM and USB_CONN_THERM
> thermistors connected to PM7250B.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 66
> ++
> 1 file changed, 66 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 2de0b8c26c35..7fe19b556e6a 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -134,6 +134,36 @@ afvdd_2p8: regulator-afvdd-2p8 {
> enable-active-high;
> vin-supply = <_bob>;
> };
> +
> + thermal-zones {
> + chg-skin-thermal {
skin
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + thermal-sensors = <_adc_tm 0>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
125
hmm..
Konrad
Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails
On 13.10.2023 15:56, Luca Weiss wrote: > It can be useful to know with which return value the retimer_set call > failed, so include this info in the dev_err print. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/3] ARM: dts: qcom: msm8974: Add watchdog node
On 10/11/23 18:33, Luca Weiss wrote: From: Matti Lehtimäki Add watchdog for MSM8974 platform. Signed-off-by: Matti Lehtimäki Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
