- 04 Sep, 2020 2 commits
-
-
Linus Walleij authored
This makes it possible to use the s6e63m0 panel with a DSI host, such as in the Samsung GT-I8190 (Golden) mobile phone. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
Stephan Gerhold <stephan@gerhold.net> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Acked-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-3-linus.walleij@linaro.org
-
Linus Walleij authored
This panel can be accessed using both SPI and DSI. To make it possible to probe and use the device also from a DSI bus, first break out the SPI support to its own file. Since all the panel driver does is write DCS commands to the panel, we pass a DCS write function to probe() from each subdriver. We make the Kconfig entry for SPI mode default so all current users will continue to work. Signed-off-by:
-
- 03 Sep, 2020 4 commits
-
-
Daniel Vetter authored
Following functions are only used internally, not by drivers: - devm_drm_dev_init Also, now that we have a very slick and polished way to allocate a drm_device with devm_drm_dev_alloc, update all the docs to reflect the new reality. Mostly this consists of deleting old and misleading hints. Two main ones: - it is no longer required that the drm_device base class is first in the structure. devm_drm_dev_alloc can cope with it being anywhere - obviously embedded now strongly recommends using devm_drm_dev_alloc v2: Fix typos (Noralf) v3: Split out the removal of drm_dev_init, that's blocked on some discussions on how to convert vgem/vkms/i915-selftests. Adjust commit message to reflect that. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> (v2) Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200902072627.3617301-1-daniel.vetter@ffwll.ch
-
Christian König authored
That is not used any more. v2: keep the NULL checks in TTM. v3: remove unused variable Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388646/
-
Christian König authored
While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve v3: rebased and use both base and offset in the check v4: fix small typos and test the patch v5: rebased and keep the mem.bus init in TTM. Signed-off-by:
-
Christian König authored
We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by:
-
- 02 Sep, 2020 4 commits
-
-
Randy Dunlap authored
Fix kernel-doc warning in <linux/dma-buf.h>: ../include/linux/dma-buf.h:330: warning: Function parameter or member 'name_lock' not described in 'dma_buf' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Christian König <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Randy Dunlap authored
Add @cookie to dma_fence_end_signalling() to prevent kernel-doc warning in drivers/dma-buf/dma-fence.c: ../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member 'cookie' not described in 'dma_fence_end_signalling' Signed-off-by:
-
Gerd Hoffmann authored
Not needed, already tracked by drm_crtc_state->active. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
-
Gerd Hoffmann authored
When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10 ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851@bugs.launchpad.net Fixes: 3954ff10 ("drm/virtio: skip set_scanout if framebuffer didn't change") Signed-off-by:
Jiri Slaby <jirislaby@kernel.org> Tested-by:
Diego Viola <diego.viola@gmail.com> Acked-by:
-
- 01 Sep, 2020 5 commits
-
-
Rikard Falkeborn authored
The only usage of these is to assign their address to the fbops field in the fb_info struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
In order to shrink drm_display_mode below the magic two cacheline mark in 64bit we need to shrink it by another 8 bytes. The easiest thing to eliminate is the 'export_head' list head which is only used during the getconnector ioctl to temporarly track which modes on the connector's mode list are to be exposed and which are to remain hidden. We can simply replace the list head with a boolean which we use to tag the modes that are to be exposed. If we make sure to clear the tags after we're done with them we don't even need an extra loop over the modes to reset the tags at the start of the getconnector ioctl. Conveniently we already have a hole for the boolean left behind by the removal of mode->private_flags. The final size of the struct is now 112 bytes on 32bit and 120 bytes on 64bit. Another alternative would be a temp bitmask so we wouldn't have to have anything in the mode struct itself. The main issue is how large of a bitmask do we need? I guess we could allocate it dynamically but that means an extra kcalloc() and an extra loop through the modes to count them first (or grow the bitmask with krealloc() as needed). CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-17-ville.syrjala@linux.intel.comReviewed-by:
Emil Velikov <emil.velikov@collabora.com>
-
Ville Syrjälä authored
The last two uses of mode->private_flags (in i915 and gma500) are now gone. So let's remove mode->private_flags entirely. v2: Drop the earlier int->u8 conversion CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
-
Sam McNally authored
For DP MST outputs, the i2c device currently only supports transfers that can be implemented using remote i2c reads. Such transfers must consist of zero or more write transactions followed by one read transaction. DDC/CI commands require standalone write transactions and hence aren't supported. Since each remote i2c write is handled as a separate transfer, remote i2c writes can support transfers consisting of write transactions, where all but the last have I2C_M_STOP set. According to the DDC/CI 1.1 standard, DDC/CI commands only require a single write or read transaction in a transfer, so this is sufficient. For i2c transfers meeting the above criteria, generate and send a remote i2c write message for each transaction. Add the trivial remote i2c write reply parsing support so remote i2c write acks bubble up correctly. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37Signed-off-by:
Sam McNally <sammc@chromium.org> Signed-off-by:
-
Dinghao Liu authored
When verify_crc_source() fails, source needs to be freed. However, current code is returning directly and ends up leaking memory. Fixes: d5cc15a0 ("drm: crc: Introduce verify_crc_source callback") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: change Fixes: tag per Laurent's review] Signed-off-by:
-
- 31 Aug, 2020 4 commits
-
-
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:
-
Dave Airlie authored
This can be gotten back from bdev. Reviewed-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:
-
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:
-
