Disable display on iMacs, as they can't do link training
on the internal display.
(tested on iMac20,1)
Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
---
.../gpu/drm/i915/display/intel_display_device.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
index 1170afaa8680..b1fec1018d7e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.c
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -3,6 +3,7 @@
* Copyright © 2023 Intel Corporation
*/
+#include <linux/dmi.h>
#include <linux/pci.h>
#include <drm/drm_color_mgmt.h>
@@ -1435,7 +1436,18 @@ static bool has_no_display(struct pci_dev *pdev)
{}
};
- return pci_match_id(ids, pdev);
+ static const struct dmi_system_id dmi_ids[] = {
+ {
+ .ident = "Apple Inc. iMac",
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac"),
+ }
+ },
+ {}
+ };
+
+ return pci_match_id(ids, pdev) || dmi_check_system(dmi_ids);
}
#define INTEL_DISPLAY_DEVICE(_id, _desc) { .devid = (_id), .desc = (_desc) }
--
2.43.0
On Wed, Jan 28, 2026 at 02:58:38PM +0000, Atharva Tiwari wrote: > Disable display on iMacs, as they can't do link training > on the internal display. > > (tested on iMac20,1) So with your patch the screen is black on those iMacs? I don't quite understand why that would be desirable. What happens without this patch? Something worse than a black screen? This needs to be explained in the commit message so that reviewers understand why the patch is needed. I also don't understand why this patch follows the EFI set_os one. What's the connection between those two patches? If there is none, they shouldn't be submitted as a series but as two individual patches. Thanks, Lukas
On Wed, 28 Jan 2026, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
> Disable display on iMacs, as they can't do link training
> on the internal display.
I'd expand on that a bit, based on the previous discussion.
>
> (tested on iMac20,1)
>
> Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
I can't test this, but if nobody chimes in to oppose, I'll take it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> ---
> .../gpu/drm/i915/display/intel_display_device.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 1170afaa8680..b1fec1018d7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -3,6 +3,7 @@
> * Copyright © 2023 Intel Corporation
> */
>
> +#include <linux/dmi.h>
> #include <linux/pci.h>
>
> #include <drm/drm_color_mgmt.h>
> @@ -1435,7 +1436,18 @@ static bool has_no_display(struct pci_dev *pdev)
> {}
> };
>
> - return pci_match_id(ids, pdev);
> + static const struct dmi_system_id dmi_ids[] = {
> + {
> + .ident = "Apple Inc. iMac",
> + .matches = {
> + DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMac"),
> + }
> + },
> + {}
> + };
> +
> + return pci_match_id(ids, pdev) || dmi_check_system(dmi_ids);
> }
>
> #define INTEL_DISPLAY_DEVICE(_id, _desc) { .devid = (_id), .desc = (_desc) }
--
Jani Nikula, Intel
On Wed, Jan 28, 2026 at 05:23:51PM +0200, Jani Nikula wrote:
> On Wed, 28 Jan 2026, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
> > Disable display on iMacs, as they can't do link training
> > on the internal display.
>
> I'd expand on that a bit, based on the previous discussion.
>
> >
> > (tested on iMac20,1)
> >
> > Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
>
> I can't test this, but if nobody chimes in to oppose, I'll take it.
I guess the main problem with a hack like this is that you won't
be able to get deep pkgC states due to the display hardware not
going into DC5/6.
But I can't immediately think of other issues due this being an
iGPU, so eg. runtime PCI D3 doesn't really do anything meaningful
and thus the display hardware remaining powered on shouldn't
matter that much (apart from the increased power usage).
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
>
> > ---
> > .../gpu/drm/i915/display/intel_display_device.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
> > index 1170afaa8680..b1fec1018d7e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> > @@ -3,6 +3,7 @@
> > * Copyright © 2023 Intel Corporation
> > */
> >
> > +#include <linux/dmi.h>
> > #include <linux/pci.h>
> >
> > #include <drm/drm_color_mgmt.h>
> > @@ -1435,7 +1436,18 @@ static bool has_no_display(struct pci_dev *pdev)
> > {}
> > };
> >
> > - return pci_match_id(ids, pdev);
> > + static const struct dmi_system_id dmi_ids[] = {
> > + {
> > + .ident = "Apple Inc. iMac",
> > + .matches = {
> > + DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "iMac"),
> > + }
> > + },
> > + {}
> > + };
> > +
> > + return pci_match_id(ids, pdev) || dmi_check_system(dmi_ids);
> > }
> >
> > #define INTEL_DISPLAY_DEVICE(_id, _desc) { .devid = (_id), .desc = (_desc) }
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
On Wed, Jan 28, 2026 at 05:37:18PM +0200, Ville Syrjälä wrote: > On Wed, Jan 28, 2026 at 05:23:51PM +0200, Jani Nikula wrote: > > On Wed, 28 Jan 2026, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote: > > > Disable display on iMacs, as they can't do link training > > > on the internal display. > > > > > > (tested on iMac20,1) > > I guess the main problem with a hack like this is that you won't > be able to get deep pkgC states due to the display hardware not > going into DC5/6. If patch [1/2] in this series results in a power regression, I'd say it needs to be reworked. Either exclude iMacs from the set_os protocol or find a way to power down the iGPU again once the kernel has assumed control. I wonder what macOS does. If the iGPU is exposed by set_os, surely macOS must be able to power down the iGPU again, so we should be doing the same. Thanks, Lukas
© 2016 - 2026 Red Hat, Inc.