summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2018-08-27drm/i915/psr: Remove wait_for_idle() for PSR2Dhinakaran Pandiyan
CI runs show PSR2 does not go to IDLE with selective update enabled on all PSR exit triggers. Specifically, logs indicate the hardware enters "SLEEP Selective Update" and not "IDLE Reset state', like the kernel expects, when vblank interrupts are enabled. This check was added for PSR1 but incorrectly extended to PSR2, remove the check as it breaks tests and prints out misleading error messages. v2: Split out non-code changes (Rodrigo) Cc: Tarun Vyas <tarun.vyas@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: c43dbcbbcc8c ("drm/i915/psr: Lockless version of psr_wait_for_idle") Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824230844.12428-1-dhinakaran.pandiyan@intel.com
2018-08-27drm/bridge: ti-sn65dsi86: Add mystery delay to enable()Sean Paul
This patch adds a 70ms mystery delay to the bridge driver in enable. By experimentation, it seems like it can go anywhere up until we initiate semi-auto link training. If we don't have the delay, link training fails. I tried to root cause this as best I could, but neither the datasheet for the panel nor the bridge mention a delay of this magnitude in their timing requirements. So for now, add the mystery delay until someone figures out a better fix. Changes in v3: - Added to the set Cc: Sandeep Panda <spanda@codeaurora.org> Reviewed-by: Sandeep Panda <spanda@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180813213058.184821-8-sean@poorly.run
2018-08-27Merge drm/drm-next into drm-misc-nextSean Paul
Now that 4.19-rc1 is cut, backmerge it into -misc-next. Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-08-27drm/mediatek: fix connection from RDMA2 to DSI1Stu Hsieh
This patch fix connection from RDMA2 to DSI1 Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: update some variable name from ovl to compStu Hsieh
This patch update some variable name from ovl to comp Because RDMA would be first HW in ddp, the naming ovl should be change to comp. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: use layer_nr function to get layer number to init planeStu Hsieh
This patch use layer_nr function to get layer number to init plane When plane init in crtc create, it use the number of OVL layer to init plane. That's OVL can read 4 memory address. For mt2712 third ddp, it use RDMA to read memory. RDMA can read 1 memory address, so it just init one plane. For compatibility, this patch use mtk_ddp_comp_layer_nr function to get layer number from their HW component in ddp for plane init. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add function to return RDMA layer numberStu Hsieh
This patch add function to return RDMA layer number RDMA always has one layer. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add function to return OVL layer numberStu Hsieh
This patch add function to return OVL layer number For now, MT8173, MT2712, MT2701 OVL all has 4 layer. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add function to get layer number for componentStu Hsieh
This patch add function to get layer number for component Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add YUYV/UYVY color format support for RDMAStu Hsieh
This patch add YUYV/UYVY color format support for RDMA and transform matrix for YUYV/UYVY. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add the comment about color format setting for OVLStu Hsieh
This patch add the comment about color format setting for OVL Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add RGB color format support for RDMAStu Hsieh
This patch add RGB color format support for RDMA, including RGB565, RGB888, RGBA8888 and ARGB8888. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add memory mode and layer_config for RDMAStu Hsieh
This patch add memory mode for RDMA and layer_config for RDMA If use RDMA to read data from memory, it should set memory mode to RDMA Layer config set the data address and pitch to RDMA from plane setting. Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add connection from RDMA2 to DSI0Stu Hsieh
This patch add connection from RDMA2 to DSI0 Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add connection from RDMA1 to DSI0Stu Hsieh
This patch add connection from RDMA1 to DSI0 Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add connection from RDMA0 to DSI1Stu Hsieh
This patch add connection from RDMA0 to DSI1 Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: add connection from RDMA0 to DPI1Stu Hsieh
This patch add connection from RDMA0 to DPI1 Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: Replace drm_dev_unref with drm_dev_putThomas Zimmermann
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-27drm/mediatek: Convert drm_atomic_helper_suspend/resume()Souptick Joarder
convert drm_atomic_helper_suspend/resume() to use drm_mode_config_helper_suspend/resume(). Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Ajit Negi <ajitn.linux@gmail.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2018-08-26Merge branch 'ida-4.19' of git://git.infradead.org/users/willy/linux-daxLinus Torvalds
Pull IDA updates from Matthew Wilcox: "A better IDA API: id = ida_alloc(ida, GFP_xxx); ida_free(ida, id); rather than the cumbersome ida_simple_get(), ida_simple_remove(). The new IDA API is similar to ida_simple_get() but better named. The internal restructuring of the IDA code removes the bitmap preallocation nonsense. I hope the net -200 lines of code is convincing" * 'ida-4.19' of git://git.infradead.org/users/willy/linux-dax: (29 commits) ida: Change ida_get_new_above to return the id ida: Remove old API test_ida: check_ida_destroy and check_ida_alloc test_ida: Convert check_ida_conv to new API test_ida: Move ida_check_max test_ida: Move ida_check_leaf idr-test: Convert ida_check_nomem to new API ida: Start new test_ida module target/iscsi: Allocate session IDs from an IDA iscsi target: fix session creation failure handling drm/vmwgfx: Convert to new IDA API dmaengine: Convert to new IDA API ppc: Convert vas ID allocation to new IDA API media: Convert entity ID allocation to new IDA API ppc: Convert mmu context allocation to new IDA API Convert net_namespace to new IDA API cb710: Convert to new IDA API rsxx: Convert to new IDA API osd: Convert to new IDA API sd: Convert to new IDA API ...
2018-08-25drm/i915: Re-apply "Perform link quality check, unconditionally during long ↵Jan-Marek Glogowski
pulse" This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com
2018-08-24drm/i915: move lookup_power_well() upPaulo Zanoni
There's no need for that forward declaration. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-4-paulo.r.zanoni@intel.com
2018-08-24drm/i915: use for_each_power_well in lookup_power_well()Paulo Zanoni
Use the nice helper function to make the implementation simpler. v2: Rebase. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-3-paulo.r.zanoni@intel.com
2018-08-24drm/i915: WARN() if we can't lookup_power_well()Paulo Zanoni
None of the current lookup_power_well() callers are actually checking for NULL return values, they all just use the pointer right away. The first idea was to replace these theoretical segfaults with a BUG() since this would at least make our code a little more explicit to the reader. It was suggested that just converting the BUG() to a WARN() and returning any power well would probably be better since it would still keep the system running while at the same time exposing the driver bug. We can only hit this NULL/BUG()/WARN() condition if we try to lookup a power well that isn't defined on a given platform. If that ever happens, we have to fix our code, making it lookup the correct power well. Because of this, I don't think it's worth trying to implement error checking in every caller. Improving our CI system will be a better use of our time once a bug is found in the wild. v2: Avoid the BUG() with a WARN() return a random PW (Michal). Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-2-paulo.r.zanoni@intel.com
2018-08-24drm/i915/icl: implement the tc/legacy HPD {dis,}connect flowsPaulo Zanoni
Unlike the other ports, TC ports are not available to use as soon as we get a hotplug. The TC PHYs can be shared between multiple controllers: display, USB, etc. As a result, handshaking through FIA is required around connect and disconnect to cleanly transfer ownership with the controller and set the type-C power state. This patch implements the flow sequences described by our specification. We opt to grab ownership of the ports as soon as we get the hotplugs in order to simplify the interactions and avoid surprises in the user space side. We may consider changing this in the future, once we improve our testing capabilities on this area. v2: * This unifies the DP and HDMI patches so we can discuss everything at once so people looking at random single patches can actually understand the direction. * I found out the spec was updated a while ago. There's a small difference in the connect flow and the patch was updated for that. * Our spec also now gives a good explanation on what is really happening. As a result, comments were added. * Add some more comments as requested by Rodrigo (Rodrigo). v3: * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act on in case it does (Chris). BSpec: 21750, 4250. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180801173441.9789-1-paulo.r.zanoni@intel.com
2018-08-24drm: Add per-plane pixel blend mode propertyLowry Li
Pixel blend modes represent the alpha blending equation selection, describing how the pixels from the current plane are composited with the background. Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to drm_plane, and related support functions. Defines three blend modes in drm_blend.h. Changes since v1: - Moves the blending equation into the DOC comment - Refines the comments of drm_plane_create_blend_mode_property to not enumerate the #defines, but instead the string values - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha Changes since v2: - Refines the comments of drm_plane_create_blend_mode_property: 1) Puts the descriptions (after the ":") on a new line 2) Adds explaining why @supported_modes need PREMUL as default Changes since v3: - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. - Since the current DRM assumption is that alpha is premultiplied as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better. - Refines some comments. Changes since v4: - Adds comments in drm_blend.h. - Removes setting default value in drm_plane_create_blend_mode_property() as it is already in __drm_atomic_helper_plane_reset(). - Fixes to use state->pixel_blend_mode instead of using plane->state->pixel_blend_mode in reset function. - Rebases on drm-misc-next. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Lowry Li <lowry.li@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/245734/
2018-08-24Merge tag 'drm-next-2018-08-24' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Just a couple of fixes" One MAINTAINERS address change, two panels fixes, and set of amdgpu fixes (build fixes, display fixes and some others)" * tag 'drm-next-2018-08-24' of git://anongit.freedesktop.org/drm/drm: drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 drm/amd/display: Don't build DCN1 when kcov is enabled Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86" drm/amdgpu/display: disable eDP fast boot optimization on DCE8 drm/amdgpu: fix amdgpu_amdkfd_remove_eviction_fence v3 drm/amdgpu: fix incorrect use of drm_file->pid drm/amdgpu: fix incorrect use of fcheck drm/powerplay: enable dpm under pass-through drm/amdgpu: access register without KIQ drm/amdgpu: set correct base for THM/NBIF/MP1 IP drm/amd/display: fix dentist did ranges drm/amd/display: make dp_ss_off optional drm/amd/display: fix dp_ss_control vbios flag parsing drm/amd/display: Do not retain link settings MAINTAINERS: drm-misc: Change seanpaul's email address drm/panel: simple: tv123wam: Add unprepare delay
2018-08-24drm/amd/display: Fix bug use wrong pp interfaceRex Zhu
Used wrong pp interface, the original interface is exposed by dpm on SI and paritial CI. Pointed out by Francis David <david.francis@amd.com> v2: dal only need to set min_dcefclk and min_fclk to smu. so use display_clock_voltage_request interface, instand of update all display configuration. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-24drm/sun4i: tcon-top: Use struct_size() in devm_kzalloc()Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL); This issue was detected with the help of Coccinelle. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824010521.GA25451@embeddedor.com
2018-08-24Merge tag 'drm-misc-next-fixes-2018-08-23-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next - Add quirk to Lenovo B50-80 to use 6 bpc instead of 8 (Feng) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20180823205434.GA137644@art_vandelay
2018-08-23drivers/gpu/drm/gma500/: change return type to 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. Ref-> 1c8f422059ae ("mm: change return type to vm_fault_t") Previously vm_insert_{pfn,mixed} returns err which driver mapped into VM_FAULT_* type. The new function vmf_insert_{pfn,mixed} will replace this inefficiency by returning VM_FAULT_* type. vmf_error() is the newly introduce inline function in 4.17-rc6. Link: http://lkml.kernel.org/r/20180713154541.GA3345@jordon-HP-15-Notebook-PC Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Cc: David Airlie <airlied@linux.ie> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-23drm/i915: Free write_buf that we allocated with kzalloc.Rodrigo Vivi
We use kzalloc to allocate the write_buf that we use for i2c transfer on hdcp write. But it seems that we are forgetting to free the memory that is not needed after i2c transfer is completed. Reported-by: Brian J Wood <brian.j.wood@intel.com> Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI") Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180823205136.31310-1-rodrigo.vivi@intel.com
2018-08-23drm/i915: Simplify condition to keep DMC active during S0ixImre Deak
For S0ix we want to deinit power domains (and so deactivate the DMC firmware) exactly when the platform supports the DC9 state. To reach S0ix we need DC9 on these platforms (for which the DMC FW needs to be deactivated) while to reach S0ix on the rest of the DMC platforms we need DC6 (which needs the DMC FW to stay active). Simplify the condition accordingly so it will be automatically correct for upcoming DC9 platforms like ICL. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822112602.27543-1-imre.deak@intel.com
2018-08-23drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80Kai-Heng Feng
Another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc instead of 8 bpc. Apply 6 bpc quirk for the panel to fix it. BugLink: https://bugs.launchpad.net/bugs/1788308 Cc: <stable@vger.kernel.org> # v4.8+ Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180823055332.7723-1-kai.heng.feng@canonical.com
2018-08-23Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next Fixes for 4.19: - Fix build when KCOV is enabled - Misc display fixes - A couple of SR-IOV fixes - Fence fixes for eviction handling for KFD - Misc other fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822203813.2733-1-alexander.deucher@amd.com
2018-08-23Merge tag 'drm-misc-next-fixes-2018-08-22' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20180822193850.GA214158@art_vandelay
2018-08-22include/linux/compiler*.h: make compiler-*.h mutually exclusiveNick Desaulniers
Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6") recently exposed a brittle part of the build for supporting non-gcc compilers. Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and __GNUC_PATCHLEVEL__ for quick compatibility with code bases that haven't added compiler specific checks for __clang__ or __INTEL_COMPILER. This is brittle, as they happened to get compatibility by posing as a certain version of GCC. This broke when upgrading the minimal version of GCC required to build the kernel, to a version above what ICC and Clang claim to be. Rather than always including compiler-gcc.h then undefining or redefining macros in compiler-intel.h or compiler-clang.h, let's separate out the compiler specific macro definitions into mutually exclusive headers, do more proper compiler detection, and keep shared definitions in compiler_types.h. Fixes: cafa0010cd51 ("Raise the minimum required gcc version to 4.6") Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by: Eli Friedman <efriedma@codeaurora.org> Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLEDhinakaran Pandiyan
Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandiyan@intel.com
2018-08-22drm/i915: Add a small wrapper to check for CCS modifiers.Dhinakaran Pandiyan
Code looks cleaner with modifiers hidden inside this wrapper. v2: Remove const qualifier (Ville) Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822193827.6341-1-dhinakaran.pandiyan@intel.com
2018-08-22drm/i915/psr: Add PSR mode/revision to debugfsAzhar Shaikh
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file i915_edp_psr_status. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1534958628-193724-1-git-send-email-azhar.shaikh@intel.com
2018-08-22drm/amdgpu: Fix page fault and kasan warning on pci device remove.Andrey Grodzovsky
Problem: When executing echo 1 > /sys/class/drm/card0/device/remove kasan warning as bellow and page fault happen because adev->gart.pages already freed by the time amdgpu_gart_unbind is called. BUG: KASAN: user-memory-access in amdgpu_gart_unbind+0x98/0x180 [amdgpu] Write of size 8 at addr 0000000000003648 by task bash/1828 CPU: 2 PID: 1828 Comm: bash Tainted: G W O 4.18.0-rc1-dev+ #29 Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming/AX370-Gaming-CF, BIOS F3 06/19/2017 Call Trace: dump_stack+0x71/0xab kasan_report+0x109/0x390 amdgpu_gart_unbind+0x98/0x180 [amdgpu] ttm_tt_unbind+0x43/0x60 [ttm] ttm_bo_move_ttm+0x83/0x1c0 [ttm] ttm_bo_handle_move_mem+0xb97/0xd00 [ttm] ttm_bo_evict+0x273/0x530 [ttm] ttm_mem_evict_first+0x29c/0x360 [ttm] ttm_bo_force_list_clean+0xfc/0x210 [ttm] ttm_bo_clean_mm+0xe7/0x160 [ttm] amdgpu_ttm_fini+0xda/0x1d0 [amdgpu] amdgpu_bo_fini+0xf/0x60 [amdgpu] gmc_v8_0_sw_fini+0x36/0x70 [amdgpu] amdgpu_device_fini+0x2d0/0x7d0 [amdgpu] amdgpu_driver_unload_kms+0x6a/0xd0 [amdgpu] drm_dev_unregister+0x79/0x180 [drm] amdgpu_pci_remove+0x2a/0x60 [amdgpu] pci_device_remove+0x5b/0x100 device_release_driver_internal+0x236/0x360 pci_stop_bus_device+0xbf/0xf0 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0xda/0xf0 kernfs_fop_write+0x186/0x220 __vfs_write+0xcc/0x330 vfs_write+0xe6/0x250 ksys_write+0xb1/0x140 do_syscall_64+0x77/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f66ebbb32c0 Fix: Split gmc_v{6,7,8,9}_0_gart_fini to postpone amdgpu_gart_fini to after memory managers are shut down since gart unbind happens as part of this procedure Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-22amdgpu: fix multi-process hang issueEmily Deng
SWDEV-146499: hang during multi vulkan process testing cause: the second frame's PREAMBLE_IB have clear-state and LOAD actions, those actions ruin the pipeline that is still doing process in the previous frame's work-load IB. fix: need insert pipeline sync if have context switch for SRIOV (because only SRIOV will report PREEMPTION flag to UMD) Signed-off-by: Monk Liu <Monk.Liu@amd.com> Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-22drm/amdgpu: fix preamble handlingChristian König
At this point the command submission can still be interrupted. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-22drm/amdgpu: fix VM clearing for the root PDChristian König
We need to figure out the address after validating the BO, not before. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-22drm/syncobj: Drop add/remove_callback from driver interfaceDaniel Vetter
This is used for handling future fences. Currently no driver use these, and I think given the new timeline fence proposed by KHR it would be better to have a more abstract interface for future fences. Could be something simple like a struct dma_future_fence plus a function to add a callback or wait for the fence to materialize. Then syncobj (and anything else really) could grow new functions to expose these two drivers. Normal dma_fence would then keep the nice guarantee that they will always signal (and through ordering, be deadlock free). dma_future_fence would then be the tricky one. This also fixes sphinx complaining about the kerneldoc. Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822092905.19884-1-daniel.vetter@ffwll.ch
2018-08-22mm, oom: distinguish blockable mode for mmu notifiersMichal Hocko
There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark an oom victim with blockable mmu notifiers as done after a short sleep. That can result in selecting a new oom victim prematurely because the previous one still hasn't torn its memory down yet. We can do much better though. Even if mmu notifiers use sleepable locks there is no reason to automatically assume those locks are held. Moreover majority of notifiers only care about a portion of the address space and there is absolutely zero reason to fail when we are unmapping an unrelated range. Many notifiers do really block and wait for HW which is harder to handle and we have to bail out though. This patch handles the low hanging fruit. __mmu_notifier_invalidate_range_start gets a blockable flag and callbacks are not allowed to sleep if the flag is set to false. This is achieved by using trylock instead of the sleepable lock for most callbacks and continue as long as we do not block down the call chain. I think we can improve that even further because there is a common pattern to do a range lookup first and then do something about that. The first part can be done without a sleeping lock in most cases AFAICS. The oom_reaper end then simply retries if there is at least one notifier which couldn't make any progress in !blockable mode. A retry loop is already implemented to wait for the mmap_sem and this is basically the same thing. The simplest way for driver developers to test this code path is to wrap userspace code which uses these notifiers into a memcg and set the hard limit to hit the oom. This can be done e.g. after the test faults in all the mmu notifier managed memory and set the hard limit to something really small. Then we are looking for a proper process tear down. [akpm@linux-foundation.org: coding style fixes] [akpm@linux-foundation.org: minor code simplification] Link: http://lkml.kernel.org/r/20180716115058.5559-1-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Acked-by: Christian König <christian.koenig@amd.com> # AMD notifiers Acked-by: Leon Romanovsky <leonro@mellanox.com> # mlx and umem_odp Reported-by: David Rientjes <rientjes@google.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Mike Marciniszyn <mike.marciniszyn@intel.com> Cc: Dennis Dalessandro <dennis.dalessandro@intel.com> Cc: Sudeep Dutt <sudeep.dutt@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Dimitri Sivanich <sivanich@sgi.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-22Revert "drm: crc: Wait for a frame before returning from open()"Mahesh Kumar
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. Don't wait for first CRC during crtc_crc_open. It avoids one frame wait during open. If application want to wait after read call, it can use poll/read blocking read() call. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821083858.26275-4-mahesh1.kumar@intel.com
2018-08-22drm/crc: Cleanup crtc_crc_open functionMahesh Kumar
This patch make changes to allocate crc-entries buffer before enabling CRC generation. It moves all the failure check early in the function before setting the source or memory allocation. Now set_crc_source takes only two variable inputs, values_cnt we already gets as part of verify_crc_source. Changes since V1: - refactor code to use single spin lock Changes since V2: - rebase Changes since V3: - rebase on top of VKMS driver Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Leo Li <sunpeng.li@amd.com> (V2) Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (V3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821083858.26275-3-mahesh1.kumar@intel.com
2018-08-22drm/vkms/crc: Implement verify_crc_source callbackMahesh Kumar
This patch implements "verify_crc_source" callback function for Virtual KMS drm driver. Changes Since V1: - update values_cnt in verify_crc_source Changes Since V2: - don't return early from set_crc_source to keep behavior same (Haneen) Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Haneen Mohammed <hamohammed.sa@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821083858.26275-2-mahesh1.kumar@intel.com
2018-08-22drm/i915: Fix glk/cnl display w/a #1175Ville Syrjälä
The workaround was supposed to look at the plane destination coordinates. Currently it's looking at some mixture of src and dst coordinates that doesn't make sense. Fix it up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719182214.4323-2-ville.syrjala@linux.intel.com Fixes: 394676f05bee (drm/i915: Add WA for planes ending close to left screen edge) Reviewed-by: Imre Deak <imre.deak@intel.com>