Commit Graph

10 Commits

Author SHA1 Message Date
Rob Clark
de558cd2ae drm/msm: adreno a306 support
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: Rob Clark <robdclark@gmail.com>
2015-06-11 13:11:01 -04:00
Rob Clark
6490ad4740 drm/msm: clarify downstream bus scaling
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: Rob Clark <robdclark@gmail.com>
2015-06-11 13:11:01 -04:00
Rob Clark
e2550b7a7d drm/msm/adreno: move decision about what gpu to to load
Move this into into adreno_device, and decide based on gpu revision
rather than just assuming a3xx.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-09-10 11:19:08 -04:00
Rob Clark
bfd28b1362 drm/msm/adreno: split adreno device out into it's own file
We'd rather not duplicate these parts as support for additional gpu
generations is added.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-09-10 11:19:08 -04:00
Rob Clark
70c70f091b drm/msm: add perf logging debugfs
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-06-02 07:36:21 -04:00
Rob Clark
37d77c3ab5 drm/msm: crank down gpu when inactive
Shut down the clks when the gpu has nothing to do.  A short inactivity
timer is used to provide a low pass filter for power transitions.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-03-31 10:27:46 -04:00
Rob Clark
871d812aa4 drm/msm: add support for non-IOMMU systems
Add a VRAM carveout that is used for systems which do not have an IOMMU.

The VRAM carveout uses CMA.  The arch code must setup a CMA pool for the
device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not
cool).  The user can configure the VRAM pool size using msm.vram module
param.

Technically, the abstraction of IOMMU behind msm_mmu is not strictly
needed, but it simplifies the GEM code a bit, and will be useful later
when I add support for a2xx devices with GPUMMU, so I decided to keep
this part.

It appears to be possible to configure the GPU to restrict access to
addresses within the VRAM pool, but this is not done yet.  So for now
the GPU will refuse to load if there is no sort of mmu.  Once address
based limits are supported and tested to confirm that we aren't giving
the GPU access to arbitrary memory, this restriction can be lifted

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09 14:38:58 -05:00
Rob Clark
bf2b33afb9 drm/msm: fix bus scaling
This got a bit broken with original patches when re-arranging things to
move dependencies on mach-msm inside #ifndef OF.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09 14:38:58 -05:00
Rob Clark
bd6f82d828 drm/msm: add basic hangcheck/recovery mechanism
A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:57:19 -04:00
Rob Clark
7198e6b031 drm/msm: add a3xx gpu support
Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
     + a3xx_gpu
     + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24 14:57:18 -04:00