[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DAZSK2NT6TAT.1N6A4I8ETH92W@fairphone.com>
Date: Mon, 30 Jun 2025 12:21:36 +0200
From: "Luca Weiss" <luca.weiss@...rphone.com>
To: "Konrad Dybcio" <konrad.dybcio@....qualcomm.com>, "Will Deacon"
<will@...nel.org>, "Robin Murphy" <robin.murphy@....com>, "Joerg Roedel"
<joro@...tes.org>, "Rob Herring" <robh@...nel.org>, "Krzysztof Kozlowski"
<krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>, "Rafael J.
Wysocki" <rafael@...nel.org>, "Viresh Kumar" <viresh.kumar@...aro.org>,
"Manivannan Sadhasivam" <mani@...nel.org>, "Herbert Xu"
<herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>,
"Vinod Koul" <vkoul@...nel.org>, "Bjorn Andersson" <andersson@...nel.org>,
"Konrad Dybcio" <konradybcio@...nel.org>, "Robert Marko"
<robimarko@...il.com>, "Das Srinagesh" <quic_gurus@...cinc.com>, "Thomas
Gleixner" <tglx@...utronix.de>, "Jassi Brar" <jassisinghbrar@...il.com>,
"Amit Kucheria" <amitk@...nel.org>, "Thara Gopinath"
<thara.gopinath@...il.com>, "Daniel Lezcano" <daniel.lezcano@...aro.org>,
"Zhang Rui" <rui.zhang@...el.com>, "Lukasz Luba" <lukasz.luba@....com>,
"Ulf Hansson" <ulf.hansson@...aro.org>
Cc: <~postmarketos/upstreaming@...ts.sr.ht>, <phone-devel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-pm@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<linux-crypto@...r.kernel.org>, <dmaengine@...r.kernel.org>,
<linux-mmc@...r.kernel.org>
Subject: Re: [PATCH 14/14] arm64: dts: qcom: Add The Fairphone (Gen. 6)
On Fri Jun 27, 2025 at 5:34 PM CEST, Konrad Dybcio wrote:
> On 6/27/25 4:44 PM, Luca Weiss wrote:
>> On Fri Jun 27, 2025 at 4:34 PM CEST, Konrad Dybcio wrote:
>>> On 6/27/25 1:33 PM, Luca Weiss wrote:
>>>> On Wed Jun 25, 2025 at 4:38 PM CEST, Konrad Dybcio wrote:
>>>>> On 6/25/25 11:23 AM, Luca Weiss wrote:
>>>>>> Add a devicetree for The Fairphone (Gen. 6) smartphone, which is based
>>>>>> on the SM7635 SoC.
>>>>>
>>>>> [...]
>>>>>
>>>>>> +&pm8550vs_d {
>>>>>> + status = "disabled";
>>>>>> +};
>>>>>> +
>>>>>> +&pm8550vs_e {
>>>>>> + status = "disabled";
>>>>>> +};
>>>>>> +
>>>>>> +&pm8550vs_g {
>>>>>> + status = "disabled";
>>>>>> +};
>>>>>
>>>>> Hm... perhaps we should disable these by deafult
>>>>
>>>> Do you want me to do this in this patchset, or we clean this up later at
>>>> some point? I'd prefer not adding even more dependencies to my patch
>>>> collection right now.
>>>
>>> I can totally hear that..
>>>
>>> Let's include it in this patchset, right before SoC addition
>>> I don't think there's any pm8550vs users trying to get merged in
>>> parallel so it should be OK
>>
>> Okay, can do. Disable all of them (_c, _d, _e, _g), and re-enable them
>> in current users? I assume there might also be boards that only have
>> e.g. _d and no _c.
>
> I suppose it's only fair to do so, in line with
>
> d37e2646c8a5 ("arm64: dts: qcom: x1e80100-pmics: Enable all SMB2360 separately")
Sounds good, I've prepared this change for v2.
>
>
>>>>>> +&usb_1 {
>>>>>> + dr_mode = "otg";
>>>>>> +
>>>>>> + /* USB 2.0 only */
>>>>>
>>>>> Because there's no usb3phy description yet, or due to hw design?
>>>>
>>>> HW design. Funnily enough with clk_ignore_unused this property is not
>>>> needed, and USB(2.0) works fine then. Just when (I assume) the USB3
>>>> clock is turned off which the bootloader has enabled, USB stops working.
>>>
>>> The USB controller has two possible clock sources: the PIPE_CLK that
>>> the QMPPHY outputs, or the UTMI clock (qcom,select-utmi-as-pipe-clk).
>>
>> So okay like this for you, for a USB2.0-only HW?
>
> Yeah, maybe change the comment to something like:
>
> /* USB 2.0 only (RX/TX lanes physically not routed) */
>
> to avoid getting this question asked again
Ack
/* USB 2.0 only, HW does not support USB 3.x */
Regards
Luca
>
>>> Because you said there's no USB3, I'm assuming DP-over-Type-C won't
>>> be a thing either? :(
>>
>> Yep. I'd have preferred USB3+DP as well since it's actually quite cool
>> to have with proper Linux. On Android, at least on older versions it's
>> barely usable imo. Can't even properly watch videos on the big screen
>> with that SW stack.
>
> Bummer! Not something we can change though :(
>
> Konrad
Powered by blists - more mailing lists