summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-02-06nvme-pci: fix rapid add remove sequenceKeith Busch
A surprise removal may fail to tear down request queues if it is racing with the initial asynchronous probe. If that happens, the remove path won't see the queue resources to tear down, and the controller reset path may create a new request queue on a removed device, but will not be able to make forward progress, deadlocking the pci removal. Protect setting up non-blocking resources from a shutdown by holding the same mutex, and transition to the CONNECTING state after these resources are initialized so the probe path may see the dead controller state before dispatching new IO. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202081 Reported-by: Alex Gagniuc <Alex_Gagniuc@Dellteam.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Tested-by: Alex Gagniuc <mr.nuke.me@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-02-06nvme: lock NS list changes while handling command effectsKeith Busch
If a controller supports the NS Change Notification, the namespace scan_work is automatically triggered after attaching a new namespace. Occasionally the namespace scan_work may append the new namespace to the list before the admin command effects handling is completed. The effects handling unfreezes namespaces, but if it unfreezes the newly attached namespace, its request_queue freeze depth will be off and we'll hit the warning in blk_mq_unfreeze_queue(). On the next namespace add, we will fail to freeze that queue due to the previous bad accounting and deadlock waiting for frozen. Fix that by preventing scan work from altering the namespace list while command effects handling needs to pair freeze with unfreeze. Reported-by: Wen Xiong <wenxiong@us.ibm.com> Tested-by: Wen Xiong <wenxiong@us.ibm.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-02-06aio: initialize kiocb private in case any filesystems expect it.Mike Marshall
A recent optimization had left private uninitialized. Fixes: 2bc4ca9bb600 ("aio: don't zero entire aio_kiocb aio_get_req()") Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mike Marshall <hubcap@omnibond.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-02-06mmc: sunxi: Filter out unsupported modes declared in the device treeChen-Yu Tsai
The MMC device tree bindings include properties used to signal various signalling speed modes. Until now the sunxi driver was accepting them without any further filtering, while the sunxi device trees were not actually using them. Since some of the H5 boards can not run at higher speed modes stably, we are resorting to declaring the higher speed modes per-board. Regardless, having boards declare modes and blindly following them, even without proper support in the driver, is generally a bad thing. Filter out all unsupported modes from the capabilities mask after the device tree properties have been parsed. Cc: <stable@vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-06mmc: sunxi: Disable HS-DDR mode for H5 eMMC controller by defaultChen-Yu Tsai
Some H5 boards seem to not have proper trace lengths for eMMC to be able to use the default setting for the delay chains under HS-DDR mode. These include the Bananapi M2+ H5 and NanoPi NEO Core2. However the Libre Computer ALL-H3-CC-H5 works just fine. For the H5 (at least for now), default to not enabling HS-DDR modes in the driver, and expect the device tree to signal HS-DDR capability on boards that work. Reported-by: Chris Blake <chrisrblake93@gmail.com> Fixes: 07bafc1e3536 ("mmc: sunxi: Use new timing mode for A64 eMMC controller") Cc: <stable@vger.kernel.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-06drm/i915: Just use icl+ definition for PLANE_WM blocks fieldVille Syrjälä
The unused bits on PLANE_WM & co. are hardwired to zero. So no need to worry about reading the extra bit on pre-icl. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205205056.30081-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2019-02-06drm/i915: Bump skl+ wm blocks to 11 bitsVille Syrjälä
On icl the plane watermark blocks field is 11 bits. Bump our define to match so that readout won't ignore the extra bit. We can safely do this for older platforms too since the unused bits are hardwired to zero. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205205056.30081-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2019-02-06drm/omap: dsi: Hack-fix DSI bus flagsTomi Valkeinen
Since commit b4935e3a3cfa ("drm/omap: Store bus flags in the omap_dss_device structure") video mode flags are managed by the omapdss (and later omapdrm) core based on bus flags stored in omap_dss_device. This works fine for all devices whose video modes are set by the omapdss and omapdrm core, but breaks DSI operation as the DSI still uses legacy code paths and sets the DISPC timings manually. To fix the problem properly we should move the DSI encoder to the new encoder model. This will however require a considerable amount of work. Restore DSI operation by adding back video mode flags handling in the DSI encoder driver as a hack in the meantime. Fixes: b4935e3a3cfa ("drm/omap: Store bus flags in the omap_dss_device structure") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-5-laurent.pinchart@ideasonboard.com
2019-02-06drm/omap: dsi: Fix OF platform depopulateTomi Valkeinen
Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind to probe") moved the of_platform_populate() call from dsi_bind() to dsi_probe(), but failed to move the corresponding of_platform_depopulate() from dsi_unbind() to dsi_remove(). This results in OF child devices being potentially removed multiple times. Fix it by placing the of_platform_depopulate() call where it belongs. Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind to probe") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-4-laurent.pinchart@ideasonboard.com
2019-02-06drm/omap: dsi: Fix crash in DSI debug dumpsTomi Valkeinen
Reading any of the DSI debugfs files results in a crash, as wrong pointer is passed to the dump functions, and the dump functions use a wrong pointer. This patch fixes DSI debug dumps. Fixes: f3ed97f9ae7d ("drm/omap: dsi: Simplify debugfs implementation") Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-3-laurent.pinchart@ideasonboard.com
2019-02-06drm/i915/pmu: Fix enable count array size and bounds checkingTvrtko Ursulin
Enable count array is supposed to have one counter for each possible engine sampler. As such, array sizing and bounds checking is not correct and would blow up the asserts if more samplers were added. No ill-effect in the current code base but lets fix it for correctness. At the same time tidy the assert for readability and robustness. v2: * One check per assert. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: b46a33e271ed ("drm/i915/pmu: Expose a PMU interface for perf queries") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190205130353.21105-1-tvrtko.ursulin@linux.intel.com
2019-02-06cfg80211: pmsr: fix abort lockingJohannes Berg
When we destroy the interface we already hold the wdev->mtx while calling cfg80211_pmsr_wdev_down(), which assumes this isn't true and flushes the worker that takes the lock, thus leading to a deadlock. Fix this by refactoring the worker and calling its code in cfg80211_pmsr_wdev_down() directly. We still need to flush the work later to make sure it's not still running and will crash, but it will not do anything. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-06cfg80211: pmsr: fix MAC address settingJohannes Berg
When we *don't* have a MAC address attribute, we shouldn't try to use this - this was intended to copy the local MAC address instead, so fix it. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-06mtd: rawnand: gpmi: fix MX28 bus master lockup problemMartin Kepplinger
Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft reset may cause bus master lock up") for MX28 too. It has the same problem. Observed problem: once per 100,000+ MX28 reboots NAND read failed on DMA timeout errors: [ 1.770823] UBI: attaching mtd3 to ubi0 [ 2.768088] gpmi_nand: DMA timeout, last DMA :1 [ 3.958087] gpmi_nand: BCH timeout, last DMA :1 [ 4.156033] gpmi_nand: Error in ECC-based read: -110 [ 4.161136] UBI warning: ubi_io_read: error -110 while reading 64 bytes from PEB 0:0, read only 0 bytes, retry [ 4.171283] step 1 error [ 4.173846] gpmi_nand: Chip: 0, Error -1 Without BCH soft reset we successfully executed 1,000,000 MX28 reboots. I have a quote from NXP regarding this problem, from July 18th 2016: "As the i.MX23 and i.MX28 are of the same generation, they share many characteristics. Unfortunately, also the erratas may be shared. In case of the documented erratas and the workarounds, you can also apply the workaround solution of one device on the other one. This have been reported, but I’m afraid that there are not an estimated date for updating the Errata documents. Please accept our apologies for any inconveniences this may cause." Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems") Cc: stable@vger.kernel.org Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Han Xu <han.xu@nxp.com> Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
2019-02-06drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSenVille Syrjälä
Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. v2: Fix potential NULL deref (kbuild test robot) Constify has_bogus_dpll_config() Cc: stable@vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089@gmail.com> Reported-by: Daniel Kamil Kozar <dkk089@gmail.com> Tested-by: Daniel Kamil Kozar <dkk089@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 7bed8adcd9f86231bb69bbc02f88ad89330f99e3) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205141846.6053-1-ville.syrjala@linux.intel.com
2019-02-06ALSA: hda/ca0132 - Fix build error without CONFIG_PCITakashi Iwai
A call of pci_iounmap() call without CONFIG_PCI leads to a build error on some architectures. We tried to address this and add a check of IS_ENABLED(CONFIG_PCI), but this still doesn't seem enough for sh. Ideally we should fix it globally, it's really a corner case, so let's paper over it with a simpler ifdef. Fixes: 1e73359a24fa ("ALSA: hda/ca0132 - make pci_iounmap() call conditional") Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-02-05drm/amd/display: Disconnect mpcc when changing tgNicholas Kazlauskas
[Why] This fixes an mpc programming error for the following sequence of atomic commits when pipe split is enabled: Commit 1: CRTC0 (plane 4, plane 3) Pipe 0: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 1: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Pipe 2: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 3: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Commit 2: CRTC0 (plane 3), CRTC1 (plane 2) Pipe 0: old_plane_state = A1, new_plane_state = A2, new_tg = T0 Pipe 1: old_plane_state = B1, new_plane_state = B2, new_tg = T1 Pipe 2: old_plane_state = A1, new_plane_state = NULL, new_tg = NULL Pipe 3: old_plane_state = B1, new_plane_state = NULL, new_tg = NULL In the second commit the assertion for mpcc in use is hit because mpcc disconnect never occurs for pipe 1. This is because the stream changes for pipe 1 and the opp_list is empty. This sequence occurs when running the "igt@kms_plane_multiple@atomic-pipe-A-tiling-none" test with two displays connected. [How] Expand the reset condition to include: "old_pipe_ctx->stream_res.tg != new_pipe_ctx->stream_res.tg" ...but only when the plane state is non-NULL for both old and new. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Apply fake sink back to MST sequenceJerry (Fangzhi) Zuo
[Why] It fixes the failure to create stream for sink in the scenario when hotplug SST and MST in sequence, and disconnect MST. [How] Add the fake sink back after the majority of MST rework is done. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: add a debug flag to force odm combineDmytro Laktyushkin
Adding a bit vector to allow forcing odm on specific otgs Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@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>
2019-02-05drm/amd/display: store timing sync info in dc_stream_statusSu Sung Chung
in program_timing_sync, after all the pipes are grouped, store timing sync info in dc_stream_status Signed-off-by: Su Sung Chung <Su.Chung@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Modify ABM 2.2 Max ReductionJosip Pavic
[Why] Reduced backlight for ABM 2.2 at levels 1 and 2 is desired for power savings. [How] Reduce the max reduction parameters for ABM 2.2 Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Josip Pavic <Josip.Pavic@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: pass vline_config parameter by reference.Yongqiang Sun
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: add gpio lock/unlockChiawen Huang
[Why] When querying HPD via GPIO flow, it will create a new gpio object then free in the end of query. There is a irql issue for HPD querying at ISR level. [How] Therefore, creating the HPD gpio object in dc_link and set it as unlcok in default. 1. reducing unnecessary malloc/free when HPD querying. 2. reducing init GPIO flow. 3. add lock/unlock to prevent multi gpio service running. Signed-off-by: Chiawen Huang <chiawen.huang@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: 3.2.16Steven Chiu
Signed-off-by: Steven Chiu <steven.chiu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: determine if a pipe is synced by plane stateWenjing Liu
[why] is_blanked is not a general indicator of if a pipe is synced for all asics. plane state is more accurate and applicable for all asics. [how] Remove is_blanked call and add checking plane_state against NULL instead. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: DGAM enabled for HDRKrunoslav Kovac
[Why] On HW that doesn't have input LUT, we may combine degamma with OS ramp Problem here is that it assumes DGAM is inverse of PQ or SRGB. It doesn't handle linear case, it would default to sRGB and always enable DGAM.. [How] Add handling for linear case. Also check for null ramp and instead of blowing up, assume it's identity. Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Check that vrefresh is in freesync rangeIlya Bakoulin
[Why] Setting monitor refresh rate below freesync range would cause the monitor to go blank indefinitely with freesync enabled [How] Set vrr_supported and ignore_msa_timing_param according to whether the refresh rate is above or below the minimum freesync frequency. Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: dmcu is blocking due to wrong disable ABM commandPaul Hsieh
[Why] Second screen to clone/extend mode, driver will send ABM pipe command to DMCU. Change mode from clone/extend to second screen only, driver send ABM level command to disable ABM but this command will not clear ABM pipe data. At this time, change second screen to PC screen only, driver will send first command "ABM_LEVEL", it will turn on ABM with incorrect ABM pile so that DMCU is blocking. [How] When driver try to disable ABM, change command from "ABM LEVEL" to "ABM PIPE" so that it will clear ABM pile data. Signed-off-by: Paul Hsieh <Paul.Hsieh@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>
2019-02-05drm/amd/display: fix issue with DC brightness low with VBAnthony Koo
[Why] The problem is that we accidentally stopped loading some of the IRAM bytes used for the backlight ramping mechanism. This happened when we started reserving some region of IRAM as DMCU FW write only. [How] This change will define a start+end region for the IRAM read only region. So the parameters needed for the backlight operation will be loaded since it will be defined outside of the read only region. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Add monitor patch for backlight offXiaodong Yan
[Why] Different panel need different time from backlight disable to end of valid video data, if the time is too short, panel will flash when dpms off [How] Add monitor patch to control the time from backlight disable to end of valid video data, Signed-off-by: Xiaodong Yan <Xiaodong.Yan@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Remove FreeSync timing changed debug outputNicholas Kazlauskas
[Why] This provides little debug value and creates a lot of dmesg noise. [How] Remove it. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Initialize stream_update to zeroNicholas Kazlauskas
[Why] The stream_update struct is left unitialized but DC will access its fields. This usually results in global state validation occur during any atomic commit with state->allow_modeset = true. [How] Initialize the struct to zero for every stream we check. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Reformat dm_determine_update_type_for_commitNicholas Kazlauskas
[Why] The indenting for this function is a few levels too deep and can be simplified a fair bit. This patch is in preparation for functional changes that fix update type determination to occur less frequently and more accurately. [How] Place checks early and exit/continue when possible. This isn't a functional change. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use the right surface for flip and FreeSyncNicholas Kazlauskas
[Why] We were always passing the first surface on the stream status for flip updates when we should be using the surface associated with the plane. [How] Use the dc_plane_state from the plane that's being updated. FreeSync should also only keep track of updates from the primary plane, so the check needed to be updated. The acrtc->stream state doesn't need to be checked for NULL before updating FreeSync either since there needs to be a stream to be inside this function as a prerequisite. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Apply all surface updates onto surfacesNicholas Kazlauskas
[Why] Most surface updates weren't propagated onto the surface during dc_commit_updates_for_stream. This makes it more difficult for DC to determine the actual surface update type required. [How] Use copy_surface_update_to_plane to propagate the changes. The FreeSync surface timing information update for BTR has been moved out of amdgpu_dm.c into this function as well. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use udelay when waiting between aux retriesJohn Barberiz
[Why] "IRQ_HPD Pulse Length Test" DP compliance test fails. Test complains that certain DPCD registers are not read within 100 ms. [How] msleep is inaccurate for small values. Used udelay instead for accuracy. Signed-off-by: John Barberiz <John.Barberiz@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: cleanup VM dw estimation a bitChristian König
No functional change. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: fix waiting for BO moves with CPU based PD/PT updatesChristian König
Otherwise we open up the possibility to use uninitialized memory. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use context parameters to enable FBCShirish S
[What] FBC fails to get enabled when switched between LINEAR(console/VT) and non-LINEAR(GUI) based rendering due to default value of tiling info stored in the current_state which is used for deciding whether or not to turn FBC on or off. [How] Use context structure's tiling information which is coherant with the screen updates. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Don't re-enable CRC when CONFIG_DEBUG_FS isn't definedNicholas Kazlauskas
[Why] When CONFIG_DEBUG_FS isn't defined then amdgpu_dm_crtc_set_crc_source is NULL. This causes a compilation error since it's being called unconditionally. [How] Guard the call based on CONFIG_DEBUG_FS - CRC capture isn't supported without this. Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Fixes: 43a6a02eb355 ("drm/amd/display: Re-enable CRC capture following modeset") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: add a workaround for GDS ordered append hangs with compute queuesMarek Olšák
I'm not increasing the DRM version because GDS isn't totally without bugs yet. v2: update emit_ib_size Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-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>
2019-02-05drm/amdgpu: Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIESAndrey Grodzovsky
New chunk for dependency on start of job's execution instead on the end. This is used for GPU deadlock prevention when userspace uses mid-IB fences to wait for mid-IB work on other rings. v2: Fix typo in AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES v3: Bump KMS version v4: put old fence AFTER acquiring the scheduled fence. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Suggested-by: Christian Koenig <Christian.Koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/powerplay: update soc boot and max level on vega10Kenneth Feng
update soc boot and max level,then uclk isn't stuck at minimum. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109462 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use memset to initialize variables in fill_plane_dcc_attributesNathan Chancellor
Clang warns: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2314:38: warning: suggest braces around initialization of subobject [-Wmissing-braces] struct dc_surface_dcc_cap output = {0}; ^ {} Previous efforts to fix this type of warning by adding or removing braces have been met with some pushback in favor of using memset [1][2]. Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree. [1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/ [2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/ Fixes: 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for GFX9") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use memset to initialize variables in ↵Nathan Chancellor
amdgpu_dm_atomic_commit_tail Clang warns: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5089:60: warning: suggest braces around initialization of subobject [-Wmissing-braces] struct dc_surface_update dummy_updates[MAX_SURFACES] = { 0 }; ^ {} Previous efforts to fix this type of warning by adding or removing braces have been met with some pushback in favor of using memset [1][2]. Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree. [1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/ [2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/ Fixes: 02d6a6fcdf68 ("drm/amd/display: Simplify underscan and ABM commit") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use memset to initialize variable in ↵Nathan Chancellor
wait_for_training_aux_rd_interval Clang warns: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:50:57: warning: suggest braces around initialization of subobject [-Wmissing-braces] union training_aux_rd_interval training_rd_interval = {0}; ^ {} 1 warning generated. Previous efforts to fix this type of warning by adding or removing braces have been met with some pushback in favor of using memset [1][2]. Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree. [1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/ [2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/ Fixes: 3cec41769d21 ("drm/amd/display: Fix use of uninitialized union") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/amdgpu: fix spelling mistake "matech" -> "match"Colin Ian King
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05mISDN: fix a race in dev_expire_timer()Eric Dumazet
Since mISDN_close() uses dev->pending to iterate over active timers, there is a chance that one timer got removed from the ->pending list in dev_expire_timer() but that the thread has not called yet wake_up_interruptible() So mISDN_close() could miss this and free dev before completion of at least one dev_expire_timer() syzbot was able to catch this race : BUG: KASAN: use-after-free in register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827 Write of size 8 at addr ffff88809fc18948 by task syz-executor1/24769 CPU: 1 PID: 24769 Comm: syz-executor1 Not tainted 5.0.0-rc5 #60 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:140 register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827 __lock_acquire+0x11f/0x4700 kernel/locking/lockdep.c:3224 lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152 __wake_up_common_lock+0xc7/0x190 kernel/sched/wait.c:120 __wake_up+0xe/0x10 kernel/sched/wait.c:145 dev_expire_timer+0xe4/0x3b0 drivers/isdn/mISDN/timerdev.c:174 call_timer_fn+0x190/0x720 kernel/time/timer.c:1325 protocol 88fb is buggy, dev hsr_slave_0 protocol 88fb is buggy, dev hsr_slave_1 expire_timers kernel/time/timer.c:1362 [inline] __run_timers kernel/time/timer.c:1681 [inline] __run_timers kernel/time/timer.c:1649 [inline] run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694 __do_softirq+0x266/0x95a kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x180/0x1d0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 </IRQ> RIP: 0010:__sanitizer_cov_trace_pc+0x26/0x50 kernel/kcov.c:101 Code: 90 90 90 90 55 48 89 e5 48 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 98 12 92 7e 81 e2 00 01 1f 00 75 2b 8b 90 d8 12 00 00 <83> fa 02 75 20 48 8b 88 e0 12 00 00 8b 80 dc 12 00 00 48 8b 11 48 RSP: 0018:ffff8880589b7a60 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: ffff888087ce25c0 RBX: 0000000000000001 RCX: ffffffff818f8ca3 RDX: 0000000000000000 RSI: ffffffff818f8b48 RDI: 0000000000000001 RBP: ffff8880589b7a60 R08: ffff888087ce25c0 R09: ffffed1015d25bd0 R10: ffffed1015d25bcf R11: ffff8880ae92de7b R12: ffffea0001ae4680 R13: ffffea0001ae4688 R14: 0000000000000000 R15: ffffea0001b41648 PageIdle include/linux/page-flags.h:398 [inline] page_is_idle include/linux/page_idle.h:29 [inline] mark_page_accessed+0x618/0x1140 mm/swap.c:398 touch_buffer fs/buffer.c:59 [inline] __find_get_block+0x312/0xcc0 fs/buffer.c:1298 sb_find_get_block include/linux/buffer_head.h:338 [inline] recently_deleted fs/ext4/ialloc.c:682 [inline] find_inode_bit.isra.0+0x202/0x510 fs/ext4/ialloc.c:722 __ext4_new_inode+0x14ad/0x52c0 fs/ext4/ialloc.c:914 ext4_symlink+0x3f8/0xbe0 fs/ext4/namei.c:3096 vfs_symlink fs/namei.c:4126 [inline] vfs_symlink+0x378/0x5d0 fs/namei.c:4112 do_symlinkat+0x22b/0x290 fs/namei.c:4153 __do_sys_symlink fs/namei.c:4172 [inline] __se_sys_symlink fs/namei.c:4170 [inline] __x64_sys_symlink+0x59/0x80 fs/namei.c:4170 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457b67 Code: 0f 1f 00 b8 5c 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 6d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 58 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 4d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fff045ce0f8 EFLAGS: 00000202 ORIG_RAX: 0000000000000058 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 0000000000457b67 RDX: 00007fff045ce173 RSI: 00000000004bd63f RDI: 00007fff045ce160 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000075 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000001 R14: 000000000000029b R15: 0000000000000001 Allocated by task 24763: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_kmalloc mm/kasan/common.c:496 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504 kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609 kmalloc include/linux/slab.h:545 [inline] mISDN_open+0x9a/0x270 drivers/isdn/mISDN/timerdev.c:59 misc_open+0x398/0x4c0 drivers/char/misc.c:141 chrdev_open+0x247/0x6b0 fs/char_dev.c:417 do_dentry_open+0x47d/0x1130 fs/open.c:771 vfs_open+0xa0/0xd0 fs/open.c:880 do_last fs/namei.c:3418 [inline] path_openat+0x10d7/0x4690 fs/namei.c:3534 do_filp_open+0x1a1/0x280 fs/namei.c:3564 do_sys_open+0x3fe/0x5d0 fs/open.c:1063 __do_sys_openat fs/open.c:1090 [inline] __se_sys_openat fs/open.c:1084 [inline] __x64_sys_openat+0x9d/0x100 fs/open.c:1084 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 24762: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458 kasan_slab_free+0xe/0x10 mm/kasan/common.c:466 __cache_free mm/slab.c:3487 [inline] kfree+0xcf/0x230 mm/slab.c:3806 mISDN_close+0x2a1/0x390 drivers/isdn/mISDN/timerdev.c:97 __fput+0x2df/0x8d0 fs/file_table.c:278 ____fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff88809fc18900 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 72 bytes inside of 192-byte region [ffff88809fc18900, ffff88809fc189c0) The buggy address belongs to the page: page:ffffea00027f0600 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0xffff88809fc18000 flags: 0x1fffc0000000200(slab) raw: 01fffc0000000200 ffffea000269f648 ffffea00029f7408 ffff88812c3f0040 raw: ffff88809fc18000 ffff88809fc18000 000000010000000b 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809fc18800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809fc18880: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88809fc18900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88809fc18980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88809fc18a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Karsten Keil <isdn@linux-pingi.de> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-05net: dsa: mv88e6xxx: Fix counting of ATU violationsAndrew Lunn
The ATU port vector contains a bit per port of the switch. The code wrongly used it as a port number, and incremented a port counter. This resulted in the wrong interfaces counter being incremented, and potentially going off the end of the array of ports. Fix this by using the source port ID for the violation, which really is a port number. Reported-by: Chris Healy <Chris.Healy@zii.aero> Tested-by: Chris Healy <Chris.Healy@zii.aero> Fixes: 65f60e4582bd ("net: dsa: mv88e6xxx: Keep ATU/VTU violation statistics") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-05thermal: cpu_cooling: Clarify error messageAmit Kucheria
Make it clear that it is a failure if the cpufreq driver was unable to register as a cooling device. Makes it easier to find in logs and grepping for words like fail, err, warn. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>