- 03 Feb, 2019 2 commits
-
-
Shayenne Moura authored
kms_flip tests are breaking on vkms when simulate vblank because vblank event sequence count returns one extra frame after arm vblank event to make a page flip. When vblank interrupt happens, userspace processes the vblank event and issues the next page flip command. Kernel calls queue_work to call commit_planes and arm the new page flip. The next vblank picks up the newly armed vblank event and vblank interrupt happens again. The arm and vblank event are asynchronous, then, on the next vblank, we receive x+2 from `get_vblank_timestamp`, instead x+1, although timestamp and vblank seqno matches. Function `get_vblank_timestamp` is reached by 2 ways: - from `drm_mode_page_flip_ioctl`: driver is doing one atomic operation to synchronize planes in the same output. There is no vblank simulation, the `drm_crtc_arm_vblank_event` function adds 1 on vblank count, and the variable in_vblank_irq is false - from `vkms_vblank_simulate`: since the driver is doing a vblank simulation, the variable in_vblank_irq is true. Fix this problem subtracting one vblank period from vblank_time when `get_vblank_timestamp` is called from trace `drm_mode_page_flip_ioctl`, i.e., is not a real vblank interrupt, and getting the timestamp and vblank seqno when it is a real vblank interrupt. The reason for all this is that get_vblank_timestamp always supplies the timestamp for the next vblank event. The hrtimer is the vblank simulator, and it needs the correct previous value to present the next vblank. Since this is how hw timestamp registers work and what the vblank core expects. Signed-off-by:Shayenne Moura <shayenneluzmoura@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by:
-
Heiko Stuebner authored
This is a panel handled through the generic lvds-panel binding, so only needs its additional compatible specified. Signed-off-by:
Heiko Stuebner <heiko.stuebner@bq.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181113124205.29319-1-heiko@sntech.de
-
- 01 Feb, 2019 4 commits
-
-
Neil Armstrong authored
In order to support the HDMI2.0 YUV420 display modes, this patch adds support for the YUV420 TMDS Clock divided by 2 and the controller passthrough mode. YUV420 Synopsys PHY support will need some specific configuration table to support theses modes. This patch is based on work from Zheng Yang <zhengyang@rock-chips.com> in the Rockchip Linux 4.4 BSP at [1] [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 Cc: Zheng Yang <zhengyang@rock-chips.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Neil Armstrong authored
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control operation in the DW-HDMI Controller, we can enable support for the HDMI2.0 3840x2160@60/50 RGB444 display modes. Signed-off-by:
-
Neil Armstrong authored
Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes. Signed-off-by:
-
Neil Armstrong authored
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS Scrambling when supported or mandatory. This patch also adds an helper to setup the control bit to support the high TMDS Bit Period/TMDS Clock-Period Ratio as required with TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. These changes were based on work done by Huicong Xu <xhc@rock-chips.com> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes on the Rockchip 4.4 BSP kernel at [1] [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 Cc: Nickey Yang <nickey.yang@rock-chips.com> Cc: Huicong Xu <xhc@rock-chips.com> Signed-off-by:
-
- 31 Jan, 2019 1 commit
-
-
Sean Paul authored
Drivers shouldn't be using these values, add a TODO so someone removes them. Changes in v2: - Add drm_display_mode.vrefresh removal (Ville) - Add Sam's R-b and bonus points Changes in v3: - Add hsync removal todo item (Daniel) - Change vrefresh wording to make removal less optional Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Bonus-points-awarded-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190129192637.73296-1-sean@poorly.run
-
- 30 Jan, 2019 9 commits
-
-
Ville Syrjälä authored
Decode the NAK reply fields to make it easier to parse the logs. v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day) Use drm_dp_mst_req_type_str() more (DK) Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190122200301.18633-2-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Make the code a bit easier to read by providing symbolic names for the reply_type (ACK vs. NAK). Also clean up some brace stuff while at it. v2: s/DP_REPLY/DP_SIDEBAND_REPLY/ (DK) Fix some checkpatch issues Signed-off-by: -
Daniel Vetter authored
It only talks about crtc, brings up intel as an example and I think is more misleading than useful really. Plus we have lots of discussion about how your standard kms driver should be initialized/cleaned up, so maybe better to document this when we have a better idea. v2: Fix typo in commit message (Nicholas). Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Daniel Vetter authored
.. next to all the other sink helpers. The rect library is more used for handling plane clipping, so belongs to those imo. Reviewed-by:
-
Daniel Vetter authored
I'm kinda fed up explaining why the have a confusing name :-) v2: Fix typo that Eric Engestrom spotted. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
Yes it's inconsitent with vrr_capable, but this is the actual uapi as exercise by igt. Fixes: ab7a664f ("drm: Document variable refresh properties") Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/gpu/drm/savage/savage_state.c:301:8: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/savage/savage_state.c:438:8: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/savage/savage_state.c:559:8: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/savage/savage_state.c:697:8: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190129202005.GA25789@embeddedor
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/gpu/drm/via/via_dmablit.c:179:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/via/via_dmablit.c:185:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/via/via_dmablit.c:187:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/via/via_dmablit.c:195:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Signed-off-by:
-
Gerd Hoffmann authored
qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt instead, to avoid wasting resources (swiotlb bounce buffers for example). Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
-
- 29 Jan, 2019 6 commits
-
-
Daniel Vetter authored
This is only used by drm_irq_install(), which is an optional helper. For legacy pci devices this is required (due to interrupt sharing without msi/msi-x), and just making this the default exactly matches the behaviour of all existing drivers using the drm_irq_install() helpers. In case that ever becomes wrong drivers can roll their own irq handling, as many drivers already do (for other reasons like needing a threaded interrupt handler, or having an entire pile of different interrupt sources). v2: Rebase v3: Improve commit message (Emil) Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
Daniel Vetter authored
And move the documenation we alreay have into kerneldoc, plus a bit of polish while at it. v2: - Ditch FIXME from commit message, I've resolved that already before sending out the first version. - Put the legacy DRIVER_ flags at the end (Sam). Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Daniel Vetter authored
If a non-legacy driver calls these it's valid to assume there is interrupt support. The flag is really only needed for legacy drivers, which control IRQ enabling/disabling through the DRM_IOCTL_CONTROL legacy IOCTL. Also remove all the flag usage from non-legacy drivers. v2: Review from Emil: - improve commit message - I forgot hibmc, fix that Cc: linux-arm-kernel@lists.infradead.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Reviewed-by:
-
Daniel Vetter authored
Both macros evaluate to 0. At the same time flag is already set to zero since the struct is kzalloc'd in framebuffer_alloc(). As called by drm_fb_helper_alloc_fbi() in the DRM drivers. v2: Rebase and improve commit message per Emil's suggestion. Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124165831.16427-27-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's probably not what you want, definitely not after Noralf's work to add drm_dev_enter/exit. Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
-
Noralf Trønnes authored
If fbdev setup has failed, lastclose will give a NULL pointer deref: [ 77.794295] [drm:drm_lastclose] [ 77.794414] [drm:drm_lastclose] driver lastclose completed [ 77.794660] Unable to handle kernel NULL pointer dereference at virtual address 00000014 [ 77.809460] pgd = b376b71b [ 77.818275] [00000014] *pgd=175ba831, *pte=00000000, *ppte=00000000 [ 77.830813] Internal error: Oops: 17 [#1] ARM [ 77.840963] Modules linked in: mi0283qt mipi_dbi tinydrm raspberrypi_hwmon gpio_backlight backlight snd_bcm2835(C) bcm2835_rng rng_core [ 77.865203] CPU: 0 PID: 527 Comm: lt-modetest Tainted: G C 5.0.0-rc1+ #1 [ 77.879525] Hardware name: BCM2835 [ 77.889185] PC is at restore_fbdev_mode+0x20/0x164 [ 77.900261] LR is at drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c [ 78.002446] Process lt-modetest (pid: 527, stack limit = 0x7a3d5c14) [ 78.291030] Backtrace: [ 78.300815] [<c04f2d0c>] (restore_fbdev_mode) from [<c04f4708>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c) [ 78.319095] r9:d8a8a288 r8:d891acf0 r7:d7697910 r6:00000000 r5:d891ac00 r4:d891ac00 [ 78.334432] [<c04f46b4>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c04f47e8>] (drm_fbdev_client_restore+0x18/0x20) [ 78.353296] r8:d76978c0 r7:d7697910 r6:d7697950 r5:d7697800 r4:d891ac00 r3:c04f47d0 [ 78.368689] [<c04f47d0>] (drm_fbdev_client_restore) from [<c051b6b4>] (drm_client_dev_restore+0x7c/0xc0) [ 78.385982] [<c051b638>] (drm_client_dev_restore) from [<c04f8fd0>] (drm_lastclose+0xc4/0xd4) [ 78.402332] r8:d76978c0 r7:d7471080 r6:c0e0c088 r5:d8a85e00 r4:d7697800 [ 78.416688] [<c04f8f0c>] (drm_lastclose) from [<c04f9088>] (drm_release+0xa8/0x10c) [ 78.431929] r5:d8a85e00 r4:d7697800 [ 78.442989] [<c04f8fe0>] (drm_release) from [<c02640c4>] (__fput+0x104/0x1c8) [ 78.457740] r8:d5ccea10 r7:d96cfb10 r6:00000008 r5:d74c1b90 r4:d8a8a280 [ 78.472043] [<c0263fc0>] (__fput) from [<c02641ec>] (____fput+0x18/0x1c) [ 78.486363] r10:00000006 r9:d7722000 r8:c01011c4 r7:00000000 r6:c0ebac6c r5:d892a340 [ 78.501869] r4:d8a8a280 [ 78.512002] [<c02641d4>] (____fput) from [<c013ef1c>] (task_work_run+0x98/0xac) [ 78.527186] [<c013ee84>] (task_work_run) from [<c010cc54>] (do_work_pending+0x4f8/0x570) [ 78.543238] r7:d7722030 r6:00000004 r5:d7723fb0 r4:00000000 [ 78.556825] [<c010c75c>] (do_work_pending) from [<c0101034>] (slow_work_pending+0xc/0x20) [ 78.674256] ---[ end trace 70d3a60cf739be3b ]--- Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use. Fixes: 9060d7f4 ("drm/fb-helper: Finish the generic fbdev emulation") Cc: stable@vger.kernel.org Signed-off-by:
-
- 28 Jan, 2019 18 commits
-
-
Eugen Hristev authored
PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. This panel with backlight is found in PDA 5" LCD screen (TM5000 series or AC320005-5). Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
-
Cristian Birsan authored
PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. This panel with backlight is found in PDA 5" LCD screen (TM5000 series or AC320005-5). Adding device tree bindings for this panel. Signed-off-by:
Cristian Birsan <cristian.birsan@microchip.com> [eugen.hristev@microchip.com]: specified backlight and supply bindings Signed-off-by:
-
Eugen Hristev authored
Precision Design Associates, Inc. (PDA) manufactures standard and custom capacitive touch screens, LCD's embedded controllers and custom embedded software. They specialize in industrial, rugged and outdoor applications. Website: http://www.pdaatl.com/Signed-off-by:
-
Paul Kocialkowski authored
This adds support for the 3.5" LCD panel from LeMaker, sold for use with BananaPi boards. It comes with a 24-bit RGB888 parallel interface and requires an active-low DE signal Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
-
Paul Kocialkowski authored
This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel, compatible with simple-panel. Signed-off-by:
-
Paul Kocialkowski authored
This introduces a new device-tree binding vendor prefix for Shenzhen LeMaker Technology Co., Ltd. This vendor was already in use but it was not documented until now. Signed-off-by:
-
Nickey Yang authored
Support Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel, it is a MIPI dual-DSI panel. v4-resend: - Thierry noted missing dt-bindings for v4 but forgot that he already had applied them one kernel release back in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebc950fdff6d5f9250cd5a5a348af97f7d8508df v4: - address Philipp's comments - real range for usleep_range and - poweroff ordering in kingdisplay_panel_prepare - return value beautification in panel_probe - update author naming for full name v3: - address Thierry's comments - error handling for init dsi writes in init - unconditionally remove the panel - don't use drm_panel_detach - a bit of variable signednes wiggling - I did talk to ChromeOS people and the delays really should be as short as possible, so dropped the 100ms from the delay comments v2: - update timing + cmds from chromeos kernel - new backlight API including switch to devm_of_find_backlight - fix most of Sean Paul's comments enable/prepare tracking seems something all panels do - document origins of the init sequence - lanes per dsi interface to 4 (two interfaces). Matches how tegra and pending rockchip dual-dsi handle (dual-)dsi lanes - spdx header instead of license boilerplate Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Sean Paul <sean@poorly.run> Signed-off-by:
-
Jagan Teki authored
ST7701 designed for small and medium sizes of TFT LCD display, is capable of supporting up to 480RGBX864 in resolution. It provides several system interfaces like MIPI/RGB/SPI. Currently added support for Techstar TS8550B which is ST7701 based 480x854, 2-lane MIPI DSI LCD panel. Driver now registering mipi_dsi device, but indeed it can extendable for RGB if any requirement trigger in future. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Jagan Teki authored
Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel with inbuilt ST7701 chip. The default regulator names in ST7701 chip is renamed in Techstar TS8550B so, add specific binding names for them. Signed-off-by:
-
Gerd Hoffmann authored
Add all standard modes from the kernel's video mode data base. Keep a few non-standard modes in the qxl mode list. Signed-off-by:
-
Gerd Hoffmann authored
Add a helper function to add custom video modes to a connector. Signed-off-by:
-
Gerd Hoffmann authored
Add a helper functions to check video modes. Also add a helper to check framebuffer buffer objects, using the former for consistency. That way we should not fail in qxl_primary_atomic_check() because video modes which are too big will not be added to the mode list in the first place. Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
-
Gerd Hoffmann authored
Lovely diffstat, thanks to the new generic fbdev emulation. drm/qxl/Makefile | 2 drm/qxl/qxl_draw.c | 232 ---------------------------------------- drm/qxl/qxl_drv.h | 21 --- drm/qxl/qxl_fb.c | 300 ----------------------------------------------------- Signed-off-by:
-
Gerd Hoffmann authored
Switch qxl over to the new generic fbdev emulation. Signed-off-by:
-
Gerd Hoffmann authored
Generic fbdev emulation needs this. Also: We must keep track of the number of mappings now, so we don't unmap early in case two users want a kmap of the same bo. Add a sanity check to destroy callback to make sure kmap/kunmap is balanced. Signed-off-by:
-
Gerd Hoffmann authored
qdev->monitors_config->max_allowed is effectively set by the qxl.num_heads module parameter, stored in the qxl_num_crtc variable. Lets get rid of the indirection and use the variable qxl_num_crtc directly. The kernel doesn't need to dereference pointers each time it needs the value, and when reading the code you don't have to trace where and why qdev->monitors_config->max_allowed is set. Signed-off-by:
-
Gerd Hoffmann authored
The qxl device supports only a single active framebuffer ("primary surface" in spice terminology). In multihead configurations are handled by defining rectangles within the primary surface for each head/crtc. Userspace which uses the qxl ioctl interface (xorg qxl driver) is aware of this limitation and will setup framebuffers and crtcs accordingly. Userspace which uses dumb framebuffers (xorg modesetting driver, wayland) is not aware of this limitation and tries to use two framebuffers (one for each crtc) instead. The qxl kms driver already has the dumb bo separated from the primary surface, by using a (shared) shadow bo as primary surface. This is needed to support pageflips without having to re-create the primary surface. The qxl driver will blit from the dumb bo to the shadow bo instead. So we can extend the shadow logic: Maintain a global shadow bo (aka primary surface), make it big enough that dumb bo's for all crtcs fit in side-by-side. Adjust the pageflip blits to place the heads next to each other in the shadow. With this patch in place multihead qxl works with wayland. Signed-off-by:
-
