[PATCH] drm/amdgpu/gfx10: add support for wks firmware loading

From: "Tianci.Yin" load different cp firmware according to the DID and RID Signed-off-by: Tianci.Yin --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Reviewed & Tested-by: Jack Zhang mailto:jack.zha...@amd.com>> BR, Jack From: Deng, Emily Sent: Thursday, September 19, 2019 10:58 AM To: Koenig, Christian Cc: Zhang, Jack (Jian) ; amd-gfx@lists.freedesktop.org; Teng, Rui ; Cui, Flora Subject: RE: [PATCH] drm/amdgpu/sriov: omit fbcon error

RE: [PATCH] drm/amdgpu: enable full ras by default

Reviewed-by: Hawking Zhang Regards, Hawking -Original Message- From: Chen, Guchun Sent: 2019年9月19日 11:15 To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ; Zhou1, Tao ; Grodzovsky, Andrey Cc: Li, Candice ; Chen, Guchun Subject: [PATCH] drm/amdgpu: enable full ras by default Enable

[PATCH] drm/amdgpu: enable full ras by default

Enable full ras by default, user does not need to enable it by boot parameter. Signed-off-by: Guchun Chen --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c

Re: [PATCH] drm/amdgpu/SRIOV: add navi12 pci id for SRIOV

Reviewed-by: Alex Deucher From: amd-gfx on behalf of jia...@amd.com Sent: Wednesday, September 18, 2019 11:04 PM To: amd-gfx@lists.freedesktop.org Cc: Zhao, Jiange ; Xiao, Jack ; Deng, Emily ; Nieto, David M ; Koenig, Christian ; Yuan, Xiaojie Subject:

[PATCH] drm/amdgpu/SRIOV: add navi12 pci id for SRIOV

From: Jiange Zhao Add Navi12 PCI id support. Signed-off-by: Jiange Zhao --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 420888e941df..b52c7255e5e4 100644

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Jack, Could you please give a try about this? Both for passthrough and sriov. Best wishes Emily Deng From: Koenig, Christian Sent: Wednesday, September 18, 2019 6:47 PM To: Deng, Emily Cc: Zhang, Jack (Jian) ; amd-gfx@lists.freedesktop.org; Teng, Rui ; Cui, Flora Subject: Re: [PATCH]

RE: libdrm patch merge request

Thanks Alex. Regards, Ma Le From: Deucher, Alexander Sent: Wednesday, September 18, 2019 8:55 PM To: Ma, Le Cc: amd-gfx@lists.freedesktop.org Subject: Re: libdrm patch merge request Done. Alex From: Ma, Le mailto:le...@amd.com>> Sent: Wednesday, September 18,

Re: [PATCH] drm/amdgpu/gfx10: add support for wks firmware loading

On Wed, Sep 18, 2019 at 10:04 PM Tianci Yin wrote: > > From: "Tianci.Yin" > > load different cp firmware according to the DID and RID > > Signed-off-by: Tianci.Yin Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 24 ++-- > 1 file changed, 18

[PATCH] drm/amdgpu/gfx10: add support for wks firmware loading

From: "Tianci.Yin" load different cp firmware according to the DID and RID Signed-off-by: Tianci.Yin --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c

Re: [PATCH] drm/amdgpu: fix multiple memory leaks

Thanks Christian for the feedback, I'll send a v2. On Wed, Sep 18, 2019 at 12:31 PM Koenig, Christian wrote: > Am 18.09.19 um 18:09 schrieb Navid Emamdoost: > > In acp_hw_init there are some allocations that needs to be released in > > case of failure: > > > > 1- adev->acp.acp_genpd should be

Re: [PATCH 01/15] drm/amdgpu: Add encoder atomic check

Haven't looked at these quite yet, but I just wanted to say ahead of time that from a quick glance these look like a big step in the right direction :). Awesome work! I will review this ASAP On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote: > From: Mikita Lipski > > [why] > In

Re: [PATCH] drm: add drm device name

Let's drop this patch. Mesa will use family_id. Marek On Wed, Sep 18, 2019 at 4:10 PM Marek Olšák wrote: > On Wed, Sep 18, 2019 at 10:03 AM Michel Dänzer wrote: > >> On 2019-09-18 1:41 a.m., Marek Olšák wrote: >> > drmVersion::name = amdgpu, radeon, intel, etc. >> > drmVersion::desc = vega10,

[PATCH 13/15] drm/amd/display: Write DSC enable to MST DPCD

From: David Francis Rework the dm_helpers_write_dsc_enable callback to handle the MST case. Use the cached dsc_aux field. Reviewed-by: Wenjing Liu Signed-off-by: David Francis --- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++- 1 file changed, 18 insertions(+), 1

[PATCH 08/15] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux

From: David Francis Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED register might have to be written on the leaf port's DPCD, its parent's DPCD, or the MST manager's DPCD. This function finds the correct aux for the job. As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual

[PATCH 05/15] drm/dp_mst: Parse FEC capability on MST ports

From: David Francis As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating if FEC can be supported up to that point in the MST network. The bit is the first byte of the ENUM_PATH_RESOURCES ack reply, bottom-most bit (refer to section 2.11.9.4 of DP standard, v1.4) That value is needed for

[PATCH 12/15] drm/amd/display: Validate DSC caps on MST endpoints

From: David Francis During MST mode enumeration, if a new dc_sink is created, populate it with dsc caps as appropriate. Use drm_dp_mst_dsc_aux_for_port to get the raw caps, then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd. Reviewed-by: Wenjing Liu Signed-off-by: David Francis ---

[PATCH 10/15] drm/amd/display: Use correct helpers to compute timeslots

From: David Francis We were using drm helpers to convert a timing into its bandwidth, its bandwidth into pbn, and its pbn into timeslots These helpers -Did not take DSC timings into account -Used the link rate and lane count of the link's aux device, which are not the same as the link's current

[PATCH 15/15] drm/amd/display: Trigger modesets on MST DSC connectors

From: David Francis Whenever a connector on an MST network is attached, detached, or undergoes a modeset, the DSC configs for each stream on that topology will be recalculated. This can change their required bandwidth, requiring a full reprogramming, as though a modeset was performed, even if

[PATCH 06/15] drm/dp_mst: Add MST support to DP DPCD R/W functions

From: David Francis Instead of having drm_dp_dpcd_read/write and drm_dp_mst_dpcd_read/write as entry points into the aux code, have drm_dp_dpcd_read/write handle both. This means that DRM drivers can make MST DPCD read/writes. v2: Fix spacing v3: Dump dpcd access on MST read/writes

[PATCH 09/15] drm/dp_mst: Add new quirk for Synaptics MST hubs

From: David Francis Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not support virtual DPCD registers, but do support DSC. The DSC caps can be read from the physical aux, like in SST DSC. These hubs have many different DEVICE_IDs. Add a new quirk to detect this case. Change-Id:

[PATCH 14/15] drm/amd/display: MST DSC compute fair share

From: David Francis If there is limited link bandwidth on a MST network, it must be divided fairly between the streams on that network Implement an algorithm to determine the correct DSC config for each stream The algorithm: This [ ] ( ) represents the range of

[PATCH 11/15] drm/amd/display: Initialize DSC PPS variables to 0

From: David Francis For DSC MST, sometimes monitors would break out in full-screen static. The issue traced back to the PPS generation code, where these variables were being used uninitialized and were picking up garbage. memset to 0 to avoid this Signed-off-by: David Francis Reviewed-by:

[PATCH 03/15] drm/amdgpu: validate mst topology in atomic check

From: Mikita Lipski [why] Validate mst topology and the number of VCPI slots available for a new state. Fail if topology has no more bandwidth for a new state. [how] Pass the atomic state to drm_dp_mst_atomic_check to verify if the new topology is possible. Cc: Lyude Paul Signed-off-by: Mikita

[PATCH 02/15] drm/amdgpu: Add connector atomic check

From: Mikita Lipski [why] Complying with new MST atomic check requirements. The driver needs to call this function on every atomic check to reset the VCPI slots if new state disables [how] - Verify that it is a MST connection - Verify that old crtc state exists - Verify the new crtc state

[PATCH 07/15] drm/dp_mst: Fill branch->num_ports

From: David Francis This field on drm_dp_mst_branch was never filled It is initialized to zero when the port is kzallocced. When a port is added to the list, increment num_ports, and when a port is removed from the list, decrement num_ports. v2: remember to decrement on port removal v3: don't

[PATCH 04/15] drm/dp_mst: Add PBN calculation for DSC modes

From: David Francis With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate

[PATCH 01/15] drm/amdgpu: Add encoder atomic check

From: Mikita Lipski [why] In order to comply with new MST atomic check we have to find and add VCPI slots to the state during atomic check whenever their is a change on mode or connector. [how] - Verify that it is a MST connection - Convert new stream's clock and bpp - Calculate PBN based on

[PATCH 00/15] DSC MST support for AMDGPU

From: Mikita Lipski This set of patches is a continuation of DSC enablement patches for AMDGPU. This set enables DSC on MST. First 3 patches add atomic check functionality to encoder and connector to allocate and release VCPI slots on each state atomic check. These changes utilize newly added

Re: [PATCH] drm: add drm device name

On Wed, Sep 18, 2019 at 10:03 AM Michel Dänzer wrote: > On 2019-09-18 1:41 a.m., Marek Olšák wrote: > > drmVersion::name = amdgpu, radeon, intel, etc. > > drmVersion::desc = vega10, vega12, vega20, ... > > > > The common Mesa code will use name and desc to select the driver. > > Like the Xorg

[PATCH] drm/amd/display: hide an unused variable

Without CONFIG_DEBUG_FS, we get a warning for an unused variable: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6020:33: error: unused variable 'source' [-Werror,-Wunused-variable] Hide the variable in an #ifdef like its only users. Fixes: 14b2584636c6 ("drm/amd/display: add

Re: [PATCH v2] drm/amdgpu: fix multiple memory leaks

On Wed, Sep 18, 2019 at 3:09 PM Navid Emamdoost wrote: > > i2s_pdata = kcalloc(3, sizeof(struct i2s_platform_data), GFP_KERNEL); > if (i2s_pdata == NULL) { > - kfree(adev->acp.acp_res); > - kfree(adev->acp.acp_cell); > - return -ENOMEM; >

[PATCH v2] drm/amdgpu: fix multiple memory leaks

In acp_hw_init there are some allocations that needs to be released in case of failure: 1- adev->acp.acp_genpd should be released if any allocation attemp for adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails. 2- all of those allocations should be released if pm_genpd_add_device fails.

[PATCH] drm/amdgpu: fix error handling in amdgpu_bo_list_create

We need to drop normal and userptr BOs separately. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c

Re: [PATCH] drm/amdgpu: fix multiple memory leaks

Am 18.09.19 um 18:09 schrieb Navid Emamdoost: > In acp_hw_init there are some allocations that needs to be released in > case of failure: > > 1- adev->acp.acp_genpd should be released if any allocation attemp for > adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails. > 2- all of those

[PATCH] drm/radeon: fix a potential NULL pointer dereference

alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. Signed-off-by: Allen Pais --- drivers/gpu/drm/radeon/radeon_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_display.c

[PATCH] drm/amdkfd: fix a potential NULL pointer dereference

alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. Signed-off-by: Allen Pais --- drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c

[PATCH] drm/amdgpu: fix multiple memory leaks

In acp_hw_init there are some allocations that needs to be released in case of failure: 1- adev->acp.acp_genpd should be released if any allocation attemp for adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails. 2- all of those allocations should be released if pm_genpd_add_device fails.

Re: [PATCH] drm: add drm device name

On 2019-09-18 1:41 a.m., Marek Olšák wrote: > drmVersion::name = amdgpu, radeon, intel, etc. > drmVersion::desc = vega10, vega12, vega20, ... > > The common Mesa code will use name and desc to select the driver. Like the Xorg modesetting driver, that code doesn't need this kernel functionality

Re: [PATCH RESEND 00/14] Next round of associating ddc adapters with connectors

Hi All, A gentle ping. Andrzej W dniu 26.08.2019 o 21:25, Andrzej Pietrasiewicz pisze: I'm resending the patches which have somehow got lost: one patch from Geert and 13 patches from me. Geert's patch updates the error message to reflect the actually called function's name. Most of patches

Re: [PATCH 2/2] drm/amdgpu/gfx10: update gfx golden settings for navi14

Series is: Reviewed-by: Alex Deucher From: amd-gfx on behalf of Tianci Yin Sent: Wednesday, September 18, 2019 6:30 AM To: amd-gfx@lists.freedesktop.org Cc: Yin, Tianci (Rico) ; Zhang, Hawking Subject: [PATCH 2/2] drm/amdgpu/gfx10: update gfx golden settings

Re: libdrm patch merge request

Done. Alex From: Ma, Le Sent: Wednesday, September 18, 2019 5:40 AM To: Deucher, Alexander Cc: amd-gfx@lists.freedesktop.org Subject: libdrm patch merge request Hi Alex, Could you help to merge patch

Re: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Driver unload works fine (barring any bugs) as long as you are not using the device. E.g., unbound the fbcon and no apps are using the GPU. Alex From: amd-gfx on behalf of Koenig, Christian Sent: Wednesday, September 18, 2019 3:53 AM To: Zhang, Jack (Jian)

Re: [PATCH] drm/amd/display: Create plane rotation property

On 2019-09-17 6:53 p.m., Pierre-Loup A. Griffais wrote: > > > On 9/12/19 10:32 AM, Pierre-Loup A. Griffais wrote: >> On 9/12/19 10:22 AM, Harry Wentland wrote: >>> On 2019-09-12 1:01 p.m., Kazlauskas, Nicholas wrote: On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote: > It's

Re: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Jack & Emily, asking around a bit helped, we should be able to take a look at the module state to distinct the two use cases like this: diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 6b96a5738e57..0af134eb03e2 100644 ---

[PATCH 2/2] drm/amdgpu/gfx10: update gfx golden settings for navi14

From: "Tianci.Yin" update registers: mmUTCL1_CTRL Change-Id: I6df12555b72ba6faa926af8155b3f079e422a500 Signed-off-by: Tianci.Yin --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c

[PATCH 1/2] drm/amdgpu/gfx10: update gfx golden settings

From: "Tianci.Yin" update registers: mmUTCL1_CTRL Change-Id: Icb50fb35a427a50a06138b8b3715651eebe92b95 Signed-off-by: Tianci.Yin --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c

Re: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Emily, Do you think this is because the wrong use case? Well Jack's use case is correct, but the PCIe hot plug removal use case is incorrect. Changing it to a warning is most likely not a good idea either because it is indeed an error to try to use PCIe hot plug removal. What we need to

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Christian, Do you think this is because the wrong use case? Even we add the error log, the issue still happens. Could we change this error to warning? As for the right method to remove the driver, it shouldn’t occur issues. Best wishes Emily Deng From: Koenig, Christian Sent: Wednesday,

Re: [PATCH] radeon: add option so DVI always respect HPD over DDC

On Mon, 9 Sep 2019 at 08:52, Deucher, Alexander wrote: > > > -Original Message- > > From: amd-gfx On Behalf Of > > Dave Airlie > > Sent: Sunday, September 1, 2019 11:09 PM > > To: amd-gfx@lists.freedesktop.org > > Subject: [PATCH] radeon: add option so DVI always respect HPD over DDC > >

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Yes, exactly. The problem is that even when output is qxl or the Intel driver our driver is still loaded and forcefully removing it renders the desktop unusable. Christian. Am 18.09.2019 11:24 schrieb "Deng, Emily" : Hi Christian, Do you mean, for passthrough mode, the desktop is rendered

libdrm patch merge request

Hi Alex, Could you help to merge patch https://gitlab.freedesktop.org/lema1/drm/commit/51f3e80716578d0bf1590286e32f00f4c09c726d into drm master branch ? Thanks. Regards, Ma Le ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Christian, Do you mean, for passthrough mode, the desktop is rendered by our asic, but enduser is trying to remove the driver by hot plug? Best wishes Emily Deng From: Koenig, Christian Sent: Wednesday, September 18, 2019 4:44 PM To: Deng, Emily Cc: Zhang, Jack (Jian) ;

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Emily, Yeah, exactly that's the problem: In some cases the driver can be unloaded while it is still in use! See we added this error message because endusers tried to use PCIe hot plug to unload the driver to use the hardware for paththrough. But this will completely nuke your desktop, even

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Christian, Before unloading driver, user must sure there is not any userspace to use of amdgpu, if not, it will report driver is in use. And the unloading driver is a feature about amdgpu driver which will be easier to replace driver without rebooting VM. Do you think it has any issue

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi Jack, Well that believe is unfortunately completely wrong. The point is that ANY use of amdgpu by userspace will prevent correct driver unload, that qxl is used for the fbcon doesn't change anything here. So the patch is a clear NAK. Driver unload is not supposed to work even under SRIOV.

RE: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

Hi, Christian and folks, In virtual machines(such virt-manager), there's always a virtual graphics device existed like "qxl" as the default gfx device. So under such condition, we believe it's reasonable to unload amdgpu driver as it is not treated as the default fbcon device. Would you please

[PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or passthrough

In virtual machine, there would be a qxl or cirrus graphics device as the default master fbcon device. So for PF(passthrough mode) or SRIOV VF, it is reasonable to unload amdgpu driver. Amdgpu doesn't have to be the only fbcon device under this condition. Signed-off-by: Jack Zhang ---

Re: [PATCH] drm: add drm device name

On Tue, 17 Sep 2019 13:32:05 +0200 Daniel Vetter wrote: > On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer wrote: > > > > On 2019-09-17 11:23 a.m., Michel Dänzer wrote: > > > On 2019-09-17 10:23 a.m., Koenig, Christian wrote: > > >> Am 17.09.19 um 10:17 schrieb Daniel Vetter: > > >>> On

RE: [PATCH 1/2] drm/amdgpu: avoid null pointer dereference

"control = >eeprom_control" is suggested, apart from this, the series is: Reviewed-by: Tao Zhou > -Original Message- > From: Chen, Guchun > Sent: 2019年9月18日 11:38 > To: amd-gfx@lists.freedesktop.org; Zhang, Hawking > ; Zhou1, Tao ; > Grodzovsky, Andrey > Cc: Chen, Guchun > Subject: