Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 8月, 2019 1 次提交
  3. 12 7月, 2019 1 次提交
    • N
      drm/amd/display: Add drm_audio_component support to amdgpu_dm · 6ce8f316
      由 Nicholas Kazlauskas 提交于 
      [Why]
The drm_audio_component can be used to give pin ELD notifications
directly to the sound driver. This fixes audio endpoints disappearing
due to missing unsolicited notifications.

[How]
Send the notification via the audio component whenever we enable or
disable audio state on a stream. This matches what i915 does with
their drm_audio_component and what Takashi Iwai's proposed hack for
radeon/amdpgu did.

This is a bit delayed in when the notification actually occurs, however.
We wait until after all the programming is complete rather than sending
the notification mid sequence.

Particular care is needed for the get ELD callback since it can happen
outside the locking and fencing DRM does for atomic commits.

Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6ce8f316
  5. 03 7月, 2019 1 次提交
  7. 26 6月, 2019 1 次提交
  9. 22 6月, 2019 6 次提交
  11. 21 6月, 2019 3 次提交
  13. 14 6月, 2019 2 次提交
    • S
      drm/amdgpu: Fix connector atomic_check compilation fail · 51e857af
      由 Sean Paul 提交于 
      I missed amdgpu in my connnector_helper_funcs->atomic_check conversion,
which is understandably causing compilation failures.

Fixes: 6f3b6278 ("drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state")
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [for rcar lvds]
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Karol Herbst <karolherbst@gmail.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614002713.141340-1-sean@poorly.run
      51e857af
    • G
      amdgpu_dm: no need to check return value of debugfs_create functions · 4be8be78
      由 Greg Kroah-Hartman 提交于 
      When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: David Francis <David.Francis@amd.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Cc: Anthony Koo <Anthony.Koo@amd.com>
Cc: hersen wu <hersenxs.wu@amd.com>
Cc: "Leo (Hanghong) Ma" <hanghong.ma@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      4be8be78
  15. 12 6月, 2019 6 次提交
    • N
      drm/amd/display: Rework CRTC color management · 7cd4b700
      由 Nicholas Kazlauskas 提交于 
      [Why]
To prepare for the upcoming DRM plane color management properties
we need to correct a lot of wrong behavior and assumptions made for
CRTC color management.

The documentation added by this commit in amdgpu_dm_color explains
how the HW color pipeline works and its limitations with the DRM
interface.

The current implementation does the following wrong:
- Implicit sRGB DGM when no CRTC DGM is set
- Implicit sRGB RGM when no CRTC RGM is set
- No way to specify a non-linear DGM matrix that produces correct output
- No way to specify a correct RGM when a linear DGM is used

We had workarounds for passing kms_color tests but not all of the
behavior we had wrong was covered by these tests (especially when
it comes to non-linear DGM). Testing both DGM and RGM at the same time
isn't something kms_color tests well either.

[How]
The specifics for how color management works in AMDGPU and the new
behavior can be found by reading the documentation added to
amdgpu_dm_color.c from this patch.

All of the incorrect cases from the old implementation have been
addressed for the atomic interface, but there still a few TODOs for
the legacy one.

Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI.

The result looks correct from visual inspection but the CRC no longer
matches. For reference, the test was previously doing the following:

linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ...

Now the test is doing:

linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ...
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      7cd4b700
    • N
      drm/amd/display: Set default ABM level to module parameter · c3e50f89
      由 Nicholas Kazlauskas 提交于 
      [Why]
The module parameter to specify the default ABM level is now defined,
so hook it up in DM.

[How]
On connector reset specify the default level. DC will program this as
part of the modeset since it gets passed onto the stream in
dm_update_crtc_state.

It's only set for eDP connectors, but it doesn't matter if this is
specified for connectors or hardware that doesn't support ABM.

It's DC's responsibility to check that ABM can be set or adjusted, and
DC does check that the DMCU firmware is running and if there's backlight
control available.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <david.francis@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      c3e50f89
    • N
      drm/amd/display: Enable fast plane updates when state->allow_modeset = true · 37fb6e8a
      由 Nicholas Kazlauskas 提交于 
      [Why]
Whenever the a modeset is allowed (but not neccessarily required) we
currently recreate all the planes in the state. Most IGT tests and
legacy IOCTLs create atomic commits with this flag set, so the pipes
are often unnecessarily reprogrammed.

Poor performance and stuttering can occur when many of these commits
are frequently issued.

This flag was needed when the appropriate conditions for checking
whether the planes needed a reset were not in place, but
should_reset_plane should cover everything needed now.

[How]
Drop the check for state->allow_modeset in should_reset_plane.

All planes on a CRTC should reset in the following conditions:
- The CRTC needs a modeset
- The CRTC degamma changes
- Planes are added or removed to the CRTC

These conditions are all covered in should_reset_plane.

We still can't drop the format change check in should_reset_plane since
fill_dc_plane_info_and_addr isn't called when validating the state, so
we can't tell if a FULL update is needed or not.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <david.francis@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      37fb6e8a
    • N
      drm/amd/display: Use current connector state if NULL when checking bpc · 01933ba4
      由 Nicholas Kazlauskas 提交于 
      [Why]
The old logic for checking which output depth to use relied on using
the current connector state rather than the new proposed state. This
was a problem when performing atomic commits since we weren't verifying
it against the incoming max_requested_bpc.

But switching this to only use the new state and not the current state
breaks filtering modes - it'll always assume that the maximum bpc
supported by the display is in use, which will cause certain modes
like 1440p@144Hz to be filtered even when using 8bpc.

[How]
Still use the connector->state if we aren't passed an explicit state.
This will respect the max_bpc the user currently has when filtering
modes.

Also remember to reset the default max_requested_bpc to 8 whenever
connector reset is called to retain old behavior when using the new
property.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110845Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      01933ba4
    • N
      drm/amd/display: Always allocate initial connector state state · f04bee34
      由 Nicholas Kazlauskas 提交于 
      [Why]
Unlike our regular connectors, MST connectors don't start off with
an initial connector state. This causes a NULL pointer dereference to
occur when attaching the bpc property since it tries to modify the
connector state.

We need an initial connector state on the connector to avoid the crash.

[How]
Use our reset helper to allocate an initial state and reset the values
to their defaults. We were already doing this before, just not for
MST connectors.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f04bee34
    • N
      drm/amd/display: Don't set mode_changed=false if the stream was removed · 7e930949
      由 Nicholas Kazlauskas 提交于 
      [Why]
When switching from vt to desktop with EDID emulation we can receive
an atomic commit such that we have a crtc where mode_changed = true.

During the dm_update_crtc_state disable pass we remove the stream from
the context and free it on the dm_new_crtc_state.

During the enable pass we compare the new provisional stream to the
dm_old_crtc_state->stream and determine that the stream is unchanged
and no scaling has been changed.

Following this, new_crtc_state->mode_changed is then set to false.
The connectors haven't changed and the CRTC active state hasn't changed
so drm_atomic_crtc_needs_modeset returns false, so we jump to
skip_modeset and we hit:

BUG_ON(dm_new_crtc_state->stream == NULL);

...since the old stream is gone from the context and the new stream is
also still NULL.

[How]
Ensure that we still a stream to reuse before checking if we can reuse
the old stream without a full modeset.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      7e930949
  17. 11 6月, 2019 1 次提交
  19. 06 6月, 2019 1 次提交
  21. 04 6月, 2019 1 次提交
  23. 03 6月, 2019 2 次提交
  25. 31 5月, 2019 4 次提交
  27. 29 5月, 2019 1 次提交
  29. 25 5月, 2019 6 次提交
  31. 24 5月, 2019 2 次提交
  33. 21 5月, 2019 1 次提交