Since commit (f6972eb FROMLIST: drm/panel: add of display
timing support), when panel has no device-tree timing, would always
get noise message:
[ 8.742157] /lvds_panel: could not find display-timings node
[ 8.747878] /lvds_panel: no timings specified
Change-Id: I9104b3017faa837807a09c21d0f948e499827ad9
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reorganize hdmi_unmute_interrupts() to put all the HPD-related config
together. This also eliminates an extra clearning of the HPD
interrupt.
BUG=chrome-os-partner:44922
TEST=HDMI still works fine.
Change-Id: I9d3cd847a00f9c887e2d054ff2b5671b0eeb8a42
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/299777
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
This is a no-op change that eliminates the dw_hdmi_fb_registered()
function and just folds the code into the one caller of the function:
hdmi_unmute_interrupts().
Eliminated because:
* The name and comment of the function implied that it was to be called
after the frame buffer was registered. ...but it wasn't called when
that happened, at least not directly.
* The function does some parts of enabling the HPD interrupt but not all
parts. Other parts are done by the calling function, and the calling
function also duplicates some bits (like clearing existing HPD). The
split doesn't make sense.
A future change will reorganize hdmi_unmute_interrupts() a little.
BUG=chrome-os-partner:44922
TEST=HDMI still works fine.
Change-Id: Ib77c03dd8f4791bc7276ccab184ff5b766de5ddd
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299776
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
I have uploaded a patch to switch DDC to standard mode in
(https://chromium-review.googlesource.com/298270), but that change
have influence the "spare register" in I2CM_DIV, I know this haven't
cause some know bug, but we need to fix it.
BUG=chrome-os-partner:34741
TEST=None
Change-Id: Iff678fb49828db9b8026422e302a03f687a7c862
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/302751
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
We should really do the reset of i2c before we set the speed. There are
no actual known problems fixed by this, but it seems like a good idea
and the latest upstream patch does this.
BUG=chrome-os-partner:34741
TEST=HDMI vs. suspend/resume, broken monitor, HDCP, etc.
Change-Id: I5207f39e074b7ab0d56d945bd1ae74d06f89c74b
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302629
Commit-Ready: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
DDC have two modes: fast mode, standard mode. The previous ddc support
patch(https://chromium-review.googlesource.com/#/c/292012/) configure
the ddc to fast mode.
It works rightly in most HDTV case, but I found that ddc would always
failed if I used the VGA->HDMI adapter. And after I switch ddc to
standard mode, no failed anymore. I believe the standard mode could
provide better compatibility.
BUG=chrome-os-partner:34741
TEST=My VGA->HDMI adapter can read edid now
Change-Id: Ia33ade0a4fda998483baf454b9ccb9f31802f6bc
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/298270
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
In (3b9ba9a FROMLIST: drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter
support) we added a new i2c bus adapter but no of_node was provided to
the adapter. This made it difficult to assign a bus number to the
adapter in the device tree.
Because of the fact that dynamic bus numbering of i2c starts at 0 and
the fact that i2c busses are no longer allowed to be loaded extra-early
at boot (because deferred probe solves the boot order problem), it's
possible that this could cause the DDC i2c bus to get ID 0 and could
cause later SoC i2c busses to fail to probe because they're expecting to
get ID 0.
Note that probe ordering of mickey is slightly different than probe
ordering of other veyron devices, which is why this only shows up on
mickey.
BUG=chrome-os-partner:44802
TEST=With dts patch can now boot mickey again
Change-Id: I8f971a967f398ab58a6713a2b6471a4a2fe61dc6
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297040
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.
The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks,
EDID reading operation won't succeed, in my practice all tested HDMI
monitors have at maximum one extension block.
(am from https://patchwork.kernel.org/patch/7098101)
Change-Id: Ic3abe878a02f89bda15f39676164803b467c62a1
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/292012
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
hdmi->disabled maybe not match to the real hardware status.
->dw_hdmi_bridge_enable()
hdmi->disabled = false;
-->dw_hdmi_update_power()
if (hdmi->rxsense)
force = DRM_FORCE_ON;
else
force = DRM_FORCE_OFF;
hdmi->rxsense maybe false on bridge enable path, then hdmi->disabled
is false, but actually hardware is power off, they are not match.
So on dw_hdmi_irq, judge the hardware status with hdmi->disabled is wrong.
This bug would cause display lost, unplug/plug can't recovery display.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Liu Ying <gnuiyl@gmail.com>
Change-Id: Iaa5c56b5df32c6d3811f4131d63033fbccd005ae
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9274599)
rockchip_drm_fb.c:In function 'rockchip_drm_fb_destroy':
rockchip_drm_fb.c:51:21: warning: unused variable 'dev' [-Wunused-variable]
Change-Id: I4b9f976c71b310c411a4d1fb9990743d7109b45f
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXnxafAAoJECTWi3JdVIfQAFEH/3bzJHWnWb+dqtcoVyDYTRiQ
rdh7yNA/Svf2hSlKB2KKwHRMtkYLf2yu/WLJxYO/42ieHj4MAJRzRdCIx6t1GNEj
CEEQwsy5ujg3KiB5I3L0/mE6GqVhNQA0F9mzZqPS4qydk9q7bBJ+QbF90yo7uxNH
rOG/Zzn4WrSd77pdnHnInyIkrTgaxMZ/V+bXiaqpKjbmGA5d02QBr2rQOdWk70ie
s+C1z2dY6QBn15yhpwXVEnqDhpqtEG4JQOdBaGWydbucdY6gfxd5D2OUqYIdEdHU
+It+OlBitjuuKvfSCK7/WHUcwWWXlVk77VRB0TZ3zVw3LEApCpA0oFmZTropIqM=
=XUa1
-----END PGP SIGNATURE-----
Merge tag 'lsk-v4.4-16.07-android'
LSK 16.07 v4.4-android
* tag 'lsk-v4.4-16.07-android': (160 commits)
arm64: kaslr: increase randomization granularity
arm64: relocatable: deal with physically misaligned kernel images
arm64: don't map TEXT_OFFSET bytes below the kernel if we can avoid it
arm64: kernel: replace early 64-bit literal loads with move-immediates
arm64: introduce mov_q macro to move a constant into a 64-bit register
arm64: kernel: perform relocation processing from ID map
arm64: kernel: use literal for relocated address of __secondary_switched
arm64: kernel: don't export local symbols from head.S
arm64: simplify kernel segment mapping granularity
arm64: cover the .head.text section in the .text segment mapping
arm64: move early boot code to the .init segment
arm64: use 'segment' rather than 'chunk' to describe mapped kernel regions
arm64: mm: Mark .rodata as RO
Linux 4.4.16
ovl: verify upper dentry before unlink and rename
drm/i915: Revert DisplayPort fast link training feature
tmpfs: fix regression hang in fallocate undo
tmpfs: don't undo fallocate past its last page
crypto: qat - make qat_asym_algs.o depend on asn1 headers
xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7
...
When enable display on loader, init gpio would change gpio status,
that would make screen flash,
Change-Id: I4b69a8d3d83c5bef09014c2134abaee6522a7046
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Because we are using a custom crtc_state structure, we must override the
reset helper to allocate the correct amount of memory.
Cc: stable@vger.kernel.org
Change-Id: I1895dbe994232991c1659cf2f4d63c4aa957b794
Fixes: 4e257d9eee ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
(cherry picked from dc0b408f5a)
Build fail with:
ERROR: "memblock_free" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined!
memblok_free fuction not export symbol, and use the flag __init, so it
can't be used on modules.
the memblock_free function only used for loader memory manager, not use
on modules context, so just use it when build-in drm/rockchip.
Change-Id: Ib88b6ca6c61f7ef85b4126d705a4911e207b57e5
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
This driver was still using the old legacy helpers and that caused a few
NULL dereferences when trying to call empty callbacks.
Change-Id: I9656aed34892260dbf9b571b95befd6af4d9b70f
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Caesar Wang <wxt@rock-chips.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465224813-7359-1-git-send-email-tomeu.vizoso@collabora.com
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(cherry picked from 5a58738309)
Provide subsystem-level suspend and resume helpers that can be used to
implement suspend/resume on atomic mode-setting enabled drivers.
v2: simplify locking, enhance kerneldoc comments
v3: pass lock acquisition context by parameter, improve kerneldoc
v4: - remove redundant code (already provided by atomic helpers)
(Maarten Lankhorst)
- move backoff dance from drm_modeset_lock_all_ctx() into suspend
helper (Daniel Vetter)
v5: handle potential EDEADLK from drm_atomic_helper_duplicate_state()
and drm_atomic_helper_disable_all() (Daniel Vetter)
Change-Id: I58c5b794cdafa6c9f2594376fc2e98918156e409
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449075005-13937-2-git-send-email-thierry.reding@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(cherry picked from 1494276000)
This function is like drm_modeset_lock_all(), but it takes the lock
acquisition context as a parameter rather than storing it in the DRM
device's mode_config structure.
Implement drm_modeset_{,un}lock_all() in terms of the new function for
better code reuse, and add a note to the kerneldoc that new code should
use the new functions.
v2: improve kerneldoc
v4: rename drm_modeset_lock_all_crtcs() to drm_modeset_lock_all_ctx()
and take mode_config's .connection_mutex instead of .mutex lock to
avoid lock inversion (Daniel Vetter), use drm_modeset_drop_locks()
which is now the equivalent of drm_modeset_unlock_all_ctx()
v5: do not take the dev->mode_config.connection_mutex in
drm_atomic_legacy_backoff() since drm_modeset_lock_all_ctx()
already keeps it, enhance kerneldoc for drm_modeset_lock_all_ctx()
(Daniel Vetter)
Change-Id: I1f16f686f77139b749b38c7a3a0dbc0b5d25f6fd
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449075005-13937-1-git-send-email-thierry.reding@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(cherry picked from commit 06eaae4638)
compat_uptr_t is defined in asm/compat.h:
typedef u32 compat_uptr_t;
but cmd and cmd_buf store the user pointers.
Do not convert 64 bit pointer to 32 bit, it
will lead copy_from_user fail.
Change-Id: Ia0435f2a495bbe64d583e213349cb9f041c9d75a
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>
The problem is that:
mipi panel probe request mipi_dsi_host_register.
mipi host attach is call from panel device, so the defer function
always can't works.
So at the first bind time, always can't found mipi panel.
Change-Id: Ic95eeb4876896ea93860d8baaae074f50f078c62
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The MIPI DSI do not need check the validity of resolution, the max resolution
should depend VOP. So remove rk3288_mipi_dsi_mode_valid here.
Change-Id: I789d184f9a14010795fe595ef31e1bea5d1022e0
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
With atomic helpers there's no need to track the enabled state of a pipe
any more, because atomic helpers track this accurately already.
Change-Id: Ic2441b5acefe327cdef797aca88f6a2098643c69
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
With atomic helpers there's no need to track the enabled state of a pipe
any more, because atomic helpers track this accurately already.
Just disable the early returns, since the debug checks might be useful.
v2: Don't call drm_helper_disable_unused_functions, it blows up
without this check. At least explains why rockchip still needed this
old legacy-style state tracing - to work around issues from calling
other legacy style functions!
Change-Id: Ib63ad83b0212c5e2b0a44c1c5e2d188e7c876107
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-18-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Should do vop_cfg_done to let windows disable take effect
Change-Id: Ib2966d8825a195696a963de7bc1d9665e78e5389
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The series of vop is:
IP version chipname
3.1 rk3288
3.2 rk3368
3.4 rk3366
3.5 rk3399 big
3.6 rk3399 lit
3.7 rk322x
The IP version is from VERSION_INFO register
major version: used for IP structure, Vop full framework is 3,
vop little framework is 2.
minor version: on same structure, newer design vop will bigger then
old one.
Change-Id: I032cb3d74cd01440274d3efeefa747e6028c1689
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
commit 34511dce4b upstream.
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 5fa836a9d8 ("drm/i915: DP link
training optimization") and 4e96c97742 ("drm/i915: eDP link training
optimization").
Fixes: 5fa836a9d8 ("drm/i915: DP link training optimization")
Fixes: 4e96c97742 ("drm/i915: eDP link training optimization")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani 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 91df09d92a)
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 58541f7a64 upstream.
Rather than returning immediately, make sure to unlock the
mutexes first.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reported-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d5f1a291e3 upstream.
For the Screen Object display unit, we need to reserve a
guest-invisible region equal to the size of the framebuffer for
the host. This region can only be reserved in VRAM, whereas
the guest-visible framebuffer can be reserved in either VRAM or
GMR.
As such priority should be given to the guest-invisible
region otherwise in a limited VRAM situation, we can fail to
allocate this region.
This patch makes it so that vmw_sou_backing_alloc() is called
before the framebuffer is pinned.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4ed7e2242b upstream.
In certain scenarios, e.g. when fbdev is enabled, we can get into
a situation where a vmw_framebuffer_pin() is called on a buffer
that is already pinned.
When this happens, ttm_bo_validate() will unintentially remove the
TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way
to actually pin the buffer again.
To prevent this, if a buffer is already pinned, then instead of
calling ttm_bo_validate(), just make sure the proposed placement is
compatible with the existing placement.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c20d213dd upstream.
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: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 04319d89fb upstream.
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: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 94477bff39 upstream.
There are cases where it is desired to see if a proposed placement
is compatible with a buffer object before calling ttm_bo_validate().
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b7e38b92b upstream.
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: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Alex Vazquez <avazquez.dev@gmail.com>
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Fixes: 1a396789f6 ("drm: add Atmel HLCDC Display Controller support")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6709887c44 upstream.
drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so
old data may be left there when a new mode is set, possibly causing odd
issues.
This patch improves the situation by always clearing the state->mode
first.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b201e743f4 upstream.
When setting mode via MODE_ID property,
drm_atomic_set_mode_prop_for_crtc() does not call
drm_mode_set_crtcinfo() which possibly causes:
"[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't
calculate constants, dotclock = 0!"
Whether the error is seen depends on the previous data in state->mode,
as state->mode is not cleared when setting new mode.
This patch adds drm_mode_set_crtcinfo() call to
drm_mode_convert_umode(), which is called in both legacy and atomic
paths. This should be fine as there's no reason to call
drm_mode_convert_umode() without also setting the crtc related fields.
drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as
that is no longer needed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a04e23d42a upstream.
Update CDCLK_FREQ on BDW after changing the cdclk frequency. Not sure
if this is a late addition to the spec, or if I simply overlooked this
step when writing the original code.
This is what Bspec has to say about CDCLK_FREQ:
"Program this field to the CD clock frequency minus one. This is used to
generate a divided down clock for miscellaneous timers in display."
And the "Broadwell Sequences for Changing CD Clock Frequency" section
clarifies this further:
"For CD clock 337.5 MHz, program 337 decimal.
For CD clock 450 MHz, program 449 decimal.
For CD clock 540 MHz, program 539 decimal.
For CD clock 675 MHz, program 674 decimal."
Cc: stable@vger.kernel.org
Cc: Mika Kahola <mika.kahola@intel.com>
Fixes: b432e5cfd5 ("drm/i915: BDW clock change support")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461689194-6079-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
(cherry picked from commit 7f1052a8fa)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b192400627 upstream.
In commit 7608a43d8f ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when
appropriate") the owner field in the mutex was updated from being
dependent upon CONFIG_SMP to using optimistic spin. Update our peek
function to suite.
Fixes:7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...")
Reported-by: Hong Liu <hong.liu@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1468244777-4888-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
(cherry picked from commit 4f074a5393)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 664a84d2c7 upstream.
During hibernation the cached DP port register value will be left with
whatever value we have there when we create the hibernation image.
Currently that means the port (and eDP PLL) will be off in the cached
value. However when we resume there is no guarantee that the value
in the actual register will match the cached value. If i915 isn't
loaded in the kernel that loads the hibernation image, the port may
well be on (eg. left on by the BIOS). The encoder state readout
does the right thing in this case and updates our encoder state
to reflect the actual hardware state. However the post-resume modeset
will then use the stale cached port register value in
intel_dp_link_down() and potentially confuse the hardware.
This was caught by the following assert
WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915]
eDP PLL state assertion failure (expected on, current off)
on account of the eDP PLL getting prematurely turned off when
shutting down the port, since the DP_PLL_ENABLE bit wasn't set
in the cached register value.
Presumably I introduced this problem in
commit 6fec766283 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
as before that we didn't update the cached value after shuttting the
port down. That's assuming the port got enabled at least once prior
to hibernating. If that didn't happen then the cached value would
still have been totally out of sync with reality (eg. first boot w/o
eDP on, then hibernate, and then resume with eDP on).
So, let's fix this properly and refresh the cached register value from
the hardware register during resume.
DDI platforms shouldn't use the cached value during port disable at
least, so shouldn't have this particular issue. They might still have
issues if we skip the initial modeset and then try to retrain the link
or something. But untangling this DP vs. DDI mess is a bigger topic,
so let's jut punt on DDI for now.
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 6fec766283 ("drm/i915: Use intel_dp->DP in eDP PLL setup")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463162036-27931-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit 64989ca4b2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 476490a945 upstream.
Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:
[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf40000
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
------------[ cut here ]------------
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.
A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.
Changes since v4:
- Fix calculation of final for systems with LVDS panels (fixes BUG() on
CI test suite)
Changes since v3:
- Move temp variable into loop
- Move checks for using_ssc_source to after we've figured out has_ck505
- Add using_ssc_source to debug output
Changes since v2:
- Fix debug output for when we disable the CPU source
Changes since v1:
- Leave the SSC source clock on instead of just shutting it off on all
of the DPLL configurations.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 217215041b upstream.
Fixes a regression caused by a stupid thinko from "disp/sor/gf119: both
links use the same training register".
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52dfcc5ccf upstream.
Hello,
after this commit:
commit f045f459d9
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=120591
Signed-off-by: Dmitrii Tcvetkov <demfloro@demfloro.ru>
Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes: f045f459d9 ("nouveau_fbcon_init()")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
