[RFC PATCH v2 0/6] switch amdgpu_dm_connector to use struct drm_edid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

After finding a null-pointer dereference when running
igt@kms_connector_force_edid (fixed by [1]), I started migrating raw
edid handles in amdgpu connectors to use opaque drm_edid and its
helpers.

However, I'm struggling to remove all drm_edid_raw() occurrences for
different reasons and, with this RFC, I'm looking for suggestions to
overcome them:
1. `dc_link` ops need a copy of edid data and size via `dc_sink`
   (basically, dc_link_add_remote_sink()). I'm unsure what a possible
   approach to clean dc_link helpers should be since it seems part of the
   shared code. Any suggestions?

2. Most of the edid data handled by `dm_helpers_parse_edid_caps()` are
   in drm_edid halpers, but there are still a few that are not managed by
   them yet. For example:
   ```
	edid_caps->serial_number = edid_buf->serial;
	edid_caps->manufacture_week = edid_buf->mfg_week;
	edid_caps->manufacture_year = edid_buf->mfg_year;
   ```
   AFAIU I see the same pending issue in i915/pnpid_get_panel_type() -
   that still uses drm_edid_raw().

My suggestion is to keep the drm_edid_raw() around and verify if there
are no regressions or functional changes after this switch of
amdgpu_dm_connector to struct drm_edid. I added FIXME comments to all
drm_edid_raw occurrences to keep these pending issues on our radar. So
we can continue removing driver-specific code in favor of drm_edid
common code. What do you think?

This is the current status of drm_edid migration in this patchset:
- patch 1-2: remove unused variables found in this process.
- patch 3-4: migration of amdgpu_dm_connector from struct edid to struct
  drm_edid and its helpers.
- patch 5-6: remove duplicated code for parsing vrr caps. WIP: require
  more validation.

Additionally, it needs extensive testing and validation of a large
variety of display caps and I don't have the required setup for it
(perhaps you can test it in your CI to point issues?). I don't see how
to reduce the scope of changes to mitigate the noise/disruption, but any
suggestions are welcome.

Thanks,

Melissa

Melissa Wen (6):
  drm/amd/display: remove unused pixel_clock_mhz from
    amdgpu_dm_connector
  drm/amd/display: clean unused variables for hdmi freesync parser
  drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid
  drm/amd/display: switch to setting physical address directly
  drm/amd/display: always call connector_update when parsing
    freesync_caps
  drm/amd/display: remove redundant freesync parser for DP

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 187 +++++-------------
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   5 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |   8 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  28 +--
 4 files changed, 71 insertions(+), 157 deletions(-)

-- 
2.43.0




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux