summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm/msm_drv.h
Commit message (Collapse)AuthorAgeFilesLines
* drm/msm: add perf logging debugfsRob Clark2014-06-021-0/+4
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add rd logging debugfsRob Clark2014-06-021-0/+11
| | | | | | | | | | To ease debugging, add debugfs file which can be cat/tail'd to log submits, along with fence #. If GPU hangs, you can look at 'gpu' debugfs file to find last completed fence and current register state, and compare with logged rd file to narrow down the DRAW_INDX which triggered the GPU hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: update for ARCH_MSM -> ARCH_QCOMRob Clark2014-05-301-1/+1
| | | | | | | Architecture rename/split.. ARCH_QCOM is for the non-legacy platforms (ie. device-tree, multiplatform support, etc). Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: use componentised device supportRob Clark2014-03-311-0/+4
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add hdmi support for apq8x74/mdp5Rob Clark2014-01-091-1/+3
| | | | | | | | | | | | | | | | The HDMI block is basically the same between older SoC's with mdp4 display controller, and newer ones with mdp5. So mostly this consists of better abstracting out the different sets of regulators, clks, etc. In particular, for regulators and clks we can split it up by what is needed for hot plug detect to work, and what is needed to light up the display. Also, 8x74 has a new phy.. a very simple one, but split out into a different mmio space. And with mdp5, the irq is shared with mdp, so we don't directly register our own irq handler. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: split out msm_kms.hRob Clark2014-01-091-30/+0
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add support for non-IOMMU systemsRob Clark2014-01-091-6/+15
| | | | | | | | | | | | | | | | | | | | | | 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>
* drm/msm: COMPILE_TEST supportRob Clark2014-01-091-0/+9
| | | | | | With a simple stub, we can get COMPILE_TEST support. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: rework inactive-workRob Clark2013-11-011-2/+19
| | | | | | | | | | | | Re-arrange things a bit so that we can get work requested after a bo fence passes, like pageflip, done before retiring bo's. Without any sort of bo cache in userspace, some games can trigger hundred's of transient bo's, which can cause retire to take a long time (5-10ms). Obviously we want a bo cache.. but this cleanup will make things a bit easier for atomic as well and makes things a bit cleaner. Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: David Brown <davidb@codeaurora.org>
* drm/msm: add plane supportRob Clark2013-11-011-0/+3
| | | | | | | | Enable using VG1 and VG2 for planes. Currently YUV/CSC or scaling is not enabled, but ARGB and xRGB blending is. Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: David Brown <davidb@codeaurora.org>
* drm/msm: prime supportRob Clark2013-11-011-2/+11
| | | | | Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: David Brown <davidb@codeaurora.org>
* drm/msm: return -EBUSY if bo still activeRob Clark2013-09-111-0/+6
| | | | | | | | | | | | When we CPU_PREP a bo with NOSYNC flag (for example, to implement PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE), an -EBUSY return indicates to userspace that the bo is still busy. Previously it was incorrectly returning 0 in this case. And while we're in there throw in an bit of extra sanity checking in case userspace tries to wait for a bogus fence. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: handle read vs write fencesRob Clark2013-09-101-1/+1
| | | | | | | | | The userspace API already had everything needed to handle read vs write synchronization. This patch actually bothers to hook it up properly, so that we don't need to (for example) stall on userspace read access to a buffer that gpu is also still reading. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: convert to drm_bridgeRob Clark2013-09-021-2/+4
| | | | | | | | | | Drop the msm_connector base class, and special calls to base class methods from the encoder, and use instead drm_bridge. This allows for a cleaner division between the hdmi (and in future dsi) blocks, from the mdp block. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/msm: add a3xx gpu supportRob Clark2013-08-241-10/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/msm: basic KMS driver for snapdragonRob Clark2013-08-241-0/+187
The snapdragon chips have multiple different display controllers, depending on which chip variant/version. (As far as I can tell, current devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And then external to the display controller are HDMI, DSI, etc. blocks which may be shared across devices which have different display controller blocks. To more easily add support for different display controller blocks, the display controller specific bits are split out into a "kms" module, which provides the kms plane/crtc/encoder objects. The external HDMI, DSI, etc. blocks are part encoder, and part connector currently. But I think I will pull in the drm_bridge patches from chromeos tree, and split them into a bridge+connector, with the registers that need to be set in modeset handled by the bridge. This would remove the 'msm_connector' base class. But some things need to be double checked to make sure I could get the correct ON/OFF sequencing.. This patch adds support for mdp4 crtc (including hw cursor), dtv encoder (part of MDP4 block), and hdmi. Signed-off-by: Rob Clark <robdclark@gmail.com>