[PATCH v6 3/5] drm: Add support to get EDID from ACPI

Geert Uytterhoeven geert at linux-m68k.org
Wed Apr 17 14:18:10 UTC 2024


Hi Mario,

On Thu, Feb 15, 2024 at 8:04 PM Mario Limonciello
<mario.limonciello at amd.com> wrote:
> On 2/15/2024 12:47, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> >> On 2/14/2024 17:13, Ville Syrjälä wrote:
> >>> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >>>> --- a/include/drm/drm_connector.h
> >>>> +++ b/include/drm/drm_connector.h
> >>>> @@ -1886,6 +1886,12 @@ struct drm_connector {
> >>>>
> >>>>            /** @hdr_sink_metadata: HDR Metadata Information read from sink */
> >>>>            struct hdr_sink_metadata hdr_sink_metadata;
> >>>> +
> >>>> +  /**
> >>>> +   * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> >>>> +   * This is only applicable to eDP and LVDS displays.
> >>>> +   */
> >>>> +  bool acpi_edid_allowed;
> >>>
> >>> Aren't there other bools/small stuff in there for tighter packing?
> >>
> >> Does the compiler automatically do the packing if you put bools nearby
> >> in a struct?  If so; TIL.
> >
> > Yes. Well, depends on the types and their alignment requirements
> > of course, and/or whether you specified __packed or not.
> >
> > You can use 'pahole' to find the holes in structures.
>
> Thanks!  I don't see a __packed attribute on struct drm_connector, but
> I'll put it near by other bools in case that changes in the future.

FTR, don't add __packed unless you have a very good reason to do so.
With __packed, the compiler will emit multiple byte-accesses to
access multi-byte integrals on platforms that do not support unaligned
memory access.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


More information about the amd-gfx mailing list