Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 7月, 2018 2 次提交
  3. 16 6月, 2018 14 次提交
  5. 15 6月, 2018 11 次提交
  7. 14 6月, 2018 13 次提交
    • C
      nvme: remove nvme_reinit_tagset · 14dfa400
      由 Christoph Hellwig 提交于 
      Unused now that all transports stopped using it.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NJens Axboe <axboe@kernel.dk>
      14dfa400
    • J
      nvme-fc: fix nulling of queue data on reconnect · 3e493c00
      由 James Smart 提交于 
      The reconnect path is calling the init routines to clear a queue
structure. But the queue structure has state that perhaps needs
to persist as long as the controller is live.

Remove the nvme_fc_init_queue() calls on reconnect.
The nvme_fc_free_queue() calls will clear state bits and reset
any relevant queue state for a new connection.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      3e493c00
    • J
      nvme-fc: remove reinit_request routine · 587331f7
      由 James Smart 提交于 
      The reinit_request routine is not necessary. Remove support for the
op callback.

As all that nvme_reinit_tagset() does is itterate and call the
reinit routine, it too has no purpose. Remove the call.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      587331f7
    • K
      drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2) · 5c16f36f
      由 Kenneth Feng 提交于 
      Fix the issue that SCLK&MCLK can't be set higher than dpm7 when
OD is enabled in SMU7.

v2: fix warning (Alex)
Signed-off-by: NKenneth Feng <kenneth.feng@amd.com>
Acked-by: Rex Zhu<rezhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      5c16f36f
    • J
      nvme-fc: change controllers first connect to use reconnect path · 4c984154
      由 James Smart 提交于 
      Current code follows the framework that has been in the transports
from the beginning where initial link-side controller connect occurs
as part of "creating the controller". Thus that first connect fully
talks to the controller and obtains values that can then be used in
for blk-mq setup, etc. It also means that everything about the
controller is fully know before the "create controller" call returns.

This has several weaknesses:
- The initial create_ctrl call made by the cli will block for a long
  time as wire transactions are performed synchronously. This delay
  becomes longer if errors occur or connectivity is lost and retries
  need to be performed.
- Code wise, it means there is a separate connect path for initial
  controller connect vs the (same) steps used in the reconnect path.
- And as there's separate paths, it means there's separate error
  handling and retry logic. It also plays havoc with the NEW state
  (should transition out of it after successful initial connect) vs
  the RESETTING and CONNECTING (reconnect) states that want to be
  transitioned to on error.
- As there's separate paths, to recover from errors and disruptions,
  it requires separate recovery/retry paths as well and can severely
  convolute the controller state.

This patch reworks the fc transport to use the same connect paths
for the initial connection as it uses for reconnect. This makes a
single path for error recovery and handling.

This patch:
- Removes the driving of the initial connect and replaces it with
  a state transition to CONNECTING and initiating the reconnect
  thread. A dummy state transition of RESETTING had to be traversed
  as a direct transtion of NEW->CONNECTING is not allowed. Given
  that the controller is "new", the RESETTING transition is a simple
  no-op. Once in the reconnecting thread, the normal behaviors of
  ctrl_loss_tmo (max_retries * connect_delay) and dev_loss_tmo will
  apply before the controller is torn down.
- Only if the state transitions couldn't be traversed and the
  reconnect thread not scheduled, will the controller be torn down
  while in create_ctrl.
- The prior code used the controller state of NEW to indicate
  whether request queues had been initialized or not. For the admin
  queue, the request queue is always created, so there's no need to
  check a state. For IO queues, change to tracking whether a successful
  io request queue create has occurred (e.g. 1st successful connect).
- The initial controller id is initialized to the dynamic controller
  id used in the initial connect message. It will be overwritten by
  the real controller id once the controller is connected on the wire.
Signed-off-by: NJames Smart <james.smart@broadcom.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      4c984154
    • E
      drm/amd/powerplay: remove uncessary extra gfxoff control call · 333c8d3e
      由 Evan Quan 提交于 
      Gfxoff is already enabled in amdgpu_device_ip_set_powergating_state.
So, no need to enable it again in pp_late_init.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      333c8d3e
    • E
      drm/amdgpu: fix parsing indirect register list v2 · cb5ed37f
      由 Evan Quan 提交于 
      WARN_ON possible buffer overflow and avoid unnecessary dereference.

v2: change BUG_ON to WARN_ON
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      cb5ed37f
    • S
      drm/amd/include: Update df 3.6 mask and shift definition · b0f6b809
      由 Shaoyun Liu 提交于 
      The register field hsas been changed in df 3.6, update to correct setting
Signed-off-by: NShaoyun Liu <Shaoyun.Liu@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      b0f6b809
    • R
      drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cards · f8a5de44
      由 Rex Zhu 提交于 
      As hw required, soc clock must large than mclk, So we set max soc
clock to OD Max Memory clk.
But on workstation, vbios do not support OD feature, the OD max memory
clock is equal to 0. In this case, driver can support underclocking.
and set od max memory clock to the value in highest memory dpm level.
So the od max memory clock should be less than highest soc clock.
and driver should not change the soc clock.

caused by commit ca57b9b0a156
("drm/amd/pp: Allow underclocking when od table is empty in vbios")
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f8a5de44
    • P
      drm/amd/display: Fix stale buffer object (bo) use · 4b3c641b
      由 Pratik Vishwakarma 提交于 
      Fixes stale buffer object (bo) usage for cursor plane

Cursor plane's bo operations are handled in DC code.
Currently, atomic_commit() does not handle bo operations
for cursor plane, as a result the bo assigned for cursor
plane in dm_plane_helper_prepare_fb() is not coherent
with the updates to the same made in dc code.This mismatch
leads to "bo" corruption and hence crashes during S3 entry.

This patch cleans up the code which was added as a hack
for 4.9 version only.
Reviewed-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: NPratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      4b3c641b
    • C
      drm/amd/pp: initialize result to before or'ing in data · c4ff91dd
      由 Colin Ian King 提交于 
      The current use of result is or'ing in values and checking for
a non-zero result, however, result is not initialized to zero
so it potentially contains garbage to start with. Fix this by
initializing it to the first return from the call to
vega10_program_didt_config_registers.

Detected by cppcheck:
"(error) Uninitialized variable: result"

Fixes: 9b7b8154 ("drm/amd/powerplay: added didt support for vega10")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
[Fix the subject as Colin's comment]
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      c4ff91dd
    • E
      drm/amd/powerplay: fix wrong clock adjust sequence · c3dade5e
      由 Evan Quan 提交于 
      The clocks should be adjusted after display configuration changed.
Otherwise, the socclk and memclk may be forced on an unnecessary higher
level.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      c3dade5e
    • L
      drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail() · 97028037
      由 Lyude Paul 提交于 
      So, unfortunately I recently made the discovery that in the upstream
kernel, the only reason that amdgpu is not currently suffering from
issues with runtime PM putting the GPU into suspend while it's driving
displays is due to the fact that on most prime systems, we have sound
devices associated with the GPU that hold their own runtime PM ref for
the GPU.

What this means however, is that in the event that there isn't any kind
of sound device active (which can easily be reproduced by building a
kernel with sound drivers disabled), the GPU will fall asleep even when
there's displays active. This appears to be in part due to the fact that
amdgpu has not actually ever relied on it's rpm_idle() function to be
the only thing keeping it running, and normally grabs it's own power
references whenever there are displays active (as can be seen with the
original pre-DC codepath in amdgpu_display_crtc_set_config() in
amdgpu_display.c). This means it's very likely that this bug was
introduced during the switch over the DC.

So to fix this, we start grabbing runtime PM references every time we
enable a previously disabled CRTC in atomic_commit_tail(). This appears
to be the correct solution, as it matches up with what i915 does in
i915/intel_runtime_pm.c.

The one sideaffect of this is that we ignore the variable that the
pre-DC code used to use for tracking when it needed runtime PM refs,
adev->have_disp_power_ref. This is mainly because there's no way for a
driver to tell whether or not all of it's CRTCs are enabled or disabled
when we've begun committing an atomic state, as there may be CRTC
commits happening in parallel that aren't contained within the atomic
state being committed. So, it's safer to just get/put a reference for
each CRTC being enabled or disabled in the new atomic state.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Acked-by: Christian König <christian.koenig@amd.com>.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      97028037