Re: [PATCH] kernel/resource: optimize find_next_iomem_res

2024-06-05 Thread Greg Kroah-Hartman
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()

2024-04-09 Thread Greg Kroah-Hartman
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

2024-03-26 Thread Greg Kroah-Hartman
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

2024-03-26 Thread Greg Kroah-Hartman
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

2024-03-26 Thread Greg Kroah-Hartman
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

2024-03-04 Thread Greg Kroah-Hartman
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()

2024-02-05 Thread Greg Kroah-Hartman
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

2024-02-05 Thread Greg Kroah-Hartman
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()

2024-02-05 Thread Greg Kroah-Hartman
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

2024-02-05 Thread Greg Kroah-Hartman
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

2023-10-05 Thread Greg Kroah-Hartman
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"

2023-10-05 Thread Greg Kroah-Hartman
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

2023-08-09 Thread Greg Kroah-Hartman
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

2023-08-02 Thread Greg Kroah-Hartman
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

2023-07-21 Thread Greg Kroah-Hartman
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

2023-07-21 Thread Greg Kroah-Hartman
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

2023-07-17 Thread Greg Kroah-Hartman
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)

2023-05-13 Thread Greg Kroah-Hartman
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

2023-05-08 Thread Greg Kroah-Hartman
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

2023-05-08 Thread Greg Kroah-Hartman
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

2023-05-08 Thread Greg Kroah-Hartman
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

2023-05-08 Thread Greg Kroah-Hartman
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

2023-05-08 Thread Greg Kroah-Hartman
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()

2023-04-17 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-03-15 Thread Greg Kroah-Hartman
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

2023-01-16 Thread Greg Kroah-Hartman
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)

2023-01-12 Thread Greg Kroah-Hartman
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)

2023-01-12 Thread Greg Kroah-Hartman
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)

2023-01-10 Thread Greg Kroah-Hartman
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)

2023-01-10 Thread Greg Kroah-Hartman
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

2022-10-24 Thread Greg Kroah-Hartman
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()

2022-09-13 Thread Greg Kroah-Hartman
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()

2022-09-13 Thread Greg Kroah-Hartman
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()

2022-09-06 Thread Greg Kroah-Hartman
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()

2022-09-06 Thread Greg Kroah-Hartman
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()

2022-09-05 Thread Greg Kroah-Hartman
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()

2022-09-05 Thread Greg Kroah-Hartman
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

2022-05-13 Thread Greg Kroah-Hartman
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

2022-05-13 Thread Greg Kroah-Hartman
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

2022-05-13 Thread Greg Kroah-Hartman
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

2022-04-12 Thread Greg Kroah-Hartman
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

2022-04-12 Thread Greg Kroah-Hartman
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

2022-04-12 Thread Greg Kroah-Hartman
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

2022-04-12 Thread Greg Kroah-Hartman
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

2022-04-11 Thread Greg Kroah-Hartman
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

2022-01-07 Thread Greg Kroah-Hartman
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

2022-01-07 Thread Greg Kroah-Hartman
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

2021-11-15 Thread Greg Kroah-Hartman
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

2021-08-10 Thread Greg Kroah-Hartman
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

2021-07-15 Thread Greg Kroah-Hartman
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

2021-07-15 Thread Greg Kroah-Hartman
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

2021-07-15 Thread Greg Kroah-Hartman
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

2021-07-15 Thread Greg Kroah-Hartman
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

2021-05-12 Thread Greg Kroah-Hartman
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

2021-05-12 Thread Greg Kroah-Hartman
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

2021-05-12 Thread Greg Kroah-Hartman
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

2021-05-12 Thread Greg Kroah-Hartman
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

2021-05-10 Thread Greg Kroah-Hartman
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

2021-05-10 Thread Greg Kroah-Hartman
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

2021-05-10 Thread Greg Kroah-Hartman
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"

2021-01-07 Thread Greg Kroah-Hartman
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"

2021-01-07 Thread Greg Kroah-Hartman
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

2020-08-17 Thread Greg Kroah-Hartman
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

2020-08-17 Thread Greg Kroah-Hartman
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()

2020-07-31 Thread Greg Kroah-Hartman
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()

2020-07-31 Thread 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.

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

2020-06-23 Thread Greg Kroah-Hartman
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

2020-03-03 Thread Greg Kroah-Hartman
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

2020-03-03 Thread Greg Kroah-Hartman
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

2019-11-08 Thread Greg Kroah-Hartman
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

2019-10-25 Thread Greg Kroah-Hartman
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

2019-10-25 Thread Greg Kroah-Hartman
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*()

2019-08-05 Thread Greg Kroah-Hartman
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*()

2019-08-05 Thread Greg Kroah-Hartman
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

2019-06-13 Thread Greg Kroah-Hartman
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

2019-06-13 Thread Greg Kroah-Hartman
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

2019-06-13 Thread Greg Kroah-Hartman
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

2019-06-13 Thread Greg Kroah-Hartman
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

2019-03-12 Thread Greg Kroah-Hartman
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

2019-03-12 Thread Greg Kroah-Hartman
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

2019-03-12 Thread Greg Kroah-Hartman
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

2019-03-12 Thread Greg Kroah-Hartman
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

2019-03-12 Thread Greg Kroah-Hartman
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

2018-09-12 Thread Greg Kroah-Hartman
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

2018-04-18 Thread Greg Kroah-Hartman
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.

2018-03-19 Thread Greg Kroah-Hartman
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.

2018-03-19 Thread Greg Kroah-Hartman
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)

2018-03-19 Thread Greg Kroah-Hartman
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)

2018-03-19 Thread Greg Kroah-Hartman
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