- 29 8月, 2017 4 次提交
-
-
由 Jason Ekstrand 提交于
Signed-off-by: NJason Ekstrand <jason@jlekstrand.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jason Ekstrand 提交于
The atomic exchange operation in drm_syncobj_replace_fence is sufficient for the case where it races with itself. However, if you have a race between a replace_fence and dma_fence_get(syncobj->fence), you may end up with the entire replace_fence happening between the point in time where the one thread gets the syncobj->fence pointer and when it calls dma_fence_get() on it. If this happens, then the reference may be dropped before we get a chance to get a new one. The new helper uses dma_fence_get_rcu_safe to get rid of the race. This is also needed because it allows us to do a bit more than just get a reference in drm_syncobj_fence_get should we wish to do so. v2: - RCU isn't that scary - Call rcu_read_lock/unlock - Don't rename fence to _fence - Make the helper static inline Signed-off-by: NJason Ekstrand <jason@jlekstrand.net> Acked-by: Christian König <christian.koenig@amd.com> (v1) Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jason Ekstrand 提交于
The function has far more in common with drm_syncobj_find than with any in the get/put functions. Signed-off-by: NJason Ekstrand <jason@jlekstrand.net> Acked-by: Christian König <christian.koenig@amd.com> (v1) Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 John Stultz 提交于
Currently the hikey dsi logic cannot generate accurate byte clocks values for all pixel clock values. Thus if a mode clock is selected that cannot match the calculated byte clock, the device will boot with a blank screen. This patch uses the new mode_valid callback (many thanks to Jose Abreu for upstreaming it!) to ensure we don't select modes we cannot generate. Also, since the ade crtc code will adjust the mode in mode_set, this patch also adds a mode_fixup callback which we use to make sure we are validating the mode clock that will eventually be used. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NJohn Stultz <john.stultz@linaro.org> Reviewed-by: NXinliang Liu <xinliang.liu@linaro.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 8月, 2017 15 次提交
-
-
由 Kuninori Morimoto 提交于
Now, we can use of_graph_get_remote_endpoint(). Let's use it. Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
-
由 Tomi Valkeinen 提交于
Seems that on omap3 enabling a crtc without any planes causes a sync lost flood. This only happens on the first enable, and after that it works. This looks like an HW issue and it's unclear why this is happening or how to fix it. This started happening after 897145d0 ("drm/omapdrm: Move commit_modeset_enables() before commit_planes()") which, as a work-around, changed omapdrm first to do the modeset enable, and plane set only after that. This WA should be fine on all DSS versions, but apparently OMAP3 DSS is an exception. This patch reverts that work-around for OMAP3 DSS. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
7d267f06 ("drm/omap: work-around for errata i886") changed how the PLL dividers and multipliers are calculated. While the new way should work fine for all the PLLs, it breaks omap5 PLLs. The issues seen are rather odd: seemed that the output clock rate is half of what we asked. It is unclear what's causing there issues. As a work-around this patch adds a "errata_i886" flag, which is set only for DRA7's PLLs, and the PLL setup is done according to that flag. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: NH. Nikolaus Schaller <hns@goldelico.com>
-
由 Tomi Valkeinen 提交于
omapdrm rejects all venc (analog tv-out) videomodes, due to somewhat strict checking of the values, making tv-out unusable. We only support two videomodes, one for PAL and one for NTSC, so instead of trying to check every field in the videomode struct, this patch makes the driver check only the pixel clock and the size of the display. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Arnd Bergmann 提交于
When CONFIG_PM is disabled, we get harmless warnings about unused functions: drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:1025:12: error: 'mdp5_runtime_resume' defined but not used [-Werror=unused-function] static int mdp5_runtime_resume(struct device *dev) ^~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:1015:12: error: 'mdp5_runtime_suspend' defined but not used [-Werror=unused-function] static int mdp5_runtime_suspend(struct device *dev) ^~~~~~~~~~~~~~~~~~~~ This marks both functions as __maybe_unused so the compiler can drop them silently. Fixes: d68fe15b ("drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Arnd Bergmann 提交于
A cleanup left behind an unused variable that we have to remove in order to avoid this harmless warning: drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'a5xx_zap_shader_init': drivers/gpu/drm/msm/adreno/a5xx_gpu.c:493:19: error: unused variable 'a5xx_gpu' [-Werror=unused-variable] Fixes: 8d6f0827 ("drm/msm: Remove uneeded platform dev members") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Not needed outside of mdp5_crtc.c. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Only needed in msm_fb.c so don't export it. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
We'll later want to re-use this for state-readback when bootloader enables display, so that we can create an fb for the initial plane->state->fb. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
The drm_framebuffer is refcnt'd these days and will unref the underlying bo as needed. So we can simplify a little. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
At least for debugging it is nice to have an easy way to force the driver not to load. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Accessing registers for an unclocked block is an insta-reboot on snapdragon devices. So add a bit of logic to track the enable_count so we can WARN_ON() unclocked register writes. This makes it much easier to track down mistakes. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
Nearly all of the buffer allocations for kernel allocate an buffer object, virtual address and GPU iova at the same time. Make a helper function to handle the details. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> [dropped msm_fbdev conversion to new helper, since it interferes with display-handover work, where we want to separate allocation and mapping] Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
Currently the GPU MMU is attached in the adreno_gpu code but as more and more of the GPU initialization moves to the generic GPU path we have a need to map and use GPU memory earlier and earlier. There isn't any reason to defer attaching the MMU until later so attach it right after the address space is created so it can be used immediately. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 22 8月, 2017 20 次提交
-
-
由 Colin Ian King 提交于
The null check on the array msto is incorrect since msto is never null. The null check should be instead on msto[i] since this is being dereferenced in the call to drm_mode_connector_attach_encoder. Thanks to Emil Velikov for pointing out the mistake in my original fix and for suggesting the correct fix. Detected by CoverityScan, CID#1375915 ("Array compared against 0") Fixes: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
It appears that MSI does not work on either G5 PPC nor on a E5500-based platform, where other hardware is reported to work fine with MSI. Both tests were conducted with NV4x hardware, so perhaps other (or even this) hardware can be made to work. It's still possible to force-enable with config=NvMSI=1 on load. Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
These are particularly annoying on Optimus systems where these paths can be called regularly. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
drm_crtc_init exposes the XRGB8888 and ARGB8888 formats. In actuality, ARGB8888's 32-bit depth messes up some formulas that weren't meant for it, and the alpha is fairly meaningless for the primary plane. The modesetting logic appears to be fully prepared for RGB565 as well as XRGB1555 however, as tested with modetest. Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
We were previously setting the pitch based on a perfectly packed buffer. This does not necessarily happen. Either modetest started generating such buffers recently, or earlier testing only happened with well-picked overlay sizes. While we're at it, beef up and refactor the error state detection. Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
Pre-nv50 YUV overlays have stringent requirements for working with the internal machinery. Instead of rejecting these at update_plane time, we should instead prevent the framebuffers from being created in the first place. Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Reviewed-by: NTobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
These are used for accesses to sparse mappings, and we want reads of such mappings to return 0. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Useful for testing, and for the userspace build where we can't kick a framebuffer driver off the device. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
Forked from GP107 implementation. Secboot/gr left out as we don't have signed blobs from NVIDIA in linux-firmware. (Ben): Was unable to mmiotrace the binary driver for unknown reasons, so not able to 100% confirm that no other changes from GP107 are needed. Quick testing shows it seems to work well enough for display. Due to NVIDIA dragging their heels on getting signed firmware to us, this is the best we can do for now. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Rosen Penev 提交于
Most of these errors seem to be WFD related. Official documentation says dcb type 8 is reserved. It's probably used for WFD. Silence the warning in either case. Connector type 70 is stated to be a virtual connector for WiFi display. Since we know this, don't warn that we don't. Signed-off by: Rosen Penev <rosenp@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Rosen Penev 提交于
This warning seems to pop up mainly in laptop cards. Silence it as it is expected behavior. Signed-off by: Rosen Penev <rosenp@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
GT215, GF100-GP100, and GP10x are all different. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
The NV_PMC_ENABLE bit for PMU did not appear until GF100, and some other unknown register needs to be poked instead. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
An upcoming commit will replace direct NV_PMC register bashing from PMU with a call to the proper function. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
We assume that each board has 4 heads for GF119+. However this is not necessarily true - in the case of a GP108 board, the register indicated that there were only 2. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Karol Herbst 提交于
This allows temperature readouts on maxwell2 GPUs. Signed-off-by: NKarol Herbst <karolherbst@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Colin Ian King 提交于
Array thresolds should be named thresholds, rename it. Also make it static static const char * const Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NMartin Peres <martin.peres@free.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 19 8月, 2017 1 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-