summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-02-06drm/amd/display: Clear dc_sink after it gets releasedJerry (Fangzhi) Zuo1-1/+3
[Why] The dc_sink was released but the pointer on the aconnector was not cleared. [How] Clear it. 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> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-06drm/amd/display: Don't re-program planes for DPMS changesNicholas Kazlauskas1-1/+2
[Why] There are opt1c lock warnings and CRTC read timeouts when running the "igt@kms_plane@plane-position-hole-dpms-pipe-*" tests. These are caused by trying to reprogram planes that are not in the current context. DPMS off removes the stream from the context. In this case: new_crtc_state->active_changed = true new_crtc_state->mode_changed = false The planes are reprogrammed before the stream is removed from the context because stream_state->mode_changed = false. For DPMS adds the stream and planes back to the context: new_crtc_state->active_changed = true new_crtc_state->mode_changed = false The planes are also reprogrammed here before the stream is added to the context because stream_state->mode_changed = true. They were not previously in the current context so warnings occur here. [How] Set stream_state->mode_changed = true when new_crtc_state->active_changed = true too. This prevents reprogramming before the context is applied in DC. The programming will be done after the context is applied. 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> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-06drm/amdgpu/display: fix compiler errors [-Werror,-Wparentheses-equality]Pratik Vishwakarma1-1/+1
Remove extraneous parentheses around the comparison to silence this warning Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-06x86/boot/compressed/64: Do not corrupt EDX on EFER.LME=1 settingKirill A. Shutemov1-0/+2
RDMSR in the trampoline code overwrites EDX but that register is used to indicate whether 5-level paging has to be enabled and if clobbered, leads to failure to boot on a 5-level paging machine. Preserve EDX on the stack while we are dealing with EFER. Fixes: b677dfae5aa1 ("x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline before returning to long mode") Reported-by: Kyle D Pelton <kyle.d.pelton@intel.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: dave.hansen@linux.intel.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Wei Huang <wei@redhat.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190206115253.1907-1-kirill.shutemov@linux.intel.com
2019-02-06ASoC: rsnd: fixup rsnd_ssi_master_clk_start() user count checkKuninori Morimoto1-1/+1
commit 4d230d1271064 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic") added new rsnd_ssi_prepare() and moved rsnd_ssi_master_clk_start() to .prepare. But, ssi user count (= ssi->usrcnt) is incremented at .init (= rsnd_ssi_init()). Because of these timing exchange, ssi->usrcnt check at rsnd_ssi_master_clk_start() should be adjusted. Otherwise, 2nd master clock setup will be no check. This patch fixup this issue. Fixes: commit 4d230d1271064 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic") Reported-by: Yusuke Goda <yusuke.goda.sx@renesas.com> Reported-by: Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-06ASoC: dapm: fix out-of-bounds accesses to DAPM lookup tablesPierre-Louis Bossart1-0/+24
KASAN reports and additional traces point to out-of-bounds accesses to the dapm_up_seq and dapm_down_seq lookup tables. The indices used are larger than the array definition. Fix by adding missing entries for the new widget types in these two lookup tables, and align them with PGA values. Also the sequences for the following widgets were not defined. Since their values defaulted to zero, assign them explicitly snd_soc_dapm_input snd_soc_dapm_output snd_soc_dapm_vmid snd_soc_dapm_siggen snd_soc_dapm_sink Fixes: 8a70b4544ef4 ('ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.'). Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-06staging/vboxvideo: Add TODODaniel Vetter1-0/+3
Noticed while wondering what vboxvideo is using the ->master_set/drop hooks for. v2: Polish grammar a bit (Sam). Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Fabio Rafael da Rosa <fdr@pid42.net> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190204103114.30772-2-daniel.vetter@ffwll.ch
2019-02-06staging/vboxvideo: don't set dev_priv_size = 0Daniel Vetter1-1/+0
The compiler already clears this for us. More important, someone might look what this is actually used for, and freak out about the dragon staring back at them. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Fabio Rafael da Rosa <fdr@pid42.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190204103114.30772-1-daniel.vetter@ffwll.ch
2019-02-06Merge branch 'nvme-5.0' of git://git.infradead.org/nvme into for-linusJens Axboe3-11/+20
Pull NVMe fixes from Christoph for this release. * 'nvme-5.0' of git://git.infradead.org/nvme: nvme-pci: fix rapid add remove sequence nvme: lock NS list changes while handling command effects
2019-02-06nvme-pci: fix rapid add remove sequenceKeith Busch1-10/+12
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 Busch2-1/+8
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 Marshall1-0/+1
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 Tsai1-0/+15
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 Tsai1-1/+10
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ä2-9/+3
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ä1-1/+1
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 Valkeinen1-0/+11
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 Valkeinen1-2/+2
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 Valkeinen1-6/+6
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 Ursulin3-11/+22
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 Berg2-7/+17
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 Berg1-2/+1
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 Kepplinger1-7/+6
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ä1-6/+44
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 Iwai1-1/+3
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-06drm/amd/display: Disconnect mpcc when changing tgNicholas Kazlauskas1-3/+4
[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-06drm/amd/display: Apply fake sink back to MST sequenceJerry (Fangzhi) Zuo2-5/+6
[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-06drm/amd/display: add a debug flag to force odm combineDmytro Laktyushkin1-0/+1
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-06drm/amd/display: store timing sync info in dc_stream_statusSu Sung Chung2-1/+21
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-06drm/amd/display: Modify ABM 2.2 Max ReductionJosip Pavic1-2/+2
[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-06drm/amd/display: pass vline_config parameter by reference.Yongqiang Sun4-8/+8
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-06drm/amd/display: add gpio lock/unlockChiawen Huang6-25/+81
[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-06drm/amd/display: 3.2.16Steven Chiu1-1/+1
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-06drm/amd/display: determine if a pipe is synced by plane stateWenjing Liu1-4/+4
[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-06drm/amd/display: DGAM enabled for HDRKrunoslav Kovac1-37/+52
[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-06drm/amd/display: Check that vrefresh is in freesync rangeIlya Bakoulin1-5/+5
[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-06drm/amd/display: dmcu is blocking due to wrong disable ABM commandPaul Hsieh1-2/+2
[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-06drm/amd/display: fix issue with DC brightness low with VBAnthony Koo1-10/+24
[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-06drm/amd/display: Add monitor patch for backlight offXiaodong Yan2-0/+5
[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-06drm/amd/display: Remove FreeSync timing changed debug outputNicholas Kazlauskas1-6/+0
[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-06drm/amd/display: Initialize stream_update to zeroNicholas Kazlauskas1-1/+2
[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-06drm/amd/display: Reformat dm_determine_update_type_for_commitNicholas Kazlauskas1-61/+65
[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-06drm/amd/display: Use the right surface for flip and FreeSyncNicholas Kazlauskas1-13/+4
[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-06drm/amd/display: Apply all surface updates onto surfacesNicholas Kazlauskas2-17/+96
[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-06drm/amd/display: Use udelay when waiting between aux retriesJohn Barberiz1-1/+1
[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-06drm/amdgpu: cleanup VM dw estimation a bitChristian König1-8/+8
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-06drm/amdgpu: fix waiting for BO moves with CPU based PD/PT updatesChristian König1-1/+6
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-06drm/amd/display: Use context parameters to enable FBCShirish S1-1/+1
[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-06drm/amd/display: Don't re-enable CRC when CONFIG_DEBUG_FS isn't definedNicholas Kazlauskas1-0/+2
[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-06drm/amdgpu: add a workaround for GDS ordered append hangs with compute queuesMarek Olšák6-6/+84
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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 05:48:30 +0300