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

[Konrad Dybcio]

On 3/31/26 6:34 PM, Maxim Storetvedt wrote:
> 
> 
> On 3/30/26 12:41, 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?
>>
>>> 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
> 
> Kernel was one shared by me in advance (same I've been using as a
> daily), so it should be OK, but there was an uphill battle in creating
> the modified system image afaik (that would boot).
> 
> Can only speculate until there is another go at this, but could likewise
> be something completely unrelated that's simple to fix, e.g. older mesa
> in image, but final attempt at boot used a dts with gpu node enabled.

FWIW the GPU and display engine are completely disjoint, so mesa itself
shouldn't be an issue (unless something was caught in a restart loop due
to poor error handling.. I've seen that N years ago but have no clue
that would still be a problem nowadays)

Konrad