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.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit 4636ce93d5 ("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.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The backend has various clocks and reset controls that need to be
enabled and deasserted before register access is possible.
Move the creation of the regmap to after the clocks and reset controls
have been configured where it makes more sense.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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.
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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.
v2: Add some comments requested by Boris
Signed-off-by: Eric Anholt <[email protected]>
Fixes: 98830d91da ("drm/vc4: Add T-format scanout support.")
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Boris Brezillon <[email protected]>
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
...
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).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103260
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Mika Kuoppala <[email protected]>
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.
Fixes: af7a8ffad9 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
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
Cc: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
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 c70087e8f1 ("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.
Signed-off-by: Maarten Lankhorst <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]> #irc
Fixes: c70087e8f1 ("drm/drm_of: add drm_of_panel_bridge_remove function")
Acked-by: Benjamin Gaignard <[email protected]>
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
@@
expression ex;
@@
(
-drm_framebuffer_unreference(ex);
+drm_framebuffer_put(ex);
|
-drm_dev_unref(ex);
+drm_dev_put(ex);
|
-drm_framebuffer_reference(ex);
+drm_framebuffer_get(ex);
)
Signed-off-by: Harsha Sharma <[email protected]>
[danvet: Drop the drm_dev_put change for now, to make the patch apply
with out a backmerge.]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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.
Cc: Rob Herring <[email protected]>
Cc: Frank Rowand <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Jyri Sarha <[email protected]>
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.
Reported-by: Kevin Hao <[email protected]>
Fixes: 11abbc9f39 ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled")
Cc: <[email protected]> # v4.11+
Signed-off-by: Jyri Sarha <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
More 4.15 drm-misc stuff:
Cross-subsystem Changes:
- bridge cleanup refactor (Benjamin Gaignard)
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)
New drivers:
- SiI9234 bridge driver (Maciej Purski)
- 7" rpi touch panel (Eric Anholt)
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()
...
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))
This adds the respective Kconfig dependency.
Fixes: 34cc0aa254 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Mark Yao <[email protected]>
Signed-off-by: Mark Yao <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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
c61eef726a ("drm: add support for monotonic vblank timestamps"),
so it's probably safer to just remove the parameter completely
and only allowing the default behavior.
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Daniel Stone <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
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 c61eef726a ("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.
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Reviewed-by: Keith Packard <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
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()
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
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.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
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.
Fixes: 80b204bce8 ("drm/i915: Enable multiple timelines")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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)
Cc: Rodrigo Vivi <[email protected]>
Cc: Jani Nikula <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
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.
Cc: [email protected]
Cc: Daniel Vetter <[email protected]>
Suggested-by: Daniel Vetter <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniel Vetter <[email protected]> #irc
