- 31 Aug, 2020 12 commits
-
-
Lyude Paul authored
First some backstory here: Currently, we keep track of whether or not we've enabled MST or not by trying to piggy-back off the MST helpers. This means that in order to check whether MST is enabled or not, we actually need to grab drm_dp_mst_topology_mgr.lock. Back when I originally wrote this, I did this piggy-backing with the intention that I'd eventually be teaching our MST helpers how to recover when an MST device has stopped responding, which in turn would require the MST helpers having a way of disabling MST independently of the driver. Note that this was before I reworked locking in the MST helpers, so at the time we were sticking random things under &mgr->lock - which grabbing this lock was meant to protect against. This never came to fruition because doing such a reset safely turned out to be a lot more painful and impossible then it sounds, and also just risks us working around issues with our MST handlers that should be properly fixed instead. Even if it did though, simply calling drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the exception of when we're tearing down our MST managers, that's always OK) wouldn't have been a bad idea, since drivers like nouveau and i915 need to do their own book keeping immediately after disabling MST. So-implementing that would likely require adding a hook for helper-triggered MST disables anyway. So, fast forward to now - we want to start adding support for all of the miscellaneous bits of the DP protocol (for both SST and MST) we're missing before moving on to supporting more complicated features like supporting different BPP values on MST, DSC, etc. Since many of these features only exist on SST and make use of DP HPD IRQs, we want to be able to atomically check whether we're servicing an MST IRQ or SST IRQ in nouveau_connector_hotplug(). Currently we literally don't do this at all, and just handle any kind of possible DP IRQ we could get including ESIs - even if MST isn't actually enabled. This would be very complicated and difficult to fix if we need to hold &mgr->lock while handling SST IRQs to ensure that the MST topology state doesn't change under us. What we really want here is to do our own tracking of whether MST is enabled or not, similar to drivers like i915, and define our own locking order to decomplicate things and avoid hitting locking issues in the future. So, let's do this by refactoring our MST probing/enabling code to use our own MST bookkeeping, along with adding a lock for protecting DP state that needs to be checked outside of our connector probing functions. While we're at it, we also remove a bunch of unneeded steps we perform when probing/enabling MST: * Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst(). I don't think these ever actually did anything, since the nvif methods for enabling MST don't actually do anything DPCD related and merely indicate to nvkm that we've turned on MST. * Checking the MSTM_CTRL bit is intact when checking the state of an enabled MST topology in nv50_mstm_detect(). I just added this to be safe originally, but now that we try reading the DPCD when probing DP connectors it shouldn't be needed as that will abort our hotplug probing if the device was removed well before we start checking for MST.. * All of the duplicate DPCD version checks. This leaves us with much nicer looking code, a much more sensible locking scheme, and an easy way of checking whether MST is enabled or not for handling DP HPD IRQs. v2: * Get rid of accidental newlines v4: * Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel bot! Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-9-lyude@redhat.com
-
Lyude Paul authored
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging Signed-off-by:
-
Lyude Paul authored
While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and nv50_outp_get_new_connector(). v2: * Don't line-wrap for_each_(old|new)_connector_in_state in nv50_outp_get_(old|new)_connector() - sravn v3: * Fix potential uninitialized usage of nv_connector (needs to be initialized to NULL at the start). Thanks kernel test robot! v4: * Actually fix uninitialized nv_connector usage in nv50_audio_component_get_eld(). The previous fix wouldn't have worked since we would have started out with nv_connector == NULL, but wouldn't clear it after a single drm_for_each_encoder() iteration. Thanks again Kernel bot! Signed-off-by:
-
Lyude Paul authored
Since commit fa3cdf8d ("drm/nouveau: Reset MST branching unit before enabling") we've been clearing DP_MST_CTRL before we start enabling MST. Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary and redundant, so let's remove it. Signed-off-by:
-
Lyude Paul authored
No functional changes. Signed-off-by:
-
Lyude Paul authored
Since this actually logs accesses, we should probably always be using this imho… Signed-off-by:
-
Lyude Paul authored
Noticed this while going through our DP code - we use an open-coded version of drm_dp_read_desc() instead of just using the helper, so change that. This will also let us use quirks in the future if we end up needing them. Signed-off-by:
-
Lyude Paul authored
Signed-off-by:
-
Randy Dunlap authored
Fix kconfig dependency warning by using a different Kconfig symbol. WARNING: unmet direct dependencies detected for VIRTIO_DMA_SHARED_BUFFER Depends on [n]: VIRTIO_MENU [=n] && DMA_SHARED_BUFFER [=y] Selected by [y]: - DRM_VIRTIO_GPU [=y] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO [=y] && MMU [=y] Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: http://patchwork.freedesktop.org/patch/msgid/7481fb88-6b04-3726-57e0-0f513245c657@infradead.org Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Dave Airlie authored
This can be gotten back from bdev. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826014428.828392-3-airlied@gmail.com
-
Dave Airlie authored
Reviewed-by:
-
Tian Tao authored
hibmc can only be used in ARM64 architectures, and mmu defaults to y in arch/arm64/Kconfig, so there is no need to add a dependency on mmu in hibmc's kconfig. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1598428528-49046-1-git-send-email-tiantao6@hisilicon.com
-
- 30 Aug, 2020 2 commits
-
-
Sidong Yang authored
This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't enabled. When running igt test kms_cursor_crc just after vkms module, the warning raised like below. Initial value of vblank time is zero and hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module isn't real hardware but just virtual hardware module. so vkms can't generate a resonable timestamp when hrtimer is off. it's best to grab the current time. [106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change [106444.471475] WARNING: CPU: 0 PID: 10109 at vkms_get_vblank_timestamp+0x42/0x50 [vkms] [106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: G W OE 5.9.0-rc1+ #6 [106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms] [106444.471528] Call Trace: [106444.471551] drm_get_last_vbltimestamp+0xb9/0xd0 [drm] [106444.471566] drm_reset_vblank_timestamp+0x63/0xe0 [drm] [106444.471579] drm_crtc_vblank_on+0x85/0x150 [drm] [106444.471582] vkms_crtc_atomic_enable+0xe/0x10 [vkms] [106444.471592] drm_atomic_helper_commit_modeset_enables+0x1db/0x230 [drm_kms_helper] [106444.471594] vkms_atomic_commit_tail+0x38/0xc0 [vkms] [106444.471601] commit_tail+0x97/0x130 [drm_kms_helper] [106444.471608] drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper] [106444.471622] drm_atomic_commit+0x4a/0x50 [drm] [106444.471629] drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper] [106444.471642] drm_mode_setcrtc+0x1d9/0x7b0 [drm] [106444.471654] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm] [106444.471666] drm_ioctl_kernel+0xb6/0x100 [drm] [106444.471677] drm_ioctl+0x3ad/0x470 [drm] [106444.471688] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm] [106444.471692] ? tomoyo_file_ioctl+0x19/0x20 [106444.471694] __x64_sys_ioctl+0x96/0xd0 [106444.471697] do_syscall_64+0x37/0x80 [106444.471699] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
Sidong Yang <realwakka@gmail.com> Reviewed-by:
Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200828124553.2178-1-realwakka@gmail.com
-
Melissa Wen authored
The VKMS blend function was ignoring the alpha channel and just overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a warning when running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT, cairo_format_argb32 uses premultiplied alpha (according to documentation). Also current DRM assumption is that alpha is premultiplied. Therefore, this patch considers premultiplied alpha blending eq to compose vaddr_src with vaddr_dst. This change removes the following cursor-alpha-transparent warning: "Suspicious CRC: All values are 0." V2: - static for local functions - const for the read-only variable argb_src - replaces variable names - drops unnecessary comment Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by:
-
- 29 Aug, 2020 5 commits
-
-
Laurent Pinchart authored
The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit f098f168 ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") has fixed the bus formats, but forgot to address the bpc value. Set it to 6. Fixes: f098f168 ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200824003254.21904-1-laurent.pinchart@ideasonboard.com
-
Vinod Koul authored
DSI end-points are supposed to be at node 0 and node 1 as per binding. So fix this and use node 0 and node 1 for dsi. Reported-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: 23278bf5 ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Robert Chiras authored
The flag MIPI_DSI_CLOCK_NON_CONTINUOUS was wrong used in the DSI driver, so it was added to this panel, but not necessary. So, remove this flag since it is not needed. Signed-off-by:
Robert Chiras <robert.chiras@nxp.com> Signed-off-by:
-
Jagan Teki authored
Add Ampire, AM-1280800N3TZQW-T00H 10.1" TFT LCD panel timings. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
-
Jagan Teki authored
Add dt-bindings for 10.1" TFT LCD module from Ampire Co. Ltd. as part of panel-simple. Signed-off-by:
-
- 27 Aug, 2020 2 commits
-
-
Maxime Ripard authored
The LVDS controller can invert the polarity / lanes of the LVDS output. The default polarity causes some issues on some panels. However, U-Boot has always used the opposite polarity without any reported issue, and the only currently supported LVDS panel in-tree (the TBS A711) seems to be able to work with both settings. Let's just use the same polarity than U-Boot to be more consistent and hopefully support all the panels. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Cc: Ondrej Jirman <megous@megous.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200704133803.37330-1-maxime@cerno.tech
-
Colin Ian King authored
There is a spelling mistake in a drm_warn message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 26 Aug, 2020 8 commits
-
-
Enric Balletbo i Serra authored
Print an error message inside ps8640_bridge_vdo_control() function when it fails so we can simplify a bit the callers, they will only need to check the error code. Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by:
Bilal Wasim <bwasim.lkml@gmail.com> Tested-by:
-
Enric Balletbo i Serra authored
Bridge drivers that implement the new model only shall return an error from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not set. So make sure we return an error because only the new drm_bridge model is supported. Reviewed-by:
-
Enric Balletbo i Serra authored
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the .get_edid callback and set the flag to indicate the core to use it. Reviewed-by:
-
Enric Balletbo i Serra authored
In an eDP application, HPD is not required and on most bridge chips useless. If HPD is not used, we need to set initial status as connected, otherwise the connector created by the drm_bridge_connector API remains in an unknown state. Reviewed-by:
-
Tian Tao authored
Use drm_err instead of DRM_ERROR in hibmc_drm_drv Signed-off-by:
-
Tian Tao authored
Use drm_err instead of DRM_ERROR in hibmc_drm_de Signed-off-by:
-
Tian Tao authored
Use drm_err instead of DRM_ERROR in hibmc_drm_vdac Signed-off-by:
-
Tian Tao authored
Use drm_err instead of DRM_ERROR in hibmc_ttm. Signed-off-by:
-
- 24 Aug, 2020 2 commits
-
-
Dave Airlie authored
This is always calculated the same, and only used in a couple of places. Signed-off-by:
-
Dave Airlie authored
The drivers all do the same thing here. Reviewed-by: Christian König <christian.koenig@amd.com> for both. Signed-off-by:
-
- 23 Aug, 2020 2 commits
-
-
Nadezda Lutovinova authored
If ge_b850v3_lvds_init() does not allocate memory for ge_b850v3_lvds_ptr, then a null pointer dereference is accessed. The patch adds checking of the return value of ge_b850v3_lvds_init(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Nadezda Lutovinova <lutovinova@ispras.ru> Signed-off-by:
-
Vinay Simha BN authored
passing zero to 'PTR_ERR' Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Vinay Simha BN <simhavcs@gmail.com> Signed-off-by:
-
- 21 Aug, 2020 5 commits
-
-
Douglas Anderson authored
Values come from the vendor and have been tested on hardware. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Douglas Anderson authored
The KD116N21-30NV-A010 is a pretty standard eDP panel. Add it to the list of compatible strings. Signed-off-by:
-
Tomi Valkeinen authored
This patch implements WA for AM65xx erratum i2000, which causes YUV formats to show wrong colors. An earlier patch removed a partial WA: a8d9d7da ("drm/tidss: remove AM65x PG1 YUV erratum code") The patch explains the reasoning for removal. The change in plans has been that it has become clear that there are and will be users for PG1 SoCs and as such it's good to implement the WA for PG1s. This patch adds the WA back so that it is only used on SR1.0 (which is the new name for PG1). The previous WA code didn't check the SoC revision, which this patch does. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200812112625.59897-1-tomi.valkeinen@ti.comReviewed-by:
Jyri Sarha <jsarha@ti.com>
-
Colin Ian King authored
There is a spelling mistake in a pr_err message. Fix it. Signed-off-by:
-
Linus Walleij authored
The OMAP DRM driver includes <linux/gpio.h> into the two hdmi4.c and hdmi5.c files but does not use any symbols from these files. Drop the includes. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Jyri Sarha <jsarha@ti.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 20 Aug, 2020 2 commits
-
-
Paul Cercueil authored
There is already a 'struct device' pointer in the drm_panel structure, that we can access easily from our priv structure, so there's no need for a separate 'dev' field there. Reviewed-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200820121256.32037-3-paul@crapouillou.net
-
Paul Cercueil authored
The drm_panel_of_backlight() function must be called after drm_panel_init(), according to the function's documentation; otherwise the backlight won't be properly initialized. Reviewed-by:
-
