Revision tags: v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1 |
|
#
983674e2 |
| 02-Nov-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/gpu: Move gpu_poll_timeout() to adreno_gpu.h The gpu_poll_timeout() function can be useful to multiple targets so mvoe it into adreno_gpu.h from the a5xx code. Signed-of
drm/msm/gpu: Move gpu_poll_timeout() to adreno_gpu.h The gpu_poll_timeout() function can be useful to multiple targets so mvoe it into adreno_gpu.h from the a5xx code. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14 |
|
#
4b565ca5 |
| 06-Aug-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Add A6XX device support Add support for the A6XX family of Adreno GPUs. The biggest addition is the GMU (Graphics Management Unit) which takes over most of the power managem
drm/msm: Add A6XX device support Add support for the A6XX family of Adreno GPUs. The biggest addition is the GMU (Graphics Management Unit) which takes over most of the power management of the GPU itself but in a ironic twist of fate needs a goodly amount of management itself. Add support for the A6XX core code, the GMU and the HFI (hardware firmware interface) queue that the CPU uses to communicate with the GMU. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
2c087a33 |
| 06-Aug-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/adreno: Load the firmware before bringing up the hardware Failure to load firmware is the primary reason to fail adreno_load_gpu(). Try to load it first before going into the har
drm/msm/adreno: Load the firmware before bringing up the hardware Failure to load firmware is the primary reason to fail adreno_load_gpu(). Try to load it first before going into the hardware initialization code and unwinding it. This is important for a6xx because the GMU gets loaded from the runtime power code and it is more costly to fail in that path because of missing firmware. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.17.13, v4.17.12, v4.17.11, v4.17.10 |
|
#
50f8d218 |
| 24-Jul-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/adreno: Add a5xx specific registers for the GPU state HLSQ, SP and TP registers are only accessible from a special aperture and to make matters worse the aperture is blocked from
drm/msm/adreno: Add a5xx specific registers for the GPU state HLSQ, SP and TP registers are only accessible from a special aperture and to make matters worse the aperture is blocked from the CPU on targets that can support secure rendering. Luckily the GPU hardware has its own purpose built register dumper that can access the registers from the aperture. Add a5xx specific code to program the crashdumper and retrieve the wayward registers and dump them for the crash state. Also, remove a block of registers the regular CPU accessible list that aren't useful for debug which helps reduce the size of the crash state file by a goodly amount. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
c0fec7f5 |
| 24-Jul-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/gpu: Capture the GPU state on a GPU hang Capture the GPU state on a GPU hang and store it for later playback via the devcoredump facility. Only one crash state is stored at a
drm/msm/gpu: Capture the GPU state on a GPU hang Capture the GPU state on a GPU hang and store it for later playback via the devcoredump facility. Only one crash state is stored at a time on the assumption that the first hang is usually the most interesting. The existing crash state can be cleared after capturing it and then a new one will be captured on the next hang. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
4f776f45 |
| 24-Jul-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/gpu: Convert the GPU show function to use the GPU state Convert the existing GPU show function to use the GPU state to dump the information rather than reading it directly from t
drm/msm/gpu: Convert the GPU show function to use the GPU state Convert the existing GPU show function to use the GPU state to dump the information rather than reading it directly from the hardware. This will require an additional step to capture the state before dumping it for the existing nodes but it will greatly facilitate reusing the same code for dumping a previously captured state from a GPU hang. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
e00e473d |
| 24-Jul-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/gpu: Capture the state of the GPU Add the infrastructure to capture the current state of the GPU and store it in memory so that it can be dumped later. For now grab the
drm/msm/gpu: Capture the state of the GPU Add the infrastructure to capture the current state of the GPU and store it in memory so that it can be dumped later. For now grab the same basic ringbuffer information and registers that are provided by the debugfs 'gpu' node but obviously this should be extended to capture a much larger set of GPU information. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
64709686 |
| 07-May-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/gpu: Increase the pm runtime autosuspend for 5xx Experimentation shows that resuming power quickly after suspending ends up forcing a system hang for unknown reasons on 5xx targe
drm/msm/gpu: Increase the pm runtime autosuspend for 5xx Experimentation shows that resuming power quickly after suspending ends up forcing a system hang for unknown reasons on 5xx targets. To avoid cycling the power too much (especially during init) turn up the autosuspend time for a5xx to 250ms and use pm_runtime_put_autosuspend() when applicable. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.16 |
|
#
9de43e79 |
| 01-Feb-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/adreno: Use generic function to load firmware to a buffer object Move a5xx specific code to load firmware into a buffer object to the generic Adreno code. This will come in usefu
drm/msm/adreno: Use generic function to load firmware to a buffer object Move a5xx specific code to load firmware into a buffer object to the generic Adreno code. This will come in useful for future targets. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
c5e3548c |
| 01-Feb-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/adreno: Define a list of firmware files to load per target The number and type of firmware files required differs for each target. Instead of using a fixed struct member for each
drm/msm/adreno: Define a list of firmware files to load per target The number and type of firmware files required differs for each target. Instead of using a fixed struct member for each possible firmware file use a generic list of files that should be loaded on boot. Use some semi-target specific enums to help each target find the appropriate firmware(s) that it needs to load. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.15 |
|
#
f306953f |
| 22-Jan-2018 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/adreno: Rename gpmufw to powerfw The power management device on the a5xx cores is known as the GPMU (Graphics Power Management Unit). On a6xx cores the device was expanded an
drm/msm/adreno: Rename gpmufw to powerfw The power management device on the a5xx cores is known as the GPMU (Graphics Power Management Unit). On a6xx cores the device was expanded and renamed as the GMU (Graphics Management Unit). Rename the 'gpmufw' name struct adreno_info as 'powerfw' to avoid confusion. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.13.16 |
|
#
999ae6ed |
| 21-Nov-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/adreno: Move clock parsing to adreno_gpu_init() Move the clock parsing to adreno_gpu_init() to allow for target specific probing and manipulation of the clock tables. Si
drm/msm/adreno: Move clock parsing to adreno_gpu_init() Move the clock parsing to adreno_gpu_init() to allow for target specific probing and manipulation of the clock tables. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
1babd706 |
| 21-Nov-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm/gpu: Remove unused bus scaling code Remove the downstream bus scaling code. It isn't needed for for compatibility with a downstream or vendor kernel. Get it out of the way to
drm/msm/gpu: Remove unused bus scaling code Remove the downstream bus scaling code. It isn't needed for for compatibility with a downstream or vendor kernel. Get it out of the way to clear space for devfreq support. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.14 |
|
#
b1fc2839 |
| 20-Oct-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Implement preemption for A5XX targets Implement preemption for A5XX targets - this allows multiple ringbuffers for different priorities with automatic preemption of a lower
drm/msm: Implement preemption for A5XX targets Implement preemption for A5XX targets - this allows multiple ringbuffers for different priorities with automatic preemption of a lower priority ringbuffer if a higher one is ready. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
f97decac |
| 20-Oct-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Support multiple ringbuffers Add the infrastructure to support the idea of multiple ringbuffers. Assign each ringbuffer an id and use that as an index for the various ring s
drm/msm: Support multiple ringbuffers Add the infrastructure to support the idea of multiple ringbuffers. Assign each ringbuffer an id and use that as an index for the various ring specific operations. The biggest delta is to support legacy fences. Each fence gets its own sequence number but the legacy functions expect to use a unique integer. To handle this we return a unique identifier for each submission but map it to a specific ring/sequence under the covers. Newer users use a dma_fence pointer anyway so they don't care about the actual sequence ID or ring. The actual mechanics for multiple ringbuffers are very target specific so this code just allows for the possibility but still only defines one ringbuffer for each target family. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
cd414f3d |
| 20-Oct-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Move memptrs to msm_gpu When we move to multiple ringbuffers we're going to store the data in the memptrs on a per-ring basis. In order to prepare for that move the current
drm/msm: Move memptrs to msm_gpu When we move to multiple ringbuffers we're going to store the data in the memptrs on a per-ring basis. In order to prepare for that move the current memptrs from the adreno namespace into msm_gpu. This is way cleaner and immediately lets us kill off some sub functions so there is much less cost later when we do move to per-ring structs. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
2c41ef1b |
| 16-Oct-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm/adreno: deal with linux-firmware fw paths When firmware was added to linux-firmware, it was put in a qcom sub- directory, unlike what we'd been using before. For a300_pfp.fw and
drm/msm/adreno: deal with linux-firmware fw paths When firmware was added to linux-firmware, it was put in a qcom sub- directory, unlike what we'd been using before. For a300_pfp.fw and a300_pm4.fw symlinks were created, but we'd prefer not to have to do this in the future. So add support to look in both places when loading firmware. Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
e8f3de96 |
| 16-Oct-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm/adreno: split out helper to load fw Prep work for the next patch. Signed-off-by: Rob Clark <robdclark@gmail.com>
|
Revision tags: v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16 |
|
#
42a105e9 |
| 08-May-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Remove memptrs->wptr memptrs->wptr seems to be unused. Remove it to avoid confusing the upcoming preemption code. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
drm/msm: Remove memptrs->wptr memptrs->wptr seems to be unused. Remove it to avoid confusing the upcoming preemption code. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
7c65817e |
| 17-May-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: gpu: Enable zap shader for A5XX 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
drm/msm: gpu: Enable zap shader for A5XX 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: Jordan Crouse <jcrouse@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> [robclark: fix Kconfig to use select instead of depends + #if IS_ENABLED()] Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2 |
|
#
bf5af4ae |
| 07-Mar-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Hard code the GPU "slow frequency" 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 t
drm/msm: Hard code the GPU "slow frequency" 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: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.10.1, v4.10 |
|
#
4e09b95d |
| 30-Jan-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm: drop quirks binding This was never documented or used in upstream dtb. It is used by downstream bindings from android device kernels. But the quirks are a property of the
drm/msm: drop quirks binding This was never documented or used in upstream dtb. It is used by downstream bindings from android device kernels. But the quirks are a property of the gpu revision, and as such are redundant to be listed separately in dt. Instead, move the quirks to the device table. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net>
show more ...
|
Revision tags: v4.9 |
|
#
2401a008 |
| 28-Nov-2016 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: gpu: Add support for the GPMU Most 5XX targets have GPMU (Graphics Power Management Unit) that handles a lot of the heavy lifting for power management including thermal and
drm/msm: gpu: Add support for the GPMU Most 5XX targets have GPMU (Graphics Power Management Unit) that handles a lot of the heavy lifting for power management including thermal and limits management and dynamic power collapse. While the GPMU itself is optional, it is usually nessesary to hit aggressive power targets. The GPMU firmware needs to be loaded into the GPMU at init time via a shared hardware block of registers. Using the GPU to write the microcode is more efficient than using the CPU so at first load create an indirect buffer that can be executed during subsequent initalization sequences. After loading the GPMU gets initalized through a shared register interface and then we mostly get out of its way and let it do its thing. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
b5f103ab |
| 28-Nov-2016 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: gpu: Add A5XX target support Add support for the A5XX family of Adreno GPUs. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@g
drm/msm: gpu: Add A5XX target support Add support for the A5XX family of Adreno GPUs. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
05b9401b |
| 28-Nov-2016 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: gpu: Add OUT_TYPE4 and OUT_TYPE7 Add helper functions for TYPE4 and TYPE7 ME opcodes that replace TYPE0 and TYPE3 starting with the A5XX targets. Signed-off-by: Jordan
drm/msm: gpu: Add OUT_TYPE4 and OUT_TYPE7 Add helper functions for TYPE4 and TYPE7 ME opcodes that replace TYPE0 and TYPE3 starting with the A5XX targets. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|