- 17 Jan, 2024 2 commits
-
-
Michał Winiarski authored
The original intent behind the test was to sanity check whether calling the debug iterator (drm_mm_print) doesn't cause any problems. Unfortunately - this call got accidentally removed during KUnit transition. Restore it. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240116174602.1019512-1-michal.winiarski@intel.com
-
Yangyu Chen authored
Some platforms may not have any memory in ZONE_DMA32 and use IOMMU to allow 32-bit-DMA-only device to work. Forcing GFP_DMA32 on dummy_read_page will fail on such platforms. Retry after fail will get this works on such platforms. Signed-off-by:
Yangyu Chen <cyy@cyyself.name> Link: https://patchwork.freedesktop.org/patch/msgid/tencent_8637383EE0A2C7CC870036AAF01909B26A0A@qq.comSigned-off-by:
Christian König <christian.koenig@amd.com>
-
- 16 Jan, 2024 2 commits
-
-
Tomi Valkeinen authored
The driver never unregisters the audio codec platform device, which can lead to a crash on module reloading, nor does it handle the return value from sii902x_audio_codec_init(). Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: ff578163 ("drm/bridge: sii902x: Implement HDMI audio support") Cc: Jyri Sarha <jsarha@ti.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240103-si902x-fixes-v1-2-b9fd3e448411@ideasonboard.comSigned-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240103-si902x-fixes-v1-2-b9fd3e448411@ideasonboard.com
-
Tomi Valkeinen authored
A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: - tidss probes, but is deferred as sii902x is still missing. - sii902x starts probing and enters sii902x_init(). - sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective. - sii902x calls sii902x_audio_codec_init() and platform_device_register_data() - The registration of the audio platform device causes probing of the deferred devices. - tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. - sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe(). Signed-off-by:
-
- 12 Jan, 2024 3 commits
-
-
Arnd Bergmann authored
As with several other panel drivers, this fails to link without the DP helper library: ld: drivers/gpu/drm/panel/panel-raydium-rm692e5.o: in function `rm692e5_prepare': panel-raydium-rm692e5.c:(.text+0x11f4): undefined reference to `drm_dsc_pps_payload_pack' Select the same symbols that the others already use. Fixes: 988d0ff2 ("drm/panel: Add driver for BOE RM692E5 AMOLED panel") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Artur Weber authored
It turns out that I had misconfigured the device I was using the panel with; the bus data polarity is not high for this panel, I had to change the config on the display controller's side. Fix the panel config to properly reflect its accurate settings. Fixes: 6810bb39 ("drm/panel: Add Samsung S6D7AA0 panel controller driver") Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by:
Artur Weber <aweber.kernel@gmail.com> Link: https://lore.kernel.org/r/20240105-tab3-display-fixes-v2-2-904d1207bf6f@gmail.comSigned-off-by:
-
Markus Niebel authored
The DE signal is active high on this display, fill in the missing bus_flags. This aligns panel_desc with its display_timing. Fixes: 9a2654c0 ("drm/panel: Add and fill drm_panel type field") Fixes: b3bfcdf8 ("drm/panel: simple: add Tianma TM070JVHG33") Signed-off-by:
Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://lore.kernel.org/r/20231012084208.2731650-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
- 08 Jan, 2024 1 commit
-
-
Douglas Anderson authored
Unlike what is claimed in commit f5aa7d46 ("drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if someone manually tries to do an AUX transfer (like via `i2cdump ${bus} 0x50 i`) while the panel is off we don't just get a simple transfer error. Instead, the whole ps8640 gets thrown for a loop and goes into a bad state. Let's put the function to wait for the HPD (and the magical 50 ms after first reset) back in when we're doing an AUX transfer. This shouldn't actually make things much slower (assuming the panel is on) because we should immediately poll and see the HPD high. Mostly this is just an extra i2c transfer to the bridge. Fixes: f5aa7d46 ("drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux") Tested-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231221135548.1.I10f326a9305d57ad32cee7f8d9c60518c8be20fb@changeid
-
- 20 Dec, 2023 1 commit
-
-
Jocelyn Falempe authored
When mgag200 switched from simple KMS to regular atomic helpers, the initialization of the gamma settings was lost. This leads to a black screen, if the bios/uefi doesn't use the same pixel color depth. This has been fixed with commit ad81e234 ("drm/mgag200: Fix gamma lut not initialized.") for most G200, but G200ER, G200EV, G200SE use their own version of crtc_helper_atomic_enable() and need to be fixed too. Fixes: 1baf9127 ("drm/mgag200: Replace simple-KMS with regular atomic helpers") Cc: <stable@vger.kernel.org> #v6.1+ Reported-by:
Roger Sewell <roger.sewell@cantab.net> Suggested-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231214163849.359691-1-jfalempe@redhat.com
-
- 19 Dec, 2023 1 commit
-
-
Douglas Anderson authored
After commit 26195af5 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID"), I got an error compiling: error: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (msg->size) *' (aka 'unsigned long *')) [-Werror,-Wcompare-distinct-pointer-types] Fix it by declaring the `len` as size_t. The above error only shows up on downstream kernels without commit d03eba99 ("minmax: allow min()/max()/clamp() if the arguments have the same signedness."), but since commit 26195af5 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") is a "Fix" that will likely be backported it seems nice to make it easy. ...plus it's more correct to declare `len` as size_t anyway. Fixes: 26195af5 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
- 18 Dec, 2023 2 commits
-
-
Douglas Anderson authored
For aux reads, the value `msg->size` indicates the size of the buffer provided by `msg->buffer`. We should never in any circumstances write more bytes to the buffer since it may overflow the buffer. In the ti-sn65dsi86 driver there is one code path that reads the transfer length from hardware. Even though it's never been seen to be a problem, we should make extra sure that the hardware isn't increasing the length since doing so would cause us to overrun the buffer. Fixes: 982f589b ("drm/bridge: ti-sn65dsi86: Update reply on aux failures") Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Douglas Anderson authored
While testing, I happened to notice a random crash that looked like: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120 Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer (allocated on the stack) to the aux->transfer() function. Presumably if the aux->transfer() writes more than one byte to this buffer then we're in a bad shape. Dropping into kgdb, I noticed that "aux->transfer" pointed at ps8640_aux_transfer(). Reading through ps8640_aux_transfer(), I can see that there are cases where it could write more bytes to msg->buffer than were specified by msg->size. This could happen if the hardware reported back something bogus to us. Let's fix this so we never write more than msg->size bytes. We'll still read all the bytes from the hardware just in case the hardware requires it since the aux transfer data comes through an auto-incrementing register. NOTE: I have no actual way to reproduce this issue but it seems likely this is what was happening in the crash I looked at. Fixes: 13afcdd7 ("drm/bridge: parade-ps8640: Add support for AUX channel") Reviewed-by:
-
- 15 Dec, 2023 2 commits
-
-
Jeffrey Hugo authored
The SOC_HW_VERSION register in the BHI space is not correctly initialized by the device and in many cases contains uninitialized data. The register could contain 0xFFFFFFFF which is a special value to indicate a link error in PCIe, therefore if observed, we could incorrectly think the device is down. Intercept reads for this register, and provide the correct value - every production instance would read 0x60110200 if the device was operating as intended. Fixes: a36bf7af ("accel/qaic: Add MHI controller") Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231208163101.1295769-3-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
Do not modify the size of dmabuf as it is immutable. Fixes: ff13be83 ("accel/qaic: Add datapath") Signed-off-by:
-
- 13 Dec, 2023 2 commits
-
-
Farouk Bouabid authored
The ltk050h3148w variant expects the horizontal component lane byte clock cycle(lbcc) to be calculated using lane_mbps (burst mode) instead of the pixel clock. Using the pixel clock rate by default for this calculation was introduced in commit ac87d236 ("drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbcc") and starting from commit 93e82bb4 ("drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode") only panels that support burst mode can keep using the lane_mbps. So add MIPI_DSI_MODE_VIDEO_BURST as part of the mode_flags for the dsi host. Fixes: 93e82bb4 ("drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode") Signed-off-by:
Farouk Bouabid <farouk.bouabid@theobroma-systems.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231213145045.41020-1-farouk.bouabid@theobroma-systems.com
-
David Heidelberg authored
Originally was in the panel-simple, but belongs to panel-simple-dsi. See arch/arm/boot/dts/nvidia/tegra114-roth.dts for more details. Resolves the following warning: ``` arch/arm/boot/dts/tegra114-roth.dt.yaml: panel@0: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/display/panel/panel-simple.yaml ``` Fixes: 310abcea ("dt-bindings: display: convert simple lg panels to DT Schema") Signed-off-by:David Heidelberg <david@ixit.cz> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
- 11 Dec, 2023 2 commits
-
-
Jani Nikula authored
When the separate add modes call was added back in commit c533b516 ("drm/edid: add separate drm_edid_connector_add_modes()"), it failed to address drm_edid_override_connector_update(). Also call add modes there. Reported-by:
bbaa <bbaa@bbaa.fun> Closes: https://lore.kernel.org/r/930E9B4C7D91FDFF+29b34d89-8658-4910-966a-c772f320ea03@bbaa.fun Fixes: c533b516 ("drm/edid: add separate drm_edid_connector_add_modes()") Cc: <stable@vger.kernel.org> # v6.3+ Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231207093821.2654267-1-jani.nikula@intel.com
-
Andrzej Kacprowski authored
Using PCI Device ID/Revision to initialize the interrupt_clear_with_0 workaround is problematic - there are many pre-production steppings with different behavior, even with the same PCI ID/Revision Instead of checking for PCI Device ID/Revision, check the VPU buttress interrupt status register behavior - if this register is not zero after writing 1s it means there register is RW instead of RW1C and we need to enable the interrupt_clear_with_0 workaround. Fixes: 7f34e01f ("accel/ivpu: Clear specific interrupt status bits on C0") Signed-off-by:
Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> Signed-off-by:
-
- 08 Dec, 2023 2 commits
-
-
Jani Nikula authored
Commit 3823119b ("drm/crtc: Fix uninit-value bug in drm_mode_setcrtc") was supposed to fix use of an uninitialized variable, but introduced another. num_connectors is only initialized if crtc_req->count_connectors > 0, but it's used regardless. Fix it. Fixes: 3823119b ("drm/crtc: Fix uninit-value bug in drm_mode_setcrtc") Cc: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com Cc: Ziqi Zhao <astrajoan@yahoo.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Ziqi Zhao authored
The connector_set contains uninitialized values when allocated with kmalloc_array. However, in the "out" branch, the logic assumes that any element in connector_set would be equal to NULL if failed to initialize, which causes the bug reported by Syzbot. The fix is to use an extra variable to keep track of how many connectors are initialized indeed, and use that variable to decrease any refcounts in the "out" branch. Reported-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com Signed-off-by:
Ziqi Zhao <astrajoan@yahoo.com> Reported-and-tested-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com Tested-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20230721161446.8602-1-astrajoan@yahoo.comSigned-off-by:
-
- 07 Dec, 2023 1 commit
-
-
Lingkai Dong authored
The DRM subsystem keeps a record of the owner of a DRM device file descriptor using thread group ID (TGID) instead of process ID (PID), to ensures all threads within the same userspace process are considered the owner. However, the DRM master ownership check compares the current thread's PID against the record, so the thread is incorrectly considered to be not the FD owner if the PID is not equal to the TGID. This causes DRM ioctls to be denied master privileges, even if the same thread that opened the FD performs an ioctl. Fix this by checking TGID. Fixes: 4230cea8 ("drm: Track clients by tgid and not tid") Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v6.4+ Link: https://patchwork.freedesktop.org/patch/msgid/PA6PR08MB107665920BE9A96658CDA04CE8884A@PA6PR08MB10766.eurprd08.prod.outlook.comSigned-off-by:
-
- 06 Dec, 2023 1 commit
-
-
Thomas Zimmermann authored
Invoke drm_plane_helper_funcs.end_fb_access before drm_atomic_helper_commit_hw_done(). The latter function hands over ownership of the plane state to the following commit, which might free it. Releasing resources in end_fb_access then operates on undefined state. This bug has been observed with non-blocking commits when they are being queued up quickly. Here is an example stack trace from the bug report. The plane state has been free'd already, so the pages for drm_gem_fb_vunmap() are gone. Unable to handle kernel paging request at virtual address 0000000100000049 [...] drm_gem_fb_vunmap+0x18/0x74 drm_gem_end_shadow_fb_access+0x1c/0x2c drm_atomic_helper_cleanup_planes+0x58/0xd8 drm_atomic_helper_commit_tail+0x90/0xa0 commit_tail+0x15c/0x188 commit_work+0x14/0x20 Fix this by running end_fb_access immediately after updating all planes in drm_atomic_helper_commit_planes(). The existing clean-up helper drm_atomic_helper_cleanup_planes() now only handles cleanup_fb. For aborted commits, roll back from drm_atomic_helper_prepare_planes() in the new helper drm_atomic_helper_unprepare_planes(). This case is different from regular cleanup, as we have to release the new state; regular cleanup releases the old state. The new helper also invokes cleanup_fb for all planes. The changes mostly involve DRM's atomic helpers. Only two drivers, i915 and nouveau, implement their own commit function. Update them to invoke drm_atomic_helper_unprepare_planes(). Drivers with custom commit_tail function do not require changes. v4: * fix documentation (kernel test robot) v3: * add drm_atomic_helper_unprepare_planes() for rolling back * use correct state for end_fb_access v2: * fix test in drm_atomic_helper_cleanup_planes() Reported-by:
Alyssa Ross <hi@alyssa.is> Closes: https://lore.kernel.org/dri-devel/87leazm0ya.fsf@alyssa.is/Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Fixes: 94d879ea ("drm/atomic-helper: Add {begin,end}_fb_access to plane helpers") Tested-by:
-
- 05 Dec, 2023 1 commit
-
-
Arnd Bergmann authored
A dependency on this feature was recently introduced: x86_64-linux-ld: vmlinux.o: in function `tc358768_bridge_pre_enable': tc358768.c:(.text+0xbe3dae): undefined reference to `drm_display_mode_to_videomode' Make sure this is always enabled. Fixes: e5fb2167 ("drm/bridge: tc358768: Use struct videomode") Signed-off-by:
-
- 30 Nov, 2023 3 commits
-
-
Adrián Larumbe authored
It was noticed when setting the Panfrost's DVFS device to the performant governor, GPU frequency as reported by fdinfo had dropped to 0 permamently. There are two separate issues causing this behaviour: - Not initialising the device's current_frequency variable to its original value during device probe(). - Updating said variable in Panfrost devfreq's get_dev_status() rather than after the new OPP's frequency had been retrieved in target(), which meant the old frequency would be assigned instead. Signed-off-by:
Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: f11b0417 ("drm/panfrost: Add fdinfo support GPU load metrics") Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Adrián Larumbe authored
A GEM object constructed from a dma-buf imported sgtable should be regarded as being memory resident, because the dma-buf API mandates backing storage to be allocated when attachment succeeds. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
-
Dave Airlie authored
This is a hack around a bug exposed with the GSP code, I'm not sure what is happening exactly, but it appears some of our flushes don't result in proper tlb invalidation for out BAR2 and we get a BAR2 fault from GSP and it all dies. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231130010852.4034774-1-airlied@gmail.com
-
- 29 Nov, 2023 6 commits
-
-
Timur Tabi authored
Document a few aspects of communication with GSP-RM. These comments are derived from notes made during early development of GSP-RM support in Nouveau, but were not included in the initial patch set. Reviewed-by:
Timur Tabi <ttabi@nvidia.com> Reviewed-by:
-
Yang Yingliang authored
mipi_dsi_device_register_full() never returns NULL pointer, it will return ERR_PTR() when it fails, so replace the check with IS_ERR(). Fixes: 0993234a ("drm/panel: Add driver for Novatek NT36523") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
-
xiazhengqiao authored
For the "starry, 2081101qfh032011-53g" panel, it is stipulated in the panel spec that MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high. Fixes: 6069b66c ("drm/panel: support for STARRY 2081101QFH032011-53G MIPI-DSI panel") Signed-off-by:
xiazhengqiao <xiazhengqiao@huaqin.corp-partner.google.com> Reviewed-by:
-
Gustavo A. R. Silva authored
Fake flexible arrays (zero-length and one-element arrays) are deprecated, and should be replaced by flexible-array members. So, replace zero-length array with a flexible-array member in `struct PACKED_REGISTRY_TABLE`. Also annotate array `entries` with `__counted_by()` to prepare for the coming implementation by GCC and Clang of the `__counted_by` attribute. Flexible array members annotated with `__counted_by` can have their accesses bounds-checked at run-time via `CONFIG_UBSAN_BOUNDS` (for array indexing) and `CONFIG_FORTIFY_SOURCE` (for strcpy/memcpy-family functions). This fixes multiple -Warray-bounds warnings: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1069:29: warning: array subscript 0 is outside array bounds of 'PACKED_REGISTRY_ENTRY[0]' [-Warray-bounds=] drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1070:29: warning: array subscript 0 is outside array bounds of 'PACKED_REGISTRY_ENTRY[0]' [-Warray-bounds=] drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1071:29: warning: array subscript 0 is outside array bounds of 'PACKED_REGISTRY_ENTRY[0]' [-Warray-bounds=] drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1072:29: warning: array subscript 0 is outside array bounds of 'PACKED_REGISTRY_ENTRY[0]' [-Warray-bounds=] While there, also make use of the struct_size() helper, and address checkpatch.pl warning: WARNING: please, no spaces at the start of a line This results in no differences in binary output. Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Dan Carpenter authored
This unlock doesn't belong here and it leads to a double unlock in the caller, r535_gsp_rpc_push(). Fixes: 176fdcbd ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
Dave Airlie authored
With the new uapi we don't have the comp flags on the allocation, so we shouldn't be using the first size that works, we should be iterating until we get the correct one. This reduces allocations from 2MB to 64k in lots of places. Fixes dEQP-VK.memory.allocation.basic.size_8KiB.forward.count_4000 on my ampere/gsp system. Cc: stable@vger.kernel.org # v6.6 Signed-off-by:
Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by:
-
- 28 Nov, 2023 4 commits
-
-
Thomas Hellström authored
"GPL-2.0-only" in the license header was incorrectly changed to the now deprecated "GPL-2.0". Fix. Cc: Maxime Ripard <mripard@kernel.org> Cc: Danilo Krummrich <dakr@redhat.com> Reported-by:
David Edelsohn <dje.gcc@gmail.com> Closes: https://lore.kernel.org/dri-devel/5lfrhdpkwhpgzipgngojs3tyqfqbesifzu5nf4l5q3nhfdhcf2@25nmiq7tfrew/T/#m5c356d68815711eea30dd94cc6f7ea8cd4344fe3 Fixes: f7749a54 ("drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MIT") Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by:
-
Linus Walleij authored
This reverts commit 199cf07e. This patch creates bugs on devices where the DRM device is the ancestor of the panel devices. Attempts to fix this have failed because it leads to using device core functionality which is questionable. Reported-by:
-
Linus Walleij authored
This reverts commit 1d5e8f4b. Greg says: "why exactly is this needed? Nothing outside of the driver core should be needing this function, it shouldn't be public at all (I missed that before.) So please, revert it for now, let's figure out why DRM thinks this is needed for it's devices, and yet no other bus/subsystem does." Link: https://lore.kernel.org/dri-devel/2023112739-willing-sighing-6bdd@gregkh/Signed-off-by:
-
Linus Walleij authored
This reverts commit 39d5b6a6. This patch was causing build errors by using an unexported function from the device core, which Greg questions the saneness in exporting. Link: https://lore.kernel.org/lkml/CACRpkdaGzXD6HbiX7mVUNJAJtMEPG00Pp6+nJ1P0JrfJ-ArMvQ@mail.gmail.com/T/Signed-off-by:
-
- 27 Nov, 2023 2 commits
-
-
Christian König authored
It's valid to add the same fence multiple times to a dma-resv object and we shouldn't need one extra slot for each. Signed-off-by:
-
Liu Ying authored
Export device_is_dependent() since the drm_kms_helper module is starting to use it. Signed-off-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
-
- 24 Nov, 2023 1 commit
-
-
Liu Ying authored
Some panel devices already depend on DRM device, like the panel in arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts, because DRM device is the ancestor of those panel devices. device_link_add() would fail by returning a NULL pointer for those panel devices because of the existing dependency. So, check the dependency by calling device_is_dependent() before adding or deleting device link between panel device and DRM device so that the link is managed only for independent panel devices. Fixes: 88787801 ("drm/bridge: panel: Fix device link for DRM_BRIDGE_ATTACH_NO_CONNECTOR") Fixes: 199cf07e ("drm/bridge: panel: Add a device link between drm device and panel device") Reported-by:
-
- 21 Nov, 2023 1 commit
-
-
Dave Airlie authored
This probably isn't the ideal fix, but we ended up using chids sparsely, and lots of things rely on indexing into the full range, so just allocate the full range up front. The GSP code fixes 8 channels into a userd page, but we end up using a single userd page per channel so end up sparsely using the range. Fixes a few crashes seen with multiple channels. Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/277Signed-off-by:
-
