aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2017-08-02drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lutMaarten Lankhorst1-0/+1
bdw_load_gamma_lut is writing beyond the array to the maximum value. The intend of the function is to clamp values > 1 to 1, so write the intended color to the max register. This fixes the following KASAN warning: [ 197.020857] [IGT] kms_pipe_color: executing [ 197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0 [ 197.078989] ================================================================== [ 197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839 [ 197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G U 4.13.0-rc1-patser+ #5211 [ 197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 [ 197.079220] Call Trace: [ 197.079230] dump_stack+0x68/0x9e [ 197.079239] print_address_description+0x6f/0x250 [ 197.079251] kasan_report+0x216/0x370 [ 197.079374] ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079451] ? gen8_write16+0x4e0/0x4e0 [i915] [ 197.079460] __asan_report_load2_noabort+0x14/0x20 [ 197.079535] bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915] [ 197.079612] broadwell_load_luts+0x1df/0x550 [i915] [ 197.079690] intel_color_load_luts+0x7b/0x80 [i915] [ 197.079764] intel_begin_crtc_commit+0x138/0x760 [i915] [ 197.079783] drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper] [ 197.079859] ? intel_pre_plane_update+0x571/0x580 [i915] [ 197.079937] intel_update_crtc+0x238/0x330 [i915] [ 197.080016] intel_update_crtcs+0x10f/0x210 [i915] [ 197.080092] intel_atomic_commit_tail+0x1552/0x3340 [i915] [ 197.080101] ? _raw_spin_unlock+0x3c/0x40 [ 197.080110] ? __queue_work+0xb40/0xbf0 [ 197.080188] ? skl_update_crtcs+0xc00/0xc00 [i915] [ 197.080195] ? trace_hardirqs_on+0xd/0x10 [ 197.080269] ? intel_atomic_commit_ready+0x128/0x13c [i915] [ 197.080329] ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915] [ 197.080336] ? debug_object_activate+0x39e/0x580 [ 197.080397] ? i915_sw_fence_await+0x30/0x30 [i915] [ 197.080409] ? __might_sleep+0x15b/0x180 [ 197.080483] intel_atomic_commit+0x944/0xa70 [i915] [ 197.080490] ? refcount_dec_and_test+0x11/0x20 [ 197.080567] ? intel_atomic_commit_tail+0x3340/0x3340 [i915] [ 197.080597] ? drm_atomic_crtc_set_property+0x303/0x580 [drm] [ 197.080674] ? intel_atomic_commit_tail+0x3340/0x3340 [i915] [ 197.080704] drm_atomic_commit+0xd7/0xe0 [drm] [ 197.080722] drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper] [ 197.080749] drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm] [ 197.080775] drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm] [ 197.080783] ? __might_fault+0x104/0x180 [ 197.080809] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080838] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080861] drm_ioctl_kernel+0x154/0x1a0 [drm] [ 197.080885] drm_ioctl+0x624/0x8f0 [drm] [ 197.080910] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm] [ 197.080934] ? drm_getunique+0x210/0x210 [drm] [ 197.080943] ? __handle_mm_fault+0x1bd0/0x1ce0 [ 197.080949] ? lock_downgrade+0x610/0x610 [ 197.080957] ? __lru_cache_add+0x15a/0x180 [ 197.080967] do_vfs_ioctl+0xd92/0xe40 [ 197.080975] ? ioctl_preallocate+0x1b0/0x1b0 [ 197.080982] ? selinux_capable+0x20/0x20 [ 197.080991] ? __do_page_fault+0x7b7/0x9a0 [ 197.080997] ? lock_downgrade+0x5bb/0x610 [ 197.081007] ? security_file_ioctl+0x57/0x90 [ 197.081016] SyS_ioctl+0x4e/0x80 [ 197.081024] entry_SYSCALL_64_fastpath+0x18/0xad [ 197.081030] RIP: 0033:0x7f61f287a987 [ 197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987 [ 197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003 [ 197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000 [ 197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58 [ 197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659 Signed-off-by: Maarten Lankhorst <[email protected]> Reported-by: Martin Peres <[email protected]> Cc: Martin Peres <[email protected]> Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl") Cc: Shashank Sharma <[email protected]> Cc: Kiran S Kumar <[email protected]> Cc: Kausal Malladi <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Matt Roper <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.7+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lionel Landwerlin <[email protected]>
2017-08-02drm/msm: Add A5XX hardware fault detectionJordan Crouse1-0/+26
The A5XX GPU has really good hardware fault detection that can detect a abnormal hardware condition and fire an interrupt in a matter of milliseconds which is a lot better than waiting for the hangcheck timer. Enable the interrupt and log information before kicking off recovery. Signed-off-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm: Remove uneeded platform dev membersJordan Crouse6-9/+1
Commit eeb754746b14 ("drm/msm/gpu: use pm-runtime") adds a pointer for the GPU platform device to the msm_gpu struct so we can happily remove the same pointers from the individual GPU structs. Signed-off-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/mdp5: Set up runtime PM for MDSSArchit Taneja3-8/+86
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and other sub-blocks. W.r.t device heirarchy, it's the parent of all these devices. The power domain of this device is actually tied to the GDSC hw. When any sub-device enables its PD, MDSS's PD is also enabled. The suspend/resume ops enable the top level clocks that end at the MDSS boundary. For now, we're letting them all be optional, since the child devices anyway hold a ref to these clocks. Until now, we'd called a runtime_get() during probe, which ensured that the GDSC was always on. Now that we've set up runtime PM for the children devices, we can get rid of this hack. Note: that the MDSS device is the platform_device in msm_drv.c. The msm_runtime_suspend/resume ops call the funcs that enable/disable the top level MDSS clocks. This is different from MDP4, where the platform device created in msm_drv.c represents MDP4 itself. It would have been nicer to hide these differences by adding new kms funcs, but runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init is called). Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/mdp5: Write to SMP registers even if allocations don't changeArchit Taneja1-8/+51
Requests for assigning/freeing SMP blocks by planes are collected during the atomic check phase, and represented by mdp5_smp_state's 'assigned' and 'released' members. Once the atomic state is committed, these members are reset to 0, indicating that the existing configuration satisfies all the planes. Future atomic commits will copy the old mdp5_smp_state, and the 'assigned' and 'released' members would be updated only if there was a change in the plane configurations. When we disable and re-enable display, we lose the values we wrote to the SMP registers, but the code doesn't program the registers because there isn't any change in mdp5_smp_state. Fix this by writing to the registers irrespective of whether there was a change in SMP state or not. We do this by keeping a cache of the register values, and write them every time we commit a state. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCsArchit Taneja2-2/+7
We shouldn't use use mode_set/mode_set_nofb helpers when we use runtime PM. The registers configured in these funcs lose their state when we eventually enable the display pipeline. Do not implement these vfuncs in the helpers, and call them in the crtc_enable/encoder_enable paths instead. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/dsi: Implement RPM suspend/resume callbacksArchit Taneja3-41/+49
The bus clocks are always enabled/disabled along with the power domain, so move it to the runtime suspend/resume ops. This cleans up the clock code a bit. Get rid of the clk_mutex mutex since it isn't needed. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/dsi: Set up runtime PM for DSIArchit Taneja2-1/+12
Call the pm_runtime_get/put API where we need the clocks enabled. The main entry/exit points are 1) enabling/disabling the DSI bridge and 2) Sending commands from the DSI host to the device. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/hdmi: Set up runtime PM for HDMIArchit Taneja3-19/+50
Enable rudimentary runtime PM in the HDMI driver. We can't really do agressive PM toggling at the moment because we need to leave the hpd clocks enabled all the time. There isn't much benefit of creating suspend/resume ops to toggle clocks either. We just make sure that we configure the power domain in the HDMI bridge's enable/disable paths, and the HDMI connector's detect() op. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocksArchit Taneja6-36/+78
mdp5_enable/disable calls are scattered all around in the MDP5 code. Use the pm_runtime_get/put calls here instead, and populate the runtime PM suspend/resume ops to manage the clocks. About the overall design: MDP5 is a child of the top level MDSS device. MDSS is also the parent to DSI, HDMI and other interfaces. When we enable MDP5's power domain, we end up enabling MDSS's PD too. It is only MDSS's PD that actually controlls the GDSC HW. Therefore, calling runtime_get/put on the MDP5 device is like just requesting a vote to enable/disable the GDSC. Functionally, replacing the clock enable/disable calls with the RPM API can result in the power domain (GDSC) state being toggled if no other child isn't powered on. This can result in the register context being lost. We make sure (in future commits) that code paths don't end up configuring registers and then later lose state, resulting in a bad HW state. For now, we've replaced each mdp5_enable/disable with runtime_get/put API. We could optimize things later by removing runtime_get/put calls which don't really need to be there. This could prevent unnecessary toggling of the power domain and clocks. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-02Merge branch 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie109-1761/+4301
into drm-next - Stop reprogramming the MC, the vbios already does this in asic_init - Reduce internal gart to 256M (this does not affect the ttm GTT pool size) - Initial support for huge pages - Rework bo migration logic - Lots of improvements for vega10 - Powerplay fixes - Additional Raven enablement - SR-IOV improvements - Bug fixes - Code cleanup * 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux: (138 commits) drm/amdgpu: fix header on gfx9 clear state drm/amdgpu: reduce the time of reading VBIOS drm/amdgpu/virtual_dce: Remove the rmmod error message drm/amdgpu/gmc9: disable legacy vga features in gmc init drm/amdgpu/gmc8: disable legacy vga features in gmc init drm/amdgpu/gmc7: disable legacy vga features in gmc init drm/amdgpu/gmc6: disable legacy vga features in gmc init (v2) drm/radeon: Set depth on low mem to 16 bpp instead of 8 bpp drm/amdgpu: fix the incorrect scratch reg number on gfx v6 drm/amdgpu: fix the incorrect scratch reg number on gfx v7 drm/amdgpu: fix the incorrect scratch reg number on gfx v8 drm/amdgpu: fix the incorrect scratch reg number on gfx v9 drm/amd/powerplay: add support for 3DP 4K@120Hz on vega10. drm/amdgpu: enable huge page handling in the VM v5 drm/amdgpu: increase fragmentation size for Vega10 v2 drm/amdgpu: ttm_bind only when user needs gpu_addr in bo pin drm/amdgpu: correct clock info for SRIOV drm/amdgpu/gmc8: SRIOV need to program fb location drm/amdgpu: disable firmware loading for psp v10 drm/amdgpu:fix gfx fence allocate size ...
2017-08-02drm/ast: Actually load DP501 firmware when requiredEgbert Eich3-11/+18
The ast driver has a code to load the DP501 firmware, but it's never used. This patch implements its actual usage by requesting the firmware on demand, and release the firmware at exit as well. Also the path contains a few cleanups and makes relevant functions static. Signed-off-by: Egbert Eich <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2017-08-02drm/ast: Add an crtc_disable callback to the crtc helper funcsEgbert Eich1-0/+16
Implement the proper CRTC disablement, just like done in mgag200 driver. Signed-off-by: Egbert Eich <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2017-08-02drm/ast: Fix memleak in error path in ast_bo_create()Egbert Eich1-5/+6
The allocated struct ast_bo was not freed in all error paths. This patch consolidates error handling and fixes this. Signed-off-by: Egbert Eich <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2017-08-02drm/ast: Free container instead of member in ast_user_framebuffer_destroy()Egbert Eich1-1/+1
Technically freeing ast_fb->base is the same as freeing ast_fb as 'base' the first member of the data structure. Still this makes it cleaner. Signed-off-by: Egbert Eich <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2017-08-02drm/ast: Simplify function ast_bo_unpin()Egbert Eich1-6/+2
Just a code refactoring, no functional change. Signed-off-by: Egbert Eich <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2017-08-02drm/i915/gvt: clean workload queue if error happenedChuanxiao Dong1-1/+18
If a workload caused a HW GPU hang or it is in the middle of vGPU reset, the workload queue should be cleaned up to emulate the hang state of the GPU. v2: - use ENGINE_MASK(ring_id) instead of (1 << ring_id). (Zhenyu) Signed-off-by: Chuanxiao Dong <[email protected]> Cc: Zhenyu Wang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2017-08-02drm/i915/gvt: change resetting to resetting_engChuanxiao Dong4-10/+13
Use resetting_eng to identify which engine is resetting so the rest ones' workload won't be impacted v2: - use ENGINE_MASK(ring_id) instead of (1 << ring_id). (Zhenyu) Signed-off-by: Chuanxiao Dong <[email protected]> Cc: Zhenyu Wang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2017-08-01drm/msm: gpu: don't abuse dma_alloc for non-DMA allocationsArnd Bergmann2-51/+23
In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t into dmam_alloc_coherent, which the compiler warns about: drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt': drivers/gpu/drm/msm/adreno/a5xx_gpu.c:54:50: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] The returned DMA address is later passed on to a function that takes a phys_addr_t, so it's clearly wrong to use the DMA mapping interface here: the memory may be uncached, or the address may be completely wrong if there is an IOMMU connected to the device. What the code actually wants to do is to get the physical address from the reserved-mem node. It goes through the dma-mapping interfaces for obscure reasons, and this apparently only works by chance, relying on specific bugs in the error handling of the arm64 dma-mapping implementation. The same problem existed in the "venus" media driver, which was now fixed by Stanimir Varbanov after long discussions. In order to make some progress here, I have now ported his approach over to the adreno driver. The patch is currently untested, and should get a good review, but it is now much simpler than the original, and it should be obvious what goes wrong if I made a mistake in the port. See also: a6e2d36bf6b7 ("media: venus: don't abuse dma_alloc for non-DMA allocations") Cc: Stanimir Varbanov <[email protected]> Fixes: 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX") Acked-by: Bjorn Andersson <[email protected]> Acked-and-Tested-by: Jordan Crouse <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: gpu: call qcom_mdt interfaces only for ARCH_QCOMArnd Bergmann2-9/+4
When compile-testing for something other than ARCH_QCOM, we run into a link error: drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init': a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to `qcom_mdt_get_size' a5xx_gpu.c:(.text.a5xx_hw_init+0x93c): undefined reference to `qcom_mdt_load' There is already an #ifdef that tries to check for CONFIG_QCOM_MDT_LOADER, but that symbol is only meaningful when building for ARCH_QCOM. This adds a compile-time check for ARCH_QCOM, and clarifies the Kconfig select statement so we don't even try it for other targets. The check for CONFIG_QCOM_MDT_LOADER can then go away, which also improves compile-time coverage and makes the code a little nicer to read. Fixes: 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX") Acked-by: Jordan Crouse <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm/adreno: Prevent unclocked access when retrieving timestampsArchit Taneja1-2/+9
msm_gpu's get_timestamp() op (called by the MSM_GET_PARAM ioctl) can result in register accesses. We need our power domain and clocks to be active for that. Make sure they are enabled here. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: args->fence should be args->flagsJordan Crouse1-1/+1
Fix a typo in msm_ioctl_gem_submit - check args->flags for the MSM_SUBMIT_NO_IMPLICIT flag instead of args->fence. Signed-off-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: Turn off hardware clock gating before reading A5XX registersJordan Crouse1-0/+7
On A5XX GPU hardware clock gating needs to be turned off before reading certain GPU registers via AHB. Turn off HWCG before calling adreno_show() to safely dump all the registers without a system hang. Signed-off-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: Allow hardware clock gating to be toggledJordan Crouse2-33/+10
There are some use cases wherein we need to turn off hardware clock gating before reading certain registers. Modify the A5XX HWCG function to allow user to enable or disable clock gating at will. Signed-off-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: Remove some potentially blocked register rangesJordan Crouse1-25/+24
The 0xf400 and 0xf800 ranges are in the RBBM_SECVID block which may be protected from CPU access. Skip dumping them since they are minimally useful for debugging and they aren't worth a system hang. Signed-off-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm/mdp5: Drop clock names with "_clk" suffixArchit Taneja1-6/+6
We have upstream bindings (msm8916) that have the "_clk" suffix in the clock names. The downstream bindings also require it. We want to drop the "_clk" suffix and at the same time support existing bindings. Update the MDP5 code with the the msm_clk_get() helper to support both old and new clock names. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm/mdp5: Fix typo in encoder_enable pathArchit Taneja1-1/+1
The mdp5_cmd_encoder_disable is accidentally called in the encoder enable path. We've not seen any problems since we haven't tested with command mode panels in a while. Fix the copy-paste error. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: NULL pointer dereference in drivers/gpu/drm/msm/msm_gem_vma.cHans Verkuil1-1/+1
While I was testing the upcoming adv7533 CEC support with my Dragonboard c410 I encountered this NULL pointer dereference: [ 17.912822] Unable to handle kernel NULL pointer dereference at virtual address 000000e8 [ 17.917191] user pgtable: 4k pages, 48-bit VAs, pgd = ffff800030e9f000 [ 17.925249] [00000000000000e8] *pgd=00000000b0daf003, *pud=0000000000000000 [ 17.931650] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 17.938395] Modules linked in: btqcomsmd btqca arc4 wcn36xx mac80211 bluetooth cfg80211 ecdh_generic r8152 snd_soc_hdmi_codec adv7511 cec qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm [ 17.943967] CPU: 0 PID: 1684 Comm: Xorg Tainted: G W 4.13.0-rc1-dragonboard #111 [ 17.962005] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 17.970685] task: ffff800031236c00 task.stack: ffff800033fbc000 [ 17.977582] PC is at msm_gem_unmap_vma+0x20/0x80 [msm] [ 17.983213] LR is at put_iova+0x60/0xb8 [msm] [ 17.988303] pc : [<ffff000000ac2d58>] lr : [<ffff000000ac07c8>] pstate: 20000145 [ 17.992733] sp : ffff800033fbfb30 [ 18.000193] x29: ffff800033fbfb30 x28: ffff800030b5f000 [ 18.003407] x27: 00000000000000b4 x26: ffff0000009f8cd8 [ 18.008789] x25: 0000000000000004 x24: dead000000000100 [ 18.014085] x23: dead000000000200 x22: ffff800030b5fd40 [ 18.019379] x21: ffff800030b5fc00 x20: 0000000000000000 [ 18.024675] x19: ffff80003082bf00 x18: 0000000000000000 [ 18.029970] x17: 0000ffffb3347e70 x16: ffff000008207638 [ 18.035265] x15: 0000000000000053 x14: 0000000000000000 [ 18.040560] x13: 0000000000000038 x12: 0101010101010101 [ 18.045855] x11: 7f7f7f7f7f7f7f7f x10: 0000000000000040 [ 18.051150] x9 : ffff800030b5f038 x8 : ffff800031657b50 [ 18.056446] x7 : ffff800031657b78 x6 : 0000000000000000 [ 18.061740] x5 : 0000000000000000 x4 : 00000000b5c01000 [ 18.067036] x3 : 0000000000000000 x2 : ffff8000337bf300 [ 18.072330] x1 : ffff80003082bf00 x0 : 0000000000000000 [ 18.077629] Process Xorg (pid: 1684, stack limit = 0xffff800033fbc000) [ 18.082925] Stack: (0xffff800033fbfb30 to 0xffff800033fc0000) [ 18.089262] fb20: ffff800033fbfb60 ffff000000ac07c8 [ 18.095081] fb40: ffff80003082bf00 ffff800030b5fc90 ffff800030b5fc00 ffff000000abf4a0 [ 18.102893] fb60: ffff800033fbfba0 ffff000000ac16b0 ffff800030b5fc00 ffff8000338ff870 [ 18.110706] fb80: ffff8000338ff800 ffff800030b5fc00 ffff800030b5fda8 ffff800033fbfd80 [ 18.118518] fba0: ffff800033fbfbe0 ffff0000009d4244 ffff800030b5fc00 ffff800030b5f038 [ 18.126332] fbc0: ffff800033fbfbd0 ffff800030b5fc00 ffff800030b5f038 ffff0000009d4840 [ 18.134144] fbe0: ffff800033fbfbf0 ffff0000009d4858 ffff800033fbfc10 ffff0000009d48e4 [ 18.141955] fc00: ffff800030b5fc00 ffff8000338ffd98 ffff800033fbfc30 ffff0000009d49a4 [ 18.149768] fc20: ffff800030b5fc00 ffff800030b5f000 ffff800033fbfc60 ffff0000009d4a4c [ 18.157581] fc40: ffff800030b5f050 ffff800030b5f000 0000000000000001 ffff800030b5fc00 [ 18.165394] fc60: ffff800033fbfca0 ffff0000009d4ab0 0000000000000018 ffff800030b5f000 [ 18.173206] fc80: ffff0000009efd28 ffff800033fbfd80 ffff8000338ff800 ffff0000009d56a8 [ 18.181019] fca0: ffff800033fbfcb0 ffff0000009efd54 ffff800033fbfcc0 ffff0000009d56c8 [ 18.188831] fcc0: ffff800033fbfd00 ffff0000009d58e0 ffff0000009fa6e0 00000000c00464b4 [ 18.196643] fce0: 0000000000000004 ffff80003082b400 0000ffffea1f0e00 0000000000000000 [ 18.204456] fd00: ffff800033fbfe00 ffff000008206f0c ffff80000335caf8 ffff80003082b400 [ 18.212269] fd20: 0000ffffea1f0e00 ffff80003082b400 00000000c00464b4 0000ffffea1f0e00 [ 18.220081] fd40: 0000000000000124 000000000000001d ffff0000089d2000 ffff800031236c00 [ 18.227894] fd60: ffff800033fbfd80 0000000000000004 ffff0000009efd28 ffff800033fbfd80 [ 18.235706] fd80: 0000000100000001 0000008000000001 0000001800000020 0000000000000001 [ 18.243518] fda0: 0000000100000000 0000000100000001 0000ffff00000000 0000ffff00000000 [ 18.251331] fdc0: 0000000000000124 0000000000000038 ffff0000089d2000 ffff800031236c00 [ 18.259144] fde0: ffff800033fbfe40 ffff000008214124 ffff800033fbfe30 ffff000008203290 [ 18.266956] fe00: ffff800033fbfe80 ffff0000082076b4 0000000000000000 ffff800030d8a000 [ 18.274768] fe20: ffff80003082b400 0000000000000016 ffff800033fbfe50 ffff0000081f0488 [ 18.282581] fe40: ffff800033fbfe80 ffff000008207678 0000000000000000 ffff80003082b400 [ 18.290393] fe60: ffff800033fbfe70 ffff0000082138b0 ffff800033fbfe80 ffff000008207658 [ 18.298207] fe80: 0000000000000000 ffff000008082f84 0000000000000000 0000800034a16000 [ 18.306017] fea0: ffffffffffffffff 0000ffffb3347e7c 0000000000000000 0000000000000015 [ 18.313832] fec0: 0000000000000016 00000000c00464b4 0000ffffea1f0e00 0000000000000001 [ 18.321643] fee0: 0000000000000020 0000000000000080 0000000000000001 0000000000000000 [ 18.329456] ff00: 000000000000001d 000000012692c5b0 0101010101010101 7f7f7f7f7f7f7f7f [ 18.337269] ff20: 0101010101010101 0000000000000038 0000000000000000 0000000000000053 [ 18.345082] ff40: 0000ffffb368b2b8 0000ffffb3347e70 0000000000000000 0000ffffb3847000 [ 18.352894] ff60: 0000ffffea1f0e00 00000000c00464b4 0000000000000016 0000ffffea1f0edc [ 18.360705] ff80: 000000012692ad20 0000000000000003 00000001214282e4 0000000121428388 [ 18.368518] ffa0: 0000000000000000 0000ffffea1f0da0 0000ffffb367185c 0000ffffea1f0da0 [ 18.376332] ffc0: 0000ffffb3347e7c 0000000000000000 0000000000000016 000000000000001d [ 18.384142] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 18.391953] Call trace: [ 18.399760] Exception stack(0xffff800033fbf950 to 0xffff800033fbfa80) [ 18.402023] f940: ffff80003082bf00 0001000000000000 [ 18.408622] f960: ffff800033fbfb30 ffff000000ac2d58 0000000020000145 ffff8000338ffa78 [ 18.416435] f980: 0000000000000000 0000000000000000 ffff800033fbf9e0 ffff0000089afcf0 [ 18.424248] f9a0: ffff80000348f230 ffff8000338ffa78 0000000000000000 0000000000000000 [ 18.432060] f9c0: ffff8000338ffaa8 0000000000000001 ffff800033fbfb80 ffff0000009e8f38 [ 18.439872] f9e0: ffff800033fbfa10 ffff0000089a9ff8 0000000000000027 ffff80003082b918 [ 18.447684] fa00: 0000000000000000 ffff80003082bf00 ffff8000337bf300 0000000000000000 [ 18.455497] fa20: 00000000b5c01000 0000000000000000 0000000000000000 ffff800031657b78 [ 18.463310] fa40: ffff800031657b50 ffff800030b5f038 0000000000000040 7f7f7f7f7f7f7f7f [ 18.471122] fa60: 0101010101010101 0000000000000038 0000000000000000 0000000000000053 [ 18.479062] [<ffff000000ac2d58>] msm_gem_unmap_vma+0x20/0x80 [msm] [ 18.486862] [<ffff000000ac07c8>] put_iova+0x60/0xb8 [msm] [ 18.492938] [<ffff000000ac16b0>] msm_gem_free_object+0x60/0x198 [msm] [ 18.498432] [<ffff0000009d4244>] drm_gem_object_free+0x1c/0x58 [drm] [ 18.504854] [<ffff0000009d4858>] drm_gem_object_put_unlocked+0x90/0xa0 [drm] [ 18.511273] [<ffff0000009d48e4>] drm_gem_object_handle_put_unlocked+0x64/0xd0 [drm] [ 18.518300] [<ffff0000009d49a4>] drm_gem_object_release_handle+0x54/0x98 [drm] [ 18.525679] [<ffff0000009d4a4c>] drm_gem_handle_delete+0x64/0xb8 [drm] [ 18.532968] [<ffff0000009d4ab0>] drm_gem_dumb_destroy+0x10/0x18 [drm] [ 18.539479] [<ffff0000009efd54>] drm_mode_destroy_dumb_ioctl+0x2c/0x40 [drm] [ 18.545992] [<ffff0000009d56c8>] drm_ioctl_kernel+0x68/0xe0 [drm] [ 18.553105] [<ffff0000009d58e0>] drm_ioctl+0x178/0x3b0 [drm] [ 18.558970] [<ffff000008206f0c>] do_vfs_ioctl+0xa4/0x7d0 [ 18.564694] [<ffff0000082076b4>] SyS_ioctl+0x7c/0x98 [ 18.569992] [<ffff000008082f84>] el0_svc_naked+0x38/0x3c [ 18.574941] Code: a90153f3 aa0003f4 f90013f5 aa0103f3 (f9407400) [ 18.580502] ---[ end trace b1ac6888ec40b0be ]--- It turns out that the aspace argument in msm_gem_unmap_vma() is NULL. Signed-off-by: Hans Verkuil <[email protected]> [Note: this case gets hit with !IOMMU config] Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: fix WARN_ON in add_vma() with no iommuHans Verkuil1-0/+4
While I was testing the upcoming adv7533 CEC support with my Dragonboard c410 I encountered this warning several times during boot: [ 4.408309] WARNING: CPU: 3 PID: 1347 at drivers/gpu/drm/msm/msm_gem.c:312 add_vma+0x78/0x88 [msm] [ 4.412951] Modules linked in: snd_soc_hdmi_codec adv7511 cec qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm [ 4.421728] CPU: 3 PID: 1347 Comm: kworker/3:3 Not tainted 4.13.0-rc1-dragonboard #111 [ 4.433090] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 4.441081] Workqueue: events deferred_probe_work_func [ 4.447929] task: ffff800031243600 task.stack: ffff800003394000 [ 4.453023] PC is at add_vma+0x78/0x88 [msm] [ 4.458823] LR is at _msm_gem_new+0xd4/0x188 [msm] [ 4.463207] pc : [<ffff000000ac01f8>] lr : [<ffff000000ac06b4>] pstate: 40000145 [ 4.467811] sp : ffff8000033978a0 [ 4.475357] x29: ffff8000033978a0 x28: ffff8000031dea18 [ 4.478572] x27: ffff800003933a00 x26: ffff800003b39800 [ 4.483953] x25: ffff8000338ff800 x24: 0000000000000001 [ 4.489249] x23: 0000000000000000 x22: ffff800003b39800 [ 4.494544] x21: ffff8000338ff800 x20: 0000000000000000 [ 4.499839] x19: ffff800003932600 x18: 0000000000000001 [ 4.505135] x17: 0000ffff8969e9e0 x16: ffff7e00000ce7a0 [ 4.510429] x15: ffffffffffffffff x14: ffff8000833977ef [ 4.515724] x13: ffff8000033977f3 x12: 0000000000000038 [ 4.521020] x11: 0101010101010101 x10: ffffff7f7fff7f7f [ 4.526315] x9 : 0000000000000000 x8 : ffff800003932800 [ 4.531633] x7 : 0000000000000000 x6 : 000000000000003f [ 4.531644] x5 : 0000000000000040 x4 : 0000000000000000 [ 4.531650] x3 : ffff800031243600 x2 : 0000000000000000 [ 4.531655] x1 : 0000000000000000 x0 : 0000000000000000 [ 4.531670] Call trace: [ 4.531676] Exception stack(0xffff8000033976c0 to 0xffff8000033977f0) [ 4.531683] 76c0: ffff800003932600 0001000000000000 ffff8000033978a0 ffff000000ac01f8 [ 4.531688] 76e0: 0000000000000140 0000000000000000 ffff800003932550 ffff800003397780 [ 4.531694] 7700: ffff800003397730 ffff000008261ce8 0000000000000000 ffff8000031d2f80 [ 4.531699] 7720: ffff800003397800 ffff0000081d671c 0000000000000140 0000000000000000 [ 4.531705] 7740: ffff000000ac04c0 0000000000004003 ffff800003397908 00000000014080c0 [ 4.531710] 7760: 0000000000000000 ffff800003b39800 0000000000000000 0000000000000000 [ 4.531716] 7780: 0000000000000000 ffff800031243600 0000000000000000 0000000000000040 [ 4.531721] 77a0: 000000000000003f 0000000000000000 ffff800003932800 0000000000000000 [ 4.531726] 77c0: ffffff7f7fff7f7f 0101010101010101 0000000000000038 ffff8000033977f3 [ 4.531730] 77e0: ffff8000833977ef ffffffffffffffff [ 4.531881] [<ffff000000ac01f8>] add_vma+0x78/0x88 [msm] [ 4.532011] [<ffff000000ac06b4>] _msm_gem_new+0xd4/0x188 [msm] [ 4.532134] [<ffff000000ac1900>] msm_gem_new+0x10/0x18 [msm] [ 4.532260] [<ffff000000acb274>] msm_dsi_host_modeset_init+0x17c/0x268 [msm] [ 4.532384] [<ffff000000ac9024>] msm_dsi_modeset_init+0x34/0x1b8 [msm] [ 4.532504] [<ffff000000ab6168>] modeset_init+0x408/0x488 [msm] [ 4.532623] [<ffff000000ab6c4c>] mdp5_kms_init+0x2b4/0x338 [msm] [ 4.532745] [<ffff000000abeff8>] msm_drm_bind+0x218/0x4e8 [msm] [ 4.532755] [<ffff00000855d744>] try_to_bring_up_master+0x1f4/0x318 [ 4.532762] [<ffff00000855d900>] component_add+0x98/0x180 [ 4.532887] [<ffff000000ac8da0>] dsi_dev_probe+0x18/0x28 [msm] [ 4.532895] [<ffff000008565fe8>] platform_drv_probe+0x58/0xc0 [ 4.532901] [<ffff00000856410c>] driver_probe_device+0x324/0x458 [ 4.532907] [<ffff00000856440c>] __device_attach_driver+0xac/0x170 [ 4.532913] [<ffff000008561ef4>] bus_for_each_drv+0x4c/0x98 [ 4.532918] [<ffff000008563c38>] __device_attach+0xc0/0x160 [ 4.532924] [<ffff000008564530>] device_initial_probe+0x10/0x18 [ 4.532929] [<ffff000008562f84>] bus_probe_device+0x94/0xa0 [ 4.532934] [<ffff0000085635d4>] deferred_probe_work_func+0x8c/0xe8 [ 4.532941] [<ffff0000080d79bc>] process_one_work+0x1d4/0x330 [ 4.532946] [<ffff0000080d7b60>] worker_thread+0x48/0x468 [ 4.532952] [<ffff0000080ddae4>] kthread+0x12c/0x130 [ 4.532958] [<ffff000008082f10>] ret_from_fork+0x10/0x40 [ 4.532962] ---[ end trace b1ac6888ec40b0bb ]--- Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm/dsi: Calculate link clock rates with updated dsi->lanesArchit Taneja1-7/+7
After the commit mentioned below, we start computing the byte and pixel clocks (dsi_calc_clk_rate) in the DSI bridge's mode_set() op. The calculation involves the number of DSI lanes being used by the downstream bridge/panel. If the downstream bridge/panel tries to change the number of DSI lanes (as done in the ADV7533 driver) in its mode_set() op, then our DSI host driver will not have the correct number of lanes when computing byte/pixel clocks. Fix this by delaying the clock rate calculation in the DSI bridge enable path. In particular, compute the clock rates in msm_dsi_host_get_phy_clk_req(). This fixes the DSI host error interrupts seen when we try to switch between modes that require different number of lanes (4 to 3 lanes, or vice versa) on db410c. The error interrupts occur since the byte/pixel clock rates aren't according to what the DSI video mode timing engine expects. Fixes: b62aa70a98c5 ("drm/msm/dsi: Move PHY operations out of host") Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm/mdp5: fix unclocked register access in _cursor_set()Rob Clark1-0/+8
Fixes an insta-reboot when screen-blanking kicks in, due to cursor updates without clocks enabled. Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: unlock on error in msm_gem_get_iova()Dan Carpenter1-3/+5
We recently added locking to this function but there was a direct return that was overlooked where we need to unlock. Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from struct_mutex") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm: fix an integer overflow testDan Carpenter1-2/+2
We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Jordan Crouse <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm/msm/mdp5: Fix compilation warningsViresh Kumar2-4/+4
Following compilation warnings were observed for these files: CC [M] drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup': drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: missing braces around initializer [-Wmissing-braces] enum mdp5_pipe stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: (near initialization for 'stage[0]') [-Wmissing-braces] drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: missing braces around initializer [-Wmissing-braces] enum mdp5_pipe r_stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: (near initialization for 'r_stage[0]') [-Wmissing-braces] drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_mode_set': drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: missing braces around initializer [-Wmissing-braces] struct phase_step step = { 0 }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: (near initialization for 'step.x') [-Wmissing-braces] drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: missing braces around initializer [-Wmissing-braces] struct pixel_ext pe = { 0 }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: (near initialization for 'pe.left') [-Wmissing-braces] This happens because in the first case we were initializing a two dimensional array with {0} and in the second case we were initializing a struct containing two arrays with {0}. Fix them by adding another pair of {}. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-08-01drm: Create a format/modifier blobBen Widawsky2-0/+91
Updated blob layout (Rob, Daniel, Kristian, xerpi) v2: * Removed __packed, and alignment (.+) * Fix indent in drm_format_modifier fields (Liviu) * Remove duplicated modifier > 64 check (Liviu) * Change comment about modifier (Liviu) * Remove arguments to blob creation, use plane instead (Liviu) * Fix data types (Ben) * Make the blob part of uapi (Daniel) v3: Remove unused ret field. Change i, and j to unsigned int (Emil) v4: Use plane->modifier_count instead of recounting (Daniel) v5: Rename modifiers to modifiers_property (Ville) Use sizeof(__u32) instead to reflect UAPI nature (Ville) Make BUILD_BUG_ON for blob header size Cc: Rob Clark <[email protected]> Cc: Kristian H. Kristensen <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Daniel Stone <[email protected]> (v2) Reviewed-by: Liviu Dudau <[email protected]> (v2) Reviewed-by: Emil Velikov <[email protected]> (v3) Signed-off-by: Daniel Stone <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-08-01drm: Plumb modifiers through plane initBen Widawsky42-49/+98
This is the plumbing for supporting fb modifiers on planes. Modifiers have already been introduced to some extent, but this series will extend this to allow querying modifiers per plane. Based on this, the client to enable optimal modifications for framebuffers. This patch simply allows the DRM drivers to initialize their list of supported modifiers upon initializing the plane. v2: A minor addition from Daniel v3: * Updated commit message * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu) * Remove some excess newlines (Liviu) * Update comment for > 64 modifiers (Liviu) v4: Minor comment adjustments (Liviu) v5: Some new platforms added due to rebase v6: Add some missed plane inits (or maybe they're new - who knows at this point) (Daniel) Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Daniel Stone <[email protected]> (v2) Reviewed-by: Liviu Dudau <[email protected]> Signed-off-by: Daniel Stone <[email protected]>
2017-08-01drm/msm: Convert to use new iterator macros, v2.Maarten Lankhorst2-11/+11
for_each_obj_in_state is about to be removed, so convert to the new iterator macros. Just like in omap, use crtc_state->active instead of crtc_state->enable when waiting for completion. Changes since v1: - Fix compilation. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Rob Clark <[email protected]> Cc: Archit Taneja <[email protected]> Cc: Vincent Abriou <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Russell King <[email protected]> Cc: Rob Herring <[email protected]> Cc: Markus Elfring <[email protected]> Cc: Sushmita Susheelendra <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Daniel Vetter <[email protected]> Tested-by: Archit Taneja <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-08-01drm/nouveau: Convert nouveau to use new iterator macros, v2.Maarten Lankhorst1-35/+37
Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Changes since v1: - Don't mix up old and new state. (danvet) - Rebase on top of interruptible swap_state changes. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2017-08-01drm/omapdrm: Fix omap_atomic_wait_for_completionMaarten Lankhorst1-3/+3
Use the new iterator macro and look for crtc_state->active instead of enable, only crtc_state->active implies that vblanks will happen. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Tomi Valkeinen <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-08-01drm/atomic: Use new iterator macros in drm_atomic_helper_wait_for_flip_done, ↵Maarten Lankhorst1-1/+1
again. for_each_obj_in_state is about to be removed, so use the correct new iterator macro. I renamed the variable to 'unused', but forgot to convert drm_atomic_helper_wait_for_flip_done to the new iterator macro, so make it work this time. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2017-07-31drm: Fix warning when building docs for scdc_helperSean Paul1-13/+20
Fixes: ../drivers/gpu/drm/drm_scdc_helper.c:203: ERROR: Unexpected indentation. ../drivers/gpu/drm/drm_scdc_helper.c:204: WARNING: Block quote ends without a blank line; unexpected unindent. Changes in v2: - Property blockquote TMDS calculations so they look pretty (Daniel) - Remove duplicate documentation from the header file Signed-off-by: Sean Paul <[email protected]> Reviewed-by: Shashank Sharma <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/modes: Fix drm_mode_is_420_only() commentSean Paul1-1/+1
Fixes the following warnings when building docs: ../drivers/gpu/drm/drm_modes.c:1623: warning: No description found for parameter 'display' ../drivers/gpu/drm/drm_modes.c:1623: warning: Excess function parameter 'connector' description in 'drm_mode_is_420_only' Signed-off-by: Sean Paul <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/i915: Update DRIVER_DATE to 20170731Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <[email protected]>
2017-07-31drm/rockchip: vop: rk3328: fix overlay abnormalMark yao3-0/+4
It's a hardware bug, all window's overlay channel reset value is same, hardware overlay would be die. so we must initial difference id for each overlay channel. The Channel register is supported on all vop will full design. Following is the details for this register VOP_WIN0_CTRL2 bit[7:4] win_rid_win0_cbr axi read id of win0 cbr channel bit[3:0] win_rid_win0_yrgb axi read id of win0 yrgb channel Signed-off-by: Mark Yao <[email protected]> Reviewed-by: Jeffy Chen <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/rockchip: vop: add a series of vop supportMark yao3-224/+908
Vop Full framework now has following vops: IP version chipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big 3.6 rk3399 lit 3.7 rk3228 3.8 rk3328 The above IP version is from H/W define, some of vop support get the IP version from VERSION_INFO register, some are not. hardcode the IP version for each vop to identify them. major version: used for IP structure, Vop full framework is 3, vop little framework is 2. minor version: on same structure, newer design vop will bigger then old one. Signed-off-by: Mark Yao <[email protected]> Reviewed-by: Jeffy Chen <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/rockchip: vop: group vop registersMark yao3-127/+146
Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao <[email protected]> Reviewed-by: Jeffy Chen <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/rockchip: vop: move line_flag_num to interrupt registersMark yao3-9/+13
In the hardware design process, the design of line flags register is associated with the interrupt register, placing the line flags in the interrupt definition is more reasonable, and it would make multi-vop define easilier. Signed-off-by: Mark Yao <[email protected]> Reviewed-by: Sean Paul <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/rockchip: vop: move write_relaxed flags to vop registerMark yao3-35/+36
Since the drm atomic framework, only a small part of the vop register needs sync write, Currently seems only following registers need sync write: cfg_done, standby and interrupt related register. All ctrl registers are using the sync write method that is inefficient, hardcode the write_relaxed flags to vop registers, then can only do synchronize write for those actual needed register. Signed-off-by: Mark Yao <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Jeffy Chen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-31drm/rockchip: vop: initialize registers directlyMark yao3-49/+11
At present we are using init_table to initialize some registers, but the Register init table use un-document define, it is unreadable, and sometimes we only want to update tiny bits, init table method is not friendly, it's diffcult to reuse for difference chips. To make it clean, initialize registers directly, and drops init_table mechanism out. Signed-off-by: Mark Yao <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Jeffy Chen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-07-29v4l: vsp1: Add pipe index argument to the VSP-DU APILaurent Pinchart1-6/+6
In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU channels that need to be configured independently. Extend the VSP-DU API with a pipeline index to identify which pipeline the caller wants to operate on. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.