[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e5cef414-912e-4387-9a47-494567fe2360@oss.qualcomm.com>
Date: Wed, 17 Dec 2025 21:20:09 +0530
From: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>
Cc: konradybcio@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
konrad.dybcio@....qualcomm.com, dmitry.baryshkov@...aro.org,
mukesh.savaliya@....qualcomm.com
Subject: Re: [PATCH 1/1] arm64: dts: qcom: talos: Drop opp-shared from QUP OPP
table
Hi Bjorn and Dmitry,
On 11/24/2025 3:10 PM, Viken Dadhaniya wrote:
>
>
> On 11/21/2025 5:33 PM, Dmitry Baryshkov wrote:
>> On Fri, Nov 21, 2025 at 03:37:21PM +0530, Viken Dadhaniya wrote:
>>>
>>>
>>> On 11/12/2025 1:25 AM, Bjorn Andersson wrote:
>>>> On Tue, Nov 11, 2025 at 10:33:50PM +0530, Viken Dadhaniya wrote:
>>>>> QUP devices are currently marked with opp-shared in their OPP table,
>>>>> causing the kernel to treat them as part of a shared OPP domain. This
>>>>> leads to the qcom_geni_serial driver failing to probe with error
>>>>> -EBUSY (-16).
>>>>>
>>>>> Remove the opp-shared property to ensure the OPP framework treats the
>>>>> QUP OPP table as device-specific, allowing the serial driver to probe
>>>>> successfully
>>>>>
>>>>> Fixes: f6746dc9e379 ("arm64: dts: qcom: qcs615: Add QUPv3 configuration")
>>>>
>>>> This was merged 11 months ago, and Yu Zhang added bluetooth support 3
>>>> months ago. What changed to break the QUP users? I think it's reasonable
>>>> to use this "Fixes", but we should document - at least on the mailing
>>>> list, where the regression happened.
>>>>
>>>> Regards,
>>>> Bjorn
>>>
>>> I’ve checked the older Linux versions and found that this issue started occurring after the following change:
>>> https://lore.kernel.org/linux-devicetree/20250630064338.2487409-1-viken.dadhaniya@oss.qualcomm.com/
>>
>> Hmm, but it's your patch. How was it tested?
>
> For this patch, I had verified only the I²C instance and compared it against other SoCs (like sc7280.dtsi). But missed to validate all other instances from SPI/Serial.
> I realized now and will make sure to test all possible nodes in future changes to avoid such gap.
>
I hope the above information addresses your question.
The current change has been validated for the SPI, Serial, and I2C drivers,
and it is functioning as expected.
Please let us know if you have any further queries.
>>
>>>
>>>>
>>>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/talos.dtsi | 1 -
>>>>> 1 file changed, 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
>>>>> index eb6f69be4a82..ed89d2d509d5 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
>>>>> @@ -536,7 +536,6 @@ cdsp_smp2p_in: slave-kernel {
>>>>>
>>>>> qup_opp_table: opp-table-qup {
>>>>> compatible = "operating-points-v2";
>>>>> - opp-shared;
>>>>>
>>>>> opp-75000000 {
>>>>> opp-hz = /bits/ 64 <75000000>;
>>>>> --
>>>>> 2.34.1
>>>>>
>>
Powered by blists - more mailing lists