- 31 Jan, 2017 3 commits
-
-
Jani Nikula authored
The function is not that big, but it's also not used for anything performance critical. Make it a normal function. As a side effect, this apparently makes sparse smarter about what it's doing, and gets rid of the warning: ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for type unsigned long ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from constant value (8000000000000000 becomes 0) v2: rebased Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485531291-24821-1-git-send-email-jani.nikula@intel.com
-
Dhinakaran Pandiyan authored
drm_atomic_set_mode_for_crtc() modifies the .enable member of CRTC state but documentation claims otherwise, fix that. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Laurent Vivier authored
VIRTIO_GPU_F_VIRGL is added in features list only for LE kernel, so we must check for it only on LE kernel, otherwise virtio_has_feature() calls BUG() and crashes the kernel. Suggested-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Laurent Vivier <lvivier@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485263549-28743-1-git-send-email-lvivier@redhat.comSigned-off-by:
-
- 30 Jan, 2017 2 commits
-
-
Gustavo Padovan authored
As Sync File is highly dependent on dma-fence* tracks it under SYNC FILE_FRAMEWORK as well. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170127175444.7995-1-gustavo@padovan.org
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: eric@anholt.net Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
- 27 Jan, 2017 16 commits
-
-
Chris Wilson authored
Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, however I have a need to manually perform the hw enabling of the signaling and would like to emit this tracepoint for completeness. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Also remove the unused tilcdc_module_ops.debugfs_cleanup() callback. drm_debugfs_cleanup() removes all debugfs files using debugfs_remove_recursive(), so there should be no need for such a callback in the future. Cc: jsarha@ti.com Cc: tomi.valkeinen@ti.com Signed-off-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: thierry.reding@gmail.com Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Additionally it uses debugfs_remove_recursive() to clean up the debugfs files, so no need for adding fake drm_info_node entries. Cc: benjamin.gaignard@linaro.org Cc: vincent.abriou@st.com Signed-off-by:
Vincent Abriou <vincent.abriou@st.com> Tested-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: tomi.valkeinen@ti.com Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: liviu.dudau@arm.com Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: l.stach@pengutronix.de Cc: linux+etnaviv@armlinux.org.uk Cc: christian.gmeiner@gmail.com Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Noralf Trønnes authored
Make it possible to compile test the driver on other platforms. Cc: l.stach@pengutronix.de Cc: linux+etnaviv@armlinux.org.uk Cc: christian.gmeiner@gmail.com Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so no need to call drm_debugfs_remove_files(). Also remove empty drm_driver.debugfs_cleanup callback. Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by:
-
Oleksandr Andrushchenko authored
From the description of the "DMA-BUF/GEM Object references and lifetime overview" it is not clear when exactly dma_buf gets destroyed and memory freed: only driver .release function mentioned which makes confusion on the real buffer's lifetime. Add more description so all the paths are covered. Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> [danvet: Minor spelling fixes, and some clarification of the 2nd paragraph.] Signed-off-by:
-
Michel Dänzer authored
The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Cc: stable@vger.kernel.org Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Noralf Trønnes authored
drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so no need to call drm_debugfs_remove_files(). Signed-off-by:
-
Noralf Trønnes authored
Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to cover for failure in the drm_driver.debugfs_init callback. Signed-off-by:
-
Noralf Trønnes authored
Instead of having the drivers call drm_debugfs_remove_files() in their drm_driver->debugfs_cleanup hook, do it automatically by traversing minor->debugfs_list. Also use debugfs_remove_recursive() so drivers who add their own debugfs files don't have to keep track of them for removal. Signed-off-by:
-
Philipp Zabel authored
Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled formats as well as so-called split-tiled variants for dual-pipe hardware, where even and odd tiles start at different base addresses. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By:
Wladimir J. van der Laan <laanwj@gmail.com> Signed-off-by:
-
- 26 Jan, 2017 14 commits
-
-
Ville Syrjälä authored
CEA-861-F tells us: "When transmitting any RGB colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore the YQ-field." So let's go ahead and do that. Perhaps there are sinks that don't ignore the YQ as they should for RGB? I wasn't able to find similar text in CEA-861-E, so it would seem to be a fairly "recent" addition. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-6-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
HDMI 2.0 recommends that we set the Q bits in the AVI infoframe even when the sink does not support quantization range selection (QS=0). According to CEA-861 we can do that as long as the Q we send matches the default quantization range for the mode. Previously I think I had misread the spec as saying that you can't send a non-zero Q at all when QS=0. But that's not what the spec actually says. v2: Fix typo in commit message (Jani) Signed-off-by:
-
Ville Syrjälä authored
Pull the logic to populate the quantization range information in the AVI infoframe into a small helper. We'll be adding a bit more logic to it, and having it in a central place seems like a good idea since it's based on the CEA-861 spec. Signed-off-by:
-
Ville Syrjälä authored
Make the code selecting the RGB quantization range a little less magicy by wrapping it up in a small helper. v2: s/adjusted_mode/mode in vc4 to make it actually compile v3: Add a comment proposed by Eric Signed-off-by:
-
Ville Syrjälä authored
drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect, so let's just include hdmi.h and drop some useless struct declarations. Signed-off-by:
-
Chris Wilson authored
Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler has been able to get smarter and spots that drm_mode_copy() is trying to preserve garbage from the stack. Fixes: 196cd5d3 ("drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/") Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
There's no late_unregister. While at it switch to the new canonical reference style. Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-14-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
The function operates on modes, not CRTCs. Also move it into drm_modes.[hc]. Spotted while reviewing CRTC docs. Reviewed-by:
-
Daniel Vetter authored
No point in documenting these, they only confuse. Reviewed-by:
-
Daniel Vetter authored
i915, nouveau (ever since merged to upstream) and radeon all lack ums support in upstream. No point keeping the ums vgaarb support around. Reviewed-by:
-
Daniel Vetter authored
With that the drm_pci_device_is_agp function becomes trivial, so inline that too. And while at it, move the drm_pci_agp_destroy declaration into drm-internal.h, since it's not used by drivers. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
-
Daniel Vetter authored
It's only for a device quirk, and we might as well do that in the load callback. Acked-by:
-
Daniel Vetter authored
Use the same trick we used for i915 when we still had ums support: Just initialize the agp support unconditionally in the driver load function. Unfortunately that means we need to export drm_agp_init again, but I think that's a lesser evil. Acked-by:
-
Daniel Vetter authored
There was a bit of mix-up between initialization and registering. v2: Review from Gustavo. Reviewed-by:
-
- 25 Jan, 2017 5 commits
-
-
Daniel Vetter authored
After going through all the trouble of splitting out parts from drm_crtc.[hc] and then properly documenting each I've entirely forgotten to show the same TLC for CRTCs themselves! Let's make amends asap. v2: Review from Eric. Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by:
-
Daniel Vetter authored
Returning 0 for an on-chip gpu doesn't change anything at all. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by:
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Eric. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Review from Gustavo. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
