History log of /openbmc/linux/drivers/gpu/drm/msm/adreno/adreno_gpu.h (Results 126 – 150 of 172)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


1234567