Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 10月, 2020 1 次提交
  3. 16 9月, 2020 3 次提交
  5. 07 8月, 2020 1 次提交
  7. 05 8月, 2020 3 次提交
  9. 31 7月, 2020 2 次提交
  11. 15 7月, 2020 2 次提交
    • A
      drm/amdgpu/display: create fake mst encoders ahead of time (v4) · 31684701
      由 Alex Deucher 提交于 
      Prevents a warning in the MST create connector case.

v2: create global fake encoders rather per connector fake encoders
to avoid running out of encoder indices.

v3: use the actual number of crtcs on the asic rather than the max
to conserve encoders.

v4: v3 plus missing hunk I forgot to git add.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1108
Fixes: c6385e50 ("drm/amdgpu: drop legacy drm load and unload callbacks")
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.7.x
      31684701
    • N
      drm/amd/display: Allow for vblank enabled with no active planes · 8fe684e9
      由 Nicholas Kazlauskas 提交于 
      [Why]
CRC capture doesn't work when the active plane count is 0 since we
currently tie both vblank and pageflip interrupts to active_plane_count
greater than 0.

[How]
The frontend is what generates the vblank interrupts while the backend
is what generates pageflip interrupts. Both have a requirement for
the CRTC to be active, so control the overall interrupt state based
on that instead.

Pageflip interrupts need to be enabled based on active plane count, but
we actually rely on power gating to take care of disabling the interrupt
for us on pipes that can be power gated.

For pipes that can't be power gated it's still fine to leave it enabled
since the interrupt only triggers after the address has been written
to that particular pipe - which we won't be doing without an active
plane.

The issue we had before with this setup was that we couldn't force
the state back on. We were essentially manipulating the refcount
to enable or disable as needed in a two pass approach.

However, there is a function that solves this problem more elegantly:
amdgpu_irq_update() will unconditionally call the set based on what it
thinks the current enablement state is.

This leaves two future TODO items for our IRQ handling:
- Disabling IRQs in commit tail instead of atomic commit
- Mapping the pageflip interrupt to VUPDATE or something that's tied to
  the frontend instead of the backend since the mapping to CRTC is not
  correct
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      8fe684e9
  13. 11 7月, 2020 1 次提交
  15. 01 7月, 2020 1 次提交
    • C
      drm/amd: correct trivial kernel-doc inconsistencies · 282fd22b
      由 Colton Lewis 提交于 
      Silence documentation warnings by correcting kernel-doc comments.

./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3388: warning: Excess function parameter 'suspend' description in 'amdgpu_device_suspend'
./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3485: warning: Excess function parameter 'resume' description in 'amdgpu_device_resume'
./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:418: warning: Excess function parameter 'tbo' description in 'amdgpu_vram_mgr_del'
./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:418: warning: Excess function parameter 'place' description in 'amdgpu_vram_mgr_del'
./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:279: warning: Excess function parameter 'tbo' description in 'amdgpu_gtt_mgr_del'
./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:279: warning: Excess function parameter 'place' description in 'amdgpu_gtt_mgr_del'
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:332: warning: Function parameter or member 'hdcp_workqueue' not described in 'amdgpu_display_manager'
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:332: warning: Function parameter or member 'cached_dc_state' not described in 'amdgpu_display_manager'
Signed-off-by: NColton Lewis <colton.w.lewis@protonmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      282fd22b
  17. 23 5月, 2020 1 次提交
  19. 23 4月, 2020 1 次提交
  21. 09 4月, 2020 1 次提交
  23. 19 3月, 2020 1 次提交
  25. 12 2月, 2020 1 次提交
  27. 10 1月, 2020 1 次提交
  29. 19 12月, 2019 1 次提交
  31. 14 11月, 2019 4 次提交
    • B
      drm/amd/display: Drop CONFIG_DRM_AMD_DC_DCN2_0 and DSC_SUPPORTED · 1da37801
      由 Bhawanpreet Lakha 提交于 
      [Why]

DCN2 and DSC are stable enough to be build by default. So drop the flags.

[How]

Remove them using the unifdef tool. The following commands were executed
in sequence:

$ find -name '*.c' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DSC_SUPPORT -DCONFIG_DRM_AMD_DC_DCN2_0 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_0 '{}' ';'
$ find -name '*.h' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DSC_SUPPORT -DCONFIG_DRM_AMD_DC_DCN2_0 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_0 '{}' ';'

In addition:

* Remove from kconfig, and replace any dependencies with DCN1_0.
* Remove from any makefiles.
* Fix and cleanup NV defninitions in dal_asic_id.h
* Expand DCN1 ifdef to include DCN2 code in the following files:
    * clk_mgr/clk_mgr.c: dc_clk_mgr_create()
    * core/dc_resources.c: dc_create_resource_pool()
    * dce/dce_dmcu.c: dcn20_*lock_phy()
    * dce/dce_dmcu.c: dcn20_funcs
    * dce/dce_dmcu.c: dcn20_dmcu_create()
    * gpio/hw_factory.c: dal_hw_factory_init()
    * gpio/hw_translate.c: dal_hw_translate_init()
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      1da37801
    • N
      drm/amd/display: Drop CONFIG_DRM_AMD_DC_DMUB guards · 2200eb9e
      由 Nicholas Kazlauskas 提交于 
      [Why]
Support for DMUB only depends on support for DC. It doesn't use floating
point so we don't need to guard it by any specific DCN revision.

[How]
Drop the guards and cleanup the newlines around each one.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      2200eb9e
    • N
      drm/amd/display: Hook up the DMUB service in DM · 743b9786
      由 Nicholas Kazlauskas 提交于 
      [Why]
We need DMCUB on Renoir to support DMCU and PHY initialization.
The DMUB service provides a mechanism to load the DMCUB.

[How]
Include the DMUB service in amdgpu_dm.

Frontdoor loading of the DMCUB firmware needs to happen via PSP. To
pass the firmware to PSP we need to hand it off to the firmware list
in the base driver during software initialization.

Most of the DMUB service can technically be initialized at this point
in time, but we don't want to be allocating framebuffer memory for
hardware that doesn't support the DMCUB and in order to check that we
need to be able to read registers - something DM helpers aren't setup
to do in software initialization.

So everything but the service creation itself will get deferred to
hardware initialization.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      743b9786
    • M
      drm/amd/display: Add MST atomic routines · 3261e013
      由 Mikita Lipski 提交于 
      - Adding encoder atomic check to find vcpi slots for a connector
- Using DRM helper functions to calculate PBN
- Adding connector atomic check to release vcpi slots if connector
loses CRTC
- Calculate  PBN and VCPI slots only once during atomic
check and store them on crtc_state to eliminate
redundant calculation
- Call drm_dp_mst_atomic_check to verify validity of MST topology
during state atomic check

v2: squashed previous 3 separate patches, removed DSC PBN calculation,
and added PBN and VCPI slots properties to amdgpu connector

v3:
- moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
- updates stream's vcpi_slots and pbn on commit
- separated patch from the DSC MST series

v4:
- set vcpi_slots and pbn properties to dm_connector_state
- copy porperties from connector state on to crtc state

v5:
- keep the pbn and vcpi values only on connnector state
- added a void pointer to the stream state instead on two ints,
because dc_stream_state is OS agnostic. Pointer points to the
current dm_connector_state.

v6:
- Remove new param from stream

v7:
- Fix error with using max capable bpc

v8:
- squash in fix from Gustavo A. R. Silva
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      3261e013
  33. 03 10月, 2019 2 次提交
  35. 17 9月, 2019 1 次提交
  37. 07 8月, 2019 1 次提交
  39. 19 7月, 2019 1 次提交
  41. 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
  43. 22 6月, 2019 2 次提交
    • N
      drm/amd/display: Rework CRTC color management · cf020d49
      由 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>
      cf020d49
    • H
      drm/amd/display: Read soc_bounding_box from gpu_info (v2) · 48321c3d
      由 Harry Wentland 提交于 
      [WHY]
We don't want to expose sensitive ASIC information before ASIC release.

[HOW]
Encode the soc_bounding_box in the gpu_info FW (for Linux) and read it
at driver load.

v2: fix warning when CONFIG_DRM_AMD_DC_DCN2_0 is not set (Alex)
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      48321c3d
  45. 21 6月, 2019 1 次提交
  47. 12 6月, 2019 1 次提交
    • 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
  49. 11 6月, 2019 1 次提交
  51. 25 5月, 2019 1 次提交
  53. 30 4月, 2019 1 次提交
    • N
      drm/amd/display: Refactor CRTC interrupt toggling logic · d6ef9b41
      由 Nicholas Kazlauskas 提交于 
      [Why]
The vblank and pageflip interrupts should only be enabled for a CRTC
that's enabled and has active planes.

The current logic takes care of this, but isn't setup to handle the case
where the active plane count goes to zero but the stream remains
enabled.

We currently block this case since we don't allow commits that enable a
CRTC with no active planes, but shouldn't be any reason we can't support
this from a hardware perspective and many userspace applications expect
to be able to do it (like IGT).

[How]
The count_crtc_active_planes function fills in the number of
"active_planes" on the dm_crtc_state. This should be the same as
DC's plane_count on the stream_status but easier to access since we
don't need to lock the private atomic state with the DC context.

Add the "interrupts_enabled" flag to the dm_crtc_state and set it based
on whether the stream exists and if there are active planes on the
stream.

Update the disable and enable logic to make use of this new flag.

There shouldn't be any functional change (yet) with this patch.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      d6ef9b41
  55. 03 4月, 2019 1 次提交
  57. 21 3月, 2019 1 次提交