Skip to content

L
linux
Switch branch/tag
  1. 11 Sep, 2018 5 commits
  3. 02 Sep, 2018 8 commits
  5. 30 Aug, 2018 2 commits
  7. 29 Aug, 2018 13 commits
  9. 28 Aug, 2018 7 commits
  11. 27 Aug, 2018 5 commits
    • Andrey Grodzovsky's avatar
      drm/amdgpu: Refine gmc9 VM fault print. · 7d0aa376
      Andrey Grodzovsky authored 
      The fault reports the page number where the fault happend and not
the exact faulty address. Update the print message to reflect that.
Signed-off-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      7d0aa376
    • David Francis's avatar
      drm/amd/display: Flatten unnecessary i2c functions · 9bbf6a53
      David Francis authored 
      [Why]
The dce_i2c_hw code contained four funtcions that were only
called in one place and did not have a clearly delineated
purpose.

[How]
Inline these functions, keeping the same functionality.

This is not a functional change.

The functions disable_i2c_hw_engine and release_engine_dce_hw were
pulled into their respective callers.

The most interesting part of this change is the acquire functions.
dce_i2c_hw_engine_acquire_engine was pulled into
dce_i2c_engine_acquire_hw, and dce_i2c_engine_acquire_hw was pulled
into acquire_i2c_hw_engine.

Some notes to show that this change is not functional:
-Failure conditions in any function resulted in a cascade of calls that
ended in a 'return NULL'.
Those are replaced with a direct 'return NULL'.

-The variable result is the one from dce_i2c_hw_engine_acquire_engine.
The boolean result used as part of return logic was removed.

-As the second half of dce_i2c_hw_engine_acquire_engine is only executed
if that function is returning true and therefore exiting the do-while
loop in dce_i2c_engine_acquire_hw, those lines were moved outside
of the loop.
Signed-off-by: default avatarDavid Francis <David.Francis@amd.com>
Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      9bbf6a53
    • Eric Yang's avatar
      drm/amd/display: support 48 MHZ refclk off · ad908423
      Eric Yang authored 
      [Why]
On PCO and up, whenever SMU receive message to indicate active
display count = 0. SMU will turn off 48MHZ TMDP reference clock
by writing to 1 TMDP_48M_Refclk_Driver_PWDN. Once this clock is
off, no PHY register will respond to register access. This means
our current sequence of notifying display count along with requesting
clock will cause driver to hang when accessing PHY registers after
displays count goes to 0.

[How]
Separate the PPSMC_MSG_SetDisplayCount message from the SMU messages
that request clocks, have display own sequencing of this message so
that we can send it at the appropriate time.
Do not redundantly power off HW when entering S3, S4, since display
should already be called to disable all streams. And ASIC soon be
powered down.
Signed-off-by: default avatarEric Yang <Eric.Yang2@amd.com>
Reviewed-by: default avatarTony Cheng <Tony.Cheng@amd.com>
Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      ad908423
    • David Francis's avatar
      drm/amd/display: Remove redundant i2c structs · d377ae4e
      David Francis authored 
      [Why]
The i2c code contains two structs that contain the same
information as i2c_payload

[How]
Replace references to those structs with references to
i2c_payload

dce_i2c_transaction_request->status was written to but never read,
so all references to it are removed
Signed-off-by: default avatarDavid Francis <David.Francis@amd.com>
Reviewed-by: default avatarJordan Lazare <Jordan.Lazare@amd.com>
Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      d377ae4e
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Support reading hw state from debugfs file · 46659a83
      Nicholas Kazlauskas authored 
      [Why]

Logging hardware state can be done by triggering a write to the
debugfs file. It would also be useful to be able to read the hardware
state from the debugfs file to be able to generate a clean log without
timestamps.

[How]

Usage: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log

Threading is an obvious concern when dealing with multiple debugfs
operations and blocking on global state in dm or dc seems unfavorable.

Adding an extra parameter for the debugfs log context state is the
implementation done here. Existing code that made use of DTN_INFO
and its associated macros needed to be refactored to support this.

We don't know the size of the log in advance so it reallocates the
log string dynamically. Once the log has been generated it's copied
into the user supplied buffer for the debugfs. This allows for seeking
support but it's worth nothing that unlike triggering output via
dmesg the hardware state might change in-between reads if your buffer
size is too small.
Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: default avatarJordan Lazare <Jordan.Lazare@amd.com>
Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      46659a83
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7