- 29 Jan, 2019 4 commits
-
-
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:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190129104248.26607-1-daniel.vetter@ffwll.ch
-
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 <noralf@tronnes.org> Signed-off-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:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125150300.33268-1-noralf@tronnes.org
-
- 28 Jan, 2019 32 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:
Rob Herring <robh@kernel.org> 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:
Heiko Stuebner <heiko@sntech.de> Reviewed-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: -
Gerd Hoffmann authored
Pass the shadow bo to qxl_io_create_primary() instead of expecting qxl_io_create_primary to check bo->shadow. Set is_primary flag on the shadow bo. Move the is_primary tracking into qxl_io_create_primary() and qxl_io_destroy_primary() functions. That simplifies primary surface tracking and the workflow in qxl_primary_atomic_update(). Signed-off-by:
-
Gerd Hoffmann authored
Track which bo is used as primary surface. With that in place we don't need the primary_created flag any more, we can just check the primary bo pointer instead. Also verify we don't already have a primary surface in qxl_io_create_primary(). Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
-
Gerd Hoffmann authored
The qxl device ties the cursor to the primary surface. Therefore calling qxl_io_destroy_primary() and qxl_io_create_primary() to switch the framebuffer causes the cursor information being lost and the driver must re-apply it. The correct call order to do that is qxl_io_destroy_primary() + qxl_io_create_primary() + qxl_primary_apply_cursor(). The old code did qxl_io_destroy_primary() + qxl_primary_apply_cursor() + qxl_io_create_primary(). Due to qxl_primary_apply_cursor request being queued in a ringbuffer and qxl_io_create_primary() trapping to the hypervisor instantly there is a high chance that qxl_io_create_primary() is processed first even with the wrong call order. But it's racy and thus not reliable. Signed-off-by:
-
Gerd Hoffmann authored
dumb buffers are used as qxl surfaces, so allocate them as QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in PRIV ttm domain then, so this reduces VRAM memory pressure. Signed-off-by:
-
Gerd Hoffmann authored
The shadow bo is used as qxl surface, so allocate it as QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in PRIV ttm domain then, so this reduces VRAM memory pressure. Signed-off-by:
-
Gerd Hoffmann authored
qxl surfaces (used for framebuffers and gem objects) can live in both VRAM and PRIV ttm domains. Update placement setup to include both. Put PRIV first in the list so it is preferred, so VRAM will have more room for objects which must be allocated there. Signed-off-by:
-
Gerd Hoffmann authored
Without that ttm offsets are not unique, they can refer to objects in both VRAM and PRIV memory (aka main and surfaces slot). One of those "why things didn't blow up without this" moments. Probably offset conflicts are rare enough by pure luck. Signed-off-by:
-
Gerd Hoffmann authored
slot_id_bits and slot_gen_bits can be read directly from qxlrom instead. va_slot_mask is never used anywhere. Signed-off-by:
-
Frediano Ziglio authored
Instead of relaying on surface type use the actual placement. This allow to have different placement for a single type of surface. Signed-off-by:
Frediano Ziglio <fziglio@redhat.com> Acked-by:
-
Gerd Hoffmann authored
Drop pointless indirection, remove the mem_slots array and index variables, drop dynamic allocation. Store memslots in qxl_device instead. Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
-
Gerd Hoffmann authored
Not used, is always NULL. Signed-off-by:
-
Damian Kos authored
This is basically the same fix as in commit fa68d4f8 ("drm/rockchip: fix for mailbox read size") but for cdn_dp_mailbox_validate_receive function. See patchwork.kernel.org/patch/10671981/ for details. Signed-off-by:
Damian Kos <dkos@cadence.com> Signed-off-by:
-
- 27 Jan, 2019 4 commits
-
-
Heiko Stuebner authored
Before assigning window data, we should check if the yuv2yuv vop-data is set at all, because it looks like it can otherwise reference something wrong, as I saw on my rk3188 today which ended up in a null pointer dereference in vop_plane_atomic_update when accessing the yuv2yuv data. Fixes: 1c21aa8f ("drm/rockchip: Fix YUV buffers color rendering") Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/2556882.Heuq80WCVD@phil
-
Peter Rosin authored
With the help from drm_atomic_helper_check_plane_state function, clipping now handles planes to be partially or totally off-screen. The plane is disabled if it is not visible. Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Boris Brezillon <bbrezillon@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190110151020.30468-4-peda@axentia.se
-
Peter Rosin authored
The destination crtc rectangle is independent of source plane rotation. Signed-off-by:
-
Peter Rosin authored
Ouch, the driver rotates planes clockwise, which is simply not correct. Signed-off-by:
-
