Re: [PATCH] kernel/resource: optimize find_next_iomem_res
On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote: > We can skip children resources when the parent resource does not cover > the range. > > This should help vmf_insert_* users on x86, such as several DRM drivers. > On my AMD Ryzen 5 7520C, when streaming data from cpu memory into amdgpu > bo, the throughput goes from 5.1GB/s to 6.6GB/s. perf report says > > 34.69%--__do_fault > 34.60%--amdgpu_gem_fault > 34.00%--ttm_bo_vm_fault_reserved > 32.95%--vmf_insert_pfn_prot > 25.89%--track_pfn_insert > 24.35%--lookup_memtype > 21.77%--pat_pagerange_is_ram > 20.80%--walk_system_ram_range > 17.42%--find_next_iomem_res > > before this change, and > > 26.67%--__do_fault > 26.57%--amdgpu_gem_fault > 25.83%--ttm_bo_vm_fault_reserved > 24.40%--vmf_insert_pfn_prot > 14.30%--track_pfn_insert > 12.20%--lookup_memtype > 9.34%--pat_pagerange_is_ram > 8.22%--walk_system_ram_range > 5.09%--find_next_iomem_res > > after. That's great, but why is walk_system_ram_range() being called so often? Shouldn't that be a "set up the device" only type of thing? Why hammer on "lookup_memtype" when you know the memtype, you just did the same thing for the previous frame. This feels like it could be optimized to just "don't call these things" which would make it go faster, right? What am I missing here, why does this always have to be calculated all the time? Resource mapping changes are rare, if at all, over the lifetime of a system uptime. Constantly calculating something that never changes feels odd to me. thanks, greg k-h
[PATCH 5.15 579/690] drm/amdgpu: Use drm_mode_copy()
5.15-stable review patch. If anyone has any objections, please let me know. -- From: Ville Syrjälä [ Upstream commit 426c89aa203bcec9d9cf6eea36735eafa1b1f099 ] struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, ) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(, ) | - memcpy(, E, S) + drm_mode_copy(, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alex Deucher Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Harry Wentland Signed-off-by: Ville Syrjälä Signed-off-by: Alex Deucher Stable-dep-of: 79f3e38f60e5 ("drm/amd/display: Preserve original aspect ratio in create stream") Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 4 ++-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c index c777aff164b76..654f99f4107ea 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c @@ -625,7 +625,7 @@ amdgpu_connector_fixup_lcd_native_mode(struct drm_encoder *encoder, if (mode->type & DRM_MODE_TYPE_PREFERRED) { if (mode->hdisplay != native_mode->hdisplay || mode->vdisplay != native_mode->vdisplay) - memcpy(native_mode, mode, sizeof(*mode)); + drm_mode_copy(native_mode, mode); } } @@ -634,7 +634,7 @@ amdgpu_connector_fixup_lcd_native_mode(struct drm_encoder *encoder, list_for_each_entry_safe(mode, t, >probed_modes, head) { if (mode->hdisplay == native_mode->hdisplay && mode->vdisplay == native_mode->vdisplay) { - *native_mode = *mode; + drm_mode_copy(native_mode, mode); drm_mode_set_crtcinfo(native_mode, CRTC_INTERLACE_HALVE_V); DRM_DEBUG_KMS("Determined LVDS native mode details from EDID\n"); break; diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 7385efe699f88..9356decd14513 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6219,7 +6219,7 @@ get_highest_refresh_rate_mode(struct amdgpu_dm_connector *aconnector, } } - aconnector->freesync_vid_base = *m_pref; + drm_mode_copy(>freesync_vid_base, m_pref); return m_pref; } @@ -6333,8 +6333,8 @@ create_stream_for_sink(struct amdgpu_dm_connector *aconnector, is_freesync_video_mode(, aconnector); if (recalculate_timing) { freesync_mode = get_highest_refresh_rate_mode(aconnector, false); - saved_mode = mode; - mode = *freesync_mode; + drm_mode_copy(_mode, ); + drm_mode_copy(, freesync_mode); } else { decide_crtc_timing_for_drm_display_mode( , preferred_mode, scale); -- 2.43.0
Re: [PATCH 05/28] usb: hcd-pci: Use PCI_IRQ_INTX
On Mon, Mar 25, 2024 at 04:09:16PM +0900, Damien Le Moal wrote: > Use the macro PCI_IRQ_INTX instead of the deprecated PCI_IRQ_LEGACY > macro. > > Signed-off-by: Damien Le Moal Acked-by: Greg Kroah-Hartman
Re: [PATCH 06/28] tty: 8250_pci: Use PCI_IRQ_INTX
On Mon, Mar 25, 2024 at 04:09:17PM +0900, Damien Le Moal wrote: > Use the macro PCI_IRQ_INTX instead of the deprecated PCI_IRQ_LEGACY > macro. > > Signed-off-by: Damien Le Moal Acked-by: Greg Kroah-Hartman
Re: [PATCH 13/28] misc: vmci_guest: Use PCI_IRQ_ALL_TYPES
On Mon, Mar 25, 2024 at 04:09:24PM +0900, Damien Le Moal wrote: > In vmci_guest_probe_device(), remove the reference to PCI_IRQ_LEGACY by > using PCI_IRQ_ALL_TYPES instead of an explicit OR of all IRQ types. > > Signed-off-by: Damien Le Moal > --- Acked-by: Greg Kroah-Hartman
Re: Please apply commit 5b750b22530fe53bf7fd6a30baacd53ada26911b to linux-6.1.y
On Tue, Feb 27, 2024 at 06:45:55PM -0700, Nathan Chancellor wrote: > Hi Greg and Sasha, > > Please apply upstream commit 5b750b22530f ("drm/amd/display: Increase > frame warning limit with KASAN or KCSAN in dml") to linux-6.1.y, as it > is needed to avoid instances of -Wframe-larger-than in allmodconfig, > which has -Werror enabled. It applies cleanly for me and it is already > in 6.6 and 6.7. The fixes tag is not entirely accurate and commit > e63e35f0164c ("drm/amd/display: Increase frame-larger-than for all > display_mode_vba files"), which was recently applied to that tree, > depends on it (I should have made that clearer in the patch). > > If there are any issues, please let me know. Now queued up, thanks. greg k-h
Re: [PATCH 2/3] PCI: introduce can_remove()
On Fri, Feb 02, 2024 at 05:25:55PM -0500, Hamza Mahfooz wrote: > Wire up the can_remove() callback, such that pci drivers can implement > their own version of it. > > Cc: sta...@vger.kernel.org > Signed-off-by: Hamza Mahfooz > --- Again, sorry, nope, not allowed.
Re: [PATCH 3/3] drm/amdgpu: wire up the can_remove() callback
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote: > Removing an amdgpu device that still has user space references allocated > to it causes undefined behaviour. So, implement amdgpu_pci_can_remove() > and disallow devices that still have files allocated to them from being > unbound. > > Cc: sta...@vger.kernel.org > Signed-off-by: Hamza Mahfooz > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index cc69005f5b46..cfa64f3c5be5 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -2323,6 +2323,22 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, > return ret; > } > > +static bool amdgpu_pci_can_remove(struct pci_dev *pdev) > +{ > + struct drm_device *dev = pci_get_drvdata(pdev); > + > + mutex_lock(>filelist_mutex); > + > + if (!list_empty(>filelist)) { > + mutex_unlock(>filelist_mutex); > + return false; > + } > + > + mutex_unlock(>filelist_mutex); > + > + return true; Also, to be pedantic, this will not work as right after you returned "true" here, userspace could open a file, causing the same issue you are trying to prevent to have happen, happen. So even if we wanted to do this, which again, we do not, this isn't even a solution for it because it will still cause you problems. greg k-h
Re: [PATCH 1/3] driver core: bus: introduce can_remove()
On Fri, Feb 02, 2024 at 05:25:54PM -0500, Hamza Mahfooz wrote: > Currently, drivers have no mechanism to block requests to unbind > devices. And that is by design. > However, this can cause resource leaks and leave the device in > an inconsistent state, such that rebinding the device may cause a hang > or otherwise prevent the device from being rebound. That is a driver bug, please fix your driver. > So, introduce the can_remove() callback to allow drivers to indicate > if it isn't appropriate to remove a device at the given time. Nope, sorry, the driver needs to be fixed. What broken driver are you needing this for? Also realize, only root can unbind drivers (and it can also unload modules), so if the root user really wants to do this, it can, and should be possible to. sorry, greg k-h
Re: [PATCH 3/3] drm/amdgpu: wire up the can_remove() callback
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote: > Removing an amdgpu device that still has user space references allocated > to it causes undefined behaviour. Then fix that please. There should not be anything special about your hardware that all of the tens of thousands of other devices can't handle today. What happens when I yank your device out of a system with a pci hotplug bus? You can't prevent that either, so this should not be any different at all. sorry, but please, just fix your driver. greg k-h
Re: [PATCH v2 1/2] usb: typec: ucsi: Use GET_CAPABILITY attributes data to set power supply scope
On Thu, Oct 05, 2023 at 12:52:29PM -0500, Mario Limonciello wrote: > On some OEM systems, adding a W7900 dGPU triggers RAS errors and hangs > at a black screen on startup. This issue occurs only if `ucsi_acpi` has > loaded before `amdgpu` has loaded. The reason for this failure is that > `amdgpu` uses power_supply_is_system_supplied() to determine if running > on AC or DC power at startup. If this value is reported incorrectly the > dGPU will also be programmed incorrectly and trigger errors. > > power_supply_is_system_supplied() reports the wrong value because UCSI > power supplies provided as part of the system don't properly report the > scope as "DEVICE" scope (not powering the system). > > In order to fix this issue check the capabilities reported from the UCSI > power supply to ensure that it supports charging a battery and that it can > be powered by AC. Mark the scope accordingly. > > Fixes: a7fbfd44c020 ("usb: typec: ucsi: Mark dGPUs as DEVICE scope") > Link: > https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb-type-c-ucsi-spec.html > p28 > Signed-off-by: Mario Limonciello > --- > Cc: Kai-Heng Feng > Cc: Alex Deucher > > Cc: Richard Gong > --- > drivers/usb/typec/ucsi/psy.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c > index 384b42267f1f..b35c6e07911e 100644 > --- a/drivers/usb/typec/ucsi/psy.c > +++ b/drivers/usb/typec/ucsi/psy.c > @@ -37,6 +37,15 @@ static int ucsi_psy_get_scope(struct ucsi_connector *con, > struct device *dev = con->ucsi->dev; > > device_property_read_u8(dev, "scope", ); > + if (scope == POWER_SUPPLY_SCOPE_UNKNOWN) { > + u32 mask = UCSI_CAP_ATTR_POWER_AC_SUPPLY | > +UCSI_CAP_ATTR_BATTERY_CHARGING; > + > + if (con->ucsi->cap.attributes & mask) > + scope = POWER_SUPPLY_SCOPE_SYSTEM; > + else > + scope = POWER_SUPPLY_SCOPE_DEVICE; > + } > val->intval = scope; > return 0; > } > -- > 2.34.1 > > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You have marked a patch with a "Fixes:" tag for a commit that is in an older released kernel, yet you do not have a cc: stable line in the signed-off-by area at all, which means that the patch will not be applied to any older kernel releases. To properly fix this, please follow the documented rules in the Documentation/process/stable-kernel-rules.rst file for how to resolve this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [PATCH v2 2/2] Revert "drm/amd/pm: workaround for the wrong ac power detection on smu 13.0.0"
On Thu, Oct 05, 2023 at 12:52:30PM -0500, Mario Limonciello wrote: > This reverts commit 0e5e1a84f0b8c814d502a135824244127fed8f23. > > Reviewed-by: Alex Deucher > Signed-off-by: Mario Limonciello No explaination as to why this needs to be reverted? And does this need to be backported anywhere? thanks, greg k-h
[PATCH 6.1 125/127] drm/amdgpu: Remove unnecessary domain argument
From: Luben Tuikov commit 3273f11675ef11959d25a56df3279f712bcd41b7 upstream Remove the "domain" argument to amdgpu_bo_create_kernel_at() since this function takes an "offset" argument which is the offset off of VRAM, and as such allocation always takes place in VRAM. Thus, the "domain" argument is unnecessary. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|7 --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |1 - 4 files changed, 6 insertions(+), 14 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -347,17 +347,16 @@ int amdgpu_bo_create_kernel(struct amdgp * @adev: amdgpu device object * @offset: offset of the BO * @size: size of the BO - * @domain: where to place it * @bo_ptr: used to initialize BOs in structures * @cpu_addr: optional CPU address mapping * - * Creates a kernel BO at a specific offset in the address space of the domain. + * Creates a kernel BO at a specific offset in VRAM. * * Returns: * 0 on success, negative error code otherwise. */ int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev, - uint64_t offset, uint64_t size, uint32_t domain, + uint64_t offset, uint64_t size, struct amdgpu_bo **bo_ptr, void **cpu_addr) { struct ttm_operation_ctx ctx = { false, false }; @@ -367,8 +366,9 @@ int amdgpu_bo_create_kernel_at(struct am offset &= PAGE_MASK; size = ALIGN(size, PAGE_SIZE); - r = amdgpu_bo_create_reserved(adev, size, PAGE_SIZE, domain, bo_ptr, - NULL, cpu_addr); + r = amdgpu_bo_create_reserved(adev, size, PAGE_SIZE, + AMDGPU_GEM_DOMAIN_VRAM, bo_ptr, NULL, + cpu_addr); if (r) return r; --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h @@ -284,7 +284,7 @@ int amdgpu_bo_create_kernel(struct amdgp u32 domain, struct amdgpu_bo **bo_ptr, u64 *gpu_addr, void **cpu_addr); int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev, - uint64_t offset, uint64_t size, uint32_t domain, + uint64_t offset, uint64_t size, struct amdgpu_bo **bo_ptr, void **cpu_addr); int amdgpu_bo_create_user(struct amdgpu_device *adev, struct amdgpu_bo_param *bp, --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1575,7 +1575,6 @@ static int amdgpu_ttm_fw_reserve_vram_in return amdgpu_bo_create_kernel_at(adev, adev->mman.fw_vram_usage_start_offset, adev->mman.fw_vram_usage_size, - AMDGPU_GEM_DOMAIN_VRAM, >mman.fw_vram_usage_reserved_bo, >mman.fw_vram_usage_va); } @@ -1600,7 +1599,6 @@ static int amdgpu_ttm_drv_reserve_vram_i return amdgpu_bo_create_kernel_at(adev, adev->mman.drv_vram_usage_start_offset, adev->mman.drv_vram_usage_size, - AMDGPU_GEM_DOMAIN_VRAM, >mman.drv_vram_usage_reserved_bo, NULL); } @@ -1681,7 +1679,6 @@ static int amdgpu_ttm_reserve_tmr(struct ret = amdgpu_bo_create_kernel_at(adev, ctx->c2p_train_data_offset, ctx->train_data_size, -AMDGPU_GEM_DOMAIN_VRAM, >c2p_bo, NULL); if (ret) { @@ -1695,7 +1692,6 @@ static int amdgpu_ttm_reserve_tmr(struct ret = amdgpu_bo_create_kernel_at(adev, adev->gmc.real_vram_size - adev->mman.discovery_tmr_size, adev->mman.discovery_tmr_size, - AMDGPU_GEM_DOMAIN_VRAM, >mman.discovery_memory, NULL); if (ret) { @@ -1796,21 +1792,18 @@ int amdgpu_ttm_init(struct amdgpu_device * avoid display artif
[PATCH 6.1 066/228] drm/amd/display: fix dc/core/dc.c kernel-doc
From: Randy Dunlap [ Upstream commit db4107e92a817502ad19fdd30250f87dcb6f6331 ] Fix all kernel-doc warnings in dc/core/dc.c: dc.c:385: warning: missing initial short description on line: * dc_stream_adjust_vmin_vmax: dc.c:392: warning: contents before sections dc.c:399: warning: No description found for return value of 'dc_stream_adjust_vmin_vmax' dc.c:434: warning: Excess function parameter 'adjust' description in 'dc_stream_get_last_used_drr_vtotal' dc.c:434: warning: No description found for return value of 'dc_stream_get_last_used_drr_vtotal' dc.c:574: warning: No description found for return value of 'dc_stream_configure_crc' dc.c:1746: warning: No description found for return value of 'dc_commit_state_no_check' dc.c:4991: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * dc_extended_blank_supported 0 Decide whether extended blank is supported dc.c:4991: warning: missing initial short description on line: * dc_extended_blank_supported 0 Decide whether extended blank is supported dc.c:4723: warning: Function parameter or member 'dc' not described in 'dc_enable_dmub_outbox' dc.c:4926: warning: Function parameter or member 'dc' not described in 'dc_process_dmub_dpia_hpd_int_enable' dc.c:4926: warning: Function parameter or member 'hpd_int_enable' not described in 'dc_process_dmub_dpia_hpd_int_enable' 12 warnings Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: Hamza Mahfooz Cc: Harry Wentland Cc: Leo Li Cc: Christian König Cc: "Pan, Xinhui" Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Stable-dep-of: 2a9482e55968 ("drm/amd/display: Prevent vtotal from being set to 0") Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc.c | 40 +++- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index 85ed1c7cdeaa9..6e2220e2e5ba3 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -382,16 +382,18 @@ static void dc_perf_trace_destroy(struct dc_perf_trace **perf_trace) } /** - * dc_stream_adjust_vmin_vmax: + * dc_stream_adjust_vmin_vmax - look up pipe context & update parts of DRR + * @dc: dc reference + * @stream: Initial dc stream state + * @adjust: Updated parameters for vertical_total_min and vertical_total_max * * Looks up the pipe context of dc_stream_state and updates the * vertical_total_min and vertical_total_max of the DRR, Dynamic Refresh * Rate, which is a power-saving feature that targets reducing panel * refresh rate while the screen is static * - * @dc: dc reference - * @stream: Initial dc stream state - * @adjust: Updated parameters for vertical_total_min and vertical_total_max + * Return: %true if the pipe context is found and adjusted; + * %false if the pipe context is not found. */ bool dc_stream_adjust_vmin_vmax(struct dc *dc, struct dc_stream_state *stream, @@ -427,14 +429,17 @@ bool dc_stream_adjust_vmin_vmax(struct dc *dc, } /** - * dc_stream_get_last_used_drr_vtotal - dc_stream_get_last_vrr_vtotal + * dc_stream_get_last_used_drr_vtotal - Looks up the pipe context of + * dc_stream_state and gets the last VTOTAL used by DRR (Dynamic Refresh Rate) * * @dc: [in] dc reference * @stream: [in] Initial dc stream state - * @adjust: [in] Updated parameters for vertical_total_min and + * @refresh_rate: [in] new refresh_rate * - * Looks up the pipe context of dc_stream_state and gets the last VTOTAL used - * by DRR (Dynamic Refresh Rate) + * Return: %true if the pipe context is found and there is an associated + * timing_generator for the DC; + * %false if the pipe context is not found or there is no + * timing_generator for the DC. */ bool dc_stream_get_last_used_drr_vtotal(struct dc *dc, struct dc_stream_state *stream, @@ -581,7 +586,10 @@ bool dc_stream_stop_dmcu_crc_win_update(struct dc *dc, struct dc_stream_state *s * once. * * By default, only CRC0 is configured, and the entire frame is used to - * calculate the crc. + * calculate the CRC. + * + * Return: %false if the stream is not found or CRC capture is not supported; + * %true if the stream has been configured. */ bool dc_stream_configure_crc(struct dc *dc, struct dc_stream_state *stream, struct crc_params *crc_window, bool enable, bool continuous) @@ -650,7 +658,7 @@ bool dc_stream_configure_crc(struct dc *dc, struct dc_stream_state *stream, * dc_stream_configure_crc needs to be called beforehand to enable CRCs. * * Return: - * false if stream is not found, or if CRCs are not enabled. + * %false if stream is not found, or if CRCs are not enabled. */ bool dc_stream_get_crc(struct
[PATCH 6.1 069/223] drm/client: Send hotplug event after registering a client
file in 6.1.y because these commits haven't happened in 6.1.y. 8ab59da26bc0 drm/fb-helper: Move generic fbdev emulation into separate source file b9c93f4ec737 drm/fbdev-generic: Rename symbols ] Cc: alexandru.gagn...@hp.com Link: https://lore.kernel.org/stable/sj0pr84mb20882eea1abb36f60e845e378f...@sj0pr84mb2088.namprd84.prod.outlook.com/ Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_client.c| 21 + drivers/gpu/drm/drm_fb_helper.c |4 2 files changed, 21 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -122,13 +122,34 @@ EXPORT_SYMBOL(drm_client_init); * drm_client_register() it is no longer permissible to call drm_client_release() * directly (outside the unregister callback), instead cleanup will happen * automatically on driver unload. + * + * Registering a client generates a hotplug event that allows the client + * to set up its display from pre-existing outputs. The client must have + * initialized its state to able to handle the hotplug event successfully. */ void drm_client_register(struct drm_client_dev *client) { struct drm_device *dev = client->dev; + int ret; mutex_lock(>clientlist_mutex); list_add(>list, >clientlist); + + if (client->funcs && client->funcs->hotplug) { + /* +* Perform an initial hotplug event to pick up the +* display configuration for the client. This step +* has to be performed *after* registering the client +* in the list of clients, or a concurrent hotplug +* event might be lost; leaving the display off. +* +* Hold the clientlist_mutex as for a regular hotplug +* event. +*/ + ret = client->funcs->hotplug(client); + if (ret) + drm_dbg_kms(dev, "client hotplug ret=%d\n", ret); + } mutex_unlock(>clientlist_mutex); } EXPORT_SYMBOL(drm_client_register); --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2634,10 +2634,6 @@ void drm_fbdev_generic_setup(struct drm_ preferred_bpp = 32; fb_helper->preferred_bpp = preferred_bpp; - ret = drm_fbdev_client_hotplug(_helper->client); - if (ret) - drm_dbg_kms(dev, "client hotplug ret=%d\n", ret); - drm_client_register(_helper->client); } EXPORT_SYMBOL(drm_fbdev_generic_setup);
[PATCH 6.4 111/292] drm/client: Send hotplug event after registering a client
From: Thomas Zimmermann commit 27655b9bb9f0d9c32b8de8bec649b676898c52d5 upstream. Generate a hotplug event after registering a client to allow the client to configure its display. Remove the hotplug calls from the existing clients for fbdev emulation. This change fixes a concurrency bug between registering a client and receiving events from the DRM core. The bug is present in the fbdev emulation of all drivers. The fbdev emulation currently generates a hotplug event before registering the client to the device. For each new output, the DRM core sends an additional hotplug event to each registered client. If the DRM core detects first output between sending the artificial hotplug and registering the device, the output's hotplug event gets lost. If this is the first output, the fbdev console display remains dark. This has been observed with amdgpu and fbdev-generic. Fix this by adding hotplug generation directly to the client's register helper drm_client_register(). Registering the client and receiving events are serialized by struct drm_device.clientlist_mutex. So an output is either configured by the initial hotplug event, or the client has already been registered. The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is done"), in which adding a client and receiving a hotplug event switched order. It was hidden, as most hardware and drivers have at least on static output configured. Other drivers didn't use the internal DRM client or still had struct drm_mode_config_funcs.output_poll_changed set. That callback handled hotplug events as well. After not setting the callback in amdgpu in commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct drm_driver.output_poll_changed"), amdgpu did not show a framebuffer console if output events got lost. The bug got copy-pasted from fbdev-generic into the other fbdev emulation. Reported-by: Moritz Duge Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649 Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is done") Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate source file") Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA helpers") Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel client") Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel client") Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation") Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client") Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel client") Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation") Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client") Fixes: 0e3172bac3f4 ("drm/amdgpu: Don't set struct drm_driver.output_poll_changed") Signed-off-by: Thomas Zimmermann Tested-by: Moritz Duge Tested-by: Torsten Krah Tested-by: Paul Schyska Cc: Daniel Vetter Cc: David Airlie Cc: Noralf Trønnes Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Javier Martinez Canillas Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Krzysztof Kozlowski Cc: Patrik Jakobsson Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Tomi Valkeinen Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: Thierry Reding Cc: Mikko Perttunen Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-te...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: # v5.2+ Reviewed-by: Javier Martinez Canillas Reviewed-by: Dmitry Baryshkov # msm Link: https://patchwork.freedesktop.org/patch/msgid/20230710091029.27503-1-tzimmerm...@suse.de [ Dropped changes to drivers/gpu/drm/armada/armada_fbdev.c as 174c3c38e3a2 drm/armada: Initialize fbdev DRM client was introduced in 6.5-rc1 ] Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_client.c | 21 + drivers/gpu/drm/drm_fbdev_dma.c |4 drivers/gpu/drm/drm_fbdev_generic.c |4 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 drivers/gpu/drm/gma500/fbdev.c|4 drivers/gpu/drm/msm/msm_fbdev.c |4 drivers/gpu/drm/omapdrm/omap_fbdev.c |4 drivers/gpu/drm/radeon/radeon_fbdev.c |4 drivers/gpu/drm/tegra/fbdev.c |4 9 files changed, 21 insertions(+), 32 deletions(-) --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -122,13 +122,34 @@ EXPORT_SYMBOL(drm_cli
Re: [PATCH v4 12/18] staging: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
On Sat, Jul 15, 2023 at 08:51:54PM +0200, Thomas Zimmermann wrote: > The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct > fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do > not set it. > > Flags should signal differences from the default values. After cleaning > up all occurrences of FBINFO_DEFAULT, the token will be removed. > > v2: > * fix commit message (Miguel) > > Signed-off-by: Thomas Zimmermann > Acked-by: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Sudip Mukherjee > Cc: Teddy Wang Acked-by: Greg Kroah-Hartman
Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)
On Fri, May 12, 2023 at 03:25:47PM +, Christophe Leroy wrote: > > > Le 12/05/2023 à 17:16, Christophe Leroy a écrit : > > > > > > Le 11/05/2023 à 19:25, Niccolò Belli a écrit : > >> [Vous ne recevez pas souvent de courriers de > >> darkba...@linuxsystems.it. D?couvrez pourquoi ceci est important ? > >> https://aka.ms/LearnAboutSenderIdentification ] > >> > >> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto: > >>> #regzbot introduced: f4f3b7dedbe849 > >>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553 > >> > >> It doesn't look like the aforementioned patch made its way into 6.3 yet: > >> > >> niko@talos2 ~/devel/linux-stable $ git branch > >> * linux-6.3.y > >> master > >> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1 > >> patching file > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > >> Hunk #1 succeeded at 227 (offset 15 lines). > >> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines). > >> patching file > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h > >> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines). > > > > As far as I can see that patch has no Fixes: tag, so it will unlikely be > > automatically merged into stable. > > > > Has anybody requested greg/sasha to get it into 6.3 ? > > > > In fact, it seems that patch is already part of 6.3: > > $ git tag --contains f4f3b7dedbe8 > v6.3 > v6.3-rc5 > v6.3-rc6 > v6.3-rc7 > v6.3.1 > v6.3.2 > v6.4-rc1 And that commit is already in the following releases: 5.10.177 5.15.106 6.1.23 6.2.10 6.3 So what needs to be done here? confused, greg k-h
[PATCH 5.15 114/371] drm/amd/display/dc/dce60/Makefile: Fix previous attempt to silence known override-init warnings
From: Lee Jones [ Upstream commit 4082b9f5ead4966797dddcfef0905d59e5a83873 ] Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:188:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC2_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:189:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: note: (near initialization for ‘xfm_regs[2].DCFE_MEM_LIGHT_SLEEP_CN [100 lines snipped for brevity] Fixes: ceb3cf476a441 ("drm/amd/display/dc/dce60/Makefile: Ignore -Woverride-init warning") Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Mauro Rossi Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile b/drivers/gpu/drm/amd/display/dc/dce60/Makefile index dda596fa1cd76..fee331accc0e7 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile @@ -23,7 +23,7 @@ # Makefile for the 'controller' sub-component of DAL. # It provides the control and status of HW CRTC block. -CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) +CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \ dce60_resource.o -- 2.39.2
[PATCH 6.3 222/694] drm/amd/display/dc/dce60/Makefile: Fix previous attempt to silence known override-init warnings
From: Lee Jones [ Upstream commit 4082b9f5ead4966797dddcfef0905d59e5a83873 ] Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:188:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC2_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:189:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: note: (near initialization for ‘xfm_regs[2].DCFE_MEM_LIGHT_SLEEP_CN [100 lines snipped for brevity] Fixes: ceb3cf476a441 ("drm/amd/display/dc/dce60/Makefile: Ignore -Woverride-init warning") Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Mauro Rossi Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile b/drivers/gpu/drm/amd/display/dc/dce60/Makefile index dda596fa1cd76..fee331accc0e7 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile @@ -23,7 +23,7 @@ # Makefile for the 'controller' sub-component of DAL. # It provides the control and status of HW CRTC block. -CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) +CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \ dce60_resource.o -- 2.39.2
[PATCH 6.1 184/611] drm/amd/display/dc/dce60/Makefile: Fix previous attempt to silence known override-init warnings
From: Lee Jones [ Upstream commit 4082b9f5ead4966797dddcfef0905d59e5a83873 ] Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:188:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC2_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:189:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: note: (near initialization for ‘xfm_regs[2].DCFE_MEM_LIGHT_SLEEP_CN [100 lines snipped for brevity] Fixes: ceb3cf476a441 ("drm/amd/display/dc/dce60/Makefile: Ignore -Woverride-init warning") Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Mauro Rossi Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile b/drivers/gpu/drm/amd/display/dc/dce60/Makefile index dda596fa1cd76..fee331accc0e7 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile @@ -23,7 +23,7 @@ # Makefile for the 'controller' sub-component of DAL. # It provides the control and status of HW CRTC block. -CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) +CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \ dce60_resource.o -- 2.39.2
[PATCH 6.1 609/611] drm/amd/display (gcc13): fix enum mismatch
From: Jiri Slaby (SUSE) commit 545094d993f4639482018becda5f2a47d126f0ab upstream. rn_vbios_smu_set_dcn_low_power_state() produces a valid warning with gcc-13: drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c:237:6: error: conflicting types for 'rn_vbios_smu_set_dcn_low_power_state' due to enum/integer mismatch; have 'void(struct clk_mgr_internal *, enum dcn_pwr_state)' drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.h:36:6: note: previous declaration of 'rn_vbios_smu_set_dcn_low_power_state' with type 'void(struct clk_mgr_internal *, int)' I.e. the type of the 2nd parameter of rn_vbios_smu_set_dcn_low_power_state() in the declaration is int, while the definition spells enum dcn_pwr_state. Synchronize them to the latter (and add a forward enum declaration). Cc: Martin Liska Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Reviewed-by: Harry Wentland Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.h |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.h +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.h @@ -26,6 +26,8 @@ #ifndef DAL_DC_RN_CLK_MGR_VBIOS_SMU_H_ #define DAL_DC_RN_CLK_MGR_VBIOS_SMU_H_ +enum dcn_pwr_state; + int rn_vbios_smu_get_smu_version(struct clk_mgr_internal *clk_mgr); int rn_vbios_smu_set_dispclk(struct clk_mgr_internal *clk_mgr, int requested_dispclk_khz); int rn_vbios_smu_set_dprefclk(struct clk_mgr_internal *clk_mgr); @@ -33,7 +35,7 @@ int rn_vbios_smu_set_hard_min_dcfclk(str int rn_vbios_smu_set_min_deep_sleep_dcfclk(struct clk_mgr_internal *clk_mgr, int requested_min_ds_dcfclk_khz); void rn_vbios_smu_set_phyclk(struct clk_mgr_internal *clk_mgr, int requested_phyclk_khz); int rn_vbios_smu_set_dppclk(struct clk_mgr_internal *clk_mgr, int requested_dpp_khz); -void rn_vbios_smu_set_dcn_low_power_state(struct clk_mgr_internal *clk_mgr, int display_count); +void rn_vbios_smu_set_dcn_low_power_state(struct clk_mgr_internal *clk_mgr, enum dcn_pwr_state); void rn_vbios_smu_enable_48mhz_tmdp_refclk_pwrdwn(struct clk_mgr_internal *clk_mgr, bool enable); void rn_vbios_smu_enable_pme_wa(struct clk_mgr_internal *clk_mgr); int rn_vbios_smu_is_periodic_retraining_disabled(struct clk_mgr_internal *clk_mgr);
[PATCH 6.2 190/663] drm/amd/display/dc/dce60/Makefile: Fix previous attempt to silence known override-init warnings
From: Lee Jones [ Upstream commit 4082b9f5ead4966797dddcfef0905d59e5a83873 ] Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC1_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:188:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:157:21: note: in expansion of macro ‘mmCRTC2_DCFE_MEM_LIGHT_SLEEP_CNTL’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.h:170:9: note: in expansion of macro ‘SRI’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:183:17: note: in expansion of macro ‘XFM_COMMON_REG_LIST_DCE60’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:189:17: note: in expansion of macro ‘transform_regs’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:722:43: note: (near initialization for ‘xfm_regs[2].DCFE_MEM_LIGHT_SLEEP_CN [100 lines snipped for brevity] Fixes: ceb3cf476a441 ("drm/amd/display/dc/dce60/Makefile: Ignore -Woverride-init warning") Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Mauro Rossi Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile b/drivers/gpu/drm/amd/display/dc/dce60/Makefile index dda596fa1cd76..fee331accc0e7 100644 --- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile @@ -23,7 +23,7 @@ # Makefile for the 'controller' sub-component of DAL. # It provides the control and status of HW CRTC block. -CFLAGS_AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) +CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init) DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \ dce60_resource.o -- 2.39.2
Re: [PATCH 1/7] mm/gup: remove unused vmas parameter from get_user_pages()
On Sat, Apr 15, 2023 at 12:27:13AM +0100, Lorenzo Stoakes wrote: > No invocation of get_user_pages() uses the vmas parameter, so remove > it. > > The GUP API is confusing and caveated. Recent changes have done much to > improve that, however there is more we can do. Exporting vmas is a prime > target as the caller has to be extremely careful to preclude their use > after the mmap_lock has expired or otherwise be left with dangling > pointers. > > Removing the vmas parameter focuses the GUP functions upon their primary > purpose - pinning (and outputting) pages as well as performing the actions > implied by the input flags. > > This is part of a patch series aiming to remove the vmas parameter > altogether. > > Signed-off-by: Lorenzo Stoakes > Suggested-by: Matthew Wilcox (Oracle) Acked-by: Greg Kroah-Hartman
[PATCH 6.2 015/141] drm/display: Dont block HDR_OUTPUT_METADATA on unknown EOTF
From: Harry Wentland commit e5eef23e267c72521d81f23f7f82d1f523d4a253 upstream. The EDID of an HDR display defines EOTFs that are supported by the display and can be set in the HDR metadata infoframe. Userspace is expected to read the EDID and set an appropriate HDR_OUTPUT_METADATA. In drm_parse_hdr_metadata_block the kernel reads the supported EOTFs from the EDID and stores them in the drm_connector->hdr_sink_metadata. While doing so it also filters the EOTFs to the EOTFs the kernel knows about. When an HDR_OUTPUT_METADATA is set it then checks to make sure the EOTF is a supported EOTF. In cases where the kernel doesn't know about a new EOTF this check will fail, even if the EDID advertises support. Since it is expected that userspace reads the EDID to understand what the display supports it doesn't make sense for DRM to block an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't understand. This comes with the added benefit of future-proofing metadata support. If the spec defines a new EOTF there is no need to update DRM and an compositor can immediately make use of it. Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/609 v2: Distinguish EOTFs defind in kernel and ones defined in EDID in the commit description (Pekka) v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved to drm_hdmi_helper.c Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Acked-by: Pekka Paalanen Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-2-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/display/drm_hdmi_helper.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/display/drm_hdmi_helper.c +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c @@ -44,10 +44,8 @@ int drm_hdmi_infoframe_set_hdr_metadata( /* Sink EOTF is Bit map while infoframe is absolute values */ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf, - connector->hdr_sink_metadata.hdmi_type1.eotf)) { - DRM_DEBUG_KMS("EOTF Not Supported\n"); - return -EINVAL; - } + connector->hdr_sink_metadata.hdmi_type1.eotf)) + DRM_DEBUG_KMS("Unknown EOTF %d\n", hdr_metadata->hdmi_metadata_type1.eotf); err = hdmi_drm_infoframe_init(frame); if (err < 0)
[PATCH 6.2 016/141] drm/connector: print max_requested_bpc in state debugfs
From: Harry Wentland commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream. This is useful to understand the bpc defaults and support of a driver. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_atomic.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1070,6 +1070,7 @@ static void drm_atomic_connector_print_s drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); + drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb)
[PATCH 6.1 013/143] drm/display: Dont block HDR_OUTPUT_METADATA on unknown EOTF
From: Harry Wentland commit e5eef23e267c72521d81f23f7f82d1f523d4a253 upstream. The EDID of an HDR display defines EOTFs that are supported by the display and can be set in the HDR metadata infoframe. Userspace is expected to read the EDID and set an appropriate HDR_OUTPUT_METADATA. In drm_parse_hdr_metadata_block the kernel reads the supported EOTFs from the EDID and stores them in the drm_connector->hdr_sink_metadata. While doing so it also filters the EOTFs to the EOTFs the kernel knows about. When an HDR_OUTPUT_METADATA is set it then checks to make sure the EOTF is a supported EOTF. In cases where the kernel doesn't know about a new EOTF this check will fail, even if the EDID advertises support. Since it is expected that userspace reads the EDID to understand what the display supports it doesn't make sense for DRM to block an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't understand. This comes with the added benefit of future-proofing metadata support. If the spec defines a new EOTF there is no need to update DRM and an compositor can immediately make use of it. Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/609 v2: Distinguish EOTFs defind in kernel and ones defined in EDID in the commit description (Pekka) v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved to drm_hdmi_helper.c Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Acked-by: Pekka Paalanen Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-2-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/display/drm_hdmi_helper.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/display/drm_hdmi_helper.c +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c @@ -44,10 +44,8 @@ int drm_hdmi_infoframe_set_hdr_metadata( /* Sink EOTF is Bit map while infoframe is absolute values */ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf, - connector->hdr_sink_metadata.hdmi_type1.eotf)) { - DRM_DEBUG_KMS("EOTF Not Supported\n"); - return -EINVAL; - } + connector->hdr_sink_metadata.hdmi_type1.eotf)) + DRM_DEBUG_KMS("Unknown EOTF %d\n", hdr_metadata->hdmi_metadata_type1.eotf); err = hdmi_drm_infoframe_init(frame); if (err < 0)
[PATCH 5.4 03/68] drm/connector: print max_requested_bpc in state debugfs
From: Harry Wentland commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream. This is useful to understand the bpc defaults and support of a driver. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_atomic.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1006,6 +1006,7 @@ static void drm_atomic_connector_print_s drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); + drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb)
[PATCH 5.15 007/145] drm/connector: print max_requested_bpc in state debugfs
From: Harry Wentland commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream. This is useful to understand the bpc defaults and support of a driver. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_atomic.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1052,6 +1052,7 @@ static void drm_atomic_connector_print_s drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); + drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb)
[PATCH 6.1 014/143] drm/connector: print max_requested_bpc in state debugfs
From: Harry Wentland commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream. This is useful to understand the bpc defaults and support of a driver. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_atomic.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1070,6 +1070,7 @@ static void drm_atomic_connector_print_s drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); + drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb)
[PATCH 5.10 005/104] drm/connector: print max_requested_bpc in state debugfs
From: Harry Wentland commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream. This is useful to understand the bpc defaults and support of a driver. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-By: Joshua Ashton Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentl...@amd.com Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_atomic.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1010,6 +1010,7 @@ static void drm_atomic_connector_print_s drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); + drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb)
[PATCH 6.1 138/183] drm/amdgpu: Fix potential NULL dereference
From: Luben Tuikov [ Upstream commit 0be7ed8e7eb15282b5d0f6fdfea884db594ea9bf ] Fix potential NULL dereference, in the case when "man", the resource manager might be NULL, when/if we print debug information. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Cc: Dan Carpenter Cc: kernel test robot Fixes: 7554886daa31ea ("drm/amdgpu: Fix size validation for non-exclusive domains (v4)") Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 3be3cba3a16d..cfd78c4a45ba 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -468,8 +468,9 @@ static bool amdgpu_bo_validate_size(struct amdgpu_device *adev, return true; fail: - DRM_DEBUG("BO size %lu > total memory in domain: %llu\n", size, - man->size); + if (man) + DRM_DEBUG("BO size %lu > total memory in domain: %llu\n", size, + man->size); return false; } -- 2.35.1
Re: [PATCH 6.0 108/148] drm/amdgpu: Fix size validation for non-exclusive domains (v4)
On Thu, Jan 12, 2023 at 11:59:06AM -0500, Luben Tuikov wrote: > On 2023-01-12 11:49, Greg Kroah-Hartman wrote: > > On Thu, Jan 12, 2023 at 11:25:08AM -0500, Luben Tuikov wrote: > >> Hi Greg, > >> > >> The patch in the link is a Fixes patch of the quoted patch, and should > >> also go in: > >> > >> https://lore.kernel.org/all/20230104221935.113400-1-luben.tui...@amd.com/ > > > > Is that in Linus's tree already? if so, what is the git commit id? > > I just checked, and not yet. Just wanted to give a heads up. > > It does have a Fixes tag, and I hope it would be picked up automatically, > when it lands in Linus' tree. That does not always happen if it does not have a "cc: stable@..." tag. So when it does land in Linus's tree, please let us know the id so we are sure to pick it up. thanks, greg k-h
Re: [PATCH 6.0 108/148] drm/amdgpu: Fix size validation for non-exclusive domains (v4)
On Thu, Jan 12, 2023 at 11:25:08AM -0500, Luben Tuikov wrote: > Hi Greg, > > The patch in the link is a Fixes patch of the quoted patch, and should also > go in: > > https://lore.kernel.org/all/20230104221935.113400-1-luben.tui...@amd.com/ Is that in Linus's tree already? if so, what is the git commit id? thanks, greg k-h
[PATCH 6.0 108/148] drm/amdgpu: Fix size validation for non-exclusive domains (v4)
From: Luben Tuikov [ Upstream commit 7554886daa31eacc8e7fac9e15bbce67d10b8f1f ] Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the requested memory exists, else we get a kernel oops when dereferencing "man". v2: Make the patch standalone, i.e. not dependent on local patches. v3: Preserve old behaviour and just check that the manager pointer is not NULL. v4: Complain if GTT domain requested and it is uninitialized--most likely a bug. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index bfe0fc258fc1..60ab2d952d5c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -446,27 +446,24 @@ static bool amdgpu_bo_validate_size(struct amdgpu_device *adev, /* * If GTT is part of requested domains the check must succeed to -* allow fall back to GTT +* allow fall back to GTT. */ if (domain & AMDGPU_GEM_DOMAIN_GTT) { man = ttm_manager_type(>mman.bdev, TTM_PL_TT); - if (size < man->size) + if (man && size < man->size) return true; - else - goto fail; - } - - if (domain & AMDGPU_GEM_DOMAIN_VRAM) { + else if (!man) + WARN_ON_ONCE("GTT domain requested but GTT mem manager uninitialized"); + goto fail; + } else if (domain & AMDGPU_GEM_DOMAIN_VRAM) { man = ttm_manager_type(>mman.bdev, TTM_PL_VRAM); - if (size < man->size) + if (man && size < man->size) return true; - else - goto fail; + goto fail; } - /* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU */ return true; -- 2.35.1
[PATCH 6.1 113/159] drm/amdgpu: Fix size validation for non-exclusive domains (v4)
From: Luben Tuikov [ Upstream commit 7554886daa31eacc8e7fac9e15bbce67d10b8f1f ] Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the requested memory exists, else we get a kernel oops when dereferencing "man". v2: Make the patch standalone, i.e. not dependent on local patches. v3: Preserve old behaviour and just check that the manager pointer is not NULL. v4: Complain if GTT domain requested and it is uninitialized--most likely a bug. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 3df13d841e4d..3be3cba3a16d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -446,27 +446,24 @@ static bool amdgpu_bo_validate_size(struct amdgpu_device *adev, /* * If GTT is part of requested domains the check must succeed to -* allow fall back to GTT +* allow fall back to GTT. */ if (domain & AMDGPU_GEM_DOMAIN_GTT) { man = ttm_manager_type(>mman.bdev, TTM_PL_TT); - if (size < man->size) + if (man && size < man->size) return true; - else - goto fail; - } - - if (domain & AMDGPU_GEM_DOMAIN_VRAM) { + else if (!man) + WARN_ON_ONCE("GTT domain requested but GTT mem manager uninitialized"); + goto fail; + } else if (domain & AMDGPU_GEM_DOMAIN_VRAM) { man = ttm_manager_type(>mman.bdev, TTM_PL_VRAM); - if (size < man->size) + if (man && size < man->size) return true; - else - goto fail; + goto fail; } - /* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU */ return true; -- 2.35.1
Re: Fwd: amdgpu: update from 5.10.145 to 5.10.146...149 breaks boot on Ryzen based computers
On Sun, Oct 23, 2022 at 10:23:53AM -0700, Linus Torvalds wrote: > This was sent to me, but should have gone to other people. > > It may already be fixed, but note how the report is about -stable > kernels, including apparently the current 5.10 stable version (149(. > > Linus > > -- Forwarded message - > From: Kevin Torkelson > Date: Thu, Oct 20, 2022 at 8:09 AM > Subject: amdgpu: update from 5.10.145 to 5.10.146...149 breaks boot on > Ryzen based computers > To: > > > Linus, > > --- Possibly Important --- > I know several people who are crashing with Debian Bullseye (stable) > with the most current kernel put out by the distribution. AMD put out > a fix that seems like it might be related here: > https://gitlab.freedesktop.org/drm/amd/-/issues/2216 We have fixes queued up for this in the stable tree for 5.10 already, thanks. greg k-h
[PATCH 5.15 038/121] drm/amd/display: fix memory leak when using debugfs_lookup()
From: Greg Kroah-Hartman commit cbfac7fa491651c57926c99edeb7495c6c1aeac2 upstream. When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Wayne Lin Cc: hersen wu Cc: Wenjing Liu Cc: Patrik Jakobsson Cc: Thelford Williams Cc: Fangzhi Zuo Cc: Yongzhi Liu Cc: Mikita Lipski Cc: Jiapeng Chong Cc: Bhanuprakash Modem Cc: Sean Paul Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: sta...@vger.kernel.org Reviewed-by: Rodrigo Siqueira Signed-off-by: Greg Kroah-Hartman Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -3007,7 +3007,7 @@ void crtc_debugfs_init(struct drm_crtc * _win_y_end_fops); debugfs_create_file_unsafe("crc_win_update", 0644, dir, crtc, _win_update_fops); - + dput(dir); } #endif /*
[PATCH 5.19 052/192] drm/amd/display: fix memory leak when using debugfs_lookup()
From: Greg Kroah-Hartman commit cbfac7fa491651c57926c99edeb7495c6c1aeac2 upstream. When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Wayne Lin Cc: hersen wu Cc: Wenjing Liu Cc: Patrik Jakobsson Cc: Thelford Williams Cc: Fangzhi Zuo Cc: Yongzhi Liu Cc: Mikita Lipski Cc: Jiapeng Chong Cc: Bhanuprakash Modem Cc: Sean Paul Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: sta...@vger.kernel.org Reviewed-by: Rodrigo Siqueira Signed-off-by: Greg Kroah-Hartman Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -3188,7 +3188,7 @@ void crtc_debugfs_init(struct drm_crtc * _win_y_end_fops); debugfs_create_file_unsafe("crc_win_update", 0644, dir, crtc, _win_update_fops); - + dput(dir); } #endif /*
Re: [PATCH] drm/amd/display: fix memory leak when using debugfs_lookup()
On Tue, Sep 06, 2022 at 11:39:44AM -0400, Rodrigo Siqueira Jordao wrote: > > > On 2022-09-06 11:06, Greg Kroah-Hartman wrote: > > On Tue, Sep 06, 2022 at 10:52:28AM -0400, Rodrigo Siqueira Jordao wrote: > > > > > > > > > On 2022-09-02 09:10, Greg Kroah-Hartman wrote: > > > > On Fri, Sep 02, 2022 at 03:01:05PM +0200, Greg Kroah-Hartman wrote: > > > > > When calling debugfs_lookup() the result must have dput() called on > > > > > it, > > > > > otherwise the memory will leak over time. Fix this up by properly > > > > > calling dput(). > > > > > > > > > > Cc: Harry Wentland > > > > > Cc: Leo Li > > > > > Cc: Rodrigo Siqueira > > > > > Cc: Alex Deucher > > > > > Cc: "Christian König" > > > > > Cc: "Pan, Xinhui" > > > > > Cc: David Airlie > > > > > Cc: Daniel Vetter > > > > > Cc: Wayne Lin > > > > > Cc: hersen wu > > > > > Cc: Wenjing Liu > > > > > Cc: Patrik Jakobsson > > > > > Cc: Thelford Williams > > > > > Cc: Fangzhi Zuo > > > > > Cc: Yongzhi Liu > > > > > Cc: Mikita Lipski > > > > > Cc: Jiapeng Chong > > > > > Cc: Bhanuprakash Modem > > > > > Cc: Sean Paul > > > > > Cc: amd-gfx@lists.freedesktop.org > > > > > Cc: dri-de...@lists.freedesktop.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > --- > > > > > > > > Despite a zillion cc: items, I forgot to cc: stable on this. Can the > > > > maintainer add that here, or do you all want me to resend it with that > > > > item added? > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Hi Greg, > > > > > > Reviewed-by: Rodrigo Siqueira > > > > > > Is 'Cc: sta...@vger.kernel.org' enough here? I can make this change > > > before I > > > merge it into amd-staging-drm-next. > > > > Yes, please add the cc: stable@ line to the body of the patch, sorry I > > forgot that. > > > > Change applied to amd-staging-drm-next, with the Cc to the stable branch. Wonderful, thanks!
Re: [PATCH] drm/amd/display: fix memory leak when using debugfs_lookup()
On Tue, Sep 06, 2022 at 10:52:28AM -0400, Rodrigo Siqueira Jordao wrote: > > > On 2022-09-02 09:10, Greg Kroah-Hartman wrote: > > On Fri, Sep 02, 2022 at 03:01:05PM +0200, Greg Kroah-Hartman wrote: > > > When calling debugfs_lookup() the result must have dput() called on it, > > > otherwise the memory will leak over time. Fix this up by properly > > > calling dput(). > > > > > > Cc: Harry Wentland > > > Cc: Leo Li > > > Cc: Rodrigo Siqueira > > > Cc: Alex Deucher > > > Cc: "Christian König" > > > Cc: "Pan, Xinhui" > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Cc: Wayne Lin > > > Cc: hersen wu > > > Cc: Wenjing Liu > > > Cc: Patrik Jakobsson > > > Cc: Thelford Williams > > > Cc: Fangzhi Zuo > > > Cc: Yongzhi Liu > > > Cc: Mikita Lipski > > > Cc: Jiapeng Chong > > > Cc: Bhanuprakash Modem > > > Cc: Sean Paul > > > Cc: amd-gfx@lists.freedesktop.org > > > Cc: dri-de...@lists.freedesktop.org > > > Signed-off-by: Greg Kroah-Hartman > > > --- > > > > Despite a zillion cc: items, I forgot to cc: stable on this. Can the > > maintainer add that here, or do you all want me to resend it with that > > item added? > > > > thanks, > > > > greg k-h > > Hi Greg, > > Reviewed-by: Rodrigo Siqueira > > Is 'Cc: sta...@vger.kernel.org' enough here? I can make this change before I > merge it into amd-staging-drm-next. Yes, please add the cc: stable@ line to the body of the patch, sorry I forgot that. thanks, greg k-h
[PATCH] drm/amd/display: fix memory leak when using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Wayne Lin Cc: hersen wu Cc: Wenjing Liu Cc: Patrik Jakobsson Cc: Thelford Williams Cc: Fangzhi Zuo Cc: Yongzhi Liu Cc: Mikita Lipski Cc: Jiapeng Chong Cc: Bhanuprakash Modem Cc: Sean Paul Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c index 0e48824f55e3..ee242d9d8b06 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -3288,6 +3288,7 @@ void crtc_debugfs_init(struct drm_crtc *crtc) _win_y_end_fops); debugfs_create_file_unsafe("crc_win_update", 0644, dir, crtc, _win_update_fops); + dput(dir); #endif debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry, crtc, _current_bpc_fops); -- 2.37.3
Re: [PATCH] drm/amd/display: fix memory leak when using debugfs_lookup()
On Fri, Sep 02, 2022 at 03:01:05PM +0200, Greg Kroah-Hartman wrote: > When calling debugfs_lookup() the result must have dput() called on it, > otherwise the memory will leak over time. Fix this up by properly > calling dput(). > > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Wayne Lin > Cc: hersen wu > Cc: Wenjing Liu > Cc: Patrik Jakobsson > Cc: Thelford Williams > Cc: Fangzhi Zuo > Cc: Yongzhi Liu > Cc: Mikita Lipski > Cc: Jiapeng Chong > Cc: Bhanuprakash Modem > Cc: Sean Paul > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Greg Kroah-Hartman > --- Despite a zillion cc: items, I forgot to cc: stable on this. Can the maintainer add that here, or do you all want me to resend it with that item added? thanks, greg k-h
[PATCH 5.4 03/18] drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types
From: Lee Jones commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function ‘dal_gpio_service_create’: drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 12 +-- drivers/gpu/drm/amd/display/include/gpio_service_interface.h |4 +-- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c @@ -53,8 +53,8 @@ */ struct gpio_service *dal_gpio_service_create( - enum dce_version dce_version_major, - enum dce_version dce_version_minor, + enum dce_version dce_version, + enum dce_environment dce_environment, struct dc_context *ctx) { struct gpio_service *service; @@ -67,14 +67,14 @@ struct gpio_service *dal_gpio_service_cr return NULL; } - if (!dal_hw_translate_init(>translate, dce_version_major, - dce_version_minor)) { + if (!dal_hw_translate_init(>translate, dce_version, + dce_environment)) { BREAK_TO_DEBUGGER(); goto failure_1; } - if (!dal_hw_factory_init(>factory, dce_version_major, - dce_version_minor)) { + if (!dal_hw_factory_init(>factory, dce_version, + dce_environment)) { BREAK_TO_DEBUGGER(); goto failure_1; } --- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h +++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h @@ -42,8 +42,8 @@ void dal_gpio_destroy( struct gpio **ptr); struct gpio_service *dal_gpio_service_create( - enum dce_version dce_version_major, - enum dce_version dce_version_minor, + enum dce_version dce_version, + enum dce_environment dce_environment, struct dc_context *ctx); struct gpio *dal_gpio_service_create_irq(
[PATCH 4.19 03/15] drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types
From: Lee Jones commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function ‘dal_gpio_service_create’: drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 12 +-- drivers/gpu/drm/amd/display/include/gpio_service_interface.h |4 +-- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c @@ -51,8 +51,8 @@ */ struct gpio_service *dal_gpio_service_create( - enum dce_version dce_version_major, - enum dce_version dce_version_minor, + enum dce_version dce_version, + enum dce_environment dce_environment, struct dc_context *ctx) { struct gpio_service *service; @@ -66,14 +66,14 @@ struct gpio_service *dal_gpio_service_cr return NULL; } - if (!dal_hw_translate_init(>translate, dce_version_major, - dce_version_minor)) { + if (!dal_hw_translate_init(>translate, dce_version, + dce_environment)) { BREAK_TO_DEBUGGER(); goto failure_1; } - if (!dal_hw_factory_init(>factory, dce_version_major, - dce_version_minor)) { + if (!dal_hw_factory_init(>factory, dce_version, + dce_environment)) { BREAK_TO_DEBUGGER(); goto failure_1; } --- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h +++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h @@ -42,8 +42,8 @@ void dal_gpio_destroy( struct gpio **ptr); struct gpio_service *dal_gpio_service_create( - enum dce_version dce_version_major, - enum dce_version dce_version_minor, + enum dce_version dce_version, + enum dce_environment dce_environment, struct dc_context *ctx); struct gpio *dal_gpio_service_create_irq(
[PATCH 5.10 04/10] drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types
From: Lee Jones commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function ‘dal_gpio_service_create’: drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 12 +-- drivers/gpu/drm/amd/display/include/gpio_service_interface.h |4 +-- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c @@ -53,8 +53,8 @@ */ struct gpio_service *dal_gpio_service_create( - enum dce_version dce_version_major, - enum dce_version dce_version_minor, + enum dce_version dce_version, + enum dce_environment dce_environment, struct dc_context *ctx) { struct gpio_service *service; @@ -67,14 +67,14 @@ struct gpio_service *dal_gpio_service_cr return NULL; } - if (!dal_hw_translate_init(>translate, dce_version_major, - dce_version_minor)) { + if (!dal_hw_translate_init(>translate, dce_version, + dce_environment)) { BREAK_TO_DEBUGGER(); goto failure_1; } - if (!dal_hw_factory_init(>factory, dce_version_major, - dce_version_minor)) { + if (!dal_hw_factory_init(>factory, dce_version, + dce_environment)) { BREAK_TO_DEBUGGER(); goto failure_1; } --- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h +++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h @@ -42,8 +42,8 @@ void dal_gpio_destroy( struct gpio **ptr); struct gpio_service *dal_gpio_service_create( - enum dce_version dce_version_major, - enum dce_version dce_version_minor, + enum dce_version dce_version, + enum dce_environment dce_environment, struct dc_context *ctx); struct gpio *dal_gpio_service_create_irq(
[PATCH 5.17 310/343] drm/amdkfd: Create file descriptor after client is added to smi_clients list
From: Lee Jones commit e79a2398e1b2d47060474dca291542368183bc0f upstream. This ensures userspace cannot prematurely clean-up the client before it is fully initialised which has been proven to cause issues in the past. Cc: Felix Kuehling Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c @@ -268,15 +268,6 @@ int kfd_smi_event_open(struct kfd_dev *d return ret; } - ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, - O_RDWR); - if (ret < 0) { - kfifo_free(>fifo); - kfree(client); - return ret; - } - *fd = ret; - init_waitqueue_head(>wait_queue); spin_lock_init(>lock); client->events = 0; @@ -286,5 +277,20 @@ int kfd_smi_event_open(struct kfd_dev *d list_add_rcu(>list, >smi_clients); spin_unlock(>smi_lock); + ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, + O_RDWR); + if (ret < 0) { + spin_lock(>smi_lock); + list_del_rcu(>list); + spin_unlock(>smi_lock); + + synchronize_rcu(); + + kfifo_free(>fifo); + kfree(client); + return ret; + } + *fd = ret; + return 0; }
[PATCH 5.10 154/171] drm/amdkfd: Create file descriptor after client is added to smi_clients list
From: Lee Jones commit e79a2398e1b2d47060474dca291542368183bc0f upstream. This ensures userspace cannot prematurely clean-up the client before it is fully initialised which has been proven to cause issues in the past. Cc: Felix Kuehling Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c @@ -270,15 +270,6 @@ int kfd_smi_event_open(struct kfd_dev *d return ret; } - ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, - O_RDWR); - if (ret < 0) { - kfifo_free(>fifo); - kfree(client); - return ret; - } - *fd = ret; - init_waitqueue_head(>wait_queue); spin_lock_init(>lock); client->events = 0; @@ -288,5 +279,20 @@ int kfd_smi_event_open(struct kfd_dev *d list_add_rcu(>list, >smi_clients); spin_unlock(>smi_lock); + ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, + O_RDWR); + if (ret < 0) { + spin_lock(>smi_lock); + list_del_rcu(>list); + spin_unlock(>smi_lock); + + synchronize_rcu(); + + kfifo_free(>fifo); + kfree(client); + return ret; + } + *fd = ret; + return 0; }
[PATCH 5.15 246/277] drm/amdkfd: Create file descriptor after client is added to smi_clients list
From: Lee Jones commit e79a2398e1b2d47060474dca291542368183bc0f upstream. This ensures userspace cannot prematurely clean-up the client before it is fully initialised which has been proven to cause issues in the past. Cc: Felix Kuehling Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c @@ -270,15 +270,6 @@ int kfd_smi_event_open(struct kfd_dev *d return ret; } - ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, - O_RDWR); - if (ret < 0) { - kfifo_free(>fifo); - kfree(client); - return ret; - } - *fd = ret; - init_waitqueue_head(>wait_queue); spin_lock_init(>lock); client->events = 0; @@ -288,5 +279,20 @@ int kfd_smi_event_open(struct kfd_dev *d list_add_rcu(>list, >smi_clients); spin_unlock(>smi_lock); + ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, + O_RDWR); + if (ret < 0) { + spin_lock(>smi_lock); + list_del_rcu(>list); + spin_unlock(>smi_lock); + + synchronize_rcu(); + + kfifo_free(>fifo); + kfree(client); + return ret; + } + *fd = ret; + return 0; }
[PATCH 5.16 257/285] drm/amdkfd: Create file descriptor after client is added to smi_clients list
From: Lee Jones commit e79a2398e1b2d47060474dca291542368183bc0f upstream. This ensures userspace cannot prematurely clean-up the client before it is fully initialised which has been proven to cause issues in the past. Cc: Felix Kuehling Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c @@ -270,15 +270,6 @@ int kfd_smi_event_open(struct kfd_dev *d return ret; } - ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, - O_RDWR); - if (ret < 0) { - kfifo_free(>fifo); - kfree(client); - return ret; - } - *fd = ret; - init_waitqueue_head(>wait_queue); spin_lock_init(>lock); client->events = 0; @@ -288,5 +279,20 @@ int kfd_smi_event_open(struct kfd_dev *d list_add_rcu(>list, >smi_clients); spin_unlock(>smi_lock); + ret = anon_inode_getfd(kfd_smi_name, _smi_ev_fops, (void *)client, + O_RDWR); + if (ret < 0) { + spin_lock(>smi_lock); + list_del_rcu(>list); + spin_unlock(>smi_lock); + + synchronize_rcu(); + + kfifo_free(>fifo); + kfree(client); + return ret; + } + *fd = ret; + return 0; }
Re: [PATCH 5.4 0/2] Fix two instances of -Wstrict-prototypes in drm/amd
On Mon, Apr 11, 2022 at 09:43:06AM -0700, Nathan Chancellor wrote: > Hi everyone, > > These two patches resolve two instances of -Wstrict-prototypes with > newer versions of clang that are present in 5.4. The main Makefile makes > this a hard error. > > The first patch is upstream commit 63617d8b125e ("drm/amdkfd: add > missing void argument to function kgd2kfd_init"), which showed up in > 5.5. > > The second patch has no upstream equivalent, as the code in question was > removed in commit e392c887df97 ("drm/amdkfd: Use array to probe > kfd2kgd_calls") upstream, which is part of a larger series that did not > look reasonable for stable. I opted to just fix the warning in the same > manner as the prior patch, which is less risky and accomplishes the same > end result of no warning. > > Colin Ian King (1): > drm/amdkfd: add missing void argument to function kgd2kfd_init > > Nathan Chancellor (1): > drm/amdkfd: Fix -Wstrict-prototypes from > amdgpu_amdkfd_gfx_10_0_get_functions() > > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_module.c| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > > base-commit: 2845ff3fd34499603249676495c524a35e795b45 > -- > 2.35.1 > Now queued up, thanks. greg k-h
[PATCH] drm/amdgpu: use default_groups in kobj_type
There are currently 2 ways to create a set of sysfs files for a kobj_type, through the default_attrs field, and the default_groups field. Move the amdgpu sysfs code to use default_groups field which has been the preferred way since aa30f47cf666 ("kobject: Add support for default attribute groups to kobj_type") so that we can soon get rid of the obsolete default_attrs field. Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Hawking Zhang Cc: John Clements Cc: Felix Kuehling Cc: Jonathan Kim Cc: Kevin Wang Cc: shaoyunl Cc: Tao Zhou Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c index 567df2db23ac..94dcb004988d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c @@ -208,6 +208,7 @@ static struct attribute *amdgpu_xgmi_hive_attrs[] = { _xgmi_hive_id, NULL }; +ATTRIBUTE_GROUPS(amdgpu_xgmi_hive); static ssize_t amdgpu_xgmi_show_attrs(struct kobject *kobj, struct attribute *attr, char *buf) @@ -237,7 +238,7 @@ static const struct sysfs_ops amdgpu_xgmi_hive_ops = { struct kobj_type amdgpu_xgmi_hive_type = { .release = amdgpu_xgmi_hive_release, .sysfs_ops = _xgmi_hive_ops, - .default_attrs = amdgpu_xgmi_hive_attrs, + .default_groups = amdgpu_xgmi_hive_groups, }; static ssize_t amdgpu_xgmi_show_device_id(struct device *dev, -- 2.34.1
[PATCH] drm/amdkfd: use default_groups in kobj_type
There are currently 2 ways to create a set of sysfs files for a kobj_type, through the default_attrs field, and the default_groups field. Move the amdkfd sysfs code to use default_groups field which has been the preferred way since aa30f47cf666 ("kobject: Add support for default attribute groups to kobj_type") so that we can soon get rid of the obsolete default_attrs field. Cc: Felix Kuehling Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index b993011cfa64..1f4a07f984eb 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -462,6 +462,7 @@ static struct attribute *procfs_queue_attrs[] = { _queue_gpuid, NULL }; +ATTRIBUTE_GROUPS(procfs_queue); static const struct sysfs_ops procfs_queue_ops = { .show = kfd_procfs_queue_show, @@ -469,7 +470,7 @@ static const struct sysfs_ops procfs_queue_ops = { static struct kobj_type procfs_queue_type = { .sysfs_ops = _queue_ops, - .default_attrs = procfs_queue_attrs, + .default_groups = procfs_queue_groups, }; static const struct sysfs_ops procfs_stats_ops = { -- 2.34.1
[PATCH 5.15 350/917] drm/amd/display: Pass display_pipe_params_st as const in DML
From: Harry Wentland [ Upstream commit 22667e6ec6b2ce9ca706e9061660b059725d009c ] [Why] This neither needs to be on the stack nor passed by value to each function call. In fact, when building with clang it seems to break the Linux's default 1024 byte stack frame limit. [How] We can simply pass this as a const pointer. This patch fixes these Coverity IDs Addresses-Coverity-ID: 1424031: ("Big parameter passed by value") Addresses-Coverity-ID: 1423970: ("Big parameter passed by value") Addresses-Coverity-ID: 1423941: ("Big parameter passed by value") Addresses-Coverity-ID: 1451742: ("Big parameter passed by value") Addresses-Coverity-ID: 1451887: ("Big parameter passed by value") Addresses-Coverity-ID: 1454146: ("Big parameter passed by value") Addresses-Coverity-ID: 1454152: ("Big parameter passed by value") Addresses-Coverity-ID: 1454413: ("Big parameter passed by value") Addresses-Coverity-ID: 1466144: ("Big parameter passed by value") Addresses-Coverity-ID: 1487237: ("Big parameter passed by value") Signed-off-by: Harry Wentland Fixes: 3fe617ccafd6 ("Enable '-Werror' by default for all kernel builds") Cc: Nick Desaulniers Cc: Linus Torvalds Cc: amd-gfx@lists.freedesktop.org Cc: Linux Kernel Mailing List Cc: Arnd Bergmann Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Xinhui Pan Cc: Nathan Chancellor Cc: Guenter Roeck Cc: l...@lists.linux.dev Acked-by: Christian König Build-tested-by: Nathan Chancellor Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- .../drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +- .../dc/dml/dcn20/display_rq_dlg_calc_20.c | 6 +- .../dc/dml/dcn20/display_rq_dlg_calc_20.h | 4 +- .../dc/dml/dcn20/display_rq_dlg_calc_20v2.c | 6 +- .../dc/dml/dcn20/display_rq_dlg_calc_20v2.h | 4 +- .../dc/dml/dcn21/display_rq_dlg_calc_21.c | 62 .../dc/dml/dcn21/display_rq_dlg_calc_21.h | 4 +- .../dc/dml/dcn30/display_rq_dlg_calc_30.c | 72 +-- .../dc/dml/dcn30/display_rq_dlg_calc_30.h | 4 +- .../dc/dml/dcn31/display_rq_dlg_calc_31.c | 68 +- .../dc/dml/dcn31/display_rq_dlg_calc_31.h | 4 +- .../drm/amd/display/dc/dml/display_mode_lib.h | 4 +- 12 files changed, 120 insertions(+), 120 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c index f2f258e70f9da..34a126816133e 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c @@ -3152,7 +3152,7 @@ void dcn20_calculate_dlg_params( context->bw_ctx.dml.funcs.rq_dlg_get_rq_reg(>bw_ctx.dml, >res_ctx.pipe_ctx[i].rq_regs, - pipes[pipe_idx].pipe); + [pipe_idx].pipe); pipe_idx++; } } diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c index 2091dd8c252da..8c168f348a27f 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c @@ -768,12 +768,12 @@ static void dml20_rq_dlg_get_rq_params(struct display_mode_lib *mode_lib, void dml20_rq_dlg_get_rq_reg(struct display_mode_lib *mode_lib, display_rq_regs_st *rq_regs, - const display_pipe_params_st pipe_param) + const display_pipe_params_st *pipe_param) { display_rq_params_st rq_param = {0}; memset(rq_regs, 0, sizeof(*rq_regs)); - dml20_rq_dlg_get_rq_params(mode_lib, _param, pipe_param.src); + dml20_rq_dlg_get_rq_params(mode_lib, _param, pipe_param->src); extract_rq_regs(mode_lib, rq_regs, rq_param); print__rq_regs_st(mode_lib, *rq_regs); @@ -1549,7 +1549,7 @@ static void dml20_rq_dlg_get_dlg_params(struct display_mode_lib *mode_lib, void dml20_rq_dlg_get_dlg_reg(struct display_mode_lib *mode_lib, display_dlg_regs_st *dlg_regs, display_ttu_regs_st *ttu_regs, - display_e2e_pipe_params_st *e2e_pipe_param, + const display_e2e_pipe_params_st *e2e_pipe_param, const unsigned int num_pipes, const unsigned int pipe_idx, const bool cstate_en, diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h index d0b90947f5409..8b23867e97c18 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h @@ -43,7 +43,7 @@ struct display_mode_lib; void dml20_rq_dlg_get_rq_reg( struct display_mode_lib *mode_lib, display_rq_regs_st *rq_regs, - const display_pipe_params_st pipe_param); +
[PATCH 5.13 081/175] drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled
From: Randy Dunlap commit 5706cb3c910cc8283f344bc37a889a8d523a2c6d upstream. 'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP is set/enabled. OTOH, when both SUSPEND and HIBERNATION are not set, PM_SLEEP is not set, so this variable cannot be used. ../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: In function ‘amdgpu_acpi_is_s0ix_active’: ../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:1046:11: error: ‘pm_suspend_target_state’ undeclared (first use in this function); did you mean ‘__KSYM_pm_suspend_target_state’? return pm_suspend_target_state == PM_SUSPEND_TO_IDLE; ^~~ __KSYM_pm_suspend_target_state Also use shorter IS_ENABLED(CONFIG_foo) notation for checking the 2 config symbols. Fixes: 91e273712ab8dd ("drm/amdgpu: Check pmops for desired suspend state") Signed-off-by: Randy Dunlap Cc: Alex Deucher Cc: Christian König Cc: "Pan, Xinhui" Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-n...@vger.kernel.org Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c @@ -904,7 +904,7 @@ void amdgpu_acpi_fini(struct amdgpu_devi */ bool amdgpu_acpi_is_s0ix_supported(struct amdgpu_device *adev) { -#if defined(CONFIG_AMD_PMC) || defined(CONFIG_AMD_PMC_MODULE) +#if IS_ENABLED(CONFIG_AMD_PMC) && IS_ENABLED(CONFIG_PM_SLEEP) if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) { if (adev->flags & AMD_IS_APU) return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
[PATCH 5.4 082/122] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2649,6 +2649,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.y != 0)) return -EINVAL; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.12 175/242] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3884,6 +3884,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.y != 0)) return -EINVAL; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.10 160/215] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3702,6 +3702,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.y != 0)) return -EINVAL; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.13 199/266] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4049,6 +4049,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.y != 0)) return -EINVAL; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.12 080/677] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3850,6 +3850,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.x = state->src_x >> 16; scaling_info->src_rect.y = state->src_y >> 16; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.11 071/601] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3740,6 +3740,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.x = state->src_x >> 16; scaling_info->src_rect.y = state->src_y >> 16; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.10 068/530] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3685,6 +3685,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.x = state->src_x >> 16; scaling_info->src_rect.y = state->src_y >> 16; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.4 042/244] drm/amd/display: Reject non-zero src_y and src_x for video planes
From: Harry Wentland commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: sta...@vger.kernel.org Cc: nicholas.kazlaus...@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deuc...@amd.com Cc: roman...@amd.com Cc: hersenxs...@amd.com Cc: danny.w...@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + 1 file changed, 17 insertions(+) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2632,6 +2632,23 @@ static int fill_dc_scaling_info(const st scaling_info->src_rect.x = state->src_x >> 16; scaling_info->src_rect.y = state->src_y >> 16; + /* +* For reasons we don't (yet) fully understand a non-zero +* src_y coordinate into an NV12 buffer can cause a +* system hang. To avoid hangs (and maybe be overly cautious) +* let's reject both non-zero src_x and src_y. +* +* We currently know of only one use-case to reproduce a +* scenario with non-zero src_x and src_y for NV12, which +* is to gesture the YouTube Android app into full screen +* on ChromeOS. +*/ + if (state->fb && + state->fb->format->format == DRM_FORMAT_NV12 && + (scaling_info->src_rect.x != 0 || +scaling_info->src_rect.y != 0)) + return -EINVAL; + scaling_info->src_rect.width = state->src_w >> 16; if (scaling_info->src_rect.width == 0) return -EINVAL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.12 153/384] drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing field overwritten issue
From: Lee Jones [ Upstream commit 3e3527f5b765c6f479ba55e5a570ee9538589a74 ] Fixes the following W=1 kernel build warning(s): In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59: drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:181:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: note: (near initialization for ‘aux_mask.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h index 277484cf853e..d4be5954d7aa 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h @@ -99,7 +99,6 @@ struct dce110_aux_registers { AUX_SF(AUX_SW_CONTROL, AUX_SW_GO, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_DATA_RW, mask_sh),\ - AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_INDEX, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_DATA, mask_sh),\ AUX_SF(AUX_SW_STATUS, AUX_SW_REPLY_BYTE_COUNT, mask_sh),\ -- 2.30.2 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.10 122/299] drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing field overwritten issue
From: Lee Jones [ Upstream commit 89adc10178fd6cb68c8ef1905d269070a4d3bd64 ] Fixes the following W=1 kernel build warning(s): In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59: drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:181:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: note: (near initialization for ‘aux_mask.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h index 382465862f29..f72f02e016ae 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h @@ -99,7 +99,6 @@ struct dce110_aux_registers { AUX_SF(AUX_SW_CONTROL, AUX_SW_GO, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_DATA_RW, mask_sh),\ - AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_INDEX, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_DATA, mask_sh),\ AUX_SF(AUX_SW_STATUS, AUX_SW_REPLY_BYTE_COUNT, mask_sh),\ -- 2.30.2 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.11 140/342] drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing field overwritten issue
From: Lee Jones [ Upstream commit 89adc10178fd6cb68c8ef1905d269070a4d3bd64 ] Fixes the following W=1 kernel build warning(s): In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59: drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58: note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: warning: initialized field overwritten [-Woverride-init] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:181:2: note: in expansion of macro ‘DCE_AUX_MASK_SH_LIST’ drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56: note: (near initialization for ‘aux_mask.AUX_SW_AUTOINCREMENT_DISABLE’) drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in expansion of macro ‘AUX_SF’ Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h index 382465862f29..f72f02e016ae 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h @@ -99,7 +99,6 @@ struct dce110_aux_registers { AUX_SF(AUX_SW_CONTROL, AUX_SW_GO, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_DATA_RW, mask_sh),\ - AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_INDEX, mask_sh),\ AUX_SF(AUX_SW_DATA, AUX_SW_DATA, mask_sh),\ AUX_SF(AUX_SW_STATUS, AUX_SW_REPLY_BYTE_COUNT, mask_sh),\ -- 2.30.2 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.10 01/20] Revert "drm/amd/display: Fix memory leaks in S3 resume"
From: Alex Deucher This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362. This leads to blank screens on some boards after replugging a display. Revert until we understand the root cause and can fix both the leak and the blank screen after replug. Cc: Stylon Wang Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Andre Tomt Cc: Oleksandr Natalenko Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2278,8 +2278,7 @@ void amdgpu_dm_update_connector_after_de drm_connector_update_edid_property(connector, aconnector->edid); - aconnector->num_modes = drm_add_edid_modes(connector, aconnector->edid); - drm_connector_list_update(connector); + drm_add_edid_modes(connector, aconnector->edid); if (aconnector->dc_link->aux_mode) drm_dp_cec_set_edid(>dm_dp_aux.aux, ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.4 01/13] Revert "drm/amd/display: Fix memory leaks in S3 resume"
From: Alex Deucher This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362. This leads to blank screens on some boards after replugging a display. Revert until we understand the root cause and can fix both the leak and the blank screen after replug. Cc: Stylon Wang Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Andre Tomt Cc: Oleksandr Natalenko Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1434,8 +1434,7 @@ amdgpu_dm_update_connector_after_detect( drm_connector_update_edid_property(connector, aconnector->edid); - aconnector->num_modes = drm_add_edid_modes(connector, aconnector->edid); - drm_connector_list_update(connector); + drm_add_edid_modes(connector, aconnector->edid); if (aconnector->dc_link->aux_mode) drm_dp_cec_set_edid(>dm_dp_aux.aux, ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.7 125/393] drm/amdgpu: use the unlocked drm_gem_object_put
From: Emil Velikov [ Upstream commit 1a87f67a66de4ad0c0d79fd86b6c5273143387c3 ] The driver does not hold struct_mutex, thus using the locked version of the helper is incorrect. Cc: Alex Deucher Cc: Christian König Cc: amd-gfx@lists.freedesktop.org Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9") Signed-off-by: Emil Velikov Acked-by: Sam Ravnborg Reviewed-by: Christian König Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-8-emil.l.veli...@gmail.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index ffeb20f11c07c..728f76cc536ee 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -552,7 +552,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev, attach = dma_buf_dynamic_attach(dma_buf, dev->dev, _dma_buf_attach_ops, obj); if (IS_ERR(attach)) { - drm_gem_object_put(obj); + drm_gem_object_put_unlocked(obj); return ERR_CAST(attach); } -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.8 143/464] drm/amdgpu: use the unlocked drm_gem_object_put
From: Emil Velikov [ Upstream commit 1a87f67a66de4ad0c0d79fd86b6c5273143387c3 ] The driver does not hold struct_mutex, thus using the locked version of the helper is incorrect. Cc: Alex Deucher Cc: Christian König Cc: amd-gfx@lists.freedesktop.org Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9") Signed-off-by: Emil Velikov Acked-by: Sam Ravnborg Reviewed-by: Christian König Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-8-emil.l.veli...@gmail.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index 43d8ed7dbd001..652c57a3b8478 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -587,7 +587,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev, attach = dma_buf_dynamic_attach(dma_buf, dev->dev, _dma_buf_attach_ops, obj); if (IS_ERR(attach)) { - drm_gem_object_put(obj); + drm_gem_object_put_unlocked(obj); return ERR_CAST(attach); } -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
On Fri, Jul 31, 2020 at 08:57:53AM +0200, Christian König wrote: > Am 31.07.20 um 08:53 schrieb Greg Kroah-Hartman: > > On Thu, Jul 30, 2020 at 05:09:07PM -0400, Luben Tuikov wrote: > > > On 2020-07-29 9:49 a.m., Alex Deucher wrote: > > > > On Wed, Jul 29, 2020 at 4:11 AM Christian König > > > > wrote: > > > > > Am 28.07.20 um 21:29 schrieb Peilin Ye: > > > > > > Compiler leaves a 4-byte hole near the end of `dev_info`, causing > > > > > > amdgpu_info_ioctl() to copy uninitialized kernel stack memory to > > > > > > userspace > > > > > > when `size` is greater than 356. > > > > > > > > > > > > In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, > > > > > > which > > > > > > unfortunately does not initialize that 4-byte hole. Fix it by using > > > > > > memset() instead. > > > > > > > > > > > > Cc: sta...@vger.kernel.org > > > > > > Fixes: c193fa91b918 ("drm/amdgpu: information leak in > > > > > > amdgpu_info_ioctl()") > > > > > > Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") > > > > > > Suggested-by: Dan Carpenter > > > > > > Signed-off-by: Peilin Ye > > > > > Reviewed-by: Christian König > > > > > > > > > > I can't count how many of those we have fixed over the years. > > > > > > > > > > At some point we should probably document that using "= {}" or "= { 0 > > > > > }" > > > > > in the kernel is a really bad idea and should be avoided. > > > > Moreover, it seems like different compilers seem to behave relatively > > > > differently with these and we often get reports of warnings with these > > > > on clang. When in doubt, memset. > > > There are quite a few of those under drivers/gpu/drm, for "amd/", > > > "scheduler/" > > > drm*.c files, > > > > > > $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex > > > "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | > > > wc -l > > > 374 > > > $_ > > > > > > Out of which only 16 are of the non-ISO C variety, "= {}", > > > > > > $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex > > > "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l > > > 16 > > > $_ > > > > > > Perhaps the latter are the more pressing ones, since it is a C++ > > > initializer and not a ISO C one. > > It only matters when we care copying the data to userspace, if it all > > stays in the kernel, all is fine. > > Well only as long as you don't try to compute a CRC32, MD5 or any > fingerprint for a hash from the bytes from the structure. > > Then it fails horrible and you wonder why the code doesn't works as > expected. True, but the number of times I have ever needed to do that to a structure for a driver is, um, never... If a structure ever needs to have that happen to it, I would sure hope the developer was aware of padding fields, otherwise, well, someone needs to take away their C language certification :) thanks, greg k-h ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
On Thu, Jul 30, 2020 at 05:09:07PM -0400, Luben Tuikov wrote: > On 2020-07-29 9:49 a.m., Alex Deucher wrote: > > On Wed, Jul 29, 2020 at 4:11 AM Christian König > > wrote: > >> > >> Am 28.07.20 um 21:29 schrieb Peilin Ye: > >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing > >>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace > >>> when `size` is greater than 356. > >>> > >>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which > >>> unfortunately does not initialize that 4-byte hole. Fix it by using > >>> memset() instead. > >>> > >>> Cc: sta...@vger.kernel.org > >>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in > >>> amdgpu_info_ioctl()") > >>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") > >>> Suggested-by: Dan Carpenter > >>> Signed-off-by: Peilin Ye > >> > >> Reviewed-by: Christian König > >> > >> I can't count how many of those we have fixed over the years. > >> > >> At some point we should probably document that using "= {}" or "= { 0 }" > >> in the kernel is a really bad idea and should be avoided. > > > > Moreover, it seems like different compilers seem to behave relatively > > differently with these and we often get reports of warnings with these > > on clang. When in doubt, memset. > > There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/" > drm*.c files, > > $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex > "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc > -l > 374 > $_ > > Out of which only 16 are of the non-ISO C variety, "= {}", > > $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex > "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l > 16 > $_ > > Perhaps the latter are the more pressing ones, since it is a C++ initializer > and not a ISO C one. It only matters when we care copying the data to userspace, if it all stays in the kernel, all is fine. thanks, greg k-h ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.4 290/314] drm/amd/display: Use swap() where appropriate
From: Ville Syrjälä [ Upstream commit 34b86b75dfc90ab3d996c224314ce51772a3b351 ] Mostly a cocci-job, but it flat out refused to remove the declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so had to do that part manually. @swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ ( - T TEMP; | - T TEMP = {...}; ) ... when != TEMP Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Nicholas Kazlauskas Signed-off-by: Ville Syrjälä Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 7 ++- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 8 ++-- drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +- 3 files changed, 5 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c index 221e0f56389f3..823843cd26133 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c @@ -2543,7 +2543,6 @@ static enum bp_result construct_integrated_info( /* Sort voltage table from low to high*/ if (result == BP_RESULT_OK) { - struct clock_voltage_caps temp = {0, 0}; uint32_t i; uint32_t j; @@ -2553,10 +2552,8 @@ static enum bp_result construct_integrated_info( info->disp_clk_voltage[j].max_supported_clk < info->disp_clk_voltage[j-1].max_supported_clk) { /* swap j and j - 1*/ - temp = info->disp_clk_voltage[j-1]; - info->disp_clk_voltage[j-1] = - info->disp_clk_voltage[j]; - info->disp_clk_voltage[j] = temp; + swap(info->disp_clk_voltage[j - 1], +info->disp_clk_voltage[j]); } } } diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c index dff65c0fe82f8..7873abea4112b 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -1613,8 +1613,6 @@ static enum bp_result construct_integrated_info( struct atom_common_table_header *header; struct atom_data_revision revision; - - struct clock_voltage_caps temp = {0, 0}; uint32_t i; uint32_t j; @@ -1644,10 +1642,8 @@ static enum bp_result construct_integrated_info( info->disp_clk_voltage[j-1].max_supported_clk ) { /* swap j and j - 1*/ - temp = info->disp_clk_voltage[j-1]; - info->disp_clk_voltage[j-1] = - info->disp_clk_voltage[j]; - info->disp_clk_voltage[j] = temp; + swap(info->disp_clk_voltage[j - 1], +info->disp_clk_voltage[j]); } } } diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index b95a58aa82d91..47e7d11ca0c9c 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -907,15 +907,11 @@ static void program_timing_sync( /* set first pipe with plane as master */ for (j = 0; j < group_size; j++) { - struct pipe_ctx *temp; - if (pipe_set[j]->plane_state) { if (j == 0) break; - temp = pipe_set[0]; - pipe_set[0] = pipe_set[j]; - pipe_set[j] = temp; + swap(pipe_set[0], pipe_set[j]); break; } } -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.4 080/152] drm/radeon: Inline drm_get_pci_dev
From: Daniel Vetter commit eb12c957735b582607e5842a06d1f4c62e185c1d upstream. It's the last user, and more importantly, it's the last non-legacy user of anything in drm_pci.c. The only tricky bit is the agp initialization. But a close look shows that radeon does not use the drm_agp midlayer (the main use of that is drm_bufs for legacy drivers), and instead could use the agp subsystem directly (like nouveau does already). Hence we can just pull this in too. A further step would be to entirely drop the use of drm_device->agp, but feels like too much churn just for this patch. Signed-off-by: Daniel Vetter Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Alex Deucher Reviewed-by: Emil Velikov Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/radeon/radeon_drv.c | 43 ++-- drivers/gpu/drm/radeon/radeon_kms.c |6 + 2 files changed, 47 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -37,6 +37,7 @@ #include #include +#include #include #include #include @@ -325,6 +326,7 @@ static int radeon_pci_probe(struct pci_d const struct pci_device_id *ent) { unsigned long flags = 0; + struct drm_device *dev; int ret; if (!ent) @@ -365,7 +367,44 @@ static int radeon_pci_probe(struct pci_d if (ret) return ret; - return drm_get_pci_dev(pdev, ent, _driver); + dev = drm_dev_alloc(_driver, >dev); + if (IS_ERR(dev)) + return PTR_ERR(dev); + + ret = pci_enable_device(pdev); + if (ret) + goto err_free; + + dev->pdev = pdev; +#ifdef __alpha__ + dev->hose = pdev->sysdata; +#endif + + pci_set_drvdata(pdev, dev); + + if (pci_find_capability(dev->pdev, PCI_CAP_ID_AGP)) + dev->agp = drm_agp_init(dev); + if (dev->agp) { + dev->agp->agp_mtrr = arch_phys_wc_add( + dev->agp->agp_info.aper_base, + dev->agp->agp_info.aper_size * + 1024 * 1024); + } + + ret = drm_dev_register(dev, ent->driver_data); + if (ret) + goto err_agp; + + return 0; + +err_agp: + if (dev->agp) + arch_phys_wc_del(dev->agp->agp_mtrr); + kfree(dev->agp); + pci_disable_device(pdev); +err_free: + drm_dev_put(dev); + return ret; } static void @@ -578,7 +617,7 @@ radeon_get_crtc_scanout_position(struct static struct drm_driver kms_driver = { .driver_features = - DRIVER_USE_AGP | DRIVER_GEM | DRIVER_RENDER, + DRIVER_GEM | DRIVER_RENDER, .load = radeon_driver_load_kms, .open = radeon_driver_open_kms, .postclose = radeon_driver_postclose_kms, --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -77,6 +78,11 @@ void radeon_driver_unload_kms(struct drm radeon_modeset_fini(rdev); radeon_device_fini(rdev); + if (dev->agp) + arch_phys_wc_del(dev->agp->agp_mtrr); + kfree(dev->agp); + dev->agp = NULL; + done_free: kfree(rdev); dev->dev_private = NULL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.5 094/176] drm/radeon: Inline drm_get_pci_dev
From: Daniel Vetter commit eb12c957735b582607e5842a06d1f4c62e185c1d upstream. It's the last user, and more importantly, it's the last non-legacy user of anything in drm_pci.c. The only tricky bit is the agp initialization. But a close look shows that radeon does not use the drm_agp midlayer (the main use of that is drm_bufs for legacy drivers), and instead could use the agp subsystem directly (like nouveau does already). Hence we can just pull this in too. A further step would be to entirely drop the use of drm_device->agp, but feels like too much churn just for this patch. Signed-off-by: Daniel Vetter Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Alex Deucher Reviewed-by: Emil Velikov Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/radeon/radeon_drv.c | 43 ++-- drivers/gpu/drm/radeon/radeon_kms.c |6 + 2 files changed, 47 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -37,6 +37,7 @@ #include #include +#include #include #include #include @@ -325,6 +326,7 @@ static int radeon_pci_probe(struct pci_d const struct pci_device_id *ent) { unsigned long flags = 0; + struct drm_device *dev; int ret; if (!ent) @@ -365,7 +367,44 @@ static int radeon_pci_probe(struct pci_d if (ret) return ret; - return drm_get_pci_dev(pdev, ent, _driver); + dev = drm_dev_alloc(_driver, >dev); + if (IS_ERR(dev)) + return PTR_ERR(dev); + + ret = pci_enable_device(pdev); + if (ret) + goto err_free; + + dev->pdev = pdev; +#ifdef __alpha__ + dev->hose = pdev->sysdata; +#endif + + pci_set_drvdata(pdev, dev); + + if (pci_find_capability(dev->pdev, PCI_CAP_ID_AGP)) + dev->agp = drm_agp_init(dev); + if (dev->agp) { + dev->agp->agp_mtrr = arch_phys_wc_add( + dev->agp->agp_info.aper_base, + dev->agp->agp_info.aper_size * + 1024 * 1024); + } + + ret = drm_dev_register(dev, ent->driver_data); + if (ret) + goto err_agp; + + return 0; + +err_agp: + if (dev->agp) + arch_phys_wc_del(dev->agp->agp_mtrr); + kfree(dev->agp); + pci_disable_device(pdev); +err_free: + drm_dev_put(dev); + return ret; } static void @@ -575,7 +614,7 @@ radeon_get_crtc_scanout_position(struct static struct drm_driver kms_driver = { .driver_features = - DRIVER_USE_AGP | DRIVER_GEM | DRIVER_RENDER, + DRIVER_GEM | DRIVER_RENDER, .load = radeon_driver_load_kms, .open = radeon_driver_open_kms, .postclose = radeon_driver_postclose_kms, --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -77,6 +78,11 @@ void radeon_driver_unload_kms(struct drm radeon_modeset_fini(rdev); radeon_device_fini(rdev); + if (dev->agp) + arch_phys_wc_del(dev->agp->agp_mtrr); + kfree(dev->agp); + dev->agp = NULL; + done_free: kfree(rdev); dev->dev_private = NULL; ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/5] power: avs: smartreflex: Remove superfluous cast in debugfs_create_file() call
On Fri, Nov 08, 2019 at 12:24:42PM +0100, Rafael J. Wysocki wrote: > On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote: > > There is no need to cast a typed pointer to a void pointer when calling > > a function that accepts the latter. Remove it, as the cast prevents > > further compiler checks. > > > > Signed-off-by: Geert Uytterhoeven > > Greg, have you taken this one by any chance? Nope, it's all yours! :) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Cleanup: replace prefered with preferred
On Thu, Oct 24, 2019 at 03:26:28PM +0300, Jani Nikula wrote: > On Wed, 23 Oct 2019, Mark Salyzyn wrote: > > I will split this between pure and inert documentation/comments for now, > > with a followup later for the code portion which understandably is more > > controversial. > > Please split by driver/subsystem too, and it'll be all around much > easier for everyone. I agree, spelling fixes are trivial and should go in per-subsystem. thanks, greg k-h ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Cleanup: replace prefered with preferred
On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote: > On 10/23/19 4:56 AM, Jarkko Sakkinen wrote: > > On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote: > > > Replace all occurrences of prefered with preferred to make future > > > checkpatch.pl's happy. A few places the incorrect spelling is > > > matched with the correct spelling to preserve existing user space API. > > > > > > Signed-off-by: Mark Salyzyn > > I'd fix such things when the code is otherwise change and scope this > > patch only to Documentation/. There is no pragmatic benefit of doing > > this for the code. > > > > /Jarkko > > The pragmatic benefit comes with the use of an ABI/API checker (which is a > 'distro' thing, not a top of tree kernel thing) produces its map which is > typically required to be co-located in the same tree as the kernel > repository. Quite a few ABI/API update checkins result in a checkpatch.pl > complaint about the misspelled elements being (re-)recorded due to > proximity. We have a separate task to improve how it is tracked in Android > to reduce milepost marker changes that result in sweeping changes to the > database which would reduce the occurrences. Requiring checkpatch spelling warnings to be correct based on function names is crazy, you should fix your tools if you are requiring something as looney as that :) > I will split this between pure and inert documentation/comments for now, > with a followup later for the code portion which understandably is more > controversial. Please break up per subsystem, like all trivial patches, as this isn't anything special. thanks, greg k-h ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 10/34] genwqe: convert put_page() to put_user_page*()
On Thu, Aug 01, 2019 at 07:19:41PM -0700, john.hubb...@gmail.com wrote: > From: John Hubbard > > For pages that were retained via get_user_pages*(), release those pages > via the new put_user_page*() routines, instead of via put_page() or > release_pages(). > > This is part a tree-wide conversion, as described in commit fc1d8e7cca2d > ("mm: introduce put_user_page*(), placeholder versions"). > > This changes the release code slightly, because each page slot in the > page_list[] array is no longer checked for NULL. However, that check > was wrong anyway, because the get_user_pages() pattern of usage here > never allowed for NULL entries within a range of pinned pages. > > Cc: Frank Haverkamp > Cc: "Guilherme G. Piccoli" > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Signed-off-by: John Hubbard > --- > drivers/misc/genwqe/card_utils.c | 17 +++------ > 1 file changed, 3 insertions(+), 14 deletions(-) Acked-by: Greg Kroah-Hartman ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 15/34] staging/vc04_services: convert put_page() to put_user_page*()
On Thu, Aug 01, 2019 at 07:19:46PM -0700, john.hubb...@gmail.com wrote: > From: John Hubbard > > For pages that were retained via get_user_pages*(), release those pages > via the new put_user_page*() routines, instead of via put_page() or > release_pages(). > > This is part a tree-wide conversion, as described in commit fc1d8e7cca2d > ("mm: introduce put_user_page*(), placeholder versions"). > > Cc: Eric Anholt > Cc: Stefan Wahren > Cc: Greg Kroah-Hartman > Cc: Mihaela Muraru > Cc: Suniel Mahesh > Cc: Al Viro > Cc: Sidong Yang > Cc: Kishore KP > Cc: linux-rpi-ker...@lists.infradead.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: de...@driverdev.osuosl.org > Signed-off-by: John Hubbard > --- > .../vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 ++---- > 1 file changed, 2 insertions(+), 8 deletions(-) Acked-by: Greg Kroah-Hartman ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] amdkfd: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Oded Gabbay Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c | 36 ++-- 1 file changed, 8 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c b/drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c index ab37d36d9cd6..15c523027285 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c @@ -85,36 +85,16 @@ static const struct file_operations kfd_debugfs_hang_hws_fops = { void kfd_debugfs_init(void) { - struct dentry *ent; - debugfs_root = debugfs_create_dir("kfd", NULL); - if (!debugfs_root || debugfs_root == ERR_PTR(-ENODEV)) { - pr_warn("Failed to create kfd debugfs dir\n"); - return; - } - - ent = debugfs_create_file("mqds", S_IFREG | 0444, debugfs_root, - kfd_debugfs_mqds_by_process, - _debugfs_fops); - if (!ent) - pr_warn("Failed to create mqds in kfd debugfs\n"); - - ent = debugfs_create_file("hqds", S_IFREG | 0444, debugfs_root, - kfd_debugfs_hqds_by_device, - _debugfs_fops); - if (!ent) - pr_warn("Failed to create hqds in kfd debugfs\n"); - - ent = debugfs_create_file("rls", S_IFREG | 0444, debugfs_root, - kfd_debugfs_rls_by_device, - _debugfs_fops); - - ent = debugfs_create_file("hang_hws", S_IFREG | 0644, debugfs_root, - NULL, - _debugfs_hang_hws_fops); - if (!ent) - pr_warn("Failed to create rls in kfd debugfs\n"); + debugfs_create_file("mqds", S_IFREG | 0444, debugfs_root, + kfd_debugfs_mqds_by_process, _debugfs_fops); + debugfs_create_file("hqds", S_IFREG | 0444, debugfs_root, + kfd_debugfs_hqds_by_device, _debugfs_fops); + debugfs_create_file("rls", S_IFREG | 0444, debugfs_root, + kfd_debugfs_rls_by_device, _debugfs_fops); + debugfs_create_file("hang_hws", S_IFREG | 0644, debugfs_root, + NULL, _debugfs_hang_hws_fops); } void kfd_debugfs_fini(void) -- 2.22.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] amdgpu: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Daniel Vetter Cc: xinhui pan Cc: Evan Quan Cc: Feifei Xu Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 51 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 4 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 5 +-- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 +-- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 5 +-- 5 files changed, 17 insertions(+), 53 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 22bd21efe6b1..1d0ef9ef35e8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -833,40 +833,24 @@ static int amdgpu_ras_sysfs_remove_all(struct amdgpu_device *adev) /* sysfs end */ /* debugfs begin */ -static int amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev) +static void amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev) { struct amdgpu_ras *con = amdgpu_ras_get_context(adev); struct drm_minor *minor = adev->ddev->primary; - struct dentry *root = minor->debugfs_root, *dir; - struct dentry *ent; - - dir = debugfs_create_dir("ras", root); - if (IS_ERR(dir)) - return -EINVAL; - con->dir = dir; - - ent = debugfs_create_file("ras_ctrl", - S_IWUGO | S_IRUGO, con->dir, - adev, _ras_debugfs_ctrl_ops); - if (IS_ERR(ent)) { - debugfs_remove(con->dir); - return -EINVAL; - } - - con->ent = ent; - return 0; + con->dir = debugfs_create_dir("ras", minor->debugfs_root); + con->ent = debugfs_create_file("ras_ctrl", S_IWUGO | S_IRUGO, con->dir, + adev, _ras_debugfs_ctrl_ops); } -int amdgpu_ras_debugfs_create(struct amdgpu_device *adev, +void amdgpu_ras_debugfs_create(struct amdgpu_device *adev, struct ras_fs_if *head) { struct amdgpu_ras *con = amdgpu_ras_get_context(adev); struct ras_manager *obj = amdgpu_ras_find_obj(adev, >head); - struct dentry *ent; if (!obj || obj->ent) - return -EINVAL; + return; get_obj(obj); @@ -874,34 +858,25 @@ int amdgpu_ras_debugfs_create(struct amdgpu_device *adev, head->debugfs_name, sizeof(obj->fs_data.debugfs_name)); - ent = debugfs_create_file(obj->fs_data.debugfs_name, - S_IWUGO | S_IRUGO, con->dir, - obj, _ras_debugfs_ops); - - if (IS_ERR(ent)) - return -EINVAL; - - obj->ent = ent; - - return 0; + obj->ent = debugfs_create_file(obj->fs_data.debugfs_name, + S_IWUGO | S_IRUGO, con->dir, obj, + _ras_debugfs_ops); } -int amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, +void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, struct ras_common_if *head) { struct ras_manager *obj = amdgpu_ras_find_obj(adev, head); if (!obj || !obj->ent) - return 0; + return; debugfs_remove(obj->ent); obj->ent = NULL; put_obj(obj); - - return 0; } -static int amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev) +static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev) { struct amdgpu_ras *con = amdgpu_ras_get_context(adev); struct ras_manager *obj, *tmp; @@ -914,8 +889,6 @@ static int amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev) debugfs_remove(con->dir); con->dir = NULL; con->ent = NULL; - - return 0; } /* debugfs end */ diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h index eaef5edefc34..7869ad18e7c1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h @@ -271,10 +271,10 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device *adev, int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev, struct ras_common_if *head); -int amdgpu_ras_debugfs_create(struct amdgpu_device *adev, +void amdgpu_ras_debugfs_create(struct amdgpu_device *adev, struct ras_fs_if *head); -int amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, +void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev, struct ras_common_i
[PATCH] amdgpu_dm: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Daniel Vetter Cc: Nicholas Kazlauskas Cc: David Francis Cc: Mario Kleiner Cc: Bhawanpreet Lakha Cc: Anthony Koo Cc: hersen wu Cc: "Leo (Hanghong) Ma" Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +--- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 35 ++- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.h | 2 +- 3 files changed, 12 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index bcb1a93c0b4c..cd10b0825087 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4825,11 +4825,7 @@ static int amdgpu_dm_connector_init(struct amdgpu_display_manager *dm, drm_connector_register(>base); #if defined(CONFIG_DEBUG_FS) - res = connector_debugfs_init(aconnector); - if (res) { - DRM_ERROR("Failed to create debugfs for connector"); - goto out_free; - } + connector_debugfs_init(aconnector); aconnector->debugfs_dpcd_address = 0; aconnector->debugfs_dpcd_size = 0; #endif diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c index 1d5fc5ad3bee..2b9ea1b67c9a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -873,25 +873,19 @@ static const struct { {"aux_dpcd_data", _dpcd_data_debugfs_fops} }; -int connector_debugfs_init(struct amdgpu_dm_connector *connector) +void connector_debugfs_init(struct amdgpu_dm_connector *connector) { int i; - struct dentry *ent, *dir = connector->base.debugfs_entry; + struct dentry *dir = connector->base.debugfs_entry; if (connector->base.connector_type == DRM_MODE_CONNECTOR_DisplayPort || connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) { for (i = 0; i < ARRAY_SIZE(dp_debugfs_entries); i++) { - ent = debugfs_create_file(dp_debugfs_entries[i].name, - 0644, - dir, - connector, - dp_debugfs_entries[i].fops); - if (IS_ERR(ent)) - return PTR_ERR(ent); + debugfs_create_file(dp_debugfs_entries[i].name, + 0644, dir, connector, + dp_debugfs_entries[i].fops); } } - - return 0; } /* @@ -1034,7 +1028,7 @@ int dtn_debugfs_init(struct amdgpu_device *adev) }; struct drm_minor *minor = adev->ddev->primary; - struct dentry *ent, *root = minor->debugfs_root; + struct dentry *root = minor->debugfs_root; int ret; ret = amdgpu_debugfs_add_files(adev, amdgpu_dm_debugfs_list, @@ -1042,20 +1036,11 @@ int dtn_debugfs_init(struct amdgpu_device *adev) if (ret) return ret; - ent = debugfs_create_file( - "amdgpu_dm_dtn_log", - 0644, - root, - adev, - _log_fops); - - if (IS_ERR(ent)) - return PTR_ERR(ent); + debugfs_create_file("amdgpu_dm_dtn_log", 0644, root, adev, + _log_fops); - ent = debugfs_create_file_unsafe("amdgpu_dm_visual_confirm", 0644, root, -adev, _confirm_fops); - if (IS_ERR(ent)) - return PTR_ERR(ent); + debugfs_create_file_unsafe("amdgpu_dm_visual_confirm", 0644, root, adev, + _confirm_fops); return 0; } diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h index bdef1587b0a0..5e5b2b2afa31 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.h @@ -29,7 +29,7 @@ #include "amdgpu.h" #include "amdgpu_dm.h" -int connector_debugfs_init(struct amdgpu_dm_connector *connector); +void connector_debugfs_init(struct amdgpu_dm_connector *connector); int dtn_debugfs_init(str
[PATCH] radeon: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/radeon/radeon_ttm.c | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5d42f8d8e68d..6bbccc796e40 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -1056,19 +1056,14 @@ static int radeon_ttm_debugfs_init(struct radeon_device *rdev) unsigned count; struct drm_minor *minor = rdev->ddev->primary; - struct dentry *ent, *root = minor->debugfs_root; - - ent = debugfs_create_file("radeon_vram", S_IFREG | S_IRUGO, root, - rdev, _ttm_vram_fops); - if (IS_ERR(ent)) - return PTR_ERR(ent); - rdev->mman.vram = ent; - - ent = debugfs_create_file("radeon_gtt", S_IFREG | S_IRUGO, root, - rdev, _ttm_gtt_fops); - if (IS_ERR(ent)) - return PTR_ERR(ent); - rdev->mman.gtt = ent; + struct dentry *root = minor->debugfs_root; + + rdev->mman.vram = debugfs_create_file("radeon_vram", S_IFREG | S_IRUGO, + root, rdev, + _ttm_vram_fops); + + rdev->mman.gtt = debugfs_create_file("radeon_gtt", S_IFREG | S_IRUGO, +root, rdev, _ttm_gtt_fops); count = ARRAY_SIZE(radeon_ttm_debugfs_list); -- 2.22.0 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5.0 13/25] drm: disable uncached DMA optimization for ARM and arm64
5.0-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memor return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4.14 127/135] drm: disable uncached DMA optimization for ARM and arm64
4.14-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index beab0f0d0cfb..250e2d13c61b 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -45,6 +45,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4.19 134/149] drm: disable uncached DMA optimization for ARM and arm64
4.19-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index bfe1639df02d..97fc498dc767 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4.9 91/96] drm: disable uncached DMA optimization for ARM and arm64
4.9-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index cebecff536a3..c5fb6f871930 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -41,6 +41,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4.20 160/171] drm: disable uncached DMA optimization for ARM and arm64
4.20-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index bfe1639df02d..97fc498dc767 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote: > The .ioctl and .compat_ioctl file operations have the same prototype so > they can both point to the same function, which works great almost all > the time when all the commands are compatible. > > One exception is the s390 architecture, where a compat pointer is only > 31 bit wide, and converting it into a 64-bit pointer requires calling > compat_ptr(). Most drivers here will ever run in s390, but since we now > have a generic helper for it, it's easy enough to use it consistently. > > I double-checked all these drivers to ensure that all ioctl arguments > are used as pointers or are ignored, but are not interpreted as integer > values. > > Signed-off-by: Arnd Bergmann Acked-by: Greg Kroah-Hartman ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm: Print unadorned pointers
On Wed, Apr 18, 2018 at 12:24:50PM +0300, Alexey Brodkin wrote: > After commit ad67b74 ("printk: hash addresses printed with %p") > pointers are being hashed when printed. However, this makes > debug output completely useless. Switch to %px in order to see the > unadorned kernel pointers. > > This was done with the following one-liner: > find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i > '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} + > > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Tobin C. Harding <m...@tobin.cc> > Cc: Alex Deucher <alexander.deuc...@amd.com> > Cc: Andrey Grodzovsky <andrey.grodzov...@amd.com> > Cc: Arnd Bergmann <a...@arndb.de> > Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org> > Cc: Chen-Yu Tsai <w...@csie.org> > Cc: Christian Gmeiner <christian.gmei...@gmail.com> > Cc: "Christian König" <christian.koe...@amd.com> > Cc: Cihangir Akturk <cakt...@gmail.com> > Cc: CK Hu <ck...@mediatek.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Dave Airlie <airl...@redhat.com> > Cc: David Airlie <airl...@linux.ie> > Cc: "David (ChunMing) Zhou" <david1.z...@amd.com> > Cc: Gerd Hoffmann <kra...@redhat.com> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: Gustavo Padovan <gust...@padovan.org> > Cc: Harry Wentland <harry.wentl...@amd.com> > Cc: "Heiko Stübner" <he...@sntech.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: "Jerry (Fangzhi) Zuo" <jerry@amd.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Krzysztof Kozlowski <k...@kernel.org> > Cc: "Leo (Sunpeng) Li" <sunpeng...@amd.com> > Cc: Lucas Stach <l.st...@pengutronix.de> > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Matthias Brugger <matthias@gmail.com> > Cc: Maxime Ripard <maxime.rip...@bootlin.com> > Cc: "Michel Dänzer" <michel.daen...@amd.com> > Cc: Oded Gabbay <oded.gab...@gmail.com> > Cc: Philipp Zabel <p.za...@pengutronix.de> > Cc: Rob Clark <robdcl...@gmail.com> > Cc: Rodrigo Vivi <rodrigo.v...@intel.com> > Cc: Roger He <hongbo...@amd.com> > Cc: Roman Li <roman...@amd.com> > Cc: Russell King <li...@armlinux.org.uk> > Cc: Samuel Li <samuel...@amd.com> > Cc: Sandy Huang <h...@rock-chips.com> > Cc: Sean Paul <seanp...@chromium.org> > Cc: Shirish S <shiris...@amd.com> > Cc: Sinclair Yeh <s...@vmware.com> > Cc: Thomas Hellstrom <thellst...@vmware.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: Tony Cheng <tony.ch...@amd.com> > Cc: Vincent Abriou <vincent.abr...@st.com> > Cc: VMware Graphics <linux-graphics-maintai...@vmware.com> > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: etna...@lists.freedesktop.org > Cc: freedr...@lists.freedesktop.org > Cc: amd-gfx@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: virtualizat...@lists.linux-foundation.org > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++--- > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_events.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 - > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +- > drivers/gpu/drm/armada/armada_gem.c| 12 +++--- > drivers/gpu/drm/drm_atomic.c | 44 > +++--- > drivers/gpu/drm/drm_bufs.c | 8 ++-- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 +- > drivers/gpu/drm/drm_lease.c| 6 +-- > drivers/gpu/drm/drm_lock.c | 2 +- > drivers/gpu/drm/drm_scatter.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 +-- > drivers/gpu/drm/i810/i810_dm
[PATCH 4.9 121/241] drm/radeon: Fail fb creation from imported dma-bufs.
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> [ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> CC: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Sasha Levin <alexander.le...@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/gpu/drm/radeon/radeon_display.c |6 ++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1352,6 +1352,12 @@ radeon_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL); if (radeon_fb == NULL) { drm_gem_object_unreference_unlocked(obj); ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 3.18 33/68] drm/radeon: Fail fb creation from imported dma-bufs.
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> [ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> CC: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Sasha Levin <alexander.le...@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/gpu/drm/radeon/radeon_display.c |6 ++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1320,6 +1320,12 @@ radeon_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL); if (radeon_fb == NULL) { drm_gem_object_unreference_unlocked(obj); ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4.9 122/241] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> [ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> CC: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Sasha Levin <alexander.le...@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |6 ++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -533,6 +533,12 @@ amdgpu_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL); if (amdgpu_fb == NULL) { drm_gem_object_unreference_unlocked(obj); ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4.4 060/134] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> [ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rog...@canonical.com> CC: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Sasha Levin <alexander.le...@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |6 ++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -560,6 +560,12 @@ amdgpu_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL); if (amdgpu_fb == NULL) { drm_gem_object_unreference_unlocked(obj); ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx