Re: [PATCH v2] arm64: dts: qcom: x1e80100-medion-sprchrgd-14-s1: Add PWM backlight

["Sérgio Ferreira" <ferreira@se-rg.io>]

Hi Ettore,

Oct 26, 2026, 18:08 by ettore.chimenti@linaro.org:

> Hi Sérgio,
>
> On Sun Oct 25, 2026 at 8:51 AM CET, Sérgio Ferreira via B4 Relay wrote:
>
>> From: Sérgio Ferreira <>> ferreira@se-rg.io>> >
>>
>> The eDP panel (CSOT MNE007ZA3-2, IPS LCD) cannot have its brightness
>> set over eDP AUX. With no backlight phandle on the panel, panel-edp
>> falls back to the DP AUX backlight, which registers dp_aux_backlight
>> with a maximum brightness of 0, so brightness control has no effect.
>>
>> Brightness is driven by PWM instead. UEFI leaves PM8550 LPG channel 3
>> running and the PWM output configured on PM8550 GPIO 8, and drives
>> PMC8380_3 GPIO 4 high as the backlight enable:
>>
>> pm8550 gpio8 : out low func1 vin-0 no pull push-pull medium
>> pmc8380_3 gpio4 : out  high normal  vin-1 pull-down push-pull medium
>>
>> The panel configuration in the Windows ACPI tables confirmed this.
>> (PMIC-controlled PWM, PMIC 1, bank 3, 9-bit, 2 kHz).
>>
>> Describe this with a pwm-backlight node: enable pm8550_pwm, add pinctrl
>> states for the enable GPIO and for gpio8 func1, and attach the
>> backlight to the panel.
>>
>> Tested on a Medion SPRCHRGD 14 S1 (X1E78100): brightness control over
>> the full range, brightness keys, suspend/resume and restore after
>> reboot.
>>
>> Assisted-by: LLM
>> Signed-off-by: Sérgio Ferreira <>> ferreira@se-rg.io>> >
>> ---
>>
>
> I tested this on a Medion SPRCHRGD 14 S1, but the controls are inverted.
> When increasing the backlight lightness it actually decreases it, and
> vice versa.
>
> ```
> % cat /sys/class/backlight/backlight/max_brightness
> 4095
>
> % echo 1 | sudo tee /sys/class/backlight/backlight/brightness
> 1 # BRIGHT
>
> % echo 2000 | sudo tee /sys/class/backlight/backlight/brightness
> 2000 # LESS BRIGHT
>
> % echo 4095 | sudo tee /sys/class/backlight/backlight/brightness
> 4095 # OFF
>
> % echo 0 | sudo tee /sys/class/backlight/backlight/brightness
> 0 # OFF
> ```
>
> Moreover, I see that from `/sys/kernel/debug/pwm` the period
> request differs from the actual:
>
> ```
> pwm-3   (backlight           ): requested
> requested configuration:  enabled, 498418/500000 ns, normal polarity
> # with brightness set at 4090:
> actual configuration:     enabled, 425834/425834 ns, normal polarity
> # with brightness set at 2:
> 0/425834 ns, normal polarity
> ```
>
> This probably causes the top 250 values to be all at the same
> brightness. Not a big deal probably.
>
> Do you have the same behavior? Can you send the EDID of your panel?
>
> Thanks,
> Ettore
>
thanks for testing.

No, i can not reproduce the value inversion. A brightness of 1 equals very dark while 4095 is maximum brightness. 0 is turning the screen off as expected.

Here is my edid:

```
edid-decode /sys/class/drm/card1-eDP-1/edid
edid-decode (hex):

00 ff ff ff ff ff ff 00 0e 77 31 14 00 00 00 00
00 21 01 04 b5 1e 13 78 03 2f 55 a6 54 4c 9b 24
0d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 17 88 40 a0 b0 08 6e 70 30 20
36 00 2d bc 10 00 00 18 00 00 00 fd 00 1e 78 e6
e6 46 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43
53 4f 54 20 54 33 0a 20 20 20 20 20 00 00 00 fc
00 4d 4e 45 30 30 37 5a 41 33 2d 32 0a 20 01 fc

70 20 79 00 00 22 00 28 bf a1 0a 85 3f 0b 9f 00
2f 00 1f 00 07 07 6d 00 02 00 05 00 b3 40 04 05
3f 0b 9f 00 2f 00 1f 00 07 07 6d 00 02 00 05 00
81 00 07 e6 06 01 01 60 60 28 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 62 90

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.4
  Vendor & Product Identification:
    Manufacturer: CSW
    Model: 5169
    Made in: 2023
  Basic Display Parameters & Features:
    Digital display
    Bits per primary color channel: 10
    DisplayPort interface
    Maximum image size: 30 cm x 19 cm
    Gamma: 2.20
    Supported color formats: RGB 4:4:4
    First detailed timing includes the native pixel format and preferred refresh rate
    Display supports continuous frequencies
  Color Characteristics:
    Red  : 0.6484, 0.3300
    Green: 0.2998, 0.6083
    Blue : 0.1416, 0.0517
    White: 0.3134, 0.3291
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:  2880x1800   60.001033 Hz  16:10   114.602 kHz    348.390000 MHz (301 mm x 188 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol N
                 Vfront    3 Vsync   6 Vback  101 Vpol N
    Display Range Limits:
      Monitor ranges (Range Limits Only): 30-120 Hz V, 230-230 kHz H, max dotclock 700 MHz
    Alphanumeric Data String: 'CSOT T3'
    Display Product Name: 'MNE007ZA3-2'
  Extension blocks: 1
Checksum: 0xfc

----------------

Block 1, DisplayID Extension Block:
  Version: 2.0
  Extension Count: 0
  Display Product Primary Use Case: Same primary use case as the base section
  Video Timing Modes Type 7 - Detailed Timings Data Block:
    DTD:  2880x1800  120.000000 Hz  16:10   229.200 kHz    696.768000 MHz (aspect 16:10, no 3D stereo, preferred)
               Hfront   48 Hsync  32 Hback   80 Hpol N
               Vfront    3 Vsync   6 Vback  101 Vpol N
    DTD:  2880x1800   48.000138 Hz  16:10    91.680 kHz    278.708000 MHz (aspect 16:10, no 3D stereo)
               Hfront   48 Hsync  32 Hback   80 Hpol N
               Vfront    3 Vsync   6 Vback  101 Vpol N
  CTA-861 DisplayID Data Block:
  HDR Static Metadata Data Block:
    Electro optical transfer functions:
      Traditional gamma - SDR luminance range
    Supported static metadata descriptors:
      Static metadata type 1
    Desired content max luminance: 96 (400.000 cd/m^2)
    Desired content max frame-average luminance: 96 (400.000 cd/m^2)
    Desired content min luminance: 40 (0.098 cd/m^2)
  Checksum: 0x62
Checksum: 0x90
```

I can confirm the PWM period value mapping is a bit off for the top-end values, though I haven't noticed that in day-to-day use.

Best,
Sérgio