summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2018-05-31drm/vc4: Add support for SAND modifier.Dave Stevenson
This is the format generated by VC4's H.264 engine, and preferred by the ISP as well. By displaying SAND buffers directly, we can avoid needing to use the ISP to rewrite the SAND H.264 output to linear before display. This is a joint effort by Dave Stevenson (who wrote the initial patch and DRM demo) and Eric Anholt (drm_fourcc.h generalization, safety checks, RGBA support). v2: Make the parameter macro give all of the middle 48 bits (suggested by Daniels). Fix fourcc_mod_broadcom_mod()'s bits/shift being swapped. Mark NV12/21 as supported, not YUV420. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> (v1) Cc: Boris Brezillon <boris.brezillon@bootlin.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-3-eric@anholt.net
2018-05-31drm/vc4: Add missing formats to vc4_format_mod_supported().Eric Anholt
Daniel's format_mod_supported() patch predated Dave's for NV21/61, and I didn't catch that when rebasing. This is a problem since the formats are now getting validated before being passed to the driver's atomic hooks. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Daniel Stone <daniels@collabora.com> Cc: Dave Stevenson <dave.stevenson@raspberrypi.org> Fixes: 423ad7b3cbd1 ("drm/vc4: Advertise supported modifiers for planes") Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-2-eric@anholt.net
2018-05-31drm: Trust format_mod_supported() when it OKs a plane modifier.Eric Anholt
For parameterized modifiers (Broadcom's SAND and UIF), we need to allow the parameter fields to be filled in, while exposing only the variant of the modifier with the parameter unfilled in the internal arrays and the format blob. Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-1-eric@anholt.net Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-05-30drm/i915: Promote .format_mod_supported() to the lead roleVille Syrjälä
Up to now we've used the plane's modifier list as the primary source of information for which modifiers are supported by a given plane. In order to allow auxiliary metadata to be embedded within the bits of the modifier we need to stop doing that. Thus we have to make .format_mod_supported() aware of the plane's capabilities and gracefully deal with any modifier being passed in directly from userspace. v2: Rebase after NV12 Simplify Cc: Eric Anholt <eric@anholt.net> References: https://lists.freedesktop.org/archives/dri-devel/2018-March/169782.html Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518162159.30305-1-ville.syrjala@linux.intel.com Reviewed-by: Eric Anholt <eric@anholt.net>
2018-05-29display: panel: Add AUO g070vvn01 display support (800x480)Lukasz Majewski
This commit adds support for AUO's 7.0" display. Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180514190849.18723-1-lukma@denx.de
2018-05-29gpu: drm: drm_vm: Adding new typedef vm_fault_tSouptick Joarder
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. commit 1c8f422059ae ("mm: change return type to vm_fault_t") Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180510134203.GA25166@jordon-HP-15-Notebook-PC
2018-05-28drm/fb-helper: Fix typo on kerneldocDaniel Vetter
Copypasta mistake. Fixes: 742547b73d27 ("drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs") Cc: Archit Taneja <architt@codeaurora.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524090105.21196-1-daniel.vetter@ffwll.ch
2018-05-28drm/sun4i: mark PM functions as __maybe_unusedArnd Bergmann
Disabling CONFIG_PM produces a compile time warning when these functions are not referenced: drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function] static int sun6i_dsi_runtime_suspend(struct device *dev) ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error: 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function] static int sun6i_dsi_runtime_resume(struct device *dev) ^~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525155030.3667352-1-arnd@arndb.de
2018-05-25drm/atmel-hlcdc: Stop using plane->fbVille Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Daniel pointed out that the drm_framebuffer_put() in the plane cleanup indicates that the driver doesn't shut things down cleanly. To do that we should be able to just call drm_atomic_helper_shutdown(). Not really sure the current cleanup sequence is actually sane, but whatever. v2: Replace the drm_framebuffer_put() with drm_atomic_helper_shutdown() (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-10-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-05-25drm/omapdrm: Nuke omap_framebuffer_get_next_connector()Ville Syrjälä
omap_framebuffer_get_next_connector() uses plane->fb which we want to deprecate for atomic drivers. As omap_framebuffer_get_next_connector() is unused just nuke the entire function. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-11-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2018-05-25drm: Add local 'plane' variable for tmp->primaryVille Syrjälä
Clean up the ugly tmp->primary-> stuff in __drm_mode_set_config_internal() with a local plane variable. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-13-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-05-25drm/atmel-hlcdc: Stop consulting plane->crtcVille Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop looking at it. Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-3-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-05-25drm/sti: Stop consulting plane->crtcVille Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop looking at it. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-05-25drm/msm: Stop consulting plane->fb/crtcVille Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop looking at them. v2: Catch the plane->crtc case too Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-05-25drm/arc: Stop consulting plane->fbVille Syrjälä
We want to stop using plane->fb with atomic driver, so stop looking at it. I have no idea what this code is trying to achieve. There is no corresponding check in the enable path. Also since arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going to assuming that I can just remove the check entirely. There seems to be a general shortage of .atomic_check() in this driver... Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405195035.24722-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Alexey Brodkin <abrodkin@synopys.com>
2018-05-25drm/edid: Fix up edid_cea_modes[] formattingVille Syrjälä
Fix up a bunch of bad indentation and insconsistent comments in edid_cea_modes[]. v2: Instead of stripping the aspect ratio comments let's add them to all modes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524192035.9776-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-25drm/xen-front: fix pointer castsOleksandr Andrushchenko
Building for a 32-bit target results in warnings from casting between a 32-bit pointer and a 64-bit integer. Fix the warnings by casting those pointers to uintptr_t first. Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180523113630.29811-1-andr2000@gmail.com
2018-05-24drm/i915: Pin the ring highChris Wilson
If we can use an unmappable ring, try to pin it out of the mappable aperture. This simple layout preference is to try and keep the mappable aperture reserved and available to handle GGTT mmapping requests from userspace without causing evictions and GPU stalls. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-4-chris@chris-wilson.co.uk
2018-05-24drm/i915: Limit searching for PIN_HIGHChris Wilson
To no surprise (since we've flip-flopped over the use of PIN_HIGH a few times), doing a search by address over a pathologically fragmented address space is exceeding slow. To protect ourselves from nearly unbounded latency (think searching a million holes while under struct_mutex), limit the search for the highest available hole and fallback to best-fit if it fails. In the pathologically fragmented case, such as igt/gem_ctx_thrash, the effect is dramatic, bringing the runtime down from hours to seconds (depending on how many other slow searches you hit, e.g. alloc_iova() and alloc_vmap_area() both degrade to a slow rbtree walk after their small cache is exhausted). For the real world, the number of search steps is unlikely to be significant as we should only need to search once per new context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-3-chris@chris-wilson.co.uk
2018-05-24drm/mm: Add a search-by-address variant to only inspect a single holeChris Wilson
Searching for an available hole by address is slow, as there no guarantee that a hole will be available and so we must walk over all nodes in the rbtree before we determine the search was futile. In many cases, the caller doesn't strictly care for the highest available hole and was just opportunistically laying out the address space in a preferred order. In such cases, the caller can accept any address and would rather do so then do a slow walk. To be able to mix search strategies, the caller wants to tell the drm_mm how long to spend on the search. Without a good guide for what should be the best split, start with a request to try once at most. That is return the top-most (or lowest) hole if it fulfils the alignment and size requirements. v2: Documentation, by why of example (selftests) and kerneldoc. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-2-chris@chris-wilson.co.uk
2018-05-24drm/mm: Reject over-sized allocation requests earlyChris Wilson
As we keep an rbtree of available holes sorted by their size, we can very easily determine if there is any hole large enough that might satisfy the allocation request. This helps when dealing with a highly fragmented address space and a request for a search by address. To cache the largest size, we convert into the cached rbtree variant which tracks the leftmost node for us. However, currently we sorted into ascending size order so the leftmost node is the smallest, and so to make it the largest hole we need to invert our sorting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-1-chris@chris-wilson.co.uk
2018-05-24gpu: drm: vgem: Change return type to vm_fault_tSouptick Joarder
Use new return type vm_fault_t for fault handler. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180416150232.GA26745@jordon-HP-15-Notebook-PC
2018-05-23gpu: drm: udl: Adding new typedef vm_fault_tSouptick Joarder
Use new return type vm_fault_t for fault and huge_fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f422059ae ("mm: change return type to vm_fault_t") Previously vm_insert_page() returns err which driver mapped into VM_FAULT_* type. The new function vmf_ insert_page() will replace this inefficiency by returning VM_FAULT_* type. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180425045922.GA21590@jordon-HP-15-Notebook-PC
2018-05-23drm/i2c: tda998x: Remove VLA usageLaura Abbott
There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The vla in reg_write_range is based on the length of data passed. The one use of a non-constant size for this range is bounded by the size buffer passed to hdmi_infoframe_pack which is a fixed size. Switch to this upper bound. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Laura Abbott <labbott@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180411010330.17866-1-labbott@redhat.com
2018-05-23drm/gma500: Remove VLALaura Abbott
There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. Switch to a reasonable upper bound for the VLAs in the gma500 driver. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Laura Abbott <labbott@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180409210647.3718-1-labbott@redhat.com
2018-05-22drm/gma500: Fix Medfield for drm_framebuffer moveDaniel Stone
Commit bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer") moved the gtt_range structure, from being in psb_framebuffer and embedding the GEM object, to being placed in the drm_framebuffer with the gtt_range being derived from the GEM object. The conversion missed out the Medfield subdriver, which was not being built in the default drm-misc config. Do the trivial fixup here. Signed-off-by: Daniel Stone <daniels@collabora.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Fixes: bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer") Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521142449.20800-1-daniels@collabora.com
2018-05-22drm/omap: Move buffer pitch/offset to drm_framebufferDaniel Stone
drm_framebuffer already holds per-plane pitch and offsets, which is filled out for us when we create the framebuffer. Nuke our local copy in the plane struct. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-7-daniels@collabora.com
2018-05-22drm/omap: Move GEM BO to drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-6-daniels@collabora.com
2018-05-21drm/v3d: Checking for NULL vs IS_ERR()Dan Carpenter
The v3d_fence_create() only returns error pointers on error. It never returns NULL. Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180518081041.GC28335@mwanda
2018-05-20drm/rockchip: lvds: avoid duplicating drm_bridge_attachPeter Rosin
drm_bridge_attach takes care of these assignments, so there is no need to open-code them a second time. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180502074025.12421-3-peda@axentia.se
2018-05-18drm/rockchip: rockchip_drm_fb -> drm_framebufferDaniel Stone
Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we can remove it. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Heiko Stübner <heiko@sntech.de> Tested-by: Heiko Stübner <heiko@sntech.de> Cc: Sandy Huang <hjc@rock-chips.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-5-daniels@collabora.com
2018-05-18drm/rockchip: Place GEM BOs in drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Heiko Stübner <heiko@sntech.de> Tested-by: Heiko Stübner <heiko@sntech.de> Cc: Sandy Huang <hjc@rock-chips.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-4-daniels@collabora.com
2018-05-18drm/mtk: mtk_drm_fb -> drm_framebufferDaniel Stone
Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can just delete it. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-3-daniels@collabora.com
2018-05-18drm/mtk: Move GEM BO to drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-2-daniels@collabora.com
2018-05-18drm/mtk: Remove impossible internal errorDaniel Stone
We cannot create a framebuffer with no objects, so there's no point testing for it. v2: Remove the error entirely. (Sean, CK, Thierry) Signed-off-by: Daniel Stone <daniels@collabora.com> Acked-by: Thierry Reding <treding@nvidia.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-1-daniels@collabora.com
2018-05-18drm/msm: Move GEM BOs to drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle function the same as the GEM framebuffer helper, we can reuse that. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-21-daniels@collabora.com
2018-05-18drm/gma500: Move GEM BO to drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-20-daniels@collabora.com
2018-05-18drm/armada: Move GEM BO to drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Russell King <linux@armlinux.org.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-19-daniels@collabora.com
2018-05-18drm/virtio: Place GEM BOs in drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-3-daniels@collabora.com
2018-05-18drm/cirrus: cirrus_framebuffer -> drm_framebufferDaniel Stone
Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer, we can drop it. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-2-daniels@collabora.com
2018-05-18drm/cirrus: Place GEM BOs in drm_framebufferDaniel Stone
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-1-daniels@collabora.com
2018-05-18drm/panel: simple: Fix data type in KEO TX31D200VM0BAA timingsStefan Agner
All values in a struct struct timing_entry (every entry in struct display_timing) require an integer. Choose the closest safe integer of 32. This avoids a warning seen with clang: drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit conversion from 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33 [-Wliteral-conversion] .vfront_porch = { 6, 21, 33.5 }, ~ ^~~~ drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit conversion from 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33 [-Wliteral-conversion] .vback_porch = { 6, 21, 33.5 }, ~ ^~~~ Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180419212003.8155-1-stefan@agner.ch
2018-05-18drm/panel: simple: AUO P320HVN03 uses SPWG data orderingLucas Stach
The patch adding support for the AUO P320HVN03 panel was written against a preliminary datasheet, which specified JEIDA data ordering. Testing with real hardware has shown that the actually used data ordering is SPWG. Fixes: 70c0d5b783f5 (drm/panel: simple: add support for AUO P320HVN03) Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411152741.22483-1-l.stach@pengutronix.de
2018-05-18drm/panel: simple: Add Innolux TV123WAM panel driver supportspanda@codeaurora.org
Add support for Innolux TV123WAM, which is a 12.3" eDP display panel with 2160x1440 resolution. Changes in v1: - Add the compatibility string, display_mode and panel_desc structures in alphabetical order (Sean Paul). Signed-off-by: Sandeep Panda <spanda@codeaurora.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1526363564-13823-4-git-send-email-spanda@codeaurora.org
2018-05-18drm/bridge: cdns: Mark runtime PM operations as maybe unusedThierry Reding
Building the driver in a configuration with !PM currently causes a warning about these operations being unused. Mark them as such to shut up the compiler. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426135853.30895-1-thierry.reding@gmail.com
2018-05-18drm/panel: otm8009a: Use new backlight APIPhilippe CORNU
The backlight API provides new functions to enable and disable the backlight and which hide the intricacies of achieving the correct result. Signed-off-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-5-philippe.cornu@st.com
2018-05-18drm/panel: otm8009a: No message if probe successPhilippe CORNU
Remove the message in case of probe success. This comes from a suggestion followed in the recent integration of the raydium rm68200 panel. Signed-off-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-4-philippe.cornu@st.com
2018-05-18drm/panel: otm8009a: Fix glitches by moving backlight enable to ↵Philippe CORNU
otm8009a_enable() The backlight 1st update was in the otm8009a_prepare() function for a bad reason: backlight was not working in video mode and the otm8009a_prepare() is in command mode for the init sequence. As the backlight is now fixed (no low-power mode), it is good to put it back in the otm8009a_enable() function, avoiding also image glitches visible on some "slow" devices. Signed-off-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-3-philippe.cornu@st.com
2018-05-18drm/panel: otm8009a: Fix backlight updatesPhilippe CORNU
Backlight updates was not working anymore since the good implementation of the DSI low-power mode in the DSI host driver. After a longer analysis, the backlight updates in DSI video mode require the DSI high- speed mode. Note: it is important to keep the DSI low-power mode for the rest of the driver as init sequence, sleep in/out... DSI commands work in low-power mode. Signed-off-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-2-philippe.cornu@st.com
2018-05-18drm/panel: Add device_link from panel device to DRM deviceJyri Sarha
Add device_link from panel device (supplier) to DRM device (consumer) when drm_panel_attach() is called. This patch should protect the master DRM driver if an attached panel driver unbinds while it is in use. The device_link should make sure the DRM device is unbound before the panel driver becomes unavailable. The device_link is removed when drm_panel_detach() is called. The drm_panel_detach() should be called by the consumer DRM driver, not the panel driver, otherwise both drivers are racing to delete the same link. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/b53584fd988d045c13de22d81825395b0ae0aad7.1524727888.git.jsarha@ti.com
generated by cgit (git 2.34.1) at 2025-06-10 14:18:56 +0000