- 29 Mar, 2022 7 commits
-
-
Jani Nikula authored
The reduced blanking bit is valid only for CVT, indicated by display range limits flags 0x04. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/5dea5ee24065450716bbc177dd6850d3193dbeec.1648477901.git.jani.nikula@intel.com
-
Jani Nikula authored
We'll want to keep the EDID immutable while parsing. Stop modifying the EDID because of the quirks. In theory, this does have userspace implications, but the userspace is supposed to use the modes exposed via KMS API, not by parsing the EDID directly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Xiaomeng Tong authored
The bug is here: if (!encoder) { The list iterator value 'encoder' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'encoder' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: ec9eab09 ("drm/tilcdc: Add drm bridge support for attaching drm bridge drivers") Signed-off-by:Xiaomeng Tong <xiam0nd.tong@gmail.com> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi> Tested-by:
-
Xiaomeng Tong authored
The bug is here: return crtc; The list iterator value 'crtc' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, return 'crtc' when found, otherwise return NULL. Cc: stable@vger.kernel.org fixes: 89c78134 ("gma500: Add Poulsbo support") Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220327052028.2013-1-xiam0nd.tong@gmail.com
-
Christian König authored
We have the BO pointer in the base structure now as well. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Link: https://patchwork.freedesktop.org/patch/msgid/20220321132601.2161-6-christian.koenig@amd.com
-
Christian König authored
Instead of providing the bulk move structure for each LRU update set this as property of the BO. This should avoid costly bulk move rebuilds with some games under RADV. v2: some name polishing, add a few more kerneldoc words. v3: add some lockdep v4: fix bugs, handle pin/unpin as well v5: improve kerneldoc Signed-off-by:
-
Christian König authored
Those functions are going to become more complex, don't inline them any more. Signed-off-by:
-
- 28 Mar, 2022 9 commits
-
-
Xiaomeng Tong authored
The bug is here: return encoder; The list iterator value 'encoder' will *always* be set and non-NULL by drm_for_each_encoder_mask(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found. Otherwise it will bypass some NULL checks and lead to invalid memory access passing the check. To fix this bug, just return 'encoder' when found, otherwise return NULL. Cc: stable@vger.kernel.org Fixes: 12885ecb ("drm/nouveau/kms/nvd9-: Add CRC support") Signed-off-by:
Lyude Paul <lyude@redhat.com> [Changed commit title] Signed-off-by:
-
Christian König authored
Not just TT and VRAM. Signed-off-by:
-
Christian König authored
Instead of duplicating that at different places add an iterator over all the resources in a resource manager. v2: add lockdep annotation and kerneldoc v3: fix various bugs pointed out by Felix v4: simplify the code a bit more Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321132601.2161-2-christian.koenig@amd.com
-
Christian König authored
This way we finally fix the problem that new resource are not immediately evict-able after allocation. That has caused numerous problems including OOM on GDS handling and not being able to use TTM as general resource manager. v2: stop assuming in ttm_resource_fini that res->bo is still valid. v3: cleanup kerneldoc, add more lockdep annotation v4: consistently use res->num_pages Signed-off-by:
-
Andrey Grodzovsky authored
Fixes the warning. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220328132532.406572-1-andrey.grodzovsky@amd.com
-
Xin Ji authored
As downstream sink was set into standby mode while bridge disabled, this patch used for setting downstream sink into normal status while enable bridge. Signed-off-by:
Xin Ji <xji@analogixsemi.com> Reviewed-by:
Pin-Yen Lin <treapking@chromium.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220322080213.1487134-1-xji@analogixsemi.com
-
Ivaylo Dimitrov authored
On devices with DMM, all allocations are done through either DMM or TILER. DMM/TILER being a limited resource means that such allocations will start to fail before actual free memory is exhausted. What is even worse is that with time DMM/TILER space gets fragmented to the point that even if we have enough free DMM/TILER space and free memory, allocation fails because there is no big enough free block in DMM/TILER space. Such failures can be easily observed with OMAP xorg DDX, for example - starting few GUI applications (so buffers for their windows are allocated) and then rotating landscape<->portrait while closing and opening new windows soon results in allocation failures. Fix that by mapping buffers through DMM/TILER only when really needed, like, for scanout buffers. Signed-off-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1642587791-13222-4-git-send-email-ivo.g.dimitrov.75@gmail.com
-
Ivaylo Dimitrov authored
Currently code allocates non-scanout BOs from SHMEM and those objects are accessible to userspace by mmap(). However, on devices with no DMM (like OMAP3), the same objects are not accessible by kernel drivers that want to render to them as code refuses to export them. In turn this means that on devices with no DMM, all buffers must be allocated as scanout, otherwise only CPU can access them. On those devices, scanout buffers are allocated from CMA, making those allocations highly unreliable. Fix that by implementing functionality to export SHMEM backed buffers on devices with no DMM. This makes CMA memory only being used when needed, instead for every buffer that has to be off-CPU rendered. Tested on Motorola Droid4 and Nokia N900 Signed-off-by:
-
Ivaylo Dimitrov authored
Move tiler related code to its own function. Signed-off-by:
-
- 25 Mar, 2022 3 commits
-
-
Cong Liu authored
qxl use ioremap to map ram_header and rom, in the arm64 implementation, the device is mapped as DEVICE_nGnRE, it can not support unaligned access. and qxl is a virtual device, it can be treated more like RAM than actual MMIO registers. use ioremap_wc() replace it. Signed-off-by:
Cong Liu <liucong2@kylinos.cn> Acked-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Rob Clark authored
With native userspace drivers in guest, a lot of GEM objects need to be neither shared nor mappable. And in fact making everything mappable and/or sharable results in unreasonably high fd usage in host VMM. Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220219170301.545432-1-robdclark@gmail.comSigned-off-by:
-
Liu Zixian authored
drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218 Signed-off-by:
Liu Zixian <liuzixian4@huawei.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixian4@huawei.comSigned-off-by:
-
- 24 Mar, 2022 15 commits
-
-
Maxime Ripard authored
In addition to the RGB444 output, the BCM2711 HDMI controller supports the YUV444 and YUV422 output formats. Let's add support for them in the driver, but still use RGB as the preferred format. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
-
Maxime Ripard authored
Currently we take the max_bpc property as the bpc value and do not try anything else. However, what the other drivers seem to be doing is that they would try with the highest bpc allowed by the max_bpc property and the hardware capabilities, test if it results in an acceptable configuration, and if not decrease the bpc and try again. Let's use the same logic. Signed-off-by:
-
Maxime Ripard authored
The current code only base its decision for whether the scrambler must be enabled or not on the pixel clock of the mode, but doesn't take the bits per color into account. Let's leverage the new function to compute the clock rate in the scrambler setup code. Signed-off-by:
-
Maxime Ripard authored
In the function that validates that the clock isn't too high, we've only taken our controller limitations into account so far. However, the sink can have a limit on the maximum TMDS clock it can deal with too which is exposed through the EDID and the drm_display_info. Make sure we check it. Signed-off-by:
-
Maxime Ripard authored
The code to compute our clock rate for a given setup will be called in multiple places in the next patches, so let's create a separate function for it. Signed-off-by:
-
Maxime Ripard authored
Our code is doing the same clock rate validation in multiple instances. Let's create a helper to share the rate validation. Signed-off-by:
-
Maxime Ripard authored
The pixel_rate field in the vc4_hdmi_connector_state struct actually stores the TMDS character rate, let's rename it for consistency. Suggested-by:
-
YueHaibing authored
If DRM_ITE_IT6505 is y but DRM_DP_HELPER is m, building failed: drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_i2c_remove': ite-it6505.c:(.text+0x35c): undefined reference to `drm_dp_aux_unregister' drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_dpcd_read': ite-it6505.c:(.text+0x420): undefined reference to `drm_dp_dpcd_read' drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_get_dpcd': ite-it6505.c:(.text+0x4a4): undefined reference to `drm_dp_dpcd_read' drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_dpcd_write': ite-it6505.c:(.text+0x52c): undefined reference to `drm_dp_dpcd_write' Select DRM_DP_HELPER for DRM_ITE_IT6505 to fix this. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
Christian König authored
Drivers should never touch this directly. v2: drop kerneldoc for now internal handling Signed-off-by:
-
Christian König authored
This function allows to replace fences from the shared fence list when we can gurantee that the operation represented by the original fence has finished or no accesses to the resources protected by the dma_resv object any more when the new fence finishes. Then use this function in the amdkfd code when BOs are unmapped from the process. v2: add an example when this is usefull. Signed-off-by:
-
Christian König authored
Use dma_resv_wait() instead of extracting the exclusive fence and waiting on it manually. Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Maor Gottlieb <maorg@nvidia.com> Cc: Gal Pressman <galpress@amazon.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20220321135856.1331-4-christian.koenig@amd.com
-
Christian König authored
We can get the excl fence together with the shared ones as well. v2: rename the member to fences as well Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220321135856.1331-5-christian.koenig@amd.com
-
Nicolas Belin authored
Adding the audio support on the HDMI bridge for I2S only. Signed-off-by:
Nicolas Belin <nbelin@baylibre.com> Signed-off-by:
Andy.Hsieh <Andy.Hsieh@mediatek.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Nicolas Belin authored
Set the register page length or window length to 0x100 according to the documentation. Fixes: 988156dc ("drm: bridge: add it66121 driver") Signed-off-by:
-
Nicolas Belin authored
Update the ITE bridge HDMI it66121 bindings in order to support audio. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 23 Mar, 2022 6 commits
-
-
Patrik Jakobsson authored
These functions operate on a crtc and should be prefixed properly. Suggested-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Patrik Jakobsson authored
These functions are not used outside of their file scope so can be declared as static. Signed-off-by:
-
Patrik Jakobsson authored
The allocation is made for the gma_connector object so we must use the same address when free()ing the object. Signed-off-by:
-
Patrik Jakobsson authored
According to docs we should only register connectors that are hotpluggable. No connectors in gma500 are hotpluggable. Signed-off-by:
-
Patrik Jakobsson authored
This makes sure we're using proper locking when iterating the list of connectors. Signed-off-by:
-
Patrik Jakobsson authored
Reloading the driver revealed that the interrupt handler never got uninstalled. Signed-off-by:
-
