Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 4月, 2019 1 次提交
  3. 12 12月, 2018 4 次提交
  5. 04 10月, 2018 1 次提交
  7. 11 8月, 2018 2 次提交
  9. 25 7月, 2018 2 次提交
  11. 04 5月, 2018 1 次提交
  13. 19 3月, 2018 1 次提交
    • A
      drm/msm: fix building without debugfs · 288e5c88
      由 Arnd Bergmann 提交于 
      The adreno driver stopped building when CONFIG_DEBUGFS is disabled:

drivers/gpu/drm/msm/adreno/adreno_device.c: In function 'adreno_load_gpu':
drivers/gpu/drm/msm/adreno/adreno_device.c:153:16: error: 'const struct msm_gpu_funcs' has no member named 'debugfs_init'
  if (gpu->funcs->debugfs_init) {
                ^~
drivers/gpu/drm/msm/adreno/adreno_device.c:154:13: error: 'const struct msm_gpu_funcs' has no member named 'debugfs_init'
   gpu->funcs->debugfs_init(gpu, dev->primary);
             ^~

This adds an #ifdef around the code that references the hidden
pointer.

Fixes: 331dc0bc ("drm/msm: add a5xx specific debugfs")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      288e5c88
  15. 20 2月, 2018 3 次提交
  17. 10 1月, 2018 4 次提交
  19. 03 1月, 2018 1 次提交
  21. 14 12月, 2017 2 次提交
  23. 28 10月, 2017 1 次提交
    • R
      drm/msm/adreno: load gpu at probe/bind time · eec874ce
      由 Rob Clark 提交于 
      Previously, in an effort to defer initializing the gpu until firmware
was available (ie. rootfs mounted), the gpu was not loaded at when the
subdevice was bound.  Which resulted that clks/etc were requested in a
place that devm couldn't really help unwind if something failed.

Instead move request_firmware() to gpu->hw_init() and construct the gpu
earlier in adreno_bind().  To avoid the rest of the driver needing to
be aware of a gpu that hasn't managed to load firmware and hw_init()
yet, stash the gpu ptr in the adreno device's drvdata, and don't set
priv->gpu() until hw_init() succeeds.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      eec874ce
  25. 16 6月, 2017 2 次提交
    • R
      drm/msm: fix locking inconsistency for gpu->hw_init() · cb1e3818
      由 Rob Clark 提交于 
      Most, but not all, paths where calling the with struct_mutex held.  The
fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run
the first time) was masking this issue.

So lets just always hold struct_mutex for hw_init().  And sprinkle some
WARN_ON()'s and might_lock() to avoid this sort of problem in the
future.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      cb1e3818
    • J
      drm/msm: gpu: Enable zap shader for A5XX · 7c65817e
      由 Jordan Crouse 提交于 
      The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
only render to buffers that are marked as secure and inaccessible
to the kernel and user through a series of hardware protections. In
practice secure mode is used to draw things like a UI on a secure
video frame.

In order to switch out of secure mode the GPU executes a special
shader that clears out the GMEM and other sensitve registers and
then writes a register. Because the kernel can't be trusted the
shader binary is signed and verified and programmed by the
secure world. To do this we need to read the MDT header and the
segments from the firmware location and put them in memory and
present them for approval.

For targets without secure support there is an out: if the
secure world doesn't support secure then there are no hardware
protections and we can freely write the SECVID_TRUST register from
the CPU. We don't have 100% confidence that we can query the
secure capabilities at run time but we have enough calls that
need to go right to give us some confidence that we're at least doing
something useful.

Of course if we guess wrong you trigger a permissions violation
which usually ends up in a system crash but thats a problem
that shows up immediately.

[v2: use child device per Bjorn]
[v3: use generic MDT loader per Bjorn]
[v4: use managed dma functions and ifdefs for the MDT loader]
[v5: Add depends for QCOM_MDT_LOADER]
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
[robclark: fix Kconfig to use select instead of depends + #if IS_ENABLED()]
Signed-off-by: NRob Clark <robdclark@gmail.com>
      7c65817e
  27. 08 4月, 2017 3 次提交
    • J
      drm/msm: gpu: Use OPP tables if we can · e2af8b6b
      由 Jordan Crouse 提交于 
      If a OPP table is defined for the GPU device in the device tree use
that in lieu of the downstream style GPU frequency table. If we do
use the downstream table convert it to a OPP table so that we can
take advantage of the OPP lookup facilities later.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      e2af8b6b
    • J
      drm/msm: Hard code the GPU "slow frequency" · bf5af4ae
      由 Jordan Crouse 提交于 
      Some A3XX and A4XX GPU targets required that the GPU clock be
programmed to a non zero value when it was disabled so
27Mhz was chosen as the "invalid" frequency.

Even though newer targets do not have the same clock restrictions
we still write 27Mhz on clock disable and expect the clock subsystem
to round down to zero.

For unknown reasons even though the slow clock speed is always
27Mhz and it isn't actually a functional level the legacy device tree
frequency tables always defined it and then did gymnastics to work
around it.

Instead of playing the same silly games just hard code the "slow" clock
speed in the code as 27MHz and save ourselves a bit of infrastructure.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      bf5af4ae
    • R
      drm/msm/gpu: use pm-runtime · eeb75474
      由 Rob Clark 提交于 
      We need to use pm-runtime properly when IOMMU is using device_link() to
control it's own clocks.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      eeb75474
  29. 07 2月, 2017 3 次提交
  31. 29 11月, 2016 3 次提交
  33. 24 10月, 2016 1 次提交
  35. 04 3月, 2016 1 次提交
  37. 14 12月, 2015 1 次提交
  39. 12 6月, 2015 2 次提交
    • R
      drm/msm: adreno a306 support · de558cd2
      由 Rob Clark 提交于 
      As found in apq8016 (used in DragonBoard 410c) and msm8916.

Note that numerically a306 is actually 307 (since a305c already claimed
306).  Nice and confusing.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      de558cd2
    • R
      drm/msm: clarify downstream bus scaling · 6490ad47
      由 Rob Clark 提交于 
      A few spots in the driver have support for downstream android
CONFIG_MSM_BUS_SCALING.  This is mainly to simplify backporting the
driver for various devices which do not have sufficient upstream
kernel support.  But the intentionally dead code seems to cause
some confusion.  Rename the #define to make this more clear.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      6490ad47
  41. 17 11月, 2014 1 次提交