Offer an option for advanced users who want larger modes at 16bpp.

This becomes necessary after the fix: "Work around mode set
failure in 2D VMs."  Without this patch, there would be no way
for existing advanced users to get to a high res mode, and the
regression is they will likely get a black screen after a software
update on their current VM.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>

In a low-memory 2D VM, fbdev can take up a large percentage of
available memory, making them unavailable for other DRM clients.

Since we do not take fbdev into account when filtering modes,
we end up claiming to support more modes than we actually do.

As a result, users get a black screen when setting a mode too
large for current available memory.  In a low-memory VM
configuration, users can get a black screen for a mode as low
as 1024x768.

The current mode filtering mechanism keys off of
SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
of surface memory we have.  Since this value is a performance
suggestion, not a hard limit, and since there should not be much
of a performance impact for a 2D VM, rather than filtering out
more modes, we will just allow ourselves to exceed the SVGA's
performance suggestion.

Also changed assumed bpp to 32 from 16 to make sure we can
actually support all the modes listed.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>

Discovered by static code analysis tool.  If for some reason communication
with the host fails more than preset number of retries, return an error
instead of return garbage.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NCharmaine Lee <charmainel@vmware.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>

Atomic updates may acquire more state than initially locked through
drm_modeset_lock_crtc, running with heavy stress can cause a
WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc:

[  601.491296] ------------[ cut here ]------------
[  601.491366] WARNING: CPU: 0 PID: 2411 at
drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491369] Modules linked in: drm i915 drm_kms_helper
[  601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G     U 4.7.0-rc4-patser+ #4798
[  601.491417] Hardware name: Intel Corporation Skylake Client
[  601.491420]  0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000
[  601.491425]  0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030
[  601.491431]  ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568
[  601.491436] Call Trace:
[  601.491443]  [<ffffffff812ead28>] dump_stack+0x4d/0x65
[  601.491447]  [<ffffffff810868e6>] __warn+0xc6/0xe0
[  601.491452]  [<ffffffff81086968>] warn_slowpath_null+0x18/0x20
[  601.491472]  [<ffffffffc00d4ffb>] drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491491]  [<ffffffffc00c5526>] drm_mode_cursor_common+0x66/0x180 [drm]
[  601.491509]  [<ffffffffc00c91cc>] drm_mode_cursor_ioctl+0x3c/0x40 [drm]
[  601.491524]  [<ffffffffc00bc94d>] drm_ioctl+0x14d/0x530 [drm]
[  601.491540]  [<ffffffffc00c9190>] ? drm_mode_setcrtc+0x520/0x520 [drm]
[  601.491545]  [<ffffffff81176aeb>] ? handle_mm_fault+0x106b/0x1430
[  601.491550]  [<ffffffff81108441>] ? stop_one_cpu+0x61/0x70
[  601.491556]  [<ffffffff811bb71d>] do_vfs_ioctl+0x8d/0x570
[  601.491560]  [<ffffffff81290d7e>] ? security_file_ioctl+0x3e/0x60
[  601.491565]  [<ffffffff811bbc74>] SyS_ioctl+0x74/0x80
[  601.491571]  [<ffffffff810e321c>] ? posix_get_monotonic_raw+0xc/0x10
[  601.491576]  [<ffffffff8175b11b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[  601.491581] ---[ end trace 56f3d3d85f000d00 ]---

For good measure, test mode_config.acquire_ctx too, although this should
never happen.

Testcase: kms_cursor_legacy
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Hello,

after this commit:

commit f045f459
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Thu Jun 2 12:23:31 2016 +1000
    drm/nouveau/fbcon: fix out-of-bounds memory accesses

kernel started to oops when loading nouveau module when using GTX 780 Ti
video adapter. This patch fixes the problem.

Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591Signed-off-by: NDmitrii Tcvetkov <demfloro@demfloro.ru>
Suggested-by: NIlia Mirkin <imirkin@alum.mit.edu>
Fixes: f045f459 ("nouveau_fbcon_init()")
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

>From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :

This was kind of a difficult bug to track down. If you're using a
Haswell system running GNOME and you have fbc completely enabled and
working, playing videos can result in video artifacts. Steps to
reproduce:

- Run GNOME
- Ensure FBC is enabled and active
- Download a movie, I used the ogg version of Big Buck Bunny for this
- Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin !
  glimagesink` in a terminal
- Watch for about over a minute, you'll see small horizontal lines go
  down the screen.

For the time being, disable FBC for Haswell by default.

Stefan Richter reported kernel freezes (no video artifacts) when fbc
is on.  (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE
applications, thread begins at https://lkml.org/lkml/2016/4/26/813).
We also got reports from Steven Honeyman on openbox+roxterm.

v2 (From Paulo):
  - Add extra information to the commit message
  - Add Fixes tag
  - Rebase

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464
Fixes: a98ee793 ("drm/i915/fbc: enable FBC by default on HSW and BDW")
Cc: stable@vger.kernel.org
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NLyude <cpaul@redhat.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465487895-7401-1-git-send-email-cpaul@redhat.com
(cherry picked from commit c7f7e2fe)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

It has been found out that in some HW combination the DisplayPort
fast link training feature caused screen flickering. Let's revert
this feature for now until we can ensure that the feature works for
all platforms.

This is a manual revert of commits 5fa836a9 ("drm/i915: DP link
training optimization") and 4e96c977 ("drm/i915: eDP link training
optimization").

Fixes: 5fa836a9 ("drm/i915: DP link training optimization")
Fixes: 4e96c977 ("drm/i915: eDP link training optimization")
Cc: <stable@vger.kernel.org> # v4.2+

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466410226-19543-1-git-send-email-mika.kahola@intel.com
(cherry picked from commit 91df09d9)

Power saving feature which reduces the amount of
voltage needed for specific engine clocks.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

avfs feature is for voltage control based on
gpu system clock on polaris10
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

To minimize the dram power expenditure during static -screen
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

sync up with internal programming recommendations.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Missing pcie dpm settings.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NKen Wang <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

before request performance state.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NKen Wang <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Wrong value passed to acpi_pcie_perf_request.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NKen Wang <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

the error lead powerplay can't get display info in DGPU case.
store_cc6_data just implement in APU.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

atmel_hlcdc_create_outputs() iterates over OF graph nodes and releases
the node (using of_node_put()) after each iteration, which is wrong
since for_each_endpoint_of_node() is already taking care of that.

Move the of_node_put() call in the error path.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Fixes: 17a8e03e ("drm: atmel-hlcdc: rework the output code to support drm bridges")

The driver is only enabling scaling, but never disabling it, thus, if you
enable the scaling feature once it stays enabled forever.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: NAlex Vazquez <avazquez.dev@gmail.com>
Reviewed-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Fixes: 1a396789 ("drm: add Atmel HLCDC Display Controller support")
Cc: <stable@vger.kernel.org>

amdgpu_cgs_acpi_eval_object() returned the value of variable "result"
without initializing it first.

This bug has been found by compiling the kernel with clang.  The
compiler complained:

    drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: error: variable
    'result' is used uninitialized whenever 'for' loop exits because its
    condition is false [-Werror,-Wsometimes-uninitialized]
            for (i = 0; i < count; i++) {
                        ^~~~~~~~~
    drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:1011:9: note: uninitialized
    use occurs here
            return result;
                   ^~~~~~
    drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: note: remove the
    condition if it is always true
            for (i = 0; i < count; i++) {
                        ^~~~~~~~~
    drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:864:12: note: initialize the
    variable 'result' to silence this warning
            int result;
                      ^
                       = 0

Fixes: 3f1d35a0 ("drm/amdgpu: implement new cgs interface for acpi
function")
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

! has higher precedence than bitwise & so we need to add parenthesis
for this to work as intended.

Fixes: 048765ad ('amdgpu: fix asic initialization for virtualized environments (v2)')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The current bitwise AND should result in the same assembler
but this is what the code is actually supposed to do.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Neither of these files issue any fbdev related calls.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This makes the defines consistent with the rest.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Commit a6f75aa1 ("drm/exynos: fimd: add HW trigger support") added
hardware trigger support to the FIMD controller driver. But this broke
the display in at least the Exynos5800 Peach Pi Chromebook.

So until the issue is fixed, avoid using HW trigger for the Exynos5420
based boards and use SW trigger as it was before the mentioned commit.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The field value is only checked in fimd_setup_trigger() if .trg_type is
I80_HW_TRG so there's no point in setting this field for the s3c6400 if
is never going to be used since .trg_type is not set.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Commit 3424e3a4 ("drm: bridge: analogix/dp: split exynos dp driver to
bridge directory") split the Exynos DP core driver into a core driver and
a bridge driver for the Analogix chip since that is also used by Rockchip.

But the change introduced a regression causing a NULL pointer dereference
when trying to access an uninitialized connector in the driver .get_modes:

Fix this by instead of having a connector struct for both the Exynos and
Analogix drivers, just use the connector initialized in the bridge driver.

Fixes: 3424e3a4 ("drm: bridge: analogix/dp: split exynos dp driver to bridge directory")
Reported-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Tested-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The isa_bus_init function must be called before drivers which utilize
the ISA bus driver are registered. A race condition for initilization
exists if device_initcall is used (the isa_bus_init callback is placed
in the same initcall level as dependent drivers which use module_init).
This patch ensures that isa_bus_init is called first by utilizing
postcore_initcall in favor of device_initcall.

Fixes: a5117ba7 ("[PATCH] Driver model: add ISA bus")
Cc: Rene Herman <rene.herman@keyaccess.nl>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Wim Van Sebroeck <wim@iguana.be>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
allowing them to build for X86_64 as they are expected to.

Cc: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patch introduces the
ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
options added as required.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It's annoying to constantly see the same "Not yet implemented" message
over and over with nothing able to be done about it, so rate limit it
for now to keep user's logs "clean".
Reported-by: NLars Täuber <lars.taeuber@web.de>
Tested-by: NLars Täuber <lars.taeuber@web.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This was accidently broken for harvest cards when the
code was refactored for Polaris support.

v2: multiply by shader engines.  Noticed by Nicolai.
Reviewed-by: NNicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This reverts commit b5e12ec3 ("Staging: rtl8188eu: rtw_efuse: Use
sizeof type *pointer instead of sizeof type.").

This commit is wrong, the rtw_malloc2d helper function takes the size of
the array elements as its 3th argument, whereas sizeof(*eFuseWord)
gives the size of a pointer instead of the size of a u16.

Since sizeof(void *) > sizeof(u16) this has no adverse effects, but it
is still wrong.

Cc: Sandhya Bankar <bankarsandhya512@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 99aded71 ("Staging: drivers: rtl8188eu: use
sizeof(*ptr) instead of sizeof(struct)").

This commit is wrong, as adapt->HalData has a type of "void *", so
now we are allocating a much to small struct, which causes the driver
to overwrite random memory which leads to a non working driver and
various system crashes.

Cc: Jacky Boen <aqiank@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no limit on high "idx" can go.  It should be less than
ARRAY_SIZE(data.states) which is 16.

The "data" variable wasn't declared in that scope so I shifted the code
around a bit to make it work.  Also I made "idx" unsigned.

Fixes: f3898ea1 ('drm/amd/powerplay: add some sysfs interfaces for powerplay.')
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This seems to be required on some X58 chipsets on systems
with more than one IOMMU. QI does not work until it is
enabled on all IOMMUs in the system.
Reported-by: NDheeraj CVR <cvr.dheeraj@gmail.com>
Tested-by: NDheeraj CVR <cvr.dheeraj@gmail.com>
Fixes: 5f0a7f76 ('iommu/vt-d: Make root entry visible for hardware right after allocation')
Cc: stable@vger.kernel.org
Signed-off-by: NJoerg Roedel <jroedel@suse.de>