Re: [PATCH 14/14] arm64: dts: qcom: Add The Fairphone (Gen. 6)

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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.
>>>>
>>>> [...]
>>>>
>>>>> +	/* Dummy panel for simple-framebuffer dimension info */
>>>>> +	panel: panel {
>>>>> +		compatible = "boe,bj631jhm-t71-d900";
>>>>> +		width-mm = <65>;
>>>>> +		height-mm = <146>;
>>>>> +	};
>>>>
>>>> I haven't ran through all the prerequisite-xx-id, but have
>>>> you submitted a binding for this?
>>>
>>> Actually not, kind of forgot about this. I believe I can create a
>>> (mostly?) complete binding for the panel, but this simple description
>>> for only width-mm & height-mm will differ from the final one, which will
>>> have the DSI port, pinctrl, reset-gpios and various supplies.
>>>
>>> I think I'll just drop it from v2 and keep it locally only, to get the
>>> simpledrm scaling right.
>>
>> Yeah I think that'd be best in general
> 
> Ack

[...]

>>>>> +&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")


>>>>> +&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

>> 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