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 <[email protected]>

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

Reply via email to