summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2018-09-15HID: redragon: fix num lock and caps lock LEDsRobert Munteanu
commit dc9b8e85ed95cbe7e3ad0eabb5b48d617bbc365e upstream. The redragon asura keyboard registers two input devices. The initial commit 85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura Keyboard") considered this an error and prevented one of the devices from registering. However, once this is done the num lock and caps lock leds no longer toggle on and off, although the key functionality is not affected. This commit removes the code that prevents the input device registration and restores the num lock and caps lock LEDs. Fixes: 85455dd906d5 ("HID: redragon: Fix modifier keys for Redragon Asura Keyboard") Signed-off-by: Robert Munteanu <rombert@apache.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: Don't warn on destroying a pinned BOMichel Dänzer
commit 456607d816d89a442a3d5ec98b02c8bc950b5228 upstream. The warning turned out to be not so useful, as BO destruction tends to be deferred to a workqueue. Also, we should be preventing any damage from this now, so not really important anymore to fix code doing this. Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: Warn and update pin_size values when destroying a pinned BOMichel Dänzer
commit 15e6b76880e65be24250e30986084b5569b7a06f upstream. This shouldn't happen, but if it does, we'll get a backtrace of the caller, and update the pin_size values as needed. v2: * Check bo->pin_count instead of placement flags (Christian König) Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: Make pin_size values atomicMichel Dänzer
commit a5ccfe5c20740f2fbf00291490cdf8d2373ec255 upstream. Concurrent execution of the non-atomic arithmetic could result in completely bogus values. v2: * Rebased on v2 of the previous patch Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/106872 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: Keep track of amount of pinned CPU visible VRAMMichel Dänzer
commit ddc21af4d0f37f42b33c54cb69b215997fe5b082 upstream. Instead of CPU invisible VRAM. Preparation for the following, no functional change intended. v2: * Also change amdgpu_vram_mgr_bo_invisible_size to amdgpu_vram_mgr_bo_visible_size, allowing further simplification (Christian König) Cc: stable@vger.kernel.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/i915: set DP Main Stream Attribute for color range on DDI platformsJani Nikula
commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream. Since Haswell we have no color range indication either in the pipe or port registers for DP. Instead, there's a separate register for setting the DP Main Stream Attributes (MSA) directly. The MSA register definition makes no references to colorimetry, just a vague reference to the DP spec. The connection to the color range was lost. Apparently we've failed to set the proper MSA bit for limited, or CEA, range ever since the first DDI platforms. We've started setting other MSA parameters since commit dae847991a43 ("drm/i915: add intel_ddi_set_pipe_settings"). Without the crucial bit of information, the DP sink has no way of knowing the source is actually transmitting limited range RGB, leading to "washed out" colors. With the colorimetry information, compliant sinks should be able to handle the limited range properly. Native (i.e. non-LSPCON) HDMI was not affected because we do pass the color range via AVI infoframes. Though not the root cause, the problem was made worse for DDI platforms with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the "Broadcast RGB" property"), which selects limited range RGB automatically based on the mode, as per the DP, HDMI and CEA specs. After all these years, the fix boils down to flipping one bit. [Per testing reports, this fixes DP sinks, but not the LSPCON. My educated guess is that the LSPCON fails to turn the CEA range MSA into AVI infoframes for HDMI.] Reported-by: Michał Kopeć <mkopec12@gmail.com> Reported-by: N. W. <nw9165-3201@yahoo.com> Reported-by: Nicholas Stommel <nicholas.stommel@gmail.com> Reported-by: Tom Yan <tom.ty89@gmail.com> Tested-by: Nicholas Stommel <nicholas.stommel@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=100023 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v3.9+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com (cherry picked from commit dc5977da99ea28094b8fa4e9bacbd29bedc41de5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/i915: Re-apply "Perform link quality check, unconditionally during long ↵Jan-Marek Glogowski
pulse" commit 399334708b4f07b107094e5db4a390f0f25d2d4f upstream. 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 (cherry picked from commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: fix incorrect use of drm_file->pidChristian König
commit c4aed87630d41ee54e2ee23d4583c3dd423296dd upstream. That's the PID of the creator of the file (usually the X server) and not the end user of the file. 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> CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: fix incorrect use of fcheckChristian König
commit bce31d4c1ae8865d6382e3a27b07b4bb8e020ade upstream. The usage isn't RCU protected. 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> CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu:add VCN booting with firmware loaded by PSPLikun Gao
commit 4d77c0f676e910fb1f1870738aa4bd168f253621 upstream. Setup psp firmware loading for VCN, and make VCN block booting from tmr mac address. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu:add VCN support in PSP driverLikun Gao
commit 235ac9de625a0a586093ad81b3de6f7d7ab913ed upstream. Add VCN support in PSP driver Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu:add new firmware id for VCNLikun Gao
commit c9ca989696ff28ffb015cc2b7c5577938ef2626c upstream. Add the new firmware id for VCN into the enum Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu:add tmr mc address into amdgpu_firmware_infoJames Zhu
commit abf412b3efb2f943d9b98a489e9aca836be21333 upstream. amdgpu IP blocks booting need Trust Memory Region(tmr) mc address of its firmware which is loaded by PSP Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Likun Gao <likun.gao@amd.com> Signed-off-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: update tmr mc addressJames Zhu
commit 435198f33b56d7b875a8173a0227ddf0de285aa1 upstream. Update tmr mc address with firmware loading address which is returned from PSP firmware Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: Check if clock source in use before disablingMikita Lipski
commit ad8960a6cb06c446d0a391ce095f6f28edf36aff upstream. [why] We are disabling clock source while other pipes are still using it, because we don't verify the number of pipes that share it. [how] - Adding a function in resources to return the number of pipes sharing the clock source. - Checking that no one is sharing the clock source before disabling Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: Pass connector id when executing VBIOS CTMikita Lipski
commit 433149130c31de3f63b17b4ce08b45dab208f7e8 upstream. [why] Older ASICs require both phys_id and connector_id to execute bios command table. If we are not passing the right connector_id - it can lead to a black screen. [how] Set connector_obj_id when executing vbios command table Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/rockchip: vop: fix irq disabled after vop driver probedSandy Huang
commit 6456314ff1de246414a43e3132075b70b3e050ac upstream. The vop irq is shared between vop and iommu and irq probing in the iommu driver moved to the probe function recently. This can in some cases lead to a stall if the irq is triggered while the vop driver still has it disabled, but the vop irq handler gets called. But there is no real need to disable the irq, as the vop can simply also track its enabled state and ignore irqs in that case. For this we can simply check the power-domain state of the vop, similar to how the iommu driver does it. So remove the enable/disable handling and add appropriate condition to the irq handler. changes in v2: - move to just check the power-domain state - add clock handling changes in v3: - clarify comment to speak of runtime-pm not power-domain changes in v4: - address Marc's comments (clk-enable WARN_ON and style improvement) Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()") Cc: stable@vger.kernel.org Signed-off-by: Sandy Huang <hjc@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-3-heiko@sntech.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/rockchip: vop: split out core clock enablement into separate functionsHeiko Stuebner
commit e2810a7167df14c762e085fae5aade38425b71bf upstream. Judging from the iommu code, both the hclk and aclk are necessary for register access. Split them off into separate functions from the regular vop enablement, so that we can use them elsewhere as well. Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()") [prerequisite change for the actual fix] Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-2-heiko@sntech.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/rockchip: lvds: add missing of_node_putJulia Lawall
commit ebfb081edc8afd250a6d290c37481bfb2262e7cb upstream. The device node iterators perform an of_node_get on each iteration, so a jump out of the loop requires an of_node_put. The semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression root,e; local idexpression child; iterator name for_each_child_of_node; @@ for_each_child_of_node(root, child) { ... when != of_node_put(child) when != e = child + of_node_put(child); ? break; ... } ... when != child // </smpl> Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: stable@vger.kernel.org Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1527102436-13447-6-git-send-email-Julia.Lawall@lip6.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: Report non-DP display as disconnected without EDIDHarry Wentland
commit 01dc285d5cd89b77686d8baef8482c58d7dc3ead upstream. [Why] Some boards seem to have a problem where HPD is high on HDMI even though no display is connected. We don't want to report these as connected. DP spec still requires us to report DP displays as connected when HPD is high but we can't read the EDID in order to go to fail-safe mode. [How] If connector_signal is not DP abort detection if we can't retrieve the EDID. v2: Add Bugzilla and stable Bugzilla: https://bugs.freedesktop.org/107390 Bugzilla: https://bugs.freedesktop.org/106846 Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: Use requested HDMI aspect ratioLeo (Sunpeng) Li
commit e11d41472a50742c16d53c968e143fb498fa482f upstream. [Why] The DRM mode's HDMI picture aspect ratio field was never saved in dc_stream's timing struct. This causes us to mistake a new stream to have the same timings as the old, even though the user has requested a different aspect ratio. [How] Save DRM's aspect ratio field within dc_stream's timing struct. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107153 Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com> Reviewed-by: Mikita Lipski <Mikita.Lipski@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: update clk for various HDMI color depthsMikita Lipski
commit 81aca8e75c1b046865fb2badef95a0dcff6f73de upstream. [why] When programming tonga's connector's backend we didn't take in account that HDMI's colour depth might be more than 8bpc therefore we need to add a switch statement that would adjust the pixel clock accordingly. [how] Add a switch statement updating clock by its appropriate coefficient. Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: Don't share clk source between DP and HDMIMikita Lipski
commit 3e27e10e2ecee0d3a0083f8ae76354ac9c6ad15c upstream. [why] Prevent clock source sharing between HDMI and DP connectors. DP shouldn't be sharing its ref clock with phy clock, which caused an issue of older ASICS booting up with multiple diplays plugged in. [how] Add an extra check that would prevent HDMI and DP sharing clk. Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: fix type of variableGustavo A. R. Silva
commit fe78627d430435d22316fe39f2012ece31bf23c2 upstream. Currently, the maximum value that *counter* can reach is 255, and code at line 150: while (counter < 1000) { implies a bigger value could be expected. Fix this by changing the type of variable *counter* from uint8_t to uint16_t. Addresses-Coverity-ID: 1470030 ("Operands don't affect result") Fixes: 2b6199a1d1b7 ("drm/amd/display: replace msleep with udelay in fbc path") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80Kai-Heng Feng
commit 25da75043f8690fd083878447c91f289dfb63b87 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/edid: Quirk Vive Pro VR headset non-desktop.Lubosz Sarnecki
commit 6931317c714885f2d792e8150ef6715d416ac681 upstream. This adds the Vive Pro's EDID information and sets EDID_QUIRK_NON_DESKTOP. Signed-off-by: Lubosz Sarnecki <lubosz.sarnecki@collabora.com> Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Cc: <stable@vger.kernel.org> # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20180529115215.4526-1-lubosz.sarnecki@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/pp/Polaris12: Fix a chunk of registers missed to programRex Zhu
commit 2d227ec2c11c568910299e8f913bac2dda47397c upstream. DIDTConfig_Polaris12[] table missed a big chunk of data. Pointed by aidan.fabius <aidan.fabius@coreavi.com> Reviewed-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> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/powerplay: fixed uninitialized valueEvan Quan
commit 1ce0688f3f6a9e9d34ae66bf779d54855def7bec upstream. The 'result' is not initialized correctly. It causes the API return an error code even on success. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/pp: Convert voltage unit in mV*4 to mV on CZ/STRex Zhu
commit 8a50bb47a863c3cb8950a2e810448c9a82a9d446 upstream. the voltage showed in debugfs and hwmon should be in mV Reviewed-by: Evan Quan <evan.quan@amd.com> 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> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: Fix RLC safe mode test in gfx_v9_0_enter_rlc_safe_modeMichel Dänzer
commit 226127a67e31a9518d9516d3e4890759b379d874 upstream. We were testing the register offset, instead of the value stored in the register, therefore always timing out the loop. This reduces suspend time of the system in the bug report below by ~600 ms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/107277 Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: fix a reversed conditionRex Zhu
commit ccf9ef0b0d10434dec5046bcfc4e834a7b1830fd upstream. This test was reversed so it would end up leading to vddnb value can't be read via hwmon on APU. Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-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> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amdgpu: update uvd_v6_0_ring_vm_funcs to use new nop packetAlex Deucher
commit afb1436c7b44ab928e6369a4d48e3abb8215241e upstream. Was missed when updating the uvd 6 module. Fixes: 1aac3c9180 (drm/amdgpu: fix insert nop for UVD6 ring) Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/i915: Free write_buf that we allocated with kzalloc.Rodrigo Vivi
commit 1b1b1162745e5f9e5c6c095afc8081df3edabc50 upstream. 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 (cherry picked from commit 62d3a8deaa10b8346d979d0dabde56c33b742afa) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/i915: Increase LSPCON timeoutFredrik Schön
commit 299c2a904b1e8d5096d4813df6371357d97a6cd1 upstream. 100 ms is not enough time for the LSPCON adapter on Intel NUC devices to settle. This causes dropped display modes at boot or screen reconfiguration. Empirical testing can reproduce the error up to a timeout of 190 ms. Basic boot and stress testing at 200 ms has not (yet) failed. Increase timeout to 400 ms to get some margin of error. Changes from v1: The initial suggestion of 1000 ms was lowered due to concerns about delaying valid timeout cases. Update patch metadata. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107503 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392 Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v4.11+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Fredrik Schön <fredrik.schon@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180817200728.8154-1-fredrik.schon@gmail.com (cherry picked from commit 59f1c8ab30d6f9042562949f42cbd3f3cf69de94) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/i915: Nuke the LVDS lid notifierVille Syrjälä
commit 05c72e77ccda89ff624108b1b59a0fc43843f343 upstream. We broke the LVDS notifier resume thing in (presumably) commit e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as we no longer duplicate the current state in the LVDS notifier and thus we never resume it properly either. Instead of trying to fix it again let's just kill off the lid notifier entirely. None of the machines tested thus far have apparently needed it. Originally the lid notifier was added to work around cases where the VBIOS was clobbering some of the hardware state behind the driver's back, mostly on Thinkpads. We now have a few report of Thinkpads working just fine without the notifier. So maybe it was misdiagnosed originally, or something else has changed (ACPI video stuff perhaps?). If we do end up finding a machine where the VBIOS is still causing problems I would suggest that we first try setting various bits in the VBIOS scratch registers. There are several to choose from that may instruct the VBIOS to steer clear. With the notifier gone we'll also stop looking at the panel status in ->detect(). v2: Nuke enum modeset_restore (Rodrigo) Cc: stable@vger.kernel.org Cc: Wolfgang Draxinger <wdraxinger.maillist@draxit.de> Cc: Vito Caputo <vcaputo@pengaru.com> Cc: kitsunyan <kitsunyan@airmail.cc> Cc: Joonas Saarinen <jza@saunalahti.fi> Tested-by: Vito Caputo <vcaputo@pengaru.com> # Thinkapd X61s Tested-by: kitsunyan <kitsunyan@airmail.cc> # ThinkPad X200 Tested-by: Joonas Saarinen <jza@saunalahti.fi> # Fujitsu Siemens U9210 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902 References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html References: https://bugs.freedesktop.org/show_bug.cgi?id=21230 Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"Chris Wilson
commit 75eef0f1ed478284911b8723a5bdb659499a7aac upstream. The LPE audio is a child device of i915, it is powered up and down alongside the igfx and presents no independent runtime interface. This aptly fulfils the description of a "No-Callback" Device, so mark it thus. Fixes: 183c00350ccd ("drm/i915: Fix runtime PM for LPE audio") Testcase: igt/pm_rpm/basic-pci-d3-state Testcase: igt/pm_rpm/basic-rte Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180802140416.6062-1-chris@chris-wilson.co.uk (cherry picked from commit 46e831abe864a6b59fa3de253a681c0f2ee1bf2f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/etnaviv: fix crash in GPU suspend when init failed due to buffer placementLucas Stach
[ Upstream commit 5b147465532365dc4e2fee8499d6ca1f52dd0d16 ] When the suballocator was unable to provide a suitable buffer for the MMUv1 linear window, we roll back the GPU initialization. As the GPU is runtime resumed at that point we need to clear the kernel cmdbuf suballoc entry to properly skip any attempt to manipulate the cmdbuf when the GPU gets shut down in the runtime suspend later on. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15drm/amd/display: Read back max backlight value at bootDavid Francis
[ Upstream commit 53a53f8687faf492df2644d8c18ff0217fc18730 ] [Why] If there is no program explicitly setting the backlight brightness (for example, during a minimal install of linux), the hardware defaults to maximum brightness but the backlight_device defaults to 0 value. Thus, settings displays the wrong brightness value. [How] When creating the backlight device, set brightness to max Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15clk: rockchip: Add pclk_rkpwm_pmu to PMU critical clocks in rk3399Levin Du
[ Upstream commit 640332d1a089909df08bc9f3e42888a2019c66e2 ] PWM2 is commonly used to control voltage of PWM regulator of VDD_LOG in RK3399. On the Firefly-RK3399 board, PWM2 outputs 40 KHz square wave from power on and the VDD_LOG is about 0.9V. When the kernel boots normally into the system, the PWM2 keeps outputing PWM signal. But the kernel hangs randomly after "Starting kernel ..." line on that board. When it happens, PWM2 outputs high level which causes VDD_LOG drops to 0.4V below the normal operating voltage. By adding "pclk_rkpwm_pmu" to the rk3399_pmucru_critical_clocks array, PWM clock is ensured to be prepared at startup and the PWM2 output is normal. After repeated tests, the early boot hang is gone. This patch works on both Firefly-RK3399 and ROC-RK3399-PC boards. Signed-off-by: Levin Du <djw@t-chip.com.cn> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15iommu/omap: Fix cache flushes on L2 table entriesRalf Goebel
[ Upstream commit 04c532a1cdc7e423656c07937aa4b5c1c2b064f9 ] The base address used for DMA operations on the second-level table did incorrectly include the offset for the table entry. The offset was then added again which lead to incorrect behavior. Operations on the L1 table are not affected. The calculation of the base address is changed to point to the beginning of the L2 table. Fixes: bfee0cf0ee1d ("iommu/omap: Use DMA-API for performing cache flushes") Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Ralf Goebel <ralf.goebel@imago-technologies.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15staging: comedi: ni_mio_common: fix subdevice flags for PFI subdeviceIan Abbott
[ Upstream commit e083926b3e269d4064825dcf2ad50c636fddf8cf ] The PFI subdevice flags indicate that the subdevice is readable and writeable, but that is only true for the supported "M-series" boards, not the older "E-series" boards. Only set the SDF_READABLE and SDF_WRITABLE subdevice flags for the M-series boards. These two flags are mainly for informational purposes. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15dm kcopyd: avoid softlockup in run_complete_jobJohn Pittman
[ Upstream commit 784c9a29e99eb40b842c29ecf1cc3a79e00fb629 ] It was reported that softlockups occur when using dm-snapshot ontop of slow (rbd) storage. E.g.: [ 4047.990647] watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [kworker/10:23:26177] ... [ 4048.034151] Workqueue: kcopyd do_work [dm_mod] [ 4048.034156] RIP: 0010:copy_callback+0x41/0x160 [dm_snapshot] ... [ 4048.034190] Call Trace: [ 4048.034196] ? __chunk_is_tracked+0x70/0x70 [dm_snapshot] [ 4048.034200] run_complete_job+0x5f/0xb0 [dm_mod] [ 4048.034205] process_jobs+0x91/0x220 [dm_mod] [ 4048.034210] ? kcopyd_put_pages+0x40/0x40 [dm_mod] [ 4048.034214] do_work+0x46/0xa0 [dm_mod] [ 4048.034219] process_one_work+0x171/0x370 [ 4048.034221] worker_thread+0x1fc/0x3f0 [ 4048.034224] kthread+0xf8/0x130 [ 4048.034226] ? max_active_store+0x80/0x80 [ 4048.034227] ? kthread_bind+0x10/0x10 [ 4048.034231] ret_from_fork+0x35/0x40 [ 4048.034233] Kernel panic - not syncing: softlockup: hung tasks Fix this by calling cond_resched() after run_complete_job()'s callout to the dm_kcopyd_notify_fn (which is dm-snap.c:copy_callback in the above trace). Signed-off-by: John Pittman <jpittman@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15PCI: mvebu: Fix I/O space end address calculationThomas Petazzoni
[ Upstream commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 ] pcie->realio.end should be the address of last byte of the area, therefore using resource_size() of another resource is not correct, we must substract 1 to get the address of the last byte. Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15xen/balloon: fix balloon initialization for PVH Dom0Roger Pau Monne
[ Upstream commit 3596924a233e45aa918c961a902170fc4916461b ] The current balloon code tries to calculate a delta factor for the balloon target when running in HVM mode in order to account for memory used by the firmware. This workaround for memory accounting doesn't work properly on a PVH Dom0, that has a static-max value different from the target value even at startup. Note that this is not a problem for DomUs because guests are started with a static-max value that matches the amount of RAM in the memory map. Fix this by forcefully setting target_diff for Dom0, regardless of it's mode. Reported-by: Gabriel Bercarug <bercarug@amazon.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15Input: do not use WARN() in input_alloc_absinfo()Dmitry Torokhov
[ Upstream commit 100294cee9a98bfd4d6cb2d1c8a8aef0e959b0c4 ] Some of fuzzers set panic_on_warn=1 so that they can handle WARN()ings the same way they handle full-blown kernel crashes. We used WARN() in input_alloc_absinfo() to get a better idea where memory allocation failed, but since then kmalloc() and friends started dumping call stack on memory allocation failures anyway, so we are not getting anything extra from WARN(). Because of the above, let's replace WARN with dev_err(). We use dev_err() instead of simply removing message and relying on kcalloc() to give us stack dump so that we'd know the instance of hardware device to which we were trying to attach input device. Reported-by: Dmitry Vyukov <dvyukov@google.com> Acked-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15scsi: aic94xx: fix an error code in aic94xx_init()Dan Carpenter
[ Upstream commit 0756c57bce3d26da2592d834d8910b6887021701 ] We accidentally return success instead of -ENOMEM on this error path. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15ACPI / scan: Initialize status to ACPI_STA_DEFAULTHans de Goede
[ Upstream commit 5971b0c1594d6c34e257101ed5fdffec65205c50 ] Since commit 63347db0affa "ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs" the status field of normal acpi_devices gets set to 0 by acpi_bus_type_and_status() and filled with its actual value later when acpi_add_single_object() calls acpi_bus_get_status(). This means that any acpi_match_device_ids() calls in between will always fail with -ENOENT. We already have a workaround for this, which temporary forces status to ACPI_STA_DEFAULT in drivers/acpi/x86/utils.c: acpi_device_always_present() and the next commit in this series adds another acpi_match_device_ids() call between status being initialized as 0 and the acpi_bus_get_status() call. Rather then adding another workaround, this commit makes acpi_bus_type_and_status() initialize status to ACPI_STA_DEFAULT, this is safe to do as the only code looking at status between the initialization and the acpi_bus_get_status() call is those acpi_match_device_ids() calls. Note this does mean that we need to (re)set status to 0 in case the acpi_bus_get_status() call fails. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15s390/dasd: fix panic for failed online processingStefan Haberland
[ Upstream commit 7c6553d4db03350dad0110c3224194c19df76a8f ] Fix a panic that occurs for a device that got an error in dasd_eckd_check_characteristics() during online processing. For example the read configuration data command may have failed. If this error occurs the device is not being set online and the earlier invoked steps during online processing are rolled back. Therefore dasd_eckd_uncheck_device() is called which needs a valid private structure. But this pointer is not valid if dasd_eckd_check_characteristics() has failed. Check for a valid device->private pointer to prevent a panic. Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15s390/dasd: fix hanging offline processing due to canceled workerStefan Haberland
[ Upstream commit 669f3765b755fd8739ab46ce3a9c6292ce8b3d2a ] During offline processing two worker threads are canceled without freeing the device reference which leads to a hanging offline process. Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15brcmfmac: fix brcmf_wiphy_wowl_params() NULL pointer dereferenceWinnie Chang
[ Upstream commit 27a8aea13053700ad2a08189024df7e341d1ee51 ] The kernel BUG happens when wowl is enabled from firmware. In brcmf_wiphy_wowl_params(), cfg is a NULL pointer because it is drvr->config returned from wiphy_to_cfg(), and drvr->config is not set yet. To fix it, set drvr->config before brcmf_setup_wiphy() which calls brcmf_wiphy_wowl_params(). Fixes: 856d5a011c86 ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()") Signed-off-by: Winnie Chang <winnie.chang@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-24 22:49:20 +0000