Dave Airlie [Tue, 20 Feb 2018 21:03:35 +0000 (07:03 +1000)]
Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/media into drm-next
LVDS startup fixes, enable VSP compositor on GEN3
* 'drm/next/du' of git://linuxtv.org/pinchartl/media:
drm: rcar-du: lvds: Refactor LVDS startup
drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3
drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2
drm: rcar-du: lvds: Fix LVDS clock frequency range
drm: rcar-du: lvds: Fix LVDCR1 for R-Car gen3
drm: rcar-du: Enable VSP compositor by default on Gen3
drm: rcar-du: Calculate DPLLCR to be more small jitter
drm: rcar-du: Use 1000 to avoid misunderstanding in rcar_du_dpll_divider()
drm: rcar-du: Remove zpos field from rcar_du_vsp_plane_state structure
Chris Wilson [Tue, 20 Feb 2018 13:42:08 +0000 (13:42 +0000)]
drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced
Rather than trusting the cached value of plane_state->vma->fence to
imply whether the plane_state itself holds a reference on the
framebuffer's fence, use the information provided in the
plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC
is entirely bounded by the plane_state active life span; it's not clear
if that is a safe assumption.
Chris Wilson [Tue, 20 Feb 2018 13:42:07 +0000 (13:42 +0000)]
drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning
Use the information about the fence state from the time of pinning to
determine if the fbdev writes are going through a fence. This avoids any
confusion in cases where the fence may appear or disappear unconnected
to the use by fbdev.
Chris Wilson [Tue, 20 Feb 2018 13:42:06 +0000 (13:42 +0000)]
drm/i915: Move the policy for placement of the GGTT vma into the caller
Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruct us where to place the VMA so
that it can enable the features it wants. As such, make the pin flags an
argument to i915_gem_object_pin_to_display() and control them from
intel_pin_and_fence_fb_obj()
Whilst taking control of the mapping for ourselves, start tracking how
we use it to avoid trying to free a fence we never claimed:
Chris Wilson [Tue, 20 Feb 2018 13:42:05 +0000 (13:42 +0000)]
drm/i915: Also check view->type for a normal GGTT view
We cannot simply use !view as shorthand for all normal GGTT views as a
few callers will always populate a i915_ggtt_view struct and set the
type to NORMAL instead. So check for (!view || view->type == NORMAL)
inside i915_gem_object_ggtt_pin().
Ville Syrjälä [Tue, 30 Jan 2018 20:38:02 +0000 (22:38 +0200)]
drm/i915: Set the primary plane pipe select bits on gen4
i965 and g4x still have the pipe select bits in the plane control
registers, they're just hardcoded to select a specific pipe. However
plane C on i965 can still move between the pipes, thus we should
program the pipe select bits on i965 if we want to expose plane C
some day.
Since there is no harm in programming the bits on any plane on
i965/g4x let's just always set them. This will also make our
pre-computed register value match what the hardware register
would read, should we want to cross check the two.
Ville Syrjälä [Tue, 30 Jan 2018 20:38:01 +0000 (22:38 +0200)]
drm/i915: Don't set cursor pipe select bits on g4x+
G4x cursor control registers still allow us to write to the pipe select
bits even though cursors are supposed to be fixed to a specific pipe.
Bspec tells us that we should only ever write 0 to these bits. Let's
follow that recommendation. On ilk+ the bits become hardwired to 0.
Also looks like ICL repurposes these bits for some other use, so
we had better stop setting them to bogus values there.
Ville Syrjälä [Wed, 24 Jan 2018 18:36:42 +0000 (20:36 +0200)]
drm/i915: Assert that we don't overflow frontbuffer tracking bits
Add some compile time assrts to the frontbuffer tracking to make sure
that we have enough bits per pipe to cover all the planes, and that we
have enough total bits to cover all the planes across all pipes.
We'll ignore any potential clash between the overlay bit and the
plane bits because that will allow us to keep using a total of 32
bits for the foreseeable future.
While at it change the macros to use BIT() and GENMASK(). The latter
gets rid of the hardcoded 0xff and thus means we can change the
number of bits per pipe by just changing
INTEL_FRONTBUFFER_BITS_PER_PIPE.
Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight
Remove tinydrm_of_find_backlight from tinydrm-helpers.c. We now have
a generic of_find_backlight defined in backlight.c. Let the callers
of tinydrm_of_find_backlight call of_find_backlight. Also, remove
select BACKLIGHT_LCD_SUPPORT and select BACKLIGHT_CLASS_DEVICE from
tinydrm/Kconfig as it is a hack that is no longer needed.
Jani Nikula [Mon, 19 Feb 2018 10:40:09 +0000 (12:40 +0200)]
drm: add documentation for tv connector state margins
A bit boring documentation fix, but gets rid of the warnings:
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.left' not described in 'drm_tv_connector_state'
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.right' not described in 'drm_tv_connector_state'
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.top' not described in 'drm_tv_connector_state'
./include/drm/drm_connector.h:370: warning: Function parameter or member 'margins.bottom' not described in 'drm_tv_connector_state'
[Depends on fe7bc493d979 ("scripts: kernel-doc: support in-line comments
on nested structs/unions") in docs-next to actually fix the warnings.]
Daniel Vetter [Mon, 19 Feb 2018 22:53:54 +0000 (23:53 +0100)]
drm/docs: Document "scaling mode" property better
Move it out of the csv dungeon.
While at it add the missing link to the helper functions for setting
up the "panel rotation" property.
Also OCD how we list enum property values and their corresponding docs.
Going for a nest definition list seams cleanest, no need for also making
it an uordered list.
Daniel Vetter [Mon, 19 Feb 2018 22:53:53 +0000 (23:53 +0100)]
drm/docs: Align layout of optional plane blending properties
Just a bit of drive-by OCD. All the other property docs use enumerations,
for some nice visual consistency. It also neatly highlights the property
name.
Daniel Vetter [Mon, 19 Feb 2018 22:53:52 +0000 (23:53 +0100)]
drm/docs: Discourage adding more to kms-properties.csv
Motivated by patch review.
The table is really hard to read in source form, hard to edit, and
we've moved away to more focused sections about specific features and
how they're exposed in properties.
Those sections can then more easily enumerate options, link to helper
functions and other parts of the docs. All things that get ugly real
fast in the docs.
Chris Wilson [Mon, 19 Feb 2018 22:06:31 +0000 (22:06 +0000)]
drm/i915: Track number of pending freed objects
During igt, we frequently call into the driver to reset both HW and
driver state (idling the device, waiting for it to become idle and
freeing off old objects) to ensure that we start each test/subtest/pass
from known state. This process incurs an RCU barrier or two to ensure
that any such pending frees are indeed flushed before we return.
However, unconditionally waiting on the RCU barrier adds needless delay
to many callers, which adds up to several seconds when repeated thousands
of times. We can skip the rcu_barrier() if by tracking how many outstanding
frees we have, we know there are none.
The same path is used along suspend, where we may be able to save the
unconditional RCU barrier.
To put it into perspective with a completely meaningless
microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw.
v2: Remove the extra synchronize_rcu() inside i915_drop_caches_set()
Linus Walleij [Tue, 20 Feb 2018 07:28:59 +0000 (08:28 +0100)]
drm: simple_kms_helper: Add mode_valid() callback support
The PL111 needs to filter valid modes based on memory bandwidth.
I guess it is a pretty simple operation, so we can still claim
the DRM KMS helper pipeline is simple after adding this (optional)
vtable callback.
Chris Wilson [Wed, 15 Nov 2017 10:50:35 +0000 (10:50 +0000)]
drm/i915/: Initialise trans_min for skl_compute_transition_wm()
clang spots
drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (INTEL_GEN(dev_priv) >= 10)
but fortunately for us we skip the function unless on a gen10+ device.
However, to keep the function generic in case we do want to re-enable it
for gen9 again, initialise trans_min to 0.
Chris Wilson [Mon, 19 Feb 2018 14:01:44 +0000 (14:01 +0000)]
drm/i915: Clear the in-use marker on execbuf failure
If we fail to unbind the vma (due to a signal on an active buffer that
needs to be moved for the next execbuf), then we need to clear the
persistent tracking state we setup for this execbuf.
Alex Deucher [Tue, 13 Feb 2018 19:33:51 +0000 (14:33 -0500)]
drm/amdgpu/cgs: add refresh rate checking to non-DC display code
Clamp the vblank period to 0 if the refresh rate is larger than
120 hz for non-DC. This allows us to remove the refresh rate
checks from powerplay for mclk switching.
drm/amdgpu_gem: fix error handling path in amdgpu_gem_va_update_vm
Currently, if amdgpu_vm_bo_update() fails, the returned error
is being ignored.
Fix this by properly checking _r_ after calling amdgpu_vm_bo_update.
Also, remove redundant code just before label _error_.
Addresses-Coverity-ID: 1464280 ("Unused value") Fixes: 0abc6878fc2d ("drm/amdgpu: update VM PDs after the PTs") Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
drm/amd/display: Fix increment when sampling OTF in DCE
Previously, the number of software segmets per region was reduced to 16.
This needs to be reflected in the sampling distance (increment) used when
translating to the hardware format.
Tao [Thu, 8 Feb 2018 21:04:25 +0000 (16:04 -0500)]
drm/amd/display: Set vsc pack revision when DPCD revision is >= 1.2
Brightness couldn't change when booting up in DC mode.
It was because "psr_enabled" flag was not set to true before
setting vsc packet revision, causing packet rev setup was skipped.
Now instead of checking the psr flag, it checks if the DPCD_REV >= 1.2
and set the vsc packet revision.
Roman Li [Tue, 6 Feb 2018 23:47:26 +0000 (18:47 -0500)]
drm/amd/display: Make FBC work without fbdev emulation
Previously, FBC dynamic allocation relied on connector modes
populated during dm init. This is only the case if
DRM_FBDEV_EMULATION config flag is enabled.
Moving fbc allocation from dm_late_init() to
amdgpu_dm_connector_get_modes() where actual modes init happens.
Leo (Sunpeng) Li [Tue, 23 Jan 2018 22:43:37 +0000 (17:43 -0500)]
drm/amd/display: When enabling CRC, disable dither & enable truncation
When user-mode is using 8bpc, the hardware represents it internally
using a higher bit depth. This causes problems when comparing CRCs for
color managment tests.
We need to disable dithering as well, since it makes CRC values
non-deterministic.
It's easy to see why dithering needs to be disabled, The reason why
truncation also needs to be enabled is better described with an example.
Consider the folowing which tests the color transform matrix (CTM):
Actual CRC = FB_B -> Degamma (Bypassed) -> CTM (0.5*Identity)
|
v
Obtain CRC <- Regamma(Bypassed)
FB_A contains a solid red color at half intensity (127 @ 8bpc)
FB_B contains a solid red color at full intensity (255 @ 8bpc)
We expect that Expected CRC = Actual CRC, but that's not the case. When
the CTM is applied, the output is at half intensity, but also at a
higher bit depth within hardware. i.e. 255/2 = 127.5: not representable
in 8bpc, but can be at 10bpc. This causes the two CRC's to be different.
The solution is to truncate the output bit depth to the same as input
when enabling CRC capture. Since Linux only supports 8bpc, hard code
that for now.
drm/amd/display: Hookup color management functions
Hookup new color management functions into amdgpu_dm:
- Notify DRM that we support CRTC color management during CRTC init
- Call color management functions within atomic check to update dc
states in preparation for a commit
drm/amd/display: Use hardware max low point when sampling OTF
The MAX_LOW_POINT macro should reflect the maximum low point within
hardware. Otherwise, sampling for the hardware points from the output
transfer function (OTF) will be incorrect.
Yongqiang Sun [Fri, 2 Feb 2018 22:35:00 +0000 (17:35 -0500)]
drm/amd/display: Keep eDP stream enabled during boot.
This path fixed specific eDP panel cold boot black screen
due to unnecessary enable link.
Change:
In case of boot up with eDP, if OS is going to set mode
on eDP, keep eDP light up, do not disable and reset corresponding
HW.
This change may affect dce asics and S3/S4 Resume with multi-monitor.
Hersen Wu [Tue, 30 Jan 2018 16:46:16 +0000 (11:46 -0500)]
drm/amd/display: VGA black screen from s3 when attached to hook
[Description] For MST, DC already notify MST sink for MST mode, DC stll
check DP SINK DPCD register to see if MST enabled. DP RX firmware may
not handle this properly.
Mikita Lipski [Sat, 3 Feb 2018 20:19:20 +0000 (15:19 -0500)]
drm/amdgpu: Unify the dm resume calls into one
amdgpu_dm_display_resume is now called from dm_resume to
unify DAL resume call into a single function call
There is no more need to separately call 2 resume functions
for DM.
Initially they were separated to resume display state after
cursor is pinned. But because there is no longer any corruption
with the cursor - the calls can be merged into one function hook.
amdgpu/dc/calcs: Support clang option for stack alignment
calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.
amdgpu/dc/dml: Support clang option for stack alignment
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.
Shaoyun Liu [Thu, 1 Feb 2018 22:37:50 +0000 (17:37 -0500)]
drm/amdgpu: Basic emulation support
Add amdgpu_emu_mode module parameter to control the emulation mode
Avoid vbios operation on emulation since there is no vbios post duirng emulation,
use the common hw_init to simulate the post
amdgpu/dc: Fix enum mismatch in calls to program_color_matrix()
The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
graphics_csc_adjust_type to program_color_matrix(), however the function
expects a parameter of type enum grph_color_adjust_option. Supposedly
the intention was to pass GRPH_COLOR_MATRIX_SW, which has the same value
as GRAPHICS_CSC_ADJUST_TYPE_SW, so the mismatch didn't cause any trouble.
Pass GRPH_COLOR_MATRIX_SW to program_color_matrix() instead of
GRAPHICS_CSC_ADJUST_TYPE_SW, this also fixes the following warning when
building the kernel with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.c:1129:24:
error: implicit conversion from enumeration type
'enum graphics_csc_adjust_type' to different enumeration type
'enum grph_color_adjust_option' [-Werror,-Wenum-conversion]
xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);
projects / linux.git / log