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

[Maxim Storetvedt <mstoretv@cern.ch>]

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.

Cheers,
-Max