Re: [PATCH] drm/panel-edp: Add Sharp SHP 0x15a7 (Surface Pro 12in 1st Ed.)

[Doug Anderson]

Hi,

On Fri, Jul 31, 2026 at 4:53 AM franzelverbier <info@xxxxxxxxxxxxxxxx> wrote:
>
> The internal eDP panel of the Microsoft Surface Pro 12in 1st Edition
> (Snapdragon X Plus, X1P42100) is not in edp_panels[], so every boot
> produces the deliberate WARN_ON splat in panel_edp_probe() and the panel
> falls back to conservative timings:
>
>   WARNING: drivers/gpu/drm/panel/panel-edp.c:814 panel_edp_probe+0x53c/0x56c
>   panel-simple-dp-aux aux-aea0000.displayport-controller:
>       Unknown panel SHP 0x15a7, using conservative timings
>
> The exact model string is not known: the device tree uses the generic
> "edp-panel" compatible and the driver does not expose the EDID it reads,
> so the entry is named "Unknown" as is done for 32 other entries.

No, the EDID should be available somewhere in sysfs or through various
tools. You should include the EDID in the commit message, as is done
for other panels. If we couldn't read the EDID, we wouldn't have known
this was SHP 0x15a7.

Ideally the EDID will have the panel name and we can include it. If
not and we really can't figure out what panel is in there (the laptop
spec sheet doesn't have it?) then we can use "Unknown".


> Timings are deliberately cautious rather than datasheet-derived. The
> conservative fallback sets unprepare=2000 and enable=200; unprepare=2000
> is a safety margin for unknown panels only and is the single occurrence
> of that value in the file -- no real panel entry uses it.
> delay_200_500_e200 keeps the same generous 200 ms enable delay while
> using the 500 ms unprepare shared by every actual panel in the table. A
> shorter enable delay may well be fine, but has not been validated here.

Sure this is fine.

> Signed-off-by: franzelverbier <info@xxxxxxxxxxxxxxxx>

Just to confirm: Is "franzelverbier" the best identity for you?


-Doug