- 25 May, 2018 1 commit
-
-
Oleksandr Andrushchenko authored
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
-
- 24 May, 2018 5 commits
-
-
Chris Wilson authored
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
-
Chris Wilson authored
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 authored
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 authored
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:
-
Souptick Joarder authored
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
-
- 23 May, 2018 3 commits
-
-
Souptick Joarder authored
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 1c8f4220 ("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:
-
Laura Abbott authored
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/621Signed-off-by:
Laura Abbott <labbott@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Laura Abbott authored
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/621Signed-off-by:
-
- 22 May, 2018 3 commits
-
-
Daniel Stone authored
Commit bc61c975 ("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: bc61c975 ("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
-
Daniel Stone authored
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:
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
-
Daniel Stone authored
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:
-
- 21 May, 2018 1 commit
-
-
Dan Carpenter authored
The v3d_fence_create() only returns error pointers on error. It never returns NULL. Fixes: 57692c94 ("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
-
- 20 May, 2018 1 commit
-
-
Peter Rosin authored
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
-
- 18 May, 2018 22 commits
-
-
Daniel Stone authored
Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we can remove it. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
-
Daniel Stone authored
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 authored
Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can just delete it. Signed-off-by:
CK Hu <ck.hu@mediatek.com> Reviewed-by:
-
Daniel Stone authored
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 authored
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 authored
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 authored
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 authored
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:
Russell King <linux@armlinux.org.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-19-daniels@collabora.com
-
Daniel Stone authored
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 authored
Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer, we can drop it. Signed-off-by:
-
Daniel Stone authored
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:
-
Stefan Agner authored
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:
-
Lucas Stach authored
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: 70c0d5b7 (drm/panel: simple: add support for AUO P320HVN03) Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
spanda@codeaurora.org authored
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:
-
spanda@codeaurora.org authored
Innolux TV123WAM is a 12.3" eDP display panel with 2160x1440 resolution, which can be supported by simple panel driver. Changes in v1: - Make use of simple panel driver instead of creating a new driver for this panel (Sean Paul). - Combine dt-binding and driver changes into one patch as done by other existing panel support changes. Changes in v2: - Separate driver change from dt-binding documentation (Rob Herring). - Add the properties from simple-panel binding that are applicable to this panel (Rob Herring). Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Thierry Reding authored
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:
-
Philippe CORNU authored
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:
-
Philippe CORNU authored
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 authored
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 authored
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:
-
Jyri Sarha authored
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:
-
Jyri Sarha authored
Remove all drm_panel_detach() calls from all panel drivers and update the kerneldoc for drm_panel_detach(). Setting the connector and drm to NULL when the DRM panel device is going away hardly serves any purpose. Usually the whole memory structure is freed right after the remove call. However, calling the detach function from the master DRM device, and setting the connector pointer to NULL, has the logic of marking the panel again as available for another DRM master to attach. The usual situation would be the same DRM master device binding again. Signed-off-by:
-
- 17 May, 2018 4 commits
-
-
Stanislav Lisovskiy authored
Added encoding of drm content_type property from drm_connector_state within AVI infoframe in order to properly handle external HDMI TV content-type setting. This requires also manipulationg ITC bit, as stated in HDMI spec. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-3-stanislav.lisovskiy@intel.com [vsyrjala: clean up checkpatch multiple blank lines warnings] Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Stanislav Lisovskiy authored
Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. v6: * Minor naming fix for the content type enumeration string. v7: * Fix parameter name for documentation and parameter alignment in order not to get warning. Added Content Type description to new HDMI connector properties section. v8: * Thrown away unneeded numbers from HDMI content-type property description. Switch to strings desription instead of plain definitions. v9: * Moved away hdmi specific content-type enum from drm_connector_state. Content type property should probably not be bound to any specific connector interface in drm_connector_state. Same probably should be done to hdmi_picture_aspect_ration enum which is also contained in drm_connector_state. Added special helper function to get derive hdmi specific relevant infoframe fields. v10: * Added usage description to HDMI properties kernel doc. v11: * Created centralized function for filling HDMI AVI infoframe, based on correspondent DRM property value. Acked-by:
-
Philippe Cornu authored
Minor fixes detected with "scripts/checkpatch.pl --strict" Signed-off-by:
-
Maxime Ripard authored
The vc4 HVS uses an internal RGB888 representation of the frames, and will by default expand formats using a lower depth using zeros. This causes an issue when we try to use other compositing software such as pixman that fill the missing bits by repeating the higher significant bits. As such, we can't check the display output in a reliable way by doing a software composition and an hardware one and compare both. To prevent this, force the same behaviour so that we can do such things. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
