diff options
author | Dave Airlie <airlied@redhat.com> | 2016-12-01 09:25:58 +1000 |
---|---|---|
committer | Dave Airlie <airlied@redhat.com> | 2016-12-01 09:25:58 +1000 |
commit | f5590134365f6f23dba723f140f72effcc71773f (patch) | |
tree | 2094f339374fa0b37b22f33a9f40950de8950def /drivers/gpu/drm/msm/msm_gpu.h | |
parent | a90f58311f48f510ea63cd2db2e32f74712c43f3 (diff) | |
parent | 2401a008461481387741bacf7318d13af2c2055f (diff) |
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
On the userspace side, all the basics are working, and most of glmark2
is working. I've been working through deqp, and I've got a couple more
things to fix (but we've gone from 70% to 80+% pass in last day, and
current deqp run that is going should pick up another 5-10%). I expect
to push the mesa patches today or tomorrow.
There are a couple more a5xx related patches to take the gpu out of
secure mode (for the devices that come up in secure mode, like the hw
I have), but those depend on an scm patch that would come in through
another tree. If that can land in the next day or two, there might
be a second late pull request for drm/msm.
In addition to the new-shiny, there have also been a lot of overlay/
plane related fixes for issues found using drm-hwc2 (in the process of
testing/debugging the atomic/kms fence patches), resulting in rework
to assign hwpipes to kms planes dynamically (as part of global atomic
state) and also handling SMP (fifo) block allocation atomically as
part of the ->atomic_check() step. All those patches should also help
out atomic weston (when those patches eventually land).
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (36 commits)
drm/msm: gpu: Add support for the GPMU
drm/msm: gpu: Add A5XX target support
drm/msm: Disable interrupts during init
drm/msm: Remove 'src_clk' from adreno configuration
drm/msm: gpu: Add OUT_TYPE4 and OUT_TYPE7
drm/msm: Add adreno_gpu_write64()
drm/msm: gpu Add new gpu register read/write functions
drm/msm: gpu: Return error on hw_init failure
drm/msm: gpu: Cut down the list of "generic" registers to the ones we use
drm/msm: update generated headers
drm/msm/adreno: move scratch register dumping to per-gen code
drm/msm/rd: support for 64b iova
drm/msm: convert iova to 64b
drm/msm: set dma_mask properly
drm/msm: Remove bad calls to of_node_put()
drm/msm/mdp5: move LM bounds check into plane->atomic_check()
drm/msm/mdp5: dump smp state on errors too
drm/msm/mdp5: add debugfs to show smp block status
drm/msm/mdp5: handle SMP block allocations "atomically"
drm/msm/mdp5: dynamically assign hw pipes to planes
...
Diffstat (limited to 'drivers/gpu/drm/msm/msm_gpu.h')
-rw-r--r-- | drivers/gpu/drm/msm/msm_gpu.h | 45 |
1 files changed, 42 insertions, 3 deletions
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h index d61d98a6e047..c4c39d3272c7 100644 --- a/drivers/gpu/drm/msm/msm_gpu.h +++ b/drivers/gpu/drm/msm/msm_gpu.h @@ -50,7 +50,7 @@ struct msm_gpu_funcs { void (*submit)(struct msm_gpu *gpu, struct msm_gem_submit *submit, struct msm_file_private *ctx); void (*flush)(struct msm_gpu *gpu); - void (*idle)(struct msm_gpu *gpu); + bool (*idle)(struct msm_gpu *gpu); irqreturn_t (*irq)(struct msm_gpu *irq); uint32_t (*last_fence)(struct msm_gpu *gpu); void (*recover)(struct msm_gpu *gpu); @@ -80,7 +80,7 @@ struct msm_gpu { /* ringbuffer: */ struct msm_ringbuffer *rb; - uint32_t rb_iova; + uint64_t rb_iova; /* list of GEM active objects: */ struct list_head active_list; @@ -98,7 +98,7 @@ struct msm_gpu { void __iomem *mmio; int irq; - struct msm_mmu *mmu; + struct msm_gem_address_space *aspace; int id; /* Power Control: */ @@ -154,6 +154,45 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg) return msm_readl(gpu->mmio + (reg << 2)); } +static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or) +{ + uint32_t val = gpu_read(gpu, reg); + + val &= ~mask; + gpu_write(gpu, reg, val | or); +} + +static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi) +{ + u64 val; + + /* + * Why not a readq here? Two reasons: 1) many of the LO registers are + * not quad word aligned and 2) the GPU hardware designers have a bit + * of a history of putting registers where they fit, especially in + * spins. The longer a GPU family goes the higher the chance that + * we'll get burned. We could do a series of validity checks if we + * wanted to, but really is a readq() that much better? Nah. + */ + + /* + * For some lo/hi registers (like perfcounters), the hi value is latched + * when the lo is read, so make sure to read the lo first to trigger + * that + */ + val = (u64) msm_readl(gpu->mmio + (lo << 2)); + val |= ((u64) msm_readl(gpu->mmio + (hi << 2)) << 32); + + return val; +} + +static inline void gpu_write64(struct msm_gpu *gpu, u32 lo, u32 hi, u64 val) +{ + /* Why not a writeq here? Read the screed above */ + msm_writel(lower_32_bits(val), gpu->mmio + (lo << 2)); + msm_writel(upper_32_bits(val), gpu->mmio + (hi << 2)); +} + int msm_gpu_pm_suspend(struct msm_gpu *gpu); int msm_gpu_pm_resume(struct msm_gpu *gpu); |