- 12 Jun, 2019 2 commits
-
-
Yannick Fertré authored
These new physical operations are helpful to power_on/off the dsi wrapper. If the dsi wrapper is powered in video mode, the display controller (ltdc) register access will hang when DSI fifos are full. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Acked-by:
Philippe Cornu <philippe.cornu@st.com> Tested-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Yannick Fertré authored
Add power on & off optional physical operation functions, helpful to program specific registers of the DSI physical part. Signed-off-by:
-
- 11 Jun, 2019 8 commits
-
-
Douglas Anderson authored
On Rockchip rk3288-based Chromebooks when you do a suspend/resume cycle: 1. You lose the ability to detect an HDMI device being plugged in. 2. If you're using the i2c bus built in to dw_hdmi then it stops working. Let's call the core dw-hdmi's suspend/resume functions to restore things. NOTE: in downstream Chrome OS (based on kernel 3.14) we used the "late/early" versions of suspend/resume because we found that the VOP was sometimes resuming before dw_hdmi and then calling into us before we were fully resumed. For now I have gone back to the normal suspend/resume because I can't reproduce the problems. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190604204207.168085-2-dianders@chromium.org
-
Douglas Anderson authored
On Rockchip rk3288-based Chromebooks when you do a suspend/resume cycle: 1. You lose the ability to detect an HDMI device being plugged in. 2. If you're using the i2c bus built in to dw_hdmi then it stops working. Let's add a hook to the core dw-hdmi driver so that we can call it in dw_hdmi-rockchip in the next commit. NOTE: the exact set of steps I've done here in resume come from looking at the normal dw_hdmi init sequence in upstream Linux plus the sequence that we did in downstream Chrome OS 3.14. Testing show that it seems to work, but if an extra step is needed or something here is not needed we could improve it. As part of this change we'll refactor the hardware init bits of dw-hdmi to happen all in one function and all at the same time. Since we need to init the interrupt mutes before we request the IRQ, this means moving the hardware init earlier in the function, but there should be no problems with that. Also as part of this we now unconditionally init the "i2c" parts of dw-hdmi, but again that ought to be fine. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
Apparently little known fact that there's no need to hand-roll your own anymore. Cc'ing a bunch of driver people who might want to know this too. v2: s/none/known/ (Chris Wilson) Cc: Rob Clark <robdclark@gmail.com> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: David Lechner <david@lechnology.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190611112859.16375-1-daniel.vetter@ffwll.ch
-
Noralf Trønnes authored
Ease entry for anyone wanting to pick up the bootsplash work by providing a couple of pointers. v2: Add Sam as contact (Sam) Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-6-noralf@tronnes.org
-
Noralf Trønnes authored
No functional changes, just moving code as-is and fixing includes. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by:
-
Noralf Trønnes authored
This prepares the modeset code so it can be moved out as-is in the next patch. v3: Remove stray newline Signed-off-by:
-
Noralf Trønnes authored
All drivers add all their connectors so there's no need to keep around an array of available connectors. Instead we just put the useable (not writeback) connectors in a temporary array using drm_client_for_each_connector_iter() everytime we probe the outputs. Other places where it's necessary to look at the connectors, we just iterate over them using the same iterator function. Rename functions which signature is changed since they will be moved to drm_client in a later patch. v6: Improve commit message (Sam Ravnborg) Signed-off-by:
-
David Riley authored
After data is copied to the cache entry, atomic_set is used indicate that the data is the entry is valid without appropriate memory barriers. Similarly the read side was missing the corresponding memory barriers. Signed-off-by:
David Riley <davidriley@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190610211810.253227-5-davidriley@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
- 10 Jun, 2019 18 commits
-
-
Sam Ravnborg authored
With this commit drm/amd/ has no longer any uses of the deprecated drmP.h header file. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190609220757.10862-11-sam@ravnborg.org
-
Sam Ravnborg authored
Drop use of drmP.h in all files named amdgpu* in drm/amd/amdgpu/ Fix fallout. Signed-off-by:
-
Sam Ravnborg authored
Drop all uses of drmP.h in drm/amd/display/. Fix fallout. Signed-off-by:
-
Sam Ravnborg authored
Delete the only include of drmP.h in powerplay/. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header file from all amd header files. This makes it a more smooth process to get rid of drmP.h in the .c files. Added include files and forwards as appropriate. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h header from atom.h Fix fallout in various files. Signed-off-by:
-
Sam Ravnborg authored
Delete the unused drmP.h from amdgpu.h. Fix fallout in various files. Signed-off-by:
-
Sam Ravnborg authored
Drop use of the deprecated drmP.h from display/dc/os_types.h Fix all fallout after this change. Most of the fixes was adding a missing include of vmalloc.h. Signed-off-by:
-
Sam Ravnborg authored
Fix so no files in drm/amd/ depends on the deprecated drm_os_linux.h header file. It was done manually: - remove drm_os_linux.h from drmP.h - fix all build errros Signed-off-by:
-
Sam Ravnborg authored
drm_print.h requires <drm/drm.h> to fix build when macros are used. Pull in the header file in drm_print.h so users do not have to do it. Signed-off-by:
-
Sam Ravnborg authored
Drop use of drmP.h in remaining .c files. To ease review a little the drmP.h removal was divided in two commits. Signed-off-by:
-
Sam Ravnborg authored
Drop use of drmP.h in all .c files named radeon*c. To ease review a little drmP.h removal was divided in two commits. Signed-off-by:
-
Sam Ravnborg authored
While removing drmP.h from all .c files the list of header files are also sorted alphabetically. To allow this adjust the header files to pull in the dependencies they needed to allow this. Signed-off-by:
-
Sam Ravnborg authored
To ease conversion of .c files drop include of drmP.h from all header files. And fix-up build errors caused by this. Signed-off-by:
-
Sam Ravnborg authored
The drm_os_linux.h header file is deprecated. Drop all uses of symbols from this file. All macros are just opencoded. A few adjustments to include files was required as the obsolete drm_os_linux.h included these headers. Signed-off-by:
-
Sam Ravnborg authored
While removing drmP.h from drm/radeon a few files ended up including drm_debugfs.h as the first file. This failed build due to missing dependencies in drm_debugfs.h. Add the missing include files. Signed-off-by:
-
Sam Ravnborg authored
While removing drmP.h from drm/radeon a few files ended up including drm_crtc.h as the first file. This failed build due to a missing dependency in drm_crtc.h. Add the missing include file. Signed-off-by:
-
Douglas Anderson authored
In commit 50f9495e ("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus") I stupidly used IS_ERR() to check for whether we have an "unwedge" pinctrl state even though on most flows through the driver the unwedge state will just be NULL. Fix it so that we consistently use NULL for no unwedge state. Fixes: 50f9495e ("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus") Cc: Douglas Anderson <dianders@chromium.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Sam Ravnborg <sam@ravnborg.org> Reported-by:
Erico Nunes <nunes.erico@gmail.com> Signed-off-by:
-
- 09 Jun, 2019 1 commit
-
-
Chris Wilson authored
This is an illegal scenario, to free the fence whilst there are pending callbacks. Currently, we emit a WARN and then cast aside the callbacks leaving them dangling. Alternatively, we could set an error on the fence and then signal fence so that any dependency chains from the fence can be tidied up, and if they care they can check for the error. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190609110002.31915-1-chris@chris-wilson.co.uk
-
- 08 Jun, 2019 3 commits
-
-
Noralf Trønnes authored
Move the modeset commit code to drm_client_modeset. No changes except exporting API. v7: Export drm_client_panel_rotation() (Gerd Hoffmann) v2: Move to drm_client_modeset.c instead of drm_client.c Signed-off-by:
-
Noralf Trønnes authored
This makes the necessary changes so the commit code can be moved out to drm_client as-is in the next patch. It's split up to ease review. Signed-off-by:
-
Noralf Trønnes authored
Prepare for moving drm_fb_helper modesetting code to drm_client. drm_client will be linked to drm.ko, so move __drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config() out of drm_kms_helper.ko. While at it, fix two checkpatch complaints: - WARNING: Block comments use a trailing */ on a separate line - CHECK: Alignment should match open parenthesis v7: Declare drm_mode_set and drm_plane_state Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 07 Jun, 2019 7 commits
-
-
Daniel Vetter authored
I. was. blind. Caught with vkms, which has some really slow crc computation function. Fixes: 1882018a ("drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry") Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Colin Ian King authored
The less than check for the variable num_lanes is always going to be false because the variable is a u32. Fix this by making num_lanes an int and also make loop index i an int too. Addresses-Coverity: ("Unsigned compared against 0") Fixes: ff578163 ("drm/bridge: sii902x: Implement HDMI audio support") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
-
Dan Carpenter authored
This should check that "i" is within bounds before checking reading from the array. Fixes: ff578163 ("drm/bridge: sii902x: Implement HDMI audio support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Yannick Fertré authored
This patch enables runtime power management (runtime PM) support for the display controller. pm_runtime_enable() and pm_runtime_disable() are added during ltdc load and unload respectively. pm_runtime_get_sync() and pm_runtime_put_sync() are added for ltdc register access. Signed-off-by:
-
Yannick Fertré authored
Print display controller hardware version in debug mode only. Signed-off-by:
-
Neil Armstrong authored
Add missing XBGR8888 & ABGR8888 formats variants from the primary plane. Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190429075238.7884-1-narmstrong@baylibre.com
-
Neil Armstrong authored
Add immutable zpos property to primary and overlay planes to specify the current fixed zpos position. Fixes: f9a23481 ("drm/meson: Support Overlay plane for video rendering") Signed-off-by:
-
- 06 Jun, 2019 1 commit
-
-
Daniel Vetter authored
In commit def35e7c Author: Shayenne Moura <shayenneluzmoura@gmail.com> Date: Wed Jan 30 14:06:36 2019 -0200 drm/vkms: Bugfix extra vblank frame we fixed the vblank counter to give accurate results outside of drm_crtc_handle_vblank, which fixed bugs around vblank timestamps being off-by-one and causing the vblank counter to jump when it shouldn't. The trouble is that this completely broke crc generation. Shayenne and Rodrigo tracked this down to the vblank timestamp going backwards in time somehow. Which then resulted in an underflow in drm_vblank.c code, which resulted in all kinds of things breaking really badly. The reason for this is that once we've called drm_crtc_handle_vblank and the hrtimer isn't forwarded yet, we're returning a vblank timestamp in the past. This race is really hard to hit since it's small, except when you enable crc generation: In that case there's a call to drm_crtc_accurate_vblank right in-betwen, so we're guaranteed to hit the bug. The fix is to roll the hrtimer forward _before_ we do the vblank processing (which has a side-effect of incrementing the vblank counter), and we always subtract one frame from the hrtimer - since now it's always one frame in the future. To make sure we don't hit this again also add a WARN_ON checking for whether our timestamp is somehow moving into the past, which is never should. This also aligns more with how real hw works: 1. first all registers are updated with the new timestamp/vblank counter values. 2. then an interrupt is generated 3. kernel interrupt handler eventually fires. So doing this aligns vkms closer with what drm_vblank.c expects. Document this also in a comment. Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
-
