Michal Wajdeczko [Mon, 16 Oct 2017 14:47:20 +0000 (14:47 +0000)]
drm/i915: Update DMC firmware load error messages
Some of the error messages from DMC load were too generic and
may be confusing for the user. Lets explicitly add DMC words there.
Also as homepage of DMC firmware is same as for the GuC and Huc,
lets reuse URL definition.
Michal Wajdeczko [Mon, 16 Oct 2017 14:47:17 +0000 (14:47 +0000)]
drm/i915/guc: Pick better place for Guc final status message
GuC status message printed right after firmware upload may be too
optimistic, as we may fail on subsequent steps. Move that message
to the end of intel_uc_init_hw where we know the status for sure.
Weinan Li [Sun, 15 Oct 2017 03:55:25 +0000 (11:55 +0800)]
drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM
Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all
the host support this feature, need to check the BIT(3) of caps in PVINFO.
v3 : Remove unnecessary comments.
v4 : Separate VM enable patch with GVT-g implementation patch due to code
dependency.
v5 : Use inline for GVT virtual HWSP caps check function.
v6 : Comments refine.
Jérémy Lefaure [Mon, 16 Oct 2017 02:33:56 +0000 (22:33 -0400)]
drm/via: use ARRAY_SIZE
Using the ARRAY_SIZE macro improves the readability of the code.
Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
(sizeof(E)@p /sizeof(*E))
|
(sizeof(E)@p /sizeof(E[...]))
|
(sizeof(E)@p /sizeof(T))
)
Jérémy Lefaure [Mon, 16 Oct 2017 02:30:46 +0000 (22:30 -0400)]
drm/gma500: use ARRAY_SIZE
Using the ARRAY_SIZE macro improves the readability of the code. Also,
it is useless to re-invent it.
Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
(sizeof(E)@p /sizeof(*E))
|
(sizeof(E)@p /sizeof(E[...]))
|
(sizeof(E)@p /sizeof(T))
)
Chen-Yu Tsai [Sat, 14 Oct 2017 04:02:52 +0000 (12:02 +0800)]
drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function
Initially we configured the PAD_CTRL1 register at probe/bind time.
However it seems the HDMI controller will modify some of the bits
in this register by itself. On the A10 it is particularly annoying
as it toggles the output invert bits, which inverts the colors on
the display output.
The U-boot driver this driver is based on sets this register twice,
though it seems it's only needed for actual display output. Hence
we move it to the mode_set function.
While debugging inverted color from the HDMI output on the A10, I
found that the lowest 3 bits were set. These were cleared on A20
boards that had normal display output. By manually toggling these
bits the mapping of the color components to these bits was found.
While these are not used anywhere, it would be nice to document
them somewhere.
Chen-Yu Tsai [Sat, 14 Oct 2017 04:02:49 +0000 (12:02 +0800)]
drm/sun4i: backend: Add comment explaining why registers are cleared
Many of the backend's layer configuration registers have undefined
default values. This poses a risk as we use regmap_update_bits in
some places, and don't overwrite the whole register.
At probe/bind time we explicitly clear all the control registers
by writing 0 to them. This patch adds a more detailed explanation
on why we're doing this.
Chen-Yu Tsai [Sat, 14 Oct 2017 04:02:48 +0000 (12:02 +0800)]
drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory
Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.
This patch uses this helper to replace our own open coded version of the
same function.
Chen-Yu Tsai [Sat, 14 Oct 2017 04:02:46 +0000 (12:02 +0800)]
drm/sun4i: don't add components that are already in the queue
Even though the components framework can handle duplicate entries,
the extra entries cause a lot more debug messages to be generated,
which would be confusing to developers not familiar with our driver
and the framework in general.
Instead, we can scan the relatively small queue and check if the
component to be added is already queued up. Since the display
pipelines are symmetrical (not considering the third display
pipeline on the A80), and we add components level by level, when
we get to the second instance at the same level, any shared downstream
components would already be in the queue.
Eric Anholt [Wed, 27 Sep 2017 19:32:09 +0000 (12:32 -0700)]
drm/vc4: Fix pitch setup for T-format scanout.
The documentation said to use src_w here, and I didn't consider that
we actually needed to be using pitch somewhere in our setup. Fixes
scanout on my DSI panel when X11 does initial setup with 1920x1080
HDMI and 800x480 DSI both at 0,0 of the same framebuffer.
Dave Airlie [Fri, 13 Oct 2017 23:39:56 +0000 (09:39 +1000)]
Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next
Most notable addition this time is the support for the GPU performance
counters by Christian. This has been in the making for some time and it
has matured a lot. Since this is adding UAPI, the corresponding WIP
userspace can be found at [1] mesa/libdrm repos. I expect that
Christian sends out the final userspace patches for this once you have
pulled the kernel bits.
Philipp optimized the probe path, so etnaviv gets out of the way for
systems that want to boot real quick.
I've done mostly cleanups, disentangling etnaviv from the IOMMU API,
with some MMUv1 optimizations on the way.
* 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux: (36 commits)
drm/etnaviv: remove unnecessary clock stabilization delay
drm/etnaviv: reduce reset delay
drm/etnaviv: remove unused function etnaviv_gem_new
drm/etnaviv: remove stale comment
drm/etnaviv: submit supports performance monitor requests
drm/etnaviv: enable debug registers on demand
drm/etnaviv: need to disable clock gating when doing profiling
drm/etnaviv: add MC perf domain
drm/etnaviv: add TX perf domain
drm/etnaviv: add RA perf domain
drm/etnaviv: add SE perf domain
drm/etnaviv: add PA perf domain
drm/etnaviv: add SH perf domain
drm/etnaviv: add PE perf domain
drm/etnaviv: add HI perf domain
drm/etnaviv: use 'sync points' for performance monitor requests
drm/etnaviv: clear alloced event
drm/etnaviv: add 'sync point' support
drm/etnaviv: add performance monitor request processing
drm/etnaviv: copy pmrs from userspace
...
Chris Wilson [Fri, 13 Oct 2017 13:12:18 +0000 (14:12 +0100)]
drm/i915: Always stop the rings before a missing GPU reset
Always try to stop the rings, even if the GPU reset itself has been
disabled (via modparam i915.reset). This should at least stop the hw
from spinning in the background consuming resources (e.g. power and
memory bandwidth) letting the system rest-in-peace.
Chris Wilson [Fri, 13 Oct 2017 13:12:17 +0000 (14:12 +0100)]
drm/i915: Keep the rings stopped until they have been re-initialized
Before modifying the ring register (RING_START, HEAD, TAIL, CTL) we
first make sure it is stopped (or else the hw may not resample the
registers). However, we do not need to let the hw restart until after we
have reprogrammed all the rings. This should help prevent situations
where pending operations on the ring may resume (because we are trying
to re-initialize following an unsuccessful GPU hang, i.e. from
i915_gem_unset_wedged).
Chris Wilson [Thu, 12 Oct 2017 20:40:19 +0000 (21:40 +0100)]
drm/i915: Stop asserting on set-wedged vs nop_submit_request ordering
Since the removal of the stop_machine(), it is allowed and expected for
the nop_submit_request() and nop_complete_submit_request() to run in
parallel to the i915_gem_set_wedged() processing. As such we can no
longer assert that i915_gem_set_wedged() has completed inside the
stop_machine prior to the individual nop_submit_request execution.
Ville Syrjälä [Tue, 10 Oct 2017 12:12:06 +0000 (15:12 +0300)]
drm/i915: Plumb crtc_state etc. directly to intel_ddi_pre_enable_{dp,hdmi}()
Rather that plumb the link parameters separately to
intel_ddi_pre_enable_dp() let's just pass the entire crtc state.
intel_ddi_pre_enable_hdmi() already took the crtc state, but for some
reason intel_ddi_pre_enable() still wanted to extract has_infoframe
from therein and pass it in separately. Let's not do that since it's
pointless.
v2: Rebase due to more code getting pulled into the DDI hooks
Ville Syrjälä [Tue, 10 Oct 2017 12:12:04 +0000 (15:12 +0300)]
drm/i915: Remove useless eDP check from intel_ddi_pre_enable_dp()
intel_edp_panel_on() will itself do the is_edp() check, so the caller
doesn't have to bother. Pre-DDI code doesn't bother, so let's follow the
same approach for DDI.
Ville Syrjälä [Tue, 10 Oct 2017 12:12:02 +0000 (15:12 +0300)]
drm/i915: Inline the required bits of intel_ddi_post_disable() into intel_ddi_fdi_post_disable()
To untangle the mess that is intel_ddi_post_disable() move the the bits
needed by FDI into intel_ddi_fdi_post_disable(). This way we can stop
worrying about FDI in intel_ddi_post_disable().
Ville Syrjälä [Tue, 10 Oct 2017 12:11:59 +0000 (15:11 +0300)]
drm/i915: Dump 'output_types' in crtc state dump
To make it easier to debug things let's dump the output types bitmask in
the crtc state dump. And to make life that much better, let's pretty
print it as a a human reaadable string as well.
v2: Have the caller pass in the buffer (Chris)
#undef OUTPUT_TYPE (Jani)
Since the driver is relying on the atomic helpers, remove the explicit
.best_encoder assignment and let the core call
drm_atomic_helper_best_encoder().
drm/drm_of: Move drm_of_panel_bridge_remove_function into header.
Core drm shouldn't depend on anything in drm-kms-helper, or the drm
module will fail to load.
insmod drm fails with
[ 6087.674390] drm: Unknown symbol drm_panel_bridge_remove (err 0)
which is defined in drm_kms_helper.ko
This call was added by commit c70087e8f16f ("drm/drm_of: add
drm_of_panel_bridge_remove function"), and the fix is defining it in the
drm_of.h header, to break the circular dependency.
Harsha Sharma [Mon, 9 Oct 2017 12:06:43 +0000 (17:36 +0530)]
drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()
Replace instances of drm_framebuffer_reference/unreference() with
*_get/put() suffixes and drm_dev_unref with *_put() suffix
because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
Done with following coccinelle semantic patch
Thierry Reding [Thu, 12 Oct 2017 14:08:57 +0000 (16:08 +0200)]
drm/atomic-helper: Fix reference to drm_crtc_send_vblank_event()
Fix up this reference so that the proper link is generated in the
documentation and so that people don't go chasing after the wrong
function for an embarrassingly long time.
Stephen Boyd [Fri, 13 Oct 2017 07:47:55 +0000 (00:47 -0700)]
drm/tilcdc: Remove redundant OF_DETACHED flag setting
of_fdt_unflatten_tree() already sets the flag on this node to
OF_DETACHED, because of_fdt_unflatten_tree() calls
__unflatten_device_tree() with the detached bool set to true.
Jyri Sarha [Thu, 12 Oct 2017 09:19:46 +0000 (12:19 +0300)]
drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
We need the total frame refresh time to check if we are too close to
vertical sync when updating the two framebuffer DMA registers and risk
a collision. This new method is more accurate that the previous that
based on mode's vrefresh value, which itself is inaccurate or may not
even be initialized.
Shashank Sharma [Tue, 10 Oct 2017 10:07:44 +0000 (15:37 +0530)]
drm/i915: Add retries for LSPCON detection
We read the dp dual mode Adapter identifier to detect the
LSPCON device. It's been observed from the CI testing that in
few cases, this read can get delayed or fail. For such scenarios,
LSPCON vendors suggest to retry the read operation.
This patch adds retry in the probe function, while reading
LSPCON identifier.
Shashank Sharma [Tue, 10 Oct 2017 10:07:43 +0000 (15:37 +0530)]
drm/i915: Don't give up waiting on INVALID_MODE
Our current logic to read LSPCON's current mode, stops retries and
breaks wait-loop, if it gets LSPCON_MODE_INVALID as return from the
core function. This doesn't allow us to try reading the mode again.
This patch removes this condition and allows retries reading
the currnt mode until timeout.
This also fixes/prevents some of the noise in form of debug messages
while running IGT CI test cases.
V2: rebase, added r-b
V2: changed some debug message levels from debug->error and
error->debug in lspcon_get_current_mode function.
V3: Rebase
Shashank Sharma [Thu, 12 Oct 2017 16:40:08 +0000 (22:10 +0530)]
drm: Add retries for lspcon mode detection
From the CI builds, its been observed that during a driver
reload/insert, dp dual mode read function sometimes fails to
read from LSPCON device over i2c-over-aux channel.
This patch:
- adds some delay and few retries, allowing a scope for these
devices to settle down and respond.
- changes one error log's level from ERROR->DEBUG as we want
to call it an error only after all the retries are exhausted.
V2: Addressed review comments from Jani (for loop for retry)
V3: Addressed review comments from Imre (break on partial read too)
V3: Addressed review comments from Ville/Imre (Add the retries
exclusively for LSPCON, not for all dp_dual_mode devices)
V4: Added r-b from Imre, sending it to dri-devel (Jani)
James Ausmus [Thu, 12 Oct 2017 21:30:36 +0000 (14:30 -0700)]
drm/i915: Fix DP_AUX_CH_CTL_TIME_OUT naming
Rename DP_AUX_CH_CTL_TIME_OUT_1600us to DP_AUX_CH_CTL_TIME_OUT_MAX, as
the meaning of the (3 << 26) value varies per platform, but it's always the
maximum timeout for that platform. Pre-CNL it means 1600us, and for CNL
it means 3200us.
Dave Airlie [Fri, 13 Oct 2017 07:33:07 +0000 (17:33 +1000)]
Merge tag 'omapdrm-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
omapdrm changes for 4.15
* OMAP4 HDMI CEC support
* tag 'omapdrm-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
omapdrm: omapdss_hdmi_ops: add lost_hotplug op
omapdrm: hdmi4: hook up the HDMI CEC support
omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support
omapdrm: hdmi4: refcount hdmi_power_on/off_core
omapdrm: hdmi4: move hdmi4_core_powerdown_disable to hdmi_power_on_core()
omapdrm: hdmi4: prepare irq handling for HDMI CEC support
omapdrm: hdmi4: make low-level functions available
omapdrm: hdmi.h: extend hdmi_core_data with CEC fields
omapdrm: encoder-tpd12s015: keep ls_oe_gpio high
Core Changes:
- less surprising atomic iterators (Maarten), fixes an oops introduced
in drm-next
- better gem/fb helper docs (Noralf)
- fix dma-buf rcu races (Christian König)
Driver Changes:
- adv7511: CEC support (Hans Verkuil)
- sun4i update from Chen-Yu to improve hdmi and A31 support
- sii8620: add remote control support (Maceiej Purski)
Note that this contains a topic pull from regmap, needed by the sun4i
changes. Mark Brown sent that out for pulling into drm-misc.
* tag 'drm-misc-next-2017-10-12' of git://anongit.freedesktop.org/drm/drm-misc: (29 commits)
drm/dp: WARN about invalid/unknown link rates and bw codes
drm/msm/mdp5: remove less than 0 comparison for unsigned value
drm/bridge/sii8620: add remote control support
drm/sun4i: hdmi: Add support for A31's HDMI controller
drm/sun4i: hdmi: Add A31 specific DDC register definitions
drm/sun4i: hdmi: Add support for controller hardware variants
dt-bindings: display: sun4i: Add binding for A31 HDMI controller
drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent
drm/sun4i: hdmi: create a regmap for later use
drm/sun4i: hdmi: Disable clks in bind function error path and unbind function
drm/sun4i: tcon: Add support for demuxing TCON output on A31
drm/sun4i: tcon: Add variant callback for TCON output muxing
drm/bridge/synopsys: dsi :remove is_panel_bridge
drm/vc4: remove bridge from driver internal structure
drm/stm: ltdc: remove bridge from driver internal structure
drm/drm_of: add drm_of_panel_bridge_remove function
drm/bridge: make drm_panel_bridge_remove more robust
dma-fence: fix dma_fence_get_rcu_safe v2
dma-buf: make reservation_object_copy_fences rcu save
drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
...
Arnd Bergmann [Thu, 5 Oct 2017 12:09:39 +0000 (14:09 +0200)]
drm/rockchip: add PINCTRL dependency for LVDS
The new driver fails to build when CONFIG_PINCTRL is disabled:
drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 'rockchip_lvds_grf_config':
drivers/gpu/drm/rockchip/rockchip_lvds.c:229:39: error: dereferencing pointer to incomplete type 'struct dev_pin_info'
if (lvds->pins && !IS_ERR(lvds->pins->default_state))
There is a risk of overflowing vblank timestamps in 2038 or 2106 if
someone sets the drm_timestamp_monotonic module parameter to zero.
I found no indication of anyone ever setting the parameter, or
complaining about the default being wrong, after it was introduced
as a way to handle backwards-compatibility with linux prior to c61eef726a78 ("drm: add support for monotonic vblank timestamps"),
so it's probably safer to just remove the parameter completely
and only allowing the default behavior.
Arnd Bergmann [Wed, 11 Oct 2017 15:20:12 +0000 (17:20 +0200)]
drm: vblank: use ktime_t instead of timeval
The drm vblank handling uses 'timeval' to store timestamps in either
monotonic or wall-clock time base. In either case, it reads the current
time as a ktime_t in get_drm_timestamp() and converts it from there.
This is a bit suspicious, as users of 'timeval' often suffer from
the time_t overflow in y2038. I have gone through this code and
found that it is unlikely to cause problems here:
- The user space ABI does not use time_t or timeval, but uses
'u32' and 'long' as the types. This means at least that rebuilding
user programs against a new libc with 64-bit time_t does not
change the ABI.
- As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps") in linux-3.8, the monotonic timestamp is the default
and can only get reverted to wall-clock through a module-parameter.
- With the default monotonic timestamps, there is no problem at all.
- The drm_wait_vblank_ioctl() interface is alway safe on 64-bit
architectures, on 32-bit it might overflow the 'long' timestamps
in 2038 with wall-clock timestamps.
- The event handling uses 'u32' seconds, which overflow in 2106
on both 32-bit and 64-bit machines, when wall-clock timestamps
are used.
- The effect of overflowing either of the two is only temporary
(during the overflow, and is likely to keep working again
afterwards. It is likely the same problem as observing a
'settimeofday()' call, which was the reason for moving to the
monotonic timestamps in the first place.
Overall, this seems good enough, so my patch removes the use of
'timeval' from the vblank handling altogether and uses ktime_t
consistently, except for the part where we copy the data to user
space structures in the existing format.
Chris Wilson [Thu, 12 Oct 2017 12:57:26 +0000 (13:57 +0100)]
drm/i915/selftests: Exercise adding requests to a full GGTT
A bug recently encountered involved the issue where are we were
submitting requests to different ppGTT, each would pin a segment of the
GGTT for its logical context and ring. However, this is invisible to
eviction as we do not tie the context/ring VMA to a request and so do
not automatically wait upon it them (instead they are marked as pinned,
preventing eviction entirely). Instead the eviction code must flush those
contexts by switching to the kernel context. This selftest tries to
fill the GGTT with contexts to exercise a path where the
switch-to-kernel-context failed to make forward progress and we fail
with ENOSPC.
v2: Make the hole in the filled GGTT explicit.
v3: Swap out the arbitrary timeout for a private notification from
i915_gem_evict_something()
Chris Wilson [Thu, 12 Oct 2017 12:57:25 +0000 (13:57 +0100)]
drm/i915/selftests: Wrap a timer into a i915_sw_fence
For some selftests, we want to issue requests but delay them going to
hardware. Furthermore, we don't want those requests to block
indefinitely (or else we may hang the driver and block testing) so we
want to employ a timeout. So naturally we want a fence that is
automatically signaled by a timer.
v2: Add kselftests.
v3: Limit the API available to selftests; there isn't an overwhelming
reason to export it universally.
Chris Wilson [Thu, 12 Oct 2017 12:57:24 +0000 (13:57 +0100)]
drm/i915: Fix eviction when the GGTT is idle but full
In the full-ppgtt world, we can fill the GGTT full of context objects.
These context objects are currently implicitly tracked by the requests
that pin them i.e. they are only unpinned when the request is completed
and retired, but we do not have the link from the vma to the request
(anymore). In order to unpin those contexts, we have to issue another
request and wait upon the switch to the kernel context.
The bug during eviction was that we assumed that a full GGTT meant we
would have requests on the GGTT timeline, and so we missed situations
where those requests where merely in flight (and when even they have not
yet been submitted to hw yet). The fix employed here is to change the
already-is-idle test to no look at the execution timeline, but count the
outstanding requests and then check that we have switched to the kernel
context. Erring on the side of overkill here just means that we stall a
little longer than may be strictly required, but we only expect to hit
this path in extreme corner cases where returning an erroneous error is
worse than the delay.
v2: Logical inversion when swapping over branches.
Ville Syrjälä [Thu, 12 Oct 2017 13:02:01 +0000 (16:02 +0300)]
drm/i915: Start tracking PSR state in crtc state
Add the minimal amount of PSR tracking into the crtc state. This allows
precomputing the possibility of using PSR correctly, and it means we can
safely call the psr enable/disable functions for any DP endcoder.
As a nice bonus we get rid of some more crtc->config usage, which we
want to kill off eventually.
v2: Fix 'goto unlock' fail in intel_psr_enable() (Jani)
Check intel_dp_is_edp() in is_edp_psr() (Jani)
Ville Syrjälä [Tue, 10 Oct 2017 13:33:22 +0000 (16:33 +0300)]
drm/vblank: Fix flip event vblank count
On machines where the vblank interrupt fires some time after the start
of vblank (or we just manage to race with the vblank interrupt handler)
we will currently stuff a stale vblank counter value into the flip event,
and thus we'll prematurely complete the flip.
Switch over to drm_crtc_accurate_vblank_count() to make sure we have an
up to date counter value, crucially also remember to add the +1 so that
the delayed vblank interrupt won't complete the flip prematurely.
Chris Wilson [Wed, 11 Oct 2017 14:18:57 +0000 (15:18 +0100)]
drm/i915/userptr: Drop struct_mutex before cleanup
Purely to silence lockdep, as we know that no bo can exist at this time
and so the inversion is impossible. Nevertheless, lockdep currently
warns on unload:
[ 137.522565] WARNING: possible circular locking dependency detected
[ 137.522568] 4.14.0-rc4-CI-CI_DRM_3209+ #1 Tainted: G U
[ 137.522570] ------------------------------------------------------
[ 137.522572] drv_module_relo/1532 is trying to acquire lock:
[ 137.522574] ("i915-userptr-acquire"){+.+.}, at: [<ffffffff8109a831>] flush_workqueue+0x91/0x540
[ 137.522581]
but task is already holding lock:
[ 137.522583] (&dev->struct_mutex){+.+.}, at: [<ffffffffa014fb3f>] i915_gem_fini+0x3f/0xc0 [i915]
[ 137.522605]
which lock already depends on the new lock.
Hans Verkuil [Thu, 17 Aug 2017 13:19:57 +0000 (15:19 +0200)]
omapdrm: omapdss_hdmi_ops: add lost_hotplug op
The CEC framework needs to know when the hotplug detect signal
disappears, since that means the CEC physical address has to be
invalidated (i.e. set to f.f.f.f).
Add a lost_hotplug op that is called when the HPD signal goes away.
Hans Verkuil [Wed, 2 Aug 2017 08:54:04 +0000 (10:54 +0200)]
omapdrm: hdmi4: move hdmi4_core_powerdown_disable to hdmi_power_on_core()
Call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to
power up the HDMI core (needed for CEC). The same call can now be dropped
in hdmi4_configure().
Hans Verkuil [Wed, 2 Aug 2017 08:54:02 +0000 (10:54 +0200)]
omapdrm: hdmi4: make low-level functions available
Three low-level functions in hdmi4.c and hdmi4_core.c are
made available for use by the OMAP4 CEC support.
Renamed the prefix to hdmi4 since these are OMAP4 specific.
These function deal with the HDMI core and are needed to
power it up for use with CEC, even when the HPD is low.
Background: even if the HPD is low it should still be possible
to use CEC. Some displays will set the HPD low when they go into standby or
when they switch to another input, but CEC is still available and able
to wake up/change input for such a display.
Hans Verkuil [Wed, 2 Aug 2017 08:54:00 +0000 (10:54 +0200)]
omapdrm: encoder-tpd12s015: keep ls_oe_gpio high
For OMAP4 CEC support the CEC pin should always be on. So keep
ls_oe_gpio high all the time in order to support CEC.
Background: even if the HPD is low it should still be possible
to use CEC. Some displays will set the HPD low when they go into standby or
when they switch to another input, but CEC is still available and able
to wake up/change input for such a display.
Dave Airlie [Thu, 12 Oct 2017 00:20:03 +0000 (10:20 +1000)]
Merge tag 'drm-intel-next-2017-09-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
2nd batch of v4.15 features:
- lib/scatterlist updates, use for userptr allocations (Tvrtko)
- Fixed point wrapper cleanup (Mahesh)
- Gen9+ transition watermarks, watermark optimization and fixes (Mahesh)
- Display IPC (Isochronous Priority Control) support (Mahesh)
- GEM workaround fixes (Oscar)
- GVT: PCI config sanitize series (Changbin)
- GVT: Workload submission error handling series (Fred)
- PSR fixes and refactoring (Rodrigo)
- HWSP based optimizations (Chris)
- Private PAT management (Zhi)
- IRQ handling fixes and refactoring (Ville)
- Module parameter refactoring and variable name clash fix (Michal)
- Execlist refactoring, incomplete request unwinding on reset (Chris)
- GuC scheduling improvements (Michal)
- OA updates (Lionel)
- Coffeelake out of alpha support (Rodrigo)
- seqno fixes (Chris)
- Execlist refactoring (Mika)
- DP and DP MST cleanups (Dhinakaran)
- Cannonlake slice/sublice config (Ben)
- Numerous fixes all around (Everyone)
* tag 'drm-intel-next-2017-09-29' of git://anongit.freedesktop.org/drm/drm-intel: (168 commits)
drm/i915: Update DRIVER_DATE to 20170929
drm/i915: Use memset64() to prefill the GTT page
drm/i915: Also discard second CRC on gen8+ platforms.
drm/i915/psr: Set frames before SU entry for psr2
drm/dp: Add defines for latency in sink
drm/i915: Allow optimized platform checks
drm/i915: Avoid using dev_priv->info.gen directly.
i915: Use %pS printk format for direct addresses
drm/i915/execlists: Notify context-out for lost requests
drm/i915/cnl: Add support slice/subslice/eu configs
drm/i915: Compact device info access by a small re-ordering
drm/i915: Add IS_PLATFORM macro
drm/i915/selftests: Try to recover from a wedged GPU during reset tests
drm/i915/huc: Reorganize HuC authentication
drm/i915: Fix default values of some modparams
drm/i915: Extend I915_PARAMS_FOR_EACH with default member value
drm/i915: Make I915_PARAMS_FOR_EACH macro more flexible
drm/i915: Enable scanline read based on frame timestamps
drm/i915/execlists: Microoptimise execlists_cancel_port_request()
drm/i915: Don't rmw PIPESTAT enable bits
...
Jani Nikula [Mon, 9 Oct 2017 09:29:58 +0000 (12:29 +0300)]
drm/i915/dp: centralize max source rate conditions more
Turn intel_dp_source_supports_hbr2() into a simple helper to query the
pre-filled source rates array, and move the conditions about which
platforms support which rates to the single point of truth in
intel_dp_set_source_rates().
This also reduces the code paths you have to think about in the source
rates initialization in intel_dp_set_source_rates(), making it easier to
grasp.
Ville Syrjälä [Mon, 9 Oct 2017 16:19:51 +0000 (19:19 +0300)]
drm/i915: Allow PCH platforms fall back to BIOS LVDS mode
With intel_encoder_current_mode() using the normal state readout code it
actually works on PCH platforms as well. So let's nuke the PCH check from
intel_lvds_init(). I suppose there aren't any machines that actually
need this, but at least we get to eliminate a few lines of code, and one
FIXME.
Ville Syrjälä [Mon, 9 Oct 2017 16:19:50 +0000 (19:19 +0300)]
drm/i915: Reuse normal state readout for LVDS/DVO fixed mode
Reuse the normal state readout code to get the fixed mode for LVDS/DVO
encoders. This removes some partially duplicated state readout code
from LVDS/DVO encoders. The duplicated code wasn't actually even
populating the negative h/vsync flags, leading to possible state checker
complaints. The normal readout code populates that stuff fully.
Daniel Vetter [Wed, 11 Oct 2017 09:10:19 +0000 (11:10 +0200)]
drm/i915: Use rcu instead of stop_machine in set_wedged
stop_machine is not really a locking primitive we should use, except
when the hw folks tell us the hw is broken and that's the only way to
work around it.
This patch tries to address the locking abuse of stop_machine() from
drm/i915: Stop the machine as we install the wedged submit_request handler
Chris said parts of the reasons for going with stop_machine() was that
it's no overhead for the fast-path. But these callbacks use irqsave
spinlocks and do a bunch of MMIO, and rcu_read_lock is _real_ fast.
To stay as close as possible to the stop_machine semantics we first
update all the submit function pointers to the nop handler, then call
synchronize_rcu() to make sure no new requests can be submitted. This
should give us exactly the huge barrier we want.
I pondered whether we should annotate engine->submit_request as __rcu
and use rcu_assign_pointer and rcu_dereference on it. But the reason
behind those is to make sure the compiler/cpu barriers are there for
when you have an actual data structure you point at, to make sure all
the writes are seen correctly on the read side. But we just have a
function pointer, and .text isn't changed, so no need for these
barriers and hence no need for annotations.
Unfortunately there's a complication with the call to
intel_engine_init_global_seqno:
- Without stop_machine we must hold the corresponding spinlock.
- Without stop_machine we must ensure that all requests are marked as
having failed with dma_fence_set_error() before we call it. That
means we need to split the nop request submission into two phases,
both synchronized with rcu:
1. Only stop submitting the requests to hw and mark them as failed.
2. After all pending requests in the scheduler/ring are suitably
marked up as failed and we can force complete them all, also force
complete by calling intel_engine_init_global_seqno().
This should fix the followwing lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc3-CI-CI_DRM_3179+ #1 Tainted: G U
------------------------------------------------------
kworker/3:4/562 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8113d4bc>] stop_machine+0x1c/0x40
but task is already holding lock:
(&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
v2: Have 1 global synchronize_rcu() barrier across all engines, and
improve commit message.
v3: We need to protect the seqno update with the timeline spinlock (in
set_wedged) to avoid racing with other updates of the seqno, like we
already do in nop_submit_request (Chris).
v4: Use two-phase sequence to plug the race Chris spotted where we can
complete requests before they're marked up with -EIO.
v5: Review from Chris:
- simplify nop_submit_request.
- Add comment to rcu_read_lock section.
- Align comments with the new style.
Jani Nikula [Mon, 9 Oct 2017 09:29:57 +0000 (12:29 +0300)]
drm/dp: WARN about invalid/unknown link rates and bw codes
Falling back to the lowest value is likely the only thing we can do, but
doing it silently seems like a bad thing to do. Catch it early and make
loud noises.
Maciej Purski [Thu, 24 Aug 2017 08:58:07 +0000 (10:58 +0200)]
drm/bridge/sii8620: add remote control support
MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.
drm/i915: Create generic functions to control RC6, RPS
Prepared generic functions intel_enable_rc6, intel_disable_rc6,
intel_enable_rps and intel_disable_rps functions to setup RC6/RPS
based on platforms.
v2: Make intel_enable/disable_rc6/rps static. (Chris)
v3: Added lockdep_assert_held(dev_priv->pcu_lock) in new generic
functions. (Chris)
Removed WARN_ON(&dev_priv->pcu_lock) from lower level functions as generic
function now has lockdep_assert. Rebase.
drm/i915: Rename intel_enable_rc6 to intel_rc6_enabled
This function gives the status of RC6, whether disabled or if
enabled then which state. intel_enable_rc6 will be used for
enabling RC6 in the next patch.
drm/i915: Name structure in dev_priv that contains RPS/RC6 state as "gt_pm"
Prepared substructure rps for RPS related state. autoenable_work is
used for RC6 too hence it is defined outside rps structure. As we do
this lot many functions are refactored to use intel_rps *rps to access
rps related members. Hence renamed intel_rps_client pointer variables
to rps_client in various functions.
v2: Rebase.
v3: s/pm/gt_pm (Chris)
Refactored access to rps structure by declaring struct intel_rps * in
many functions.
drm/i915: Move rps.hw_lock to dev_priv and s/hw_lock/pcu_lock
In order to separate GT PM related functionality into new structure
we are updating rps structure. hw_lock in it is used for display
related PCU communication too hence move it to dev_priv.
This patch separates RC6 and RPS enabling for BDW.
RC6/RPS Disabling are handled through gen6 functions.
PM Programming guide recommends a sequence within forcewakes to
configure RC6, RPS and ring frequencies in sequence. With this
patch the order is still maintained.
v2: Update sequence numbers in RC6 programming and comment about
intent of reset_rps during gen8_enable_rps. (Radoslaw)
projects / linux.git / log