Re: [PATCH v6 3/3] arm64: dts: qcom: Add Samsung Galaxy Book4 Edge DTS/DTSI

[Dmitry Baryshkov]

On Mon, Mar 30, 2026 at 12:41:57PM +0200, Konrad Dybcio wrote:
> On 3/26/26 7:30 PM, Maxim Storetvedt wrote:
> > 
> > 
> > On 3/26/26 12:33, Konrad Dybcio wrote:
> >> On 3/25/26 7:30 PM, Maxim Storetvedt wrote:
> >>>
> >>>
> >>> On 3/23/26 13:17, Konrad Dybcio wrote:
> >>>> On 3/22/26 5:03 PM, Maxim Storetvedt wrote:
> >>>>> Adds devicetrees for the 14-inch and 16-inch SKUs of the Samsung Galaxy Book4 Edge.
> >>>>>
> >>>>> These use a common dtsi derived from nodes that were able to work on Linux
> >>>>> from the initial Galaxy Book4 Edge DTS by Marcus:
> >>>>>
> >>>>> Link: https://lore.kernel.org/all/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
> >>>>>
> >>>>> combined with the ongoing patch for the Honor Magicbook Art 14, and its downstream by
> >>>>> Valentin Manea, which shares device similarities:
> >>>>
> >>>> [...]
> >>>>
> >>>>> +&i2c8 {
> >>>>> +	clock-frequency = <400000>;
> >>>>> +
> >>>>> +	status = "okay";
> >>>>> +
> >>>>> +	touchscreen@5d {
> >>>>> +		compatible = "hid-over-i2c";
> >>>>> +		reg = <0x5d>;
> >>>>> +
> >>>>> +		hid-descr-addr = <0x1>;
> >>>>> +		interrupts-extended = <&tlmm 34 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +
> >>>>> +		vdd-supply = <&vreg_misc_3p3>;
> >>>>> +		/* Lower power supply is not enoug to work. */
> >>>>> +		// vddl-supply = <&vreg_l15b_1p8>;
> >>>>
> >>>> How should we interpret that?
> >>>>
> >>>
> >>> This was in the original patch, but using that same regulator appears to
> >>> be enough to also get touchscreen working on the 16" book4e. That said,
> >>> it still does not work on the 14". Something to revisit later...
> >>>
> >>>>
> >>>> [...]
> >>>>
> >>>>> +&panel {
> >>>>> +	compatible = "samsung,atna40cu07", "samsung,atna33xc20";
> >>>>
> >>>> I think it'd make sense to move the compatible from 'common' to the
> >>>> 16in DTS then too
> >>>>
> >>>>> +	enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
> >>>>
> >>>> this matches the common definition
> >>>>
> >>>>> +	power-supply = <&vreg_edp_3p3>;
> >>>>
> >>>> ditto
> >>>>
> >>>>> +	no-hpd;
> >>>>
> >>>> really??
> >>>>
> >>> One less thing to debug while previously attempting to work around the
> >>> "illegal link rate" error, which turned out to be related to eDP 1.4
> >>> (similar to the sp11). I've kept it as-is in case other SKUs attempt
> >>> booting from this dts, such as the x1e80100 16" (as it might be getting
> >>> a black screen using the current x1e84100 16" dts, though this is not
> >>> fully tested).
> >>
> >> So do the 80100 and 84100-equipped SKUs of the laptop come with different
> >> displays?
> >>
> >> Konrad
> > 
> > So far assumed both 16" variants to be fairly similar, though one
> > valiant 16" 80100 user over in the debug thread did try to boot via the
> > 84100 dts, with no success. Instead having the screen go dark after the
> > first post-tux kernel prints.
> 
> Does switching to the generic edp-panel compatible (which will parse the
> EDID and try not to be overly smart about it) help here?

I think it was not possible because those panels need special treatment.

> 
> > This was strapped together via WSL though, so could be there was
> > something else at fault, but strange it didn't at least fall back to a
> > visible initramfs shell.
> 
> You mean the kernel had been compiled via WSL? That shouldn't be a problem..
> 
> Konrad

-- 
With best wishes
Dmitry