Adding override bpc to EDP_PANEL_ENTRY3 quirk.
Signed-off-by: Ajye Huang <ajye_huang@compal.corp-partner.google.com>
---
drivers/gpu/drm/panel/panel-edp.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
index 944c7c70de55..da3e8f223ec3 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -218,6 +218,9 @@ struct edp_panel_entry {
/** @override_edid_mode: Override the mode obtained by edid. */
const struct drm_display_mode *override_edid_mode;
+
+ /** @override_bpc: Override the Bits per color obtained by edid. */
+ unsigned int override_bpc;
};
struct panel_edp {
@@ -586,6 +589,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
bool has_override_edid_mode = p->detected_panel &&
p->detected_panel != ERR_PTR(-EINVAL) &&
p->detected_panel->override_edid_mode;
+ bool has_override_bpc = p->detected_panel &&
+ p->detected_panel != ERR_PTR(-EINVAL) &&
+ p->detected_panel->override_bpc;
/* probe EDID if a DDC bus is available */
if (p->ddc) {
@@ -611,6 +617,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
} else {
num += drm_edid_connector_add_modes(connector);
}
+
+ if (has_override_bpc)
+ connector->display_info.bpc = p->detected_panel->override_bpc;
}
pm_runtime_mark_last_busy(panel->dev);
@@ -1871,6 +1880,17 @@ static const struct panel_delay delay_80_500_e50_d50 = {
.override_edid_mode = _mode \
}
+#define EDP_PANEL_ENTRY3(vend_chr_0, vend_chr_1, vend_chr_2, product_id, _delay, _name, _bpc) \
+{ \
+ .ident = { \
+ .name = _name, \
+ .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1, vend_chr_2, \
+ product_id), \
+ }, \
+ .delay = _delay, \
+ .override_bpc = _bpc \
+}
+
/*
* This table is used to figure out power sequencing delays for panels that
* are detected by EDID. Entries here may point to entries in the
--
2.25.1
On Wed, 29 Oct 2025, Ajye Huang <ajye_huang@compal.corp-partner.google.com> wrote:
> Adding override bpc to EDP_PANEL_ENTRY3 quirk.
>
> Signed-off-by: Ajye Huang <ajye_huang@compal.corp-partner.google.com>
> ---
> drivers/gpu/drm/panel/panel-edp.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> index 944c7c70de55..da3e8f223ec3 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -218,6 +218,9 @@ struct edp_panel_entry {
>
> /** @override_edid_mode: Override the mode obtained by edid. */
> const struct drm_display_mode *override_edid_mode;
> +
> + /** @override_bpc: Override the Bits per color obtained by edid. */
> + unsigned int override_bpc;
> };
>
> struct panel_edp {
> @@ -586,6 +589,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> bool has_override_edid_mode = p->detected_panel &&
> p->detected_panel != ERR_PTR(-EINVAL) &&
> p->detected_panel->override_edid_mode;
Unrelated to the patch at hand, since the pattern is there already, but
something like this should be more reliable:
bool has_override_edid_mode = !IS_ERR_OR_NULL(p->detected_panel) &&
p->detected_panel->override_edid_mode;
It does not look like p->detected_panel could have other error pointer
values than -EINVAL, but it looks awkward to check for NULL and one
error pointer value, and then go on to dereference it.
I guess even better would be to always use either NULL *or* error
pointers, not a mix, but I digress.
BR,
Jani.
> + bool has_override_bpc = p->detected_panel &&
> + p->detected_panel != ERR_PTR(-EINVAL) &&
> + p->detected_panel->override_bpc;
>
> /* probe EDID if a DDC bus is available */
> if (p->ddc) {
> @@ -611,6 +617,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> } else {
> num += drm_edid_connector_add_modes(connector);
> }
> +
> + if (has_override_bpc)
> + connector->display_info.bpc = p->detected_panel->override_bpc;
> }
>
> pm_runtime_mark_last_busy(panel->dev);
> @@ -1871,6 +1880,17 @@ static const struct panel_delay delay_80_500_e50_d50 = {
> .override_edid_mode = _mode \
> }
>
> +#define EDP_PANEL_ENTRY3(vend_chr_0, vend_chr_1, vend_chr_2, product_id, _delay, _name, _bpc) \
> +{ \
> + .ident = { \
> + .name = _name, \
> + .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1, vend_chr_2, \
> + product_id), \
> + }, \
> + .delay = _delay, \
> + .override_bpc = _bpc \
> +}
> +
> /*
> * This table is used to figure out power sequencing delays for panels that
> * are detected by EDID. Entries here may point to entries in the
--
Jani Nikula, Intel
Hi,
On Thu, Oct 30, 2025 at 2:44 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Wed, 29 Oct 2025, Ajye Huang <ajye_huang@compal.corp-partner.google.com> wrote:
> > Adding override bpc to EDP_PANEL_ENTRY3 quirk.
> >
> > Signed-off-by: Ajye Huang <ajye_huang@compal.corp-partner.google.com>
> > ---
> > drivers/gpu/drm/panel/panel-edp.c | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> > index 944c7c70de55..da3e8f223ec3 100644
> > --- a/drivers/gpu/drm/panel/panel-edp.c
> > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > @@ -218,6 +218,9 @@ struct edp_panel_entry {
> >
> > /** @override_edid_mode: Override the mode obtained by edid. */
> > const struct drm_display_mode *override_edid_mode;
> > +
> > + /** @override_bpc: Override the Bits per color obtained by edid. */
> > + unsigned int override_bpc;
> > };
> >
> > struct panel_edp {
> > @@ -586,6 +589,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> > bool has_override_edid_mode = p->detected_panel &&
> > p->detected_panel != ERR_PTR(-EINVAL) &&
> > p->detected_panel->override_edid_mode;
>
> Unrelated to the patch at hand, since the pattern is there already, but
> something like this should be more reliable:
>
> bool has_override_edid_mode = !IS_ERR_OR_NULL(p->detected_panel) &&
> p->detected_panel->override_edid_mode;
>
> It does not look like p->detected_panel could have other error pointer
> values than -EINVAL, but it looks awkward to check for NULL and one
> error pointer value, and then go on to dereference it.
>
> I guess even better would be to always use either NULL *or* error
> pointers, not a mix, but I digress.
Yeah, that makes sense. If someone wants to send a patch cleaning this
up, I'd be happy to review it! :-)
-Doug
Hi, On Wed, Oct 29, 2025 at 1:11 AM Ajye Huang <ajye_huang@compal.corp-partner.google.com> wrote: > > Adding override bpc to EDP_PANEL_ENTRY3 quirk. > > Signed-off-by: Ajye Huang <ajye_huang@compal.corp-partner.google.com> > --- > drivers/gpu/drm/panel/panel-edp.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) This seems OK to me. I'd be OK with: Reviewed-by: Douglas Anderson <dianders@chromium.org> I think you could alternatively add a EDID_QUIRK_FORCE_6BPC quirk for this panel in "drivers/gpu/drm/drm_edid.c", though I haven't tested it. That _might_ be a better solution? Maybe Jani or someone else CCed would have an opinion. At first I was thinking that the quirks in "drm_edid.c" were probably just for "DP" display, but then I just realized that they probably also are for "eDP" panels. Specifically I think Intel hardware doesn't use panel-edp.c so I think the only place quirks could get applied (if an eDP panel was also used on Intel hardware) was from "drm_edid.c". Any chance you could confirm if EDID_QUIRK_FORCE_6BPC works for you? Does anyone else CCed have an opinion of which they like better? -Doug
On Wed, 29 Oct 2025, Doug Anderson <dianders@chromium.org> wrote: > At first I was thinking that the quirks in "drm_edid.c" were probably > just for "DP" display, but then I just realized that they probably > also are for "eDP" panels. Specifically I think Intel hardware doesn't > use panel-edp.c so I think the only place quirks could get applied (if > an eDP panel was also used on Intel hardware) was from "drm_edid.c". > > Any chance you could confirm if EDID_QUIRK_FORCE_6BPC works for you? > > Does anyone else CCed have an opinion of which they like better? No strong opinions, but obviously having it in drm_edid.c would be more generic. Until you encounter panels where you need to force something other than 6 bpc, when it stops being generic and becomes an obstacle. ;) BR, Jani. -- Jani Nikula, Intel
Hi Doug,
On Thu, Oct 30, 2025 at 7:21 AM Doug Anderson <dianders@chromium.org> wrote:
> At first I was thinking that the quirks in "drm_edid.c" were probably
> just for "DP" display, but then I just realized that they probably
> also are for "eDP" panels. Specifically I think Intel hardware doesn't
> use panel-edp.c so I think the only place quirks could get applied (if
> an eDP panel was also used on Intel hardware) was from "drm_edid.c".
>
> Any chance you could confirm if EDID_QUIRK_FORCE_6BPC works for you?
The following quirks added in drm_edid.c is workable,
+ /* Sharp LQ116M1JW10 reports 8 bpc and it will display noise,
but display noiseless as 6 bpc */
+ EDID_QUIRK('S', 'H', 'P', 0x154c, EDID_QUIRK_FORCE_6BPC),
I will send upstream a new patch for modifying the drm_edid.c , thank
you so much
© 2016 - 2025 Red Hat, Inc.