linux-kernel - Re: [PATCH v3 8/8] arm64: dts: qcom: Add support for Pixel 3 and Pixel 3 XL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9c91625-a829-474f-9fda-5e39342bb4af@ixit.cz>
Date: Tue, 18 Nov 2025 14:31:11 +0100
From: David Heidelberg <david@...t.cz>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Sumit Semwal <sumit.semwal@...aro.org>,
 Casey Connolly <casey.connolly@...aro.org>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Jessica Zhang <jesszhan0024@...il.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>
Cc: phodina@...tonmail.com, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 phone-devel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 Amit Pundir <amit.pundir@...aro.org>, Casey Connolly <casey@...nolly.tech>,
 Joel Selvaraj <foss@...lselvaraj.com>, Vinod Koul <vkoul@...nel.org>
Subject: Re: [PATCH v3 8/8] arm64: dts: qcom: Add support for Pixel 3 and
 Pixel 3 XL

On 18/11/2025 13:32, Konrad Dybcio wrote:
> On 11/18/25 12:30 PM, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@...t.cz>
>>
>> This adds initial device tree support for the following phones:
>>
>>   - Google Pixel 3 (blueline)
>>   - Google Pixel 3 XL (crosshatch)
>>
>> Both phone boards use the same identifiers and differ only slightly
>> in their connected peripherals.
> 
> [...]
> 
>> +&cont_splash_mem {
>> +	reg = <0 0x9d400000 0 0x02400000>;
>> +};
> 
> You override it to the same value on both devices, keep it in common

Done.

> 
>> +
>> +&framebuffer0 {
>> +	width = <1080>;
>> +	height = <2160>;
>> +	stride = <(1080 * 4)>;
>> +	format = "a8r8g8b8";
> 
> The format is mandated by the UEFI specification and won't change too
> 

Done.

> [...]
> 
>> +&tlmm {
>> +	panel_te_pin: panel-te-state {
>> +		pins = "gpio12";
>> +		function = "mdp_vsync";
>> +		drive-strength = <2>;
>> +		bias-pull-down;
>> +	};
>> +
>> +	panel_reset_pins: panel-active-state {
>> +		pins = "gpio6";
> 
> Pin entries would be best sorted by the GPIO index:
> 
> https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-nodes
> 
> 

Done.

>> +		function = "gpio";
>> +		drive-strength = <8>;
>> +		bias-disable;
>> +	};
>> +
>> +	panel_suspend: panel-suspend-state {
>> +		pins = "gpio6";
>> +		function = "gpio";
>> +		drive-strength = <2>;
>> +		bias-pull-down;
>> +	};
>> +
>> +};
> 
> Stray \n above
> 
> [...]
> 
>> +&adsp_pas {
>> +	firmware-name = "qcom/sdm845/Google/blueline/adsp.mbn";
> 
> Sorry if I asked this before, but are the binaries identical for
> both devices?

Yes, there is only one firmware, which crosshatch has different, but all 
listed in the initial bringup are used for both.

To add, crosshatch was somehow not that popular device, so as I've been 
suggested in u-boot discussion, I would love to keep blueline everywhere.

One exception is LineageOS kernels, where they go by name crosshatch, 
but again for the both phones.

> 
> [...]
> 
> 
>> +		vreg_l14a_1p88: ldo14 {
>> +			regulator-min-microvolt = <1800000>;
>> +			regulator-max-microvolt = <1800000>;
>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>> +			regulator-boot-on;
>> +			/*
>> +			 * We can't properly bring the panel back if it gets turned off
>> +			 * so keep it's regulators always on for now.
>> +			 */
>> +			regulator-always-on;
> 
> Is that still the case with your fixes to the panel driver?
> 
> [...]

Sadly yes, but I think Petr Hodina has idea what needs to be addressed, 
so likely before 6.19 this will get addressed.

> 
>> +
>> +		vreg_l28a_3p0: ldo28 {
>> +			regulator-min-microvolt = <2856000>;
>> +			regulator-max-microvolt = <3008000>;
>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
>> +			regulator-boot-on;
>> +			/*
>> +			 * We can't properly bring the panel back if it gets turned off
>> +			 * so keep it's regulators always on for now.
>> +			 */
>> +			regulator-always-on;
> 
> ditto
> 
> [...]
> 
>> +	regulators-1 {
>> +		compatible = "qcom,pmi8998-rpmh-regulators";
>> +		qcom,pmic-id = "b";
>> +
>> +		vdd-bob-supply = <&vph_pwr>;
>> +
>> +		vreg_bob: bob {
>> +			regulator-min-microvolt = <3312000>;
>> +			regulator-max-microvolt = <3600000>;
> 
> This is a very broad range, what voltage does it need to be?

I think it's possible, I just randomly picked bob regs, and f.e. 
qcs6490-radxa-dragon-q6a.dts has even greater range.

Downstream set it also this way on blueline/crosshatch.

> 
> [...]
> 
> [...]
> 
>> +&tlmm {
>> +	gpio-reserved-ranges = < 0 4>, /* SPI (Intel MNH Pixel Visual Core) */
> 
> stray space before '0'

done

> 
> Konrad

-- 
David Heidelberg