qxl: hook monitors_config updates into crtc, not encoder.
The encoder callbacks are only called in case the video mode changes.
So any layout changes without mode changes will go unnoticed.
Add qxl_crtc_update_monitors_config(), based on the old
qxl_write_monitors_config_for_encoder() function. Hook it into the
enable, disable and flush atomic crtc callbacks. Remove monitors_config
updates from all other places.
qxl_io_log() sends messages over to the host (qemu) for logging.
Remove the function and all callers, we can just use standard
DRM_DEBUG calls (and if needed a serial console).
Philippe CORNU [Thu, 25 Jan 2018 15:55:04 +0000 (16:55 +0100)]
drm/bridge/synopsys: dsi: use adjusted_mode in mode_set
The "adjusted_mode" clock value (ie the real pixel clock) is more
accurate than "mode" clock value (ie the panel/bridge requested
clock value). It offers a better preciseness for timing
computations and allows to reduce the extra dsi bandwidth in
burst mode (from ~20% to ~10-12%, hw platform dependent).
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
drm/gma500: fix psb_intel_lvds_mode_valid()'s return type
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method, psb_intel_lvds_mode_valid(), uses an 'int' for it.
Fix this by using 'enum drm_mode_status' for psb_intel_lvds_mode_valid().
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
drm/bridge: tc358767: fix mode_valid's return type
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Kieran Bingham [Tue, 13 Feb 2018 17:48:57 +0000 (17:48 +0000)]
drm: adv7511: Add support for i2c_new_secondary_device
The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.
Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.
Kieran Bingham [Tue, 13 Feb 2018 17:48:54 +0000 (17:48 +0000)]
dt-bindings: adv7511: Extend bindings to allow specifying slave map addresses
The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.
Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.
Daniel Vetter [Thu, 5 Apr 2018 15:44:46 +0000 (17:44 +0200)]
drm/atomic: better doc for implicit vs explicit fencing
Note that a pile of drivers don't seem to take implicit fencing into
account, or at least don't call drm_atoimc_set_fence_for_plane().
Cc'ing relevant people, or at least some. Some drivers also look like
they don't disable implicit fencing (e.g. amdgpu) because the explicit
fences and implicit fences are handled by entirely independent code
paths.
I also wonder whether we shouldn't just make the recommended helpers
the default ones, since a lot of drivers don't bother to handle the
implicit fences at all it seems. The helpers won't blow up even for
non-GEM drivers or GEM drivers which don't fill out the gem bo
pointers in struct drm_framebuffer.
v2: Comments from Eric.
Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-7-daniel.vetter@ffwll.ch
Hans de Goede [Wed, 18 Apr 2018 12:36:42 +0000 (14:36 +0200)]
drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad Mixx 320
The Lenovo Ideapad Mixx 320 laptop uses a portrait LCD panel, add a
quirk for this.
While at it instead of duplicating the same drm_dmi_panel_orientation_data
for 3 laptops add a generic lcd800x1280_rightside_up orientation_data and
use that for all 3 (including the new Mixx 320 entry).
Tomasz Figa [Mon, 23 Apr 2018 10:50:03 +0000 (12:50 +0200)]
drm/rockchip: psr: Remove flush by CRTC
It is not used anymore after last changes and it was not even correct to
begin with as it assumed a 1:1 relation between a CRTC and encoder,
while in fact a CRTC can be attached to multiple encoders.
Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-28-enric.balletbo@collabora.com
Tomasz Figa [Mon, 23 Apr 2018 10:50:02 +0000 (12:50 +0200)]
drm/rockchip: Disallow PSR for the whole atomic commit
Currently PSR flush is triggered from CRTC's .atomic_begin() callback,
which is executed after modeset disables and enables and before plane
updates are committed. Since PSR flush and re-enable can be triggered
asynchronously by external sources (input event, delayed work), it can
race with hardware programming done in the aforementioned stages.
This patch blocks the PSR completely before hardware programming part
begins and unblock after it ends. This relies on reference counted PSR
disable introduced with previous patch.
Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-27-enric.balletbo@collabora.com
Tomasz Figa [Mon, 23 Apr 2018 10:50:01 +0000 (12:50 +0200)]
drm/rockchip: psr: Sanitize semantics of allow/inhibit API
Currently both rockchip_drm_psr_activate() and _deactivate() only set the
boolean "active" flag without actually making sure that hardware state
complies with it.
Since we are going to extend the usage of this API to properly lock PSR
for the duration of atomic commits, we change the semantics in following
way:
- a counter is used to track the number of inhibit requests,
- PSR is actually disabled in hardware on first inhibit request,
- PSR enable work is scheduled on last allow request.
The above allows using the API as a way to deterministically synchronize
PSR state changes with other DRM events, i.e. atomic commits and cursor
updates. As a nice side effect, the naming is sorted out and we have
"inhibit" for stopping the software logic and "enable" for hardware
state.
Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-26-enric.balletbo@collabora.com
Tomasz Figa [Mon, 23 Apr 2018 10:50:00 +0000 (12:50 +0200)]
drm/rockchip: psr: Avoid redundant calls to .set() callback
The first time after we call rockchip_drm_do_flush() after
rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The
difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a
delayed work pending - PSR is off in either state. However
psr_set_state() only catches the transition from PSR_FLUSH to
PSR_DISABLE (which never happens), while going from PSR_DISABLE to
PSR_FLUSH triggers a call to psr->set() to disable PSR while it's
already disabled. This triggers the eDP PHY power-on sequence without
being shut down first and this seems to occasionally leave the encoder
unable to later enable PSR. Let's just simplify the state machine and
simply consider PSR_DISABLE and PSR_FLUSH the same state.
Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-25-enric.balletbo@collabora.com
Tomasz Figa [Mon, 23 Apr 2018 10:49:59 +0000 (12:49 +0200)]
drm/rockchip: analogix_dp: Do not call Analogix code before bind
Driver callbacks, such as system suspend or resume can be called any
time, specifically they can be called before the component bind
callback. Let's use dp->adp pointer as a safeguard and skip calling
Analogix entry points if it is an ERR_PTR().
Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-24-enric.balletbo@collabora.com
Douglas Anderson [Mon, 23 Apr 2018 10:49:58 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Split the platform-specific poweron in two parts
Some of the platform-specific stuff in rockchip_dp_poweron() needs to
happen before the generic code. Some needs to happen after. Let's
split the callback in two.
Specifically we can't start doing PSR work until _after_ the whole
controller is up, so don't set the enable until the end.
Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org>
[seanpaul added exynos change] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-23-enric.balletbo@collabora.com
Mark Yao [Mon, 23 Apr 2018 10:49:57 +0000 (12:49 +0200)]
drm/rockchip: pre dither down when output bpc is 8bit
Some encoder have a crc verification check, crc check fail if
input and output data is not equal.
That means encoder input and output need use same color depth,
vop can output 10bit data to encoder, but some panel only support
8bit depth, that would make crc check die.
So pre dither down vop data to 8bit if panel's bpc is 8.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
[seanpaul resolved conflict in rockchip_drm_vop.c] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-22-enric.balletbo@collabora.com
Douglas Anderson [Mon, 23 Apr 2018 10:49:56 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
The comments in analogix_dp_init_aux() claim that we're disabling aux
channel retries, but then right below it for Rockchip it sets them to
3. If we actually need 3 retries for Rockchip then we could adjust
the comment, but it seems more likely that we want the same retry
behavior across all platforms.
Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: 征增 王 <wzz@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-21-enric.balletbo@collabora.com
Douglas Anderson [Mon, 23 Apr 2018 10:49:55 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Properly log AUX CH errors
The code in analogix_dp_transfer() that was supposed to print out:
AUX CH error happened
Was actually dead code. That's because the previous check (whether
the interrupt status indicated any errors) would have hit for all
errors anyway.
Let's combine the two error checks so we can actually see AUX CH
errors. We'll also downgrade the message to a warning since some of
these types of errors might be expected for some displays. If this
gets too noisy we can downgrade again to debug.
Cc: 征增 王 <wzz@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-20-enric.balletbo@collabora.com
Douglas Anderson [Mon, 23 Apr 2018 10:49:54 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
The current user of the analogix power_off is "analogix_dp-rockchip".
That driver does this:
- deactivate PSR
- turn off a clock
Both of these things (especially deactive PSR) should be done before
we turn the PHY power off and turn off analog power. Let's move the
callback up.
Note that without this patch (and with
https://patchwork.kernel.org/patch/9553349/ [seanpaul: this patch was
not applied, but it seems like the race can still occur]), I experienced
an error in reboot testing where one thread was at:
The flush handler thread was finding AUX channel errors and eventually
reported "Failed to apply PSR", where I had a kgdb breakpoint. Presumably
the device would have eventually given up and shut down anyway, but it
seems better to fix the order to be more correct.
Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-19-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:53 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Move fast link training detect to set_bridge
It's too early to detect fast link training, if other step after it
failed, we will set fast_link flag to 1, and retry set_bridge again. In
this case we will power down and power up panel power supply, and we
will do fast link training since we have set fast_link flag to 1. In
fact, we should do full link training now, not the fast link training.
So we should move the fast link detection at the end of set_bridge.
Cc: Tomasz Figa <tfiga@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-18-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:52 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1
Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
Exynos:
on Exynos edp phy,
BIT 7 MASTER_VID_FUNC_EN_N
BIT 6 reserved
BIT 5 SLAVE_VID_FUNC_EN_N
on Rockchip edp phy,
BIT 7 reserved
BIT 6 RK_VID_CAP_FUNC_EN_N
BIT 5 RK_VID_FIFO_FUNC_EN_N
So, we should do some private operations to Rockchip.
Cc: Tomasz Figa <tfiga@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-17-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:51 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Fix timeout of video streamclk config
The STRM_VALID bit in register ANALOGIX_DP_SYS_CTL_3 may be unstable,
so we may hit the error log "Timeout of video streamclk ok" since
checked this unstable bit.
In fact, we can go continue and the streamclk is ok if we wait enough time,
it does no effect on display.
Let's change this error to warn.
Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-16-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:50 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
list. We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
instead of ANALOGIX_DP_PLL_CTL.
Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-15-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:49 +0000 (12:49 +0200)]
drm/rockchip: Restore psr->state when enable/disable psr failed
If we failed disable psr, it would hang the display until next psr
cycle coming. So we should restore psr->state when it failed.
Cc: Tomasz Figa <tfiga@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-14-enric.balletbo@collabora.com
Lin Huang [Mon, 23 Apr 2018 10:49:48 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Reset aux channel if an error occurred
AUX errors are caused by many different reasons. We may not know what
happened in aux channel on failure, so let's reset aux channel if some
errors occurred.
Cc: 征增 王 <wzz@rock-chips.com> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-13-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:47 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
There are some different bits between Rockchip and Exynos in register
"AUX_PD". This patch fixes the incorrect operations about it.
Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-12-enric.balletbo@collabora.com
Lin Huang [Mon, 23 Apr 2018 10:49:46 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Check dpcd write/read status
We need to check the dpcd write/read return value to see whether the
write/read was successful
Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-11-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:45 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
Enhanced mode is required by the eDP 1.2 specification, and not doing it
early could result in a period of time where we have a link transmitting
idle packets without it. Since there is no reason to disable it, we just
enable it at the beginning of link training and then keep it on all the
time.
Cc: Tomasz Figa <tfiga@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-10-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:41 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Wait for HPD signal before configuring link
According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.
Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-6-enric.balletbo@collabora.com
zain wang [Mon, 23 Apr 2018 10:49:39 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Don't use fast link training when panel just powered up
Panel would reset its setting when it powers down. It would forget the last
succeeded link training setting. So we can't use the last successful link
training setting to do fast link training. Let's reset fast_train_enable in
analogix_dp_bridge_disable();
Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-4-enric.balletbo@collabora.com
Lin Huang [Mon, 23 Apr 2018 10:49:37 +0000 (12:49 +0200)]
drm/bridge: analogix_dp: Move enable video into config_video()
We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.
We needed to increase the delay in the timeout loop because there is
random "Timeout of video streamclk ok" message happen when debug edp
panel, this time do not define in the spec.
Cc: 征增 王 <wzz@rock-chips.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-2-enric.balletbo@collabora.com
Stefan Schake [Fri, 20 Apr 2018 12:25:44 +0000 (05:25 -0700)]
drm/vc4: Add CTM support
The hardware has a single block for applying a CTM prior to gamma lut.
It can be fed with pixels from one of our CRTC at a time and uses a
matrix with S0.9 scalars. Use private atomic state to reject attempts
from userland to apply CTM for more than one CRTC at a time and reject
matrices with scalars that we can't approximate without integer bits.
Signed-off-by: Stefan Schake <stschake@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/218067/
Stefan Schake [Sat, 21 Apr 2018 00:09:54 +0000 (17:09 -0700)]
drm/vc4: Add support for plane alpha
The HVS supports mixing fixed alpha with per-pixel alpha or
setting a fixed plane alpha in case there is no per-pixel information.
This allows us to support the generic DRM plane alpha property.
Boris Brezillon [Sat, 21 Apr 2018 07:08:45 +0000 (09:08 +0200)]
drm/bridge: Add Cadence DSI driver
Add a driver for Cadence DPI -> DSI bridge.
This driver only support a subset of Cadence DSI bridge capabilities.
This driver has been tested/debugged in a simulated environment which
explains why some of the features are missing. Here is a
non-exhaustive list of missing features:
* burst mode
* DPHY init/configuration steps
* support for additional input interfaces (SDI input)
DSI commands and non-burst video mode have been tested.
Philippe CORNU [Tue, 10 Apr 2018 13:53:12 +0000 (15:53 +0200)]
drm/stm: ltdc: fix warning in ltdc_crtc_update_clut()
Fix the warning
"warn: variable dereferenced before check 'crtc' (see line 390)"
by removing unnecessary checks as ltdc_crtc_update_clut() is
only called from ltdc_crtc_atomic_flush() where crtc and
crtc->state are not NULL.
Many thanks to Dan Carpenter for the bug report
https://lists.freedesktop.org/archives/dri-devel/2018-February/166918.html
drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1
Without this the following pipeline didn't work:
domU:
1. xen-front allocates a non-contig buffer
2. creates grants out of it
dom0:
3. converts the grants into a dma-buf. Since they're non-contig, the
scatter-list is huge.
4. imports it into rcar-du, which requires dma-contig memory for
scanout.
-> On this given platform there's an IOMMU, so in theory this should
work. But in practice this failed, because of the huge number of sg
entries, even though the IOMMU driver mapped it all into a dma-contig
range.
With a guest-contig buffer allocated in step 1, this problem doesn't
exist. But there's technically no reason to require guest-contig
memory for xen buffer sharing using grants.
Given all that, the xen-front cma support is not needed and should be
removed.
Gustavo Padovan [Fri, 30 Mar 2018 08:54:45 +0000 (10:54 +0200)]
drm/vc4: update cursors asynchronously through atomic
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v7: Place the drm_atomic_set_fb_for_plane() call after the new
FB has been applied to the HW to avoid possible use-after-free
issues
v6: add missing drm_atomic_set_fb_for_plane() in
vc4_plane_atomic_async_update() (Boris Brezillon)
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commit (Eric Anholt)
v3: move size checks back to drivers (Ville Syrjälä)
v2: move fb setting to core and use new state (Eric Anholt)
Stefan Schake [Wed, 11 Apr 2018 20:49:13 +0000 (22:49 +0200)]
drm/vc4: Expose gamma as atomic property
We are an atomic driver so the gamma LUT should also be exposed as a
CRTC property through the DRM atomic color management. This will also
take care of the legacy path for us.
Eric Anholt [Wed, 11 Apr 2018 20:49:12 +0000 (22:49 +0200)]
drm/vc4: Add some missing HVS register definitions.
At least the RGBA expand field we should have been setting, because we
aren't expanding correctly for 565 -> 8888. Other registers are ones
that may be interesting for various projects that have been discussed.
Maxime Ripard [Wed, 11 Apr 2018 07:39:29 +0000 (09:39 +0200)]
drm/docs: Remove the rcar alpha from the csv file
Now that we moved the rcar-du DRM driver has been switched to the generic
alpha property, remove the former property documentation from the
deprecated CSV file.
Maxime Ripard [Wed, 11 Apr 2018 07:39:25 +0000 (09:39 +0200)]
drm/blend: Add a generic alpha property
Some drivers duplicate the logic to create a property to store a per-plane
alpha.
This is especially useful if we ever want to support extra protocols for
Wayland like:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
Let's create a helper in order to move that to the core.
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com
Maxime Ripard [Wed, 4 Apr 2018 09:57:11 +0000 (11:57 +0200)]
drm/sun4i: Add Allwinner A31 MIPI-DSI controller support
Most of the Allwinner SoCs since the A31 share the same MIPI-DSI
controller.
While that controller is mostly undocumented, the code is out there and has
been cleaned up in order to be integrated into DRM. However, there's still
some dark areas that are a bit unclear about how the block exactly
operates.
Maxime Ripard [Wed, 4 Apr 2018 09:57:09 +0000 (11:57 +0200)]
drm/sun4i: tcon: Add TRI finish interrupt for vblank
The "CPU" (or Intel 8080) interface uses a different interrupt called
TRI_FINISH (most likely TRI being for trigger) to notify the end of frames,
and hence the VBLANK period.
And that interrupt to the possible VBLANK interrupts source.
Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg
structure") reworked some code inside of this driver and made it select
CONFIG_OF. This results in the entire OF layer being enabled when
building an allmodconfig on ia64. OF on ia64 is completely unsupported
so this isn't a great state of affairs.
The 0day robot noticed a link-time failure on ia64 caused by
using of_node_to_nid() in an otherwise unrelated driver. The
generic fallback for of_node_to_nid() only exists when:
Since CONFIG_NUMA is usually selected for IA64 we get the link failure.
Fix this by making the driver depend on OF rather than selecting it,
odds are that was the original intent.
Link: https://lists.01.org/pipermail/kbuild-all/2018-March/045172.html Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-ia64@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403053401.30045-1-oohall@gmail.com
drm/xen-front: Add support for Xen PV display frontend
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].
Driver limitations:
1. Only primary plane without additional properties is supported.
2. Only one video mode supported which resolution is configured
via XenStore.
3. All CRTCs operate at fixed frequency of 60Hz.
1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.
2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
- read connector(s) configuration
- read buffer allocation mode (backend/frontend)
3. Handle Xen event channels:
- create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
- implement event channels interrupt handlers
- create and destroy event channels with respect to Xen bus state
4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
- handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
page directory
- allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
- grant references to the required set of pages for the
shared buffer itself
- implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)
- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
(primary) plane:
- initialize connectors according to XenStore configuration
- handle frame done events from the backend
- create and destroy frame buffers and propagate those
to the backend
- propagate set/reset mode configuration to the backend on display
enable/disable callbacks
- send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback
- implement virtual connector handling:
- support only pixel formats suitable for single plane modes
- make sure the connector is always connected
- support a single video mode as per para-virtualized driver
configuration
6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment,
namely requirements dictated by the accompanying DRM/(v)GPU drivers
running in both host and guest environments, number of operating
modes of para-virtualized display driver are supported:
- display buffers can be allocated by either
frontend driver or backend
- display buffers can be allocated to be contiguous
in memory or not
Note! Frontend driver itself has no dependency on contiguous memory for
its operation.
6.1. Buffers allocated by the frontend driver.
The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.
6.1.1. Front driver configured to use GEM CMA helpers
This use-case is useful when used with accompanying DRM/vGPU driver
in guest domain which was designed to only work with contiguous
buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
only import contiguous PRIME buffers, thus requiring frontend driver
to provide such. In order to implement this mode of operation
para-virtualized frontend driver can be configured to use
GEM CMA helpers.
6.1.2. Front driver doesn't use GEM CMA
If accompanying drivers can cope with non-contiguous memory then, to
lower pressure on CMA subsystem of the kernel, driver can allocate
buffers from system memory.
Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.
6.2. Buffers allocated by the backend
This mode of operation is run-time configured via guest domain
configuration through XenStore entries.
For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting physically contiguous memory, this allows implementing
zero-copying use-cases.
Note, while using this scenario the following should be considered:
a) If guest domain dies then pages/grants received from the backend
cannot be claimed back
b) Misbehaving guest may send too many requests to the
backend exhausting its grant references and memory
(consider this from security POV).
Note! Configuration options 1.1 (contiguous display buffers) and 2
(backend allocated buffers) are not supported at the same time.
7. Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to the communication channel
- time-out used for backend communication is set to 3000 ms
- manage display buffers shared with the backend
Ville Syrjälä [Thu, 22 Mar 2018 17:41:35 +0000 (19:41 +0200)]
drm/i915: Make force_load_detect effective even w/ DMI quirks/hotplug
When doing forced load detection testing we should totally ignore any
hotplug status for the connector. This is mostly relevant for machines
where we already ignore the hotplug status based on the DMI quirks. On
other machines we would currently skip the force load detection tests
on account of the connector already being connected.
v2: Drop the other force_load_detect check since it's useless now (Maarten)
Ville Syrjälä [Thu, 22 Mar 2018 15:22:57 +0000 (17:22 +0200)]
drm: Make the fb refcount handover less magic
Instead of assigning the plane->fb pointer and clearing the fb pointer
to hand over the reference, let's just do it by grabbing another
referece for plane->fb and let fb keep its original one.
projects / mirror_ubuntu-focal-kernel.git / log