v2:
Use dma_fence_wait instead of dma_fence_wait_timeout(...,MAX_SCHEDULE_TIMEOUT)
Avoid printing error message for ERESTARTSYS
Originally-by: NDavid Panariti <David.Panariti@amd.com>
Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

GFP_TRANSHUGE tries very hard to allocate huge pages, which can result
in long delays with high memory pressure. I have observed firefox
freezing for up to around a minute due to this while restic was taking
a full system backup.

Since we don't really need huge pages, use GFP_TRANSHUGE_LIGHT |
__GFP_NORETRY instead, in order to fail quickly when there are no huge
pages available.

Set __GFP_KSWAPD_RECLAIM as well, in order for huge pages to be freed
up in the background if necessary.

With these changes, I'm no longer seeing freezes during a restic backup.

Cc: stable@vger.kernel.org
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Allocating up to 32 physically contiguous pages can easily fail (and has
failed for me), and isn't necessary anyway.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The two ranges overlap.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NJerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

edid should be freed once it's finished being used.

Fixes: 56fe8b6f ("drm/bridge: Add RGB to VGA bridge support")
Cc: Rob Herring <robh@kernel.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: <stable@vger.kernel.org> # v4.9+
Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180420190007.1572-1-seanpaul@chromium.org

Commit b9f19259 ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
introduced a mechanism to mark some BOs as purgeable to allow the driver
to drop them under memory pressure. In order to implement this feature
we had to add a mechanism to mark BOs as currently used by a piece of
hardware which materialized through the ->usecnt counter.

Plane code is supposed to increment usecnt when it attaches a BO to a
plane and decrement it when it's done with this BO, which was done in
the ->prepare_fb() and ->cleanup_fb() hooks. The problem is, async page
flip logic does not go through the regular atomic update path, and
->prepare_fb() and ->cleanup_fb() are not called in this case.

Fix that by manually calling vc4_bo_{inc,dec}_usecnt() in the
async-page-flip path.

Note that all this should go away as soon as we get generic async page
flip support in the core, in the meantime, this fix should do the
trick.

Fixes: b9f19259 ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
Reported-by: NPeter Robinson <pbrobinson@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180430133232.32457-1-boris.brezillon@bootlin.com
Link: https://patchwork.freedesktop.org/patch/msgid/20180430133232.32457-1-boris.brezillon@bootlin.com

As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.

This removes the error message in the dmesg log:

    i915 0000:00:02.0: Direct firmware load for
        i915/glk_dmc_ver1_04.bin failed with error -2
    i915 0000:00:02.0: Failed to load DMC firmware
        i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
    i915 0000:00:02.0: DMC firmware homepage:
        https://01.org/linuxgraphics/downloads/firmware

and now shows that the firmware has correctly loaded:

    [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
Signed-off-by: NIan W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411044213.383-1-ianwmorrison@gmail.com
(cherry picked from commit f6d3e06f)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

A buffer object leak was introduced when fixing a premature buffer
object release. Fix this.

Cc: <stable@vger.kernel.org>
Fixes: 73a88250 ("Fix a destoy-while-held mutex problem.")
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

At least since the atomic port, the vmwgfx fbdev code is taking
a number of unnecessary modeset locks. In particular the
kms_set_config() function will grab its own locks, leading to
locking retries. So avoid drm_modeset_lock_all() and instead
provide a local acquire context for kms_set_config(). Also have the
vmw_kms_fbdev_init data itself grab the lock that it needs.

This also fixed a long standing problem that vmw_fb_close() didn't
provide an acquire context for kms_set_config(), causing potential
warnings and hangs during driver unload. This problem was uncovered by the
recent commit "drm/vmwgfx: Improve on hibernation"

Testing done:
Repeated driver load and unload on Ubuntu 16.04.2

Fixes: c3b9b165 ("drm/vmwgfx: Improve on hibernation")
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

We're currently failing to reset everything in display_info.hdmi
which will potentially cause us to use stale information when
swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
with a HDMI 1.x monitor we will continue to think that the monitor
supports scrambling. That will lead to a black screen since the
HDMI 1.x monitor won't understand the scrambled signal.

Fix the problem by clearing display_info.hdmi fully. And while at
eliminate some duplicated code by calling drm_reset_display_info()
in drm_add_display_info().

Cc: stable@vger.kernel.org
Cc: Antony Chen <antonychen@qnap.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424130250.7028-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NAntony Chen <antonychen@qnap.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Wait until we have enough space in the virt queue to actually queue up
our request.  Avoids the guest spinning in case we have a non-zero
amount of free entries but not enough for the request.

Cc: stable@vger.kernel.org
Reported-by: NAlain Magloire <amagloire@blackberry.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180403095904.11152-1-kraxel@redhat.comSigned-off-by: NSean Paul <seanpaul@chromium.org>

qxl expects that list_first_entry(release->bos) returns the first
element qxl added to the list.  ttm_eu_reserve_buffers() may reorder
the list though.

Add a release_bo field to struct qxl_release and use that instead.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180418054257.15388-3-kraxel@redhat.comSigned-off-by: NSean Paul <seanpaul@chromium.org>

s/PAGE_SIZE/PAGE_MASK/

Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
bad side effects and managed to stay unnoticed for years that way ...
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180418054257.15388-2-kraxel@redhat.comSigned-off-by: NSean Paul <seanpaul@chromium.org>

The reverted commit broke LVDS output on TBS A711 Tablet. That tablet
has simple-panel node that has fixed pixel clock-frequency that A83T
SoC used in the tablet can't generate exactly.

Requested rate is 52000000 and rounded_rate is calculated as 51857142.
It's close enough for it to work in practice, but with strict check
in the reverted commit, the mode is rejected needlessly in this case.

DT allows to specify a range of values for simple-panel/clock-frequency,
but driver doesn't respect that ATM. Given that TBS A711 is the single
user of sun4i-lvds driver, let's revert that commit for now, until
a better solution for the problem is found.

Also see: https://patchwork.kernel.org/patch/9446385/ for relevant
discussion (or search for "[RFC] drm/sun4i: rgb: Add 5% tolerance
to dot clock frequency check").

Fixes: e4e4b7ad ("drm/sun4i: add lvds mode_valid function")
Reported-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180421045155.15332-1-megous@megous.comSigned-off-by: NSean Paul <seanpaul@chromium.org>

Extended fix to: "Don't read EDID in atomic_check"

Fix issue of missing dc_sink in .mode_valid in hot plug routine.

Need to check dc_sink everytime in .get_modes hook after checking
edid, since edid is not getting removed in hot unplug but dc_sink
doesn't.
Signed-off-by: NJerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Extended fix to: "Don't read EDID in atomic_check"

Fix display property not observed in GUI display after hot plug.

Call drm_mode_connector_update_edid_property every time in
.get_modes hook, due to the fact that edid property is getting
removed from usermode ioctl DRM_IOCTL_MODE_GETCONNECTOR each time
in hot unplug.
Signed-off-by: NJerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We shouldn't attempt to read EDID in atomic_check. We really shouldn't
even be modifying the connector object, or any other non-state object,
but this is a start at least.

Moving EDID cleanup to dm_dp_mst_connector_destroy from
dm_dp_destroy_mst_connector to ensure the EDID is still available for
headless mode.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The below commit

    "drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2"

introduces a slight behavioral change to rmfb. Instead of disabling a crtc
when the primary plane is disabled, it now preserves it.

Since DC is currently not equipped to handle this we need to fail such
a commit, otherwise we might see a corrupted screen.

This is based on Shirish's previous approach but avoids adding all
planes to the new atomic state which leads to a full update in DC for
any commit, and is not what we intend.

Theoretically DM should be able to deal with states with fully populated planes,
even for simple updates, such as cursor updates. This should still be
addressed in the future.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Lock irq table when reading a work in queue,
unlock to flush the work, lock again till all tasks
are cleared
Signed-off-by: NMikita Lipski <mikita.lipski@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If the initial fbdev configuration (intel_fbdev_initial_config()) runs
and there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened (but
internally the return is -EAGAIN).  Because no framebuffer was
allocated, when a sink is connected intel_fbdev_output_poll_changed()
will not execute drm_fb_helper_hotplug_event() that would trigger
another try to do the initial fbdev configuration.

So here allowing drm_fb_helper_hotplug_event() to be executed when there
is no framebuffer allocated and fbdev was not set up yet.

This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if
intel_fbdev_initial_config() is executed before the first sink MST is
discovered it will cause this same issue.

This is a follow-up patch of
https://patchwork.freedesktop.org/patch/196089/

Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
  drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Tested-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17
Tested-by: NIan Pilcher <arequipeno@gmail.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
(cherry picked from commit df9e6521)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.

We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.

v2: added bugzilla entry (Imre), added stable (Chris)
Reported-by: NImre Deak <imre.deak@intel.com>
References: https://lkml.org/lkml/2018/4/18/798 [1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
(cherry picked from commit 3085982c)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Otherwise, the SQ may skip some of the register writes, or shader waves may
be allocated where we don't expect them, so that as a result we don't actually
reset all of the register SRAMs. This can lead to spurious ECC errors later on
if a shader uses an uninitialized register.
Signed-off-by: NNicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

When CONFIG_MMU_NOTIFIER is not enabled, struct mmu_notifier has an
incomplete type definition, which causes build errors.

../drivers/gpu/drm/amd/amdkfd/kfd_priv.h:607:22: error: field 'mmu_notifier' has incomplete type
../include/linux/kernel.h:979:32: error: dereferencing pointer to incomplete type
../include/linux/kernel.h:980:18: error: dereferencing pointer to incomplete type
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:434:2: error: implicit declaration of function 'mmu_notifier_unregister_no_release' [-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:435:2: error: implicit declaration of function 'mmu_notifier_call_srcu' [-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:438:21: error: variable 'kfd_process_mmu_notifier_ops' has initializer but incomplete type
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: error: unknown field 'release' specified in initializer
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: excess elements in struct initializer [enabled by default]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: (near initialization for 'kfd_process_mmu_notifier_ops') [enabled by default]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:534:2: error: implicit declaration of function 'mmu_notifier_register' [-Werror=implicit-function-declaration]
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Tested-by: NAnders Roxell <anders.roxell@linaro.org>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Currently if a user requests clock counters for a node without a GPU
resource we will always return EINVAL.

Instead if no GPU resource is attached, fill the gpu_clock_counter
argument with zeroes so that we may proceed and return valid CPU
counters.
Signed-off-by: NAndres Rodriguez <andres.rodriguez@amd.com>
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Passing NULL pointer to PTR_ERR will result in return value of 0
indicating success which is clearly not what it is intended here.
This patch returns -EINVAL instead.

v2: change ret code to -ENODEV

Fixes: 5ec7e028 ("drm/amdkfd: Add ioctls for GPUVM memory management")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Fixes: 5ec7e028 ("drm/amdkfd: Add ioctls for GPUVM memory management")
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.

I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.

Fixes: 53421c2f ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
(cherry picked from commit b49be662)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

In GLK when the device boots with only 1366x768 panel without audio, HDA
codec doesn't come up. In this case, the CDCLK is less than twice the
BCLK. Even though audio isn't being enabled, having a too low CDCLK
leads to audio probe failing altogether.

Require CDCLK to be at least twice the BLCK regardless of audio. This is
a minimal fix to improve things. Unfortunately, this a) leads to too
high CDCLK being used when audio is not used, and b) is still not enough
to fix audio probe when no outputs are connected at probe time.

The proper fix would be to increase CDCLK dynamically from the audio
component hooks.

v2:
    - Address comment (Jani)
    - New design approach
v3: - Typo fix on top of v1

v4 by Jani: rewrite commit message, add comment in code

Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Cc: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: NWenkai Du <wenkai.du@intel.com>
Tested-by: NWenkai Du <wenkai.du@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937Signed-off-by: NAbhay Kumar <abhay.kumar@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418103707.14645-1-jani.nikula@intel.com
(cherry picked from commit 2a5b95b4)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

update vega12 smu interface.
Signed-off-by: NKenneth Feng <kenneth.feng@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Make sure to update the MCLK and SCLK flags when setting the VDDC
flags due to dependencies.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Even though this is required for degamma since DCE HW only supports a
couple predefined LUTs we can just program the LUT directly for regamma.

This fixes dark screens which occurs when we program regamma to bypass
while degamma is using srgb LUT.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Currently the error pointer returned by msm_alloc_stolen_fb gets passed
to drm_framebuffer_remove. The latter handles only NULL pointers, thus
a nasty crash will occur.

Drop the unnecessary fail label and the associated checks - both err and
fb will be set at this stage.

Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The function dsi_get_cmd_fmt returns enum dsi_cmd_dst_format,
use the correct enum value also for MIPI_DSI_FMT_RGB666/_PACKED.

This has been discovered using clang:
  drivers/gpu/drm/msm/dsi/dsi_host.c:743:35: warning: implicit conversion
        from enumeration type 'enum dsi_vid_dst_format' to different
        enumeration type 'enum dsi_cmd_dst_format' [-Wenum-conversion]
          case MIPI_DSI_FMT_RGB666:       return VID_DST_FORMAT_RGB666;
                                          ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Commit 62e3a3e3 changed get_pages() to initialise
msm_gem_object::pages before trying to initialise msm_gem_object::sgt,
so that put_pages() would properly clean up pages in the failure
case.

However, this means that put_pages() now needs to check that
msm_gem_object::sgt is not null before trying to clean it up, and
this check was only applied to part of the cleanup code.  Move
it all into the conditional block.  (Strictly speaking we don't
need to make the kfree() conditional, but since we can't avoid
checking for null ourselves we may as well do so.)

Fixes: 62e3a3e3 ("drm/msm: fix leak in failed get_pages")
Signed-off-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Reviewed-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change plumbs the new fb modifier through the various mdp/disp
get_format hooks.
Signed-off-by: NJeykumar Sankaran <jsanka@codeaurora.org>
[seanpaul pimped out commit message a bit]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Don't leave the event != NULL once it's consumed, this is used a signal
to the atomic helpers that the event will be handled by the driver.

Changes in v2:
- None
Changes in v3:
- Rebased on Archit's private_obj set
Changes in v4:
- None

Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.

Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- None
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NAbhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>