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

[Tianci Yin]

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 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 082a0b3298a9..65caf404e7d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -66,6 +66,11 @@ MODULE_FIRMWARE("amdgpu/navi10_mec.bin");
 MODULE_FIRMWARE("amdgpu/navi10_mec2.bin");
 MODULE_FIRMWARE("amdgpu/navi10_rlc.bin");
 
+MODULE_FIRMWARE("amdgpu/navi14_ce_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_pfp_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_me_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec2_wks.bin");
 MODULE_FIRMWARE("amdgpu/navi14_ce.bin");
 MODULE_FIRMWARE("amdgpu/navi14_pfp.bin");
 MODULE_FIRMWARE("amdgpu/navi14_me.bin");
@@ -591,7 +596,8 @@ static void gfx_v10_0_check_gfxoff_flag(struct 
amdgpu_device *adev)
 static int gfx_v10_0_init_microcode(struct amdgpu_device *adev)
 {
const char *chip_name;
-   char fw_name[30];
+   char fw_name[40];
+   char wks[10];
int err;
struct amdgpu_firmware_info *info = NULL;
const struct common_firmware_header *header = NULL;
@@ -604,12 +610,16 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
 
DRM_DEBUG("\n");
 
+   memset(wks, 0, sizeof(wks));
switch (adev->asic_type) {
case CHIP_NAVI10:
chip_name = "navi10";
break;
case CHIP_NAVI14:
chip_name = "navi14";
+   if (!(adev->pdev->device == 0x7340 &&
+ adev->pdev->revision != 0x00))
+   snprintf(wks, sizeof(wks), "_wks");
break;
case CHIP_NAVI12:
chip_name = "navi12";
@@ -618,7 +628,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
BUG();
}
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.pfp_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -629,7 +639,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.pfp_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
adev->gfx.pfp_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.me_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -640,7 +650,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.me_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
adev->gfx.me_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.ce_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -705,7 +715,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
if (adev->gfx.rlc.is_rlc_v2_1)
gfx_v10_0_init_rlc_ext_microcode(adev);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.mec_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -716,7 +726,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.mec_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
adev->gfx.mec_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.mec2_fw, fw_name, adev->dev);
if (!err) {
err = amdgpu_ucode_validate(adev->gfx.mec2_fw);
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Zhang, Jack (Jian)]

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 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 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 6:47 PM
To: Deng, Emily mailto:emily.d...@amd.com>>
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
mailto:rui.t...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1074,7 +1074,10 @@ amdgpu_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);

-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+#ifdef MODULE
+   if (THIS_MODULE->state != MODULE_STATE_GOING)
+#endif
+   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
pci_disable_device(pdev);

It's a bit of a hack, but I think that this should work.

Regards,
Christian.

Am 18.09.19 um 12:29 schrieb Christian König:
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 distinct is why the function is called, if it's because of 
pci_unregister_driver(_kms_pci_driver) in amdgpu_exit() then the use 
case is valid and we should not print the error.

But if it's because somebody does something like "echo 1 > 
/sys/bus/pci/devices/\:0b\:00.1/remove" then that is invalid and we should 
print it.

We could do some hack and look at the stack trace, but that is probably not 
reliable either.

Maybe we can look at the module reference count or something like that.

Regards,
Christian.

Am 18.09.19 um 12:04 schrieb Deng, Emily:
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, September 18, 2019 5:45 PM
To: Deng, Emily 
Cc: Zhang, Jack (Jian) ; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
; Cui, Flora 

Subject: 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" 
mailto:emily.d...@amd.com>>:

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 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 4:44 PM
To: Deng, Emily mailto:emily.d...@amd.com>>
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
mailto:rui.t...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.



Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.



I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.



Regards,

Christian.





Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

Hi Christian,

 Before unloading 

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

[Zhang, Hawking]

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 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 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e941df..dd3b5dfaaa70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -150,7 +150,7 @@ struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
 };
 int amdgpu_ras_enable = -1;
-uint amdgpu_ras_mask = 0xfffb;
+uint amdgpu_ras_mask = 0x;
 
 /**
  * DOC: vramlimit (int)
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Chen, Guchun]

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 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e941df..dd3b5dfaaa70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -150,7 +150,7 @@ struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
 };
 int amdgpu_ras_enable = -1;
-uint amdgpu_ras_mask = 0xfffb;
+uint amdgpu_ras_mask = 0x;
 
 /**
  * DOC: vramlimit (int)
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Deucher, Alexander]

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
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1034,6 +1034,7 @@ static const struct pci_device_id pciidlist[] = {

 /* Navi12 */
 {0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
+   {0x1002, 0x7362, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},

 {0, 0, 0}
 };
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[jianzh]

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
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1034,6 +1034,7 @@ static const struct pci_device_id pciidlist[] = {
 
/* Navi12 */
{0x1002, 0x7360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
+   {0x1002, 0x7362, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI12},
 
{0, 0, 0}
 };
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Deng, Emily]

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] 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
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1074,7 +1074,10 @@ amdgpu_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);

-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+#ifdef MODULE
+   if (THIS_MODULE->state != MODULE_STATE_GOING)
+#endif
+   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
pci_disable_device(pdev);

It's a bit of a hack, but I think that this should work.

Regards,
Christian.

Am 18.09.19 um 12:29 schrieb Christian König:
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 distinct is why the function is called, if it's because of 
pci_unregister_driver(_kms_pci_driver) in amdgpu_exit() then the use 
case is valid and we should not print the error.

But if it's because somebody does something like "echo 1 > 
/sys/bus/pci/devices/\:0b\:00.1/remove" then that is invalid and we should 
print it.

We could do some hack and look at the stack trace, but that is probably not 
reliable either.

Maybe we can look at the module reference count or something like that.

Regards,
Christian.

Am 18.09.19 um 12:04 schrieb Deng, Emily:
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, September 18, 2019 5:45 PM
To: Deng, Emily 
Cc: Zhang, Jack (Jian) ; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
; Cui, Flora 

Subject: 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" 
mailto:emily.d...@amd.com>>:

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 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 4:44 PM
To: Deng, Emily mailto:emily.d...@amd.com>>
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
mailto:rui.t...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.



Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.



I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.



Regards,

Christian.





Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Cc: 

RE: libdrm patch merge request

[Ma, Le]

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, 2019 5:40 AM
To: Deucher, Alexander 
mailto:alexander.deuc...@amd.com>>
Cc: amd-gfx@lists.freedesktop.org 
mailto:amd-gfx@lists.freedesktop.org>>
Subject: 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
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Alex Deucher]

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 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 082a0b3298a9..b5d3e75e7e88 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -66,6 +66,11 @@ MODULE_FIRMWARE("amdgpu/navi10_mec.bin");
>  MODULE_FIRMWARE("amdgpu/navi10_mec2.bin");
>  MODULE_FIRMWARE("amdgpu/navi10_rlc.bin");
>
> +MODULE_FIRMWARE("amdgpu/navi14_ce_wks.bin");
> +MODULE_FIRMWARE("amdgpu/navi14_pfp_wks.bin");
> +MODULE_FIRMWARE("amdgpu/navi14_me_wks.bin");
> +MODULE_FIRMWARE("amdgpu/navi14_mec_wks.bin");
> +MODULE_FIRMWARE("amdgpu/navi14_mec2_wks.bin");
>  MODULE_FIRMWARE("amdgpu/navi14_ce.bin");
>  MODULE_FIRMWARE("amdgpu/navi14_pfp.bin");
>  MODULE_FIRMWARE("amdgpu/navi14_me.bin");
> @@ -591,7 +596,8 @@ static void gfx_v10_0_check_gfxoff_flag(struct 
> amdgpu_device *adev)
>  static int gfx_v10_0_init_microcode(struct amdgpu_device *adev)
>  {
> const char *chip_name;
> -   char fw_name[30];
> +   const char *wks;
> +   char fw_name[40];
> int err;
> struct amdgpu_firmware_info *info = NULL;
> const struct common_firmware_header *header = NULL;
> @@ -618,7 +624,13 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
> *adev)
> BUG();
> }
>
> -   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", chip_name);
> +   if(adev->pdev->device == 0x7340 &&
> +  adev->pdev->revision != 0x00)
> +   wks = "";
> +   else
> +   wks = "_wks";
> +
> +   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp%s.bin", chip_name, 
> wks);
> err = request_firmware(>gfx.pfp_fw, fw_name, adev->dev);
> if (err)
> goto out;
> @@ -629,7 +641,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
> *adev)
> adev->gfx.pfp_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
> adev->gfx.pfp_feature_version = 
> le32_to_cpu(cp_hdr->ucode_feature_version);
>
> -   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", chip_name);
> +   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me%s.bin", chip_name, 
> wks);
> err = request_firmware(>gfx.me_fw, fw_name, adev->dev);
> if (err)
> goto out;
> @@ -640,7 +652,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
> *adev)
> adev->gfx.me_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
> adev->gfx.me_feature_version = 
> le32_to_cpu(cp_hdr->ucode_feature_version);
>
> -   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin", chip_name);
> +   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce%s.bin", chip_name, 
> wks);
> err = request_firmware(>gfx.ce_fw, fw_name, adev->dev);
> if (err)
> goto out;
> @@ -705,7 +717,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
> *adev)
> if (adev->gfx.rlc.is_rlc_v2_1)
> gfx_v10_0_init_rlc_ext_microcode(adev);
>
> -   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);
> +   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec%s.bin", chip_name, 
> wks);
> err = request_firmware(>gfx.mec_fw, fw_name, adev->dev);
> if (err)
> goto out;
> @@ -716,7 +728,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
> *adev)
> adev->gfx.mec_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
> adev->gfx.mec_feature_version = 
> le32_to_cpu(cp_hdr->ucode_feature_version);
>
> -   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2.bin", chip_name);
> +   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2%s.bin", chip_name, 
> wks);
> err = request_firmware(>gfx.mec2_fw, fw_name, adev->dev);
> if (!err) {
> err = amdgpu_ucode_validate(adev->gfx.mec2_fw);
> --
> 2.17.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Tianci Yin]

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 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 082a0b3298a9..b5d3e75e7e88 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -66,6 +66,11 @@ MODULE_FIRMWARE("amdgpu/navi10_mec.bin");
 MODULE_FIRMWARE("amdgpu/navi10_mec2.bin");
 MODULE_FIRMWARE("amdgpu/navi10_rlc.bin");
 
+MODULE_FIRMWARE("amdgpu/navi14_ce_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_pfp_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_me_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec_wks.bin");
+MODULE_FIRMWARE("amdgpu/navi14_mec2_wks.bin");
 MODULE_FIRMWARE("amdgpu/navi14_ce.bin");
 MODULE_FIRMWARE("amdgpu/navi14_pfp.bin");
 MODULE_FIRMWARE("amdgpu/navi14_me.bin");
@@ -591,7 +596,8 @@ static void gfx_v10_0_check_gfxoff_flag(struct 
amdgpu_device *adev)
 static int gfx_v10_0_init_microcode(struct amdgpu_device *adev)
 {
const char *chip_name;
-   char fw_name[30];
+   const char *wks;
+   char fw_name[40];
int err;
struct amdgpu_firmware_info *info = NULL;
const struct common_firmware_header *header = NULL;
@@ -618,7 +624,13 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
BUG();
}
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp.bin", chip_name);
+   if(adev->pdev->device == 0x7340 &&
+  adev->pdev->revision != 0x00)
+   wks = "";
+   else
+   wks = "_wks";
+
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_pfp%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.pfp_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -629,7 +641,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.pfp_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
adev->gfx.pfp_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.me_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -640,7 +652,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.me_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
adev->gfx.me_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ce%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.ce_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -705,7 +717,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
if (adev->gfx.rlc.is_rlc_v2_1)
gfx_v10_0_init_rlc_ext_microcode(adev);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.mec_fw, fw_name, adev->dev);
if (err)
goto out;
@@ -716,7 +728,7 @@ static int gfx_v10_0_init_microcode(struct amdgpu_device 
*adev)
adev->gfx.mec_fw_version = le32_to_cpu(cp_hdr->header.ucode_version);
adev->gfx.mec_feature_version = 
le32_to_cpu(cp_hdr->ucode_feature_version);
 
-   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2.bin", chip_name);
+   snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec2%s.bin", chip_name, 
wks);
err = request_firmware(>gfx.mec2_fw, fw_name, adev->dev);
if (!err) {
err = amdgpu_ucode_validate(adev->gfx.mec2_fw);
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Navid Emamdoost]

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 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.
>
> Good catch, but please use goto error handling instead of adding more
> and more kfree calls.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Navid Emamdoost 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 10 +-
> >   1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > index eba42c752bca..dd3fa85b11c5 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > @@ -231,17 +231,21 @@ static int acp_hw_init(void *handle)
> >   adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
> >   GFP_KERNEL);
> >
> > - if (adev->acp.acp_cell == NULL)
> > + if (adev->acp.acp_cell == NULL) {
> > + kfree(adev->acp.acp_genpd);
> >   return -ENOMEM;
> > + }
> >
> >   adev->acp.acp_res = kcalloc(5, sizeof(struct resource),
> GFP_KERNEL);
> >   if (adev->acp.acp_res == NULL) {
> > + kfree(adev->acp.acp_genpd);
> >   kfree(adev->acp.acp_cell);
> >   return -ENOMEM;
> >   }
> >
> >   i2s_pdata = kcalloc(3, sizeof(struct i2s_platform_data),
> GFP_KERNEL);
> >   if (i2s_pdata == NULL) {
> > + kfree(adev->acp.acp_genpd);
> >   kfree(adev->acp.acp_res);
> >   kfree(adev->acp.acp_cell);
> >   return -ENOMEM;
> > @@ -348,6 +352,10 @@ static int acp_hw_init(void *handle)
> >   r = pm_genpd_add_device(>acp.acp_genpd->gpd, dev);
> >   if (r) {
> >   dev_err(dev, "Failed to add dev to genpd\n");
> > + kfree(adev->acp.acp_genpd);
> > + kfree(adev->acp.acp_res);
> > + kfree(adev->acp.acp_cell);
> > + kfree(i2s_pdata);
> >   return r;
> >   }
> >   }
>
>

-- 
Navid.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Lyude Paul]

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 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 stream parameters
> - Find and add VCPI slots to the state
> 
> Cc: Lyude Paul 
> Signed-off-by: Mikita Lipski 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 +++
>  1 file changed, 59 insertions(+)
> 
> 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 7b0ca2e1ed8b..d700b962d338 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4432,6 +4432,65 @@ static int dm_encoder_helper_atomic_check(struct
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state
> *conn_state)
>  {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> + struct dm_crtc_state *dm_new_crtc_state =
> to_dm_crtc_state(crtc_state);
> + const struct drm_display_mode *adjusted_mode = _state-
> >adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + int pbn, slots,clock, bpp = 0;
> +
> + if (!dm_new_crtc_state)
> + return 0;
> +
> + if (!aconnector || !aconnector->port)
> + return 0;
> +
> + mst_port = aconnector->port;
> + mst_mgr = >mst_port->mst_mgr;
> +
> + if (!mst_mgr->mst_state)
> + return 0;
> +
> + if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> + return 0;
> +
> + switch (convert_color_depth_from_display_info(connector, conn_state))
> {
> + case COLOR_DEPTH_666:
> + bpp = 6;
> + break;
> + case COLOR_DEPTH_888:
> + bpp = 8;
> + break;
> + case COLOR_DEPTH_101010:
> + bpp = 10;
> + break;
> + case COLOR_DEPTH_121212:
> + bpp = 12;
> + break;
> + case COLOR_DEPTH_141414:
> + bpp = 14;
> + break;
> + case COLOR_DEPTH_161616:
> + bpp = 16;
> + break;
> + default:
> + ASSERT(bpp != 0);
> + break;
> + }
> +
> + bpp *= 3;
> + clock = adjusted_mode->clock;
> + pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + slots = drm_dp_atomic_find_vcpi_slots(state,
> + mst_mgr,
> + mst_port,
> + pbn);
> + if (slots < 0) {
> + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
> + return slots;
> + }
>   return 0;
>  }
>  
-- 
Cheers,
Lyude Paul

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm: add drm device name

[Marek Olšák]

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, 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 or new PCI IDs. It can just select the current driver for
>> all devices which aren't supported by older drivers (which is a fixed
>> set at this point).
>>
>>
>> > The AMD-specific Mesa code will use desc to identify the chip.
>>
>> Doesn't libdrm_amdgpu's struct amdgpu_gpu_info::family_id provide the
>> same information?
>>
>
> Not for the common code, though I guess common Mesa code could use the
> INFO ioctl. Is that what you mean?
>
> Marek
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index aaf3158534ab..a83d7da259fe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -38,6 +38,7 @@
 #include "dc.h"
 #include "amdgpu_dm.h"
 #include "amdgpu_dm_irq.h"
+#include "amdgpu_dm_mst_types.h"
 
 #include "dm_helpers.h"
 
@@ -557,8 +558,24 @@ bool dm_helpers_dp_write_dsc_enable(
 )
 {
uint8_t enable_dsc = enable ? 1 : 0;
+   struct amdgpu_dm_connector *aconnector;
+
+   if (!stream)
+   return false;
+
+   if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST) {
+   aconnector = (struct amdgpu_dm_connector 
*)stream->dm_stream_context;
+
+   if (!aconnector->dsc_aux)
+   return false;
+
+   return (drm_dp_dpcd_write(aconnector->dsc_aux, DP_DSC_ENABLE, 
_dsc, 1) >= 0);
+   }
+
+   if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT)
+   return dm_helpers_dp_write_dpcd(ctx, stream->link, 
DP_DSC_ENABLE, _dsc, 1);
 
-   return dm_helpers_dp_write_dpcd(ctx, stream->sink->link, DP_DSC_ENABLE, 
_dsc, 1);
+   return false;
 }
 #endif
 
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 DPCD
is a DP feature new in DP v1.4, which exposes certain DPCD
registers on virtual ports.

v2: Remember to unlock mutex on all paths
v3: Refactor to match coding style and increase brevity

Cc: Lyude Paul 
Cc: Jani Nikula 
Cc: Harry Wentland 
Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 127 ++
 include/drm/drm_dp_mst_helper.h   |   2 +
 2 files changed, 129 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ae2f986d76a2..dd2ca065cc92 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4147,3 +4147,130 @@ static void drm_dp_mst_unregister_i2c_bus(struct 
drm_dp_aux *aux)
 {
i2c_del_adapter(>ddc);
 }
+
+/**
+ * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer Device
+ * @port: The port to check
+ *
+ * A single physical MST hub object can be represented in the topology
+ * by multiple branches, with virtual ports between those branches.
+ *
+ * As of DP1.4, An MST hub with internal (virtual) ports must expose
+ * certain DPCD registers over those ports. See sections 2.6.1.1.1
+ * and 2.6.1.1.2 of Display Port specification v1.4 for details.
+ *
+ * May acquire mgr->lock
+ *
+ * Returns:
+ * true if the port is a virtual DP peer device, false otherwise
+ */
+static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
+{
+   struct drm_dp_mst_port *downstream_port;
+
+   if (!port || port->dpcd_rev < DP_DPCD_REV_14)
+   return false;
+
+   /* Virtual DP Sink (Internal Display Panel) */
+   if (port->port_num >= 8)
+   return true;
+
+   /* DP-to-HDMI Protocol Converter */
+   if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
+   !port->mcs &&
+   port->ldps)
+   return true;
+
+   /* DP-to-DP */
+   mutex_lock(>mgr->lock);
+   if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
+   port->mstb &&
+   port->mstb->num_ports == 2) {
+   list_for_each_entry(downstream_port, >mstb->ports, next) {
+   if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
+   !downstream_port->input) {
+   mutex_unlock(>mgr->lock);
+   return true;
+   }
+   }
+   }
+   mutex_unlock(>mgr->lock);
+
+   return false;
+}
+
+/**
+ * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
+ * @port: The port to check. A leaf of the MST tree with an attached display.
+ *
+ * Depending on the situation, DSC may be enabled via the endpoint aux,
+ * the immediately upstream aux, or the connector's physical aux.
+ *
+ * This is both the correct aux to read DSC_CAPABILITY and the
+ * correct aux to write DSC_ENABLED.
+ *
+ * This operation can be expensive (up to four aux reads), so
+ * the caller should cache the return.
+ *
+ * Returns:
+ * NULL if DSC cannot be enabled on this port, otherwise the aux device
+ */
+struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
+{
+   struct drm_dp_mst_port *immediate_upstream_port;
+   struct drm_dp_mst_port *fec_port;
+
+   if (!port)
+   return NULL;
+
+   if (port->parent)
+   immediate_upstream_port = port->parent->port_parent;
+   else
+   immediate_upstream_port = NULL;
+
+   fec_port = immediate_upstream_port;
+   while (fec_port) {
+   /*
+* Each physical link (i.e. not a virtual port) between the
+* output and the primary device must support FEC
+*/
+   if (!drm_dp_mst_is_virtual_dpcd(fec_port) &&
+   !fec_port->fec_capable)
+   return NULL;
+
+   fec_port = fec_port->parent->port_parent;
+   }
+
+   /* DP-to-DP peer device */
+   if (drm_dp_mst_is_virtual_dpcd(immediate_upstream_port)) {
+   u8 upstream_dsc;
+   u8 endpoint_dsc;
+   u8 endpoint_fec;
+
+   if (drm_dp_dpcd_read(>aux,
+DP_DSC_SUPPORT, _dsc, 1) < 0)
+   return NULL;
+   if (drm_dp_dpcd_read(>aux,
+DP_FEC_CAPABILITY, _fec, 1) < 0)
+   return NULL;
+   if (drm_dp_dpcd_read(_upstream_port->aux,
+DP_DSC_SUPPORT, _dsc, 1) < 0)
+   return NULL;
+
+   /* Enpoint decompression with DP-to-DP peer 

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

[mikita.lipski]

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 FEC and DSC support

Store it on drm_dp_mst_port

Signed-off-by: David Francis 
Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 include/drm/drm_dp_mst_helper.h   | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 659099366f8b..c1a7ddfdc4bd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -552,6 +552,7 @@ static bool 
drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband
 {
int idx = 1;
repmsg->u.path_resources.port_number = (raw->msg[idx] >> 4) & 0xf;
+   repmsg->u.path_resources.fec_capable = raw->msg[idx] & 0x1;
idx++;
if (idx > raw->curlen)
goto fail_len;
@@ -2180,6 +2181,7 @@ static int drm_dp_send_enum_path_resources(struct 
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("enum path resources %d: %d %d\n", 
txmsg->reply.u.path_resources.port_number, 
txmsg->reply.u.path_resources.full_payload_bw_number,
   
txmsg->reply.u.path_resources.avail_payload_bw_number);
port->available_pbn = 
txmsg->reply.u.path_resources.avail_payload_bw_number;
+   port->fec_capable = 
txmsg->reply.u.path_resources.fec_capable;
}
}
 
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 9116b2c95239..f113ae04fa88 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -108,6 +108,8 @@ struct drm_dp_mst_port {
 * audio-capable.
 */
bool has_audio;
+
+   bool fec_capable;
 };
 
 /**
@@ -312,6 +314,7 @@ struct drm_dp_port_number_req {
 
 struct drm_dp_enum_path_resources_ack_reply {
u8 port_number;
+   bool fec_capable;
u16 full_payload_bw_number;
u16 avail_payload_bw_number;
 };
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  3 ++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 31 ++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index c36fe617eac4..1228449bca84 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -268,6 +268,9 @@ struct amdgpu_dm_connector {
struct drm_dp_mst_port *port;
struct amdgpu_dm_connector *mst_port;
struct amdgpu_encoder *mst_encoder;
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   struct drm_dp_aux *dsc_aux;
+#endif
 
/* TODO see if we can merge with ddc_bus or make a dm_connector */
struct amdgpu_i2c_adapter *i2c;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 4e1bbf5bbe77..379bc5f388f7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 #include "dm_services.h"
 #include "amdgpu.h"
 #include "amdgpu_dm.h"
@@ -189,6 +190,28 @@ static const struct drm_connector_funcs 
dm_dp_mst_connector_funcs = {
.early_unregister = amdgpu_dm_mst_connector_early_unregister,
 };
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+static bool validate_dsc_caps_on_connector(struct amdgpu_dm_connector 
*aconnector)
+{
+   struct dc_sink *dc_sink = aconnector->dc_sink;
+   struct drm_dp_mst_port *port = aconnector->port;
+   u8 dsc_caps[16] = { 0 };
+
+   aconnector->dsc_aux = drm_dp_mst_dsc_aux_for_port(port);
+
+   if (!aconnector->dsc_aux)
+   return false;
+
+   if (drm_dp_dpcd_read(aconnector->dsc_aux, DP_DSC_SUPPORT, dsc_caps, 16) 
< 0)
+   return false;
+
+   if (!dc_dsc_parse_dsc_dpcd(dsc_caps, NULL, 
_sink->sink_dsc_caps.dsc_dec_caps))
+   return false;
+
+   return true;
+}
+#endif
+
 static int dm_dp_mst_get_modes(struct drm_connector *connector)
 {
struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
@@ -231,10 +254,16 @@ static int dm_dp_mst_get_modes(struct drm_connector 
*connector)
/* dc_link_add_remote_sink returns a new reference */
aconnector->dc_sink = dc_sink;
 
-   if (aconnector->dc_sink)
+   if (aconnector->dc_sink) {
amdgpu_dm_update_freesync_caps(
connector, aconnector->edid);
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (!validate_dsc_caps_on_connector(aconnector))
+   memset(>dc_sink->sink_dsc_caps,
+  0, 
sizeof(aconnector->dc_sink->sink_dsc_caps));
+#endif
+   }
}
 
drm_connector_update_edid_property(
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 cap
-Did not take FEC into account (FEC reduces the PBN per timeslot)

For converting timing into PBN, use the new function
drm_dp_calc_pbn_mode_dsc that handles the DSC case

For converting PBN into time slots, amdgpu doesn't use the
'correct' atomic method (drm_dp_atomic_find_vcpi_slots), so
don't add a new helper to cover our approach. Use the same
means of calculating pbn per time slot as the DSC code.

Cc: Jerry Zuo 
Cc: Nicholas Kazlauskas 
Signed-off-by: David Francis 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c  | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index b151a5a51a94..aaf3158534ab 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -188,8 +188,8 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
int slots = 0;
bool ret;
int clock;
-   int bpp = 0;
int pbn = 0;
+   int pbn_per_timeslot, bpp = 0;
 
aconnector = (struct amdgpu_dm_connector *)stream->dm_stream_context;
 
@@ -233,11 +233,19 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
 
bpp = bpp * 3;
 
-   /* TODO need to know link rate */
-
-   pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (stream->timing.flags.DSC)
+   pbn = drm_dp_calc_pbn_mode(clock,
+  
stream->timing.dsc_cfg.bits_per_pixel,
+  true);
+   else
+#endif
+   pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
 
-   slots = drm_dp_find_vcpi_slots(mst_mgr, pbn);
+   /* Convert kilobits per second / 64 (for 64 timeslots) to pbn 
(54/64 megabytes per second) */
+   pbn_per_timeslot = dc_link_bandwidth_kbps(
+   stream->link, 
dc_link_get_link_cap(stream->link)) / (8 * 1000 * 54);
+   slots = DIV_ROUND_UP(pbn, pbn_per_timeslot);
ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port, pbn, slots);
 
if (!ret)
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 that stream did not change timing.

Therefore, whenever a crtc has drm_atomic_crtc_needs_modeset,
for each crtc that shares a MST topology with that stream and
supports DSC, add that crtc (and all affected connectors and
planes) to the atomic state and set mode_changed on its state

v2: Do this check only on Navi and before adding connectors
and planes on modesetting crtcs

Cc: Leo Li 
Cc: Nicholas Kazlauskas 
Cc: Lyude Paul 
Signed-off-by: David Francis 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 79 +++
 1 file changed, 79 insertions(+)

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 ba017e6bf0b4..f65326e85b86 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6704,6 +6704,74 @@ static int do_aquire_global_lock(struct drm_device *dev,
return ret < 0 ? ret : 0;
 }
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+/*
+ * TODO: This logic should at some point be moved into DRM
+ */
+static int add_affected_mst_dsc_crtcs(struct drm_atomic_state *state, struct 
drm_crtc *crtc)
+{
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_connector_list_iter conn_iter;
+   struct drm_crtc_state *new_crtc_state;
+   struct amdgpu_dm_connector *aconnector = NULL, *aconnector_to_add;
+   int i, j;
+   struct drm_crtc *crtcs_affected[AMDGPU_MAX_CRTCS] = { 0 };
+
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
+   if (conn_state->crtc != crtc)
+   continue;
+
+   aconnector = to_amdgpu_dm_connector(connector);
+   if (!aconnector->port)
+   aconnector = NULL;
+   else
+   break;
+   }
+
+   if (!aconnector)
+   return 0;
+
+   i = 0;
+   drm_connector_list_iter_begin(state->dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   if (!connector->state || !connector->state->crtc)
+   continue;
+
+   aconnector_to_add = to_amdgpu_dm_connector(connector);
+   if (!aconnector_to_add->port)
+   continue;
+
+   if (aconnector_to_add->port->mgr != aconnector->port->mgr)
+   continue;
+
+   if (!aconnector_to_add->dc_sink)
+   continue;
+
+   if 
(!aconnector_to_add->dc_sink->sink_dsc_caps.dsc_dec_caps.is_dsc_supported)
+   continue;
+
+   if (i >= AMDGPU_MAX_CRTCS)
+   continue;
+
+   crtcs_affected[i] = connector->state->crtc;
+   i++;
+   }
+   drm_connector_list_iter_end(_iter);
+
+   for (j = 0; j < i; j++) {
+   new_crtc_state = drm_atomic_get_crtc_state(state, 
crtcs_affected[j]);
+   if (IS_ERR(new_crtc_state))
+   return PTR_ERR(new_crtc_state);
+
+   new_crtc_state->mode_changed = true;
+   }
+
+   return 0;
+
+}
+#endif
+
 static void get_freesync_config_for_crtc(
struct dm_crtc_state *new_crtc_state,
struct dm_connector_state *new_con_state)
@@ -7388,6 +7456,17 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (adev->asic_type >= CHIP_NAVI10) {
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
+   ret = add_affected_mst_dsc_crtcs(state, crtc);
+   if (ret)
+   goto fail;
+   }
+   }
+   }
+#endif
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
if (!drm_atomic_crtc_needs_modeset(new_crtc_state) &&
!new_crtc_state->color_mgmt_changed &&
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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

Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_aux_dev.c | 12 ++--
 drivers/gpu/drm/drm_dp_helper.c  | 30 --
 2 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 00610bd8d6c1..0780fc358389 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -162,11 +162,7 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb, struct 
iov_iter *to)
break;
}
 
-   if (aux_dev->aux->is_remote)
-   res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
-  todo);
-   else
-   res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+   res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
 
if (res <= 0)
break;
@@ -214,11 +210,7 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb, 
struct iov_iter *from)
break;
}
 
-   if (aux_dev->aux->is_remote)
-   res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
-   todo);
-   else
-   res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
+   res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf, todo);
 
if (res <= 0)
break;
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 54a6414c5d96..0cbf10727bd6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_helper_internal.h"
@@ -272,7 +273,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
 
 /**
  * drm_dp_dpcd_read() - read a series of bytes from the DPCD
- * @aux: DisplayPort AUX channel
+ * @aux: DisplayPort AUX channel (SST or MST)
  * @offset: address of the (first) register to read
  * @buffer: buffer to store the register values
  * @size: number of bytes in @buffer
@@ -301,13 +302,18 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned 
int offset,
 * We just have to do it before any DPCD access and hope that the
 * monitor doesn't power down exactly after the throw away read.
 */
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
-1);
-   if (ret != 1)
-   goto out;
+   if (!aux->is_remote) {
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV,
+buffer, 1);
+   if (ret != 1)
+   goto out;
+   }
 
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
-size);
+   if (aux->is_remote)
+   ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
+   else
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset,
+buffer, size);
 
 out:
drm_dp_dump_access(aux, DP_AUX_NATIVE_READ, offset, buffer, ret);
@@ -317,7 +323,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read);
 
 /**
  * drm_dp_dpcd_write() - write a series of bytes to the DPCD
- * @aux: DisplayPort AUX channel
+ * @aux: DisplayPort AUX channel (SST or MST)
  * @offset: address of the (first) register to write
  * @buffer: buffer containing the values to write
  * @size: number of bytes in @buffer
@@ -334,8 +340,12 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned 
int offset,
 {
int ret;
 
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
-size);
+   if (aux->is_remote)
+   ret = drm_dp_mst_dpcd_write(aux, offset, buffer, size);
+   else
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset,
+buffer, size);
+
drm_dp_dump_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer, ret);
return ret;
 }
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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: I9d332f273dfca0cfbced111e62f5a06c5c312893
Cc: Lyude Paul 
Cc: Jani Nikula 
Cc: Harry Wentland 
Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dp_helper.c   |  4 +++-
 drivers/gpu/drm/drm_dp_mst_topology.c | 27 +++
 include/drm/drm_dp_helper.h   |  7 +++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0cbf10727bd6..c3e1da78e442 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1288,7 +1288,9 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
/* LG LP140WF6-SPM1 eDP panel */
{ OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r', 'T'), 
false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
/* Apple panels need some additional handling to support PSR */
-   { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false, 
BIT(DP_DPCD_QUIRK_NO_PSR) }
+   { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false, 
BIT(DP_DPCD_QUIRK_NO_PSR) },
+   /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
+   { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true, 
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
 };
 
 #undef OUI
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index dd2ca065cc92..4e493d8af288 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4219,6 +4219,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct 
drm_dp_mst_port *port)
 {
struct drm_dp_mst_port *immediate_upstream_port;
struct drm_dp_mst_port *fec_port;
+   struct drm_dp_desc desc = { 0 };
 
if (!port)
return NULL;
@@ -4271,6 +4272,32 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct 
drm_dp_mst_port *port)
if (drm_dp_mst_is_virtual_dpcd(port))
return >aux;
 
+   /*
+* Synaptics quirk
+* Applies to ports for which:
+* - Physical aux has Synaptics OUI
+* - DPv1.4 or higher
+* - Port is on primary branch device
+* - Not a VGA adapter (DP_DWN_STRM_PORT_TYPE_ANALOG)
+*/
+   if (!drm_dp_read_desc(port->mgr->aux, , true))
+   return NULL;
+
+   if (drm_dp_has_quirk(, DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) &&
+   port->mgr->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 &&
+   port->parent == port->mgr->mst_primary) {
+   u8 downstreamport;
+
+   if (drm_dp_dpcd_read(>aux, DP_DOWNSTREAMPORT_PRESENT,
+, 1) < 0)
+   return NULL;
+
+   if ((downstreamport & DP_DWN_STRM_PORT_PRESENT) &&
+  ((downstreamport & DP_DWN_STRM_PORT_TYPE_MASK)
+!= DP_DWN_STRM_PORT_TYPE_ANALOG))
+   return port->mgr->aux;
+   }
+
return NULL;
 }
 EXPORT_SYMBOL(drm_dp_mst_dsc_aux_for_port);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 6ae1a6765f63..919ad940bfb1 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1414,6 +1414,13 @@ enum drm_dp_quirk {
 * driver still need to implement proper handling for such device.
 */
DP_DPCD_QUIRK_NO_PSR,
+   /**
+* @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
+*
+* The device supports MST DSC despite not supporting Virtual DPCD.
+* The DSC caps can be read from the physical aux instead.
+*/
+   DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
 };
 
 /**
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 bandwidths possible for a given stream.
The [] area represents the range of DSC configs, and the ()
represents no DSC. The bandwidth used increases from left to right.

First, try disabling DSC on all streams
 [  ]  (|)
 [ ](|)
Check this against the bandwidth limits of the link and each branch
(including each endpoint). If it passes, the job is done

Second, try maximum DSC compression on all streams
that support DSC
 [| ]( )
 [|] ( )
If this does not pass, then enabling this combination of streams
is impossible

Otherwise, divide the remaining bandwidth evenly amongst the streams
 [|  ] ( )
 [|  ]( )

If one or more of the streams reach minimum compression, evenly
divide the reamining bandwidth amongst the remaining streams
 [|] ( )
 [   |]   ( )
 [ |   ]   ( )
 [ |  ]  ( )

If all streams can reach minimum compression, disable compression
greedily
 [  |]  ( )
 [|]( )
 [ ](|)

Perform this algorithm on each full update, on each MST link
with at least one DSC stream on it

After the configs are computed, call
dcn20_add_dsc_to_stream_resource on each stream with DSC enabled.
It is only after all streams are created that we can know which
of them will need DSC.

Do all of this at the end of amdgpu atomic check.  If it fails,
fail check; This combination of timings cannot be supported.

Reviewed-by: Wenjing Liu 
Signed-off-by: David Francis 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   4 +
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 386 ++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |   4 +
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |   7 +-
 .../drm/amd/display/dc/dcn20/dcn20_resource.h |   1 +
 5 files changed, 400 insertions(+), 2 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 1130298c6930..ba017e6bf0b4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7564,6 +7564,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (!compute_mst_dsc_configs_for_state(dm_state->context))
+   goto fail;
+#endif
if (dc_validate_global_state(dc, dm_state->context, false) != 
DC_OK) {
ret = -EINVAL;
goto fail;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 379bc5f388f7..0356688c5ebf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -38,6 +38,8 @@
 
 #include "i2caux_interface.h"
 
+#include "dc/dcn20/dcn20_resource.h"
+
 /* #define TRACE_DPCD */
 
 #ifdef TRACE_DPCD
@@ -490,3 +492,387 @@ void amdgpu_dm_initialize_dp_connector(struct 
amdgpu_display_manager *dm,
aconnector->connector_id);
 }
 
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+struct dsc_mst_fairness_params {
+   struct dc_crtc_timing *timing;
+   struct dc_sink *sink;
+   struct dc_dsc_bw_range bw_range;
+   bool compression_possible;
+   struct drm_dp_mst_port *port;
+};
+
+struct dsc_mst_fairness_vars {
+   int pbn;
+   bool dsc_enabled;
+   int bpp_x16;
+};
+
+static bool port_downstream_of_branch(struct drm_dp_mst_port *port,
+   struct drm_dp_mst_branch *branch)
+{
+   while (port->parent) {
+   if (port->parent == branch)
+   return true;
+
+   if (port->parent->port_parent)
+   port = port->parent->port_parent;
+   else
+   break;
+   }
+   return false;
+}
+
+static bool check_pbn_limit_on_branch(struct drm_dp_mst_branch *branch,
+   struct dsc_mst_fairness_params *params,
+   struct dsc_mst_fairness_vars *vars, int count)
+{
+   struct drm_dp_mst_port *port;
+   int i;
+   int pbn_limit = 0;
+   int pbn_used = 0;
+
+   list_for_each_entry(port, >ports, next) {
+   if (port->mstb)
+   if (!check_pbn_limit_on_branch(port->mstb, params, 
vars, count))
+   return false;
+
+   if 

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

[mikita.lipski]

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: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 3 +++
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index a519dbc5ecb6..5d6cbaebebc0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -496,6 +496,9 @@ bool dp_set_dsc_pps_sdp(struct pipe_ctx *pipe_ctx, bool 
enable)
struct dsc_config dsc_cfg;
uint8_t dsc_packed_pps[128];
 
+   memset(_cfg, 0, sizeof(dsc_cfg));
+   memset(dsc_packed_pps, 0, 128);
+
/* Enable DSC hw block */
dsc_cfg.pic_width = stream->timing.h_addressable + 
stream->timing.h_border_left + stream->timing.h_border_right;
dsc_cfg.pic_height = stream->timing.v_addressable + 
stream->timing.v_border_top + stream->timing.v_border_bottom;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index 63eb377ed9c0..296eeff00296 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -207,6 +207,9 @@ static bool dsc2_get_packed_pps(struct 
display_stream_compressor *dsc, const str
struct dsc_reg_values dsc_reg_vals;
struct dsc_optc_config dsc_optc_cfg;
 
+   memset(_reg_vals, 0, sizeof(dsc_reg_vals));
+   memset(_optc_cfg, 0, sizeof(dsc_optc_cfg));
+
DC_LOG_DSC("Getting packed DSC PPS for DSC Config:");
dsc_config_log(dsc, dsc_cfg);
DC_LOG_DSC("DSC Picture Parameter Set (PPS):");
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 Lipski 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
 1 file changed, 5 insertions(+)

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 d700b962d338..39c239a08633 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7485,6 +7485,11 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+   /* Perform validation of MST topology in the state*/
+   ret = drm_dp_mst_atomic_check(state);
+   if (ret)
+   goto fail;
+
if (state->legacy_cursor_update) {
/*
 * This is a fast cursor update coming from the plane update
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 disables sink
- Release VCPI slots on the port

Cc: Lyude Paul 
Signed-off-by: Mikita Lipski 
---
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 16218a202b59..4e1bbf5bbe77 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -252,10 +252,44 @@ static struct drm_encoder *dm_mst_best_encoder(struct 
drm_connector *connector)
return _dm_connector->mst_encoder->base;
 }
 
+static int dm_dp_mst_atomic_check(struct drm_connector *connector,
+   struct drm_connector_state *new_conn_state)
+{
+   struct drm_atomic_state *state = new_conn_state->state;
+   struct drm_connector_state *old_conn_state =
+   drm_atomic_get_old_connector_state(state, connector);
+   struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
+   struct drm_crtc_state *new_crtc_state;
+   struct drm_dp_mst_topology_mgr *mst_mgr;
+   struct drm_dp_mst_port *mst_port;
+
+   if (!aconnector || !aconnector->port)
+   return 0;
+
+   mst_port = aconnector->port;
+   mst_mgr = >mst_port->mst_mgr;
+
+   if (!old_conn_state->crtc)
+   return 0;
+
+   if (new_conn_state->crtc) {
+   new_crtc_state = drm_atomic_get_old_crtc_state(state, 
new_conn_state->crtc);
+   if (!new_crtc_state ||
+   !drm_atomic_crtc_needs_modeset(new_crtc_state) ||
+   new_crtc_state->enable)
+   return 0;
+   }
+
+   return drm_dp_atomic_release_vcpi_slots(state,
+   mst_mgr,
+   mst_port);
+}
+
 static const struct drm_connector_helper_funcs 
dm_dp_mst_connector_helper_funcs = {
.get_modes = dm_dp_mst_get_modes,
.mode_valid = amdgpu_dm_connector_mode_valid,
.best_encoder = dm_mst_best_encoder,
+   .atomic_check = dm_dp_mst_atomic_check,
 };
 
 static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 explicitly init to 0

Signed-off-by: David Francis 
Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c1a7ddfdc4bd..ae2f986d76a2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1670,6 +1670,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
mutex_lock(>mgr->lock);
drm_dp_mst_topology_get_port(port);
list_add(>next, >ports);
+   mstb->num_ports++;
mutex_unlock(>mgr->lock);
}
 
@@ -1704,6 +1705,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
/* remove it from the port list */
mutex_lock(>mgr->lock);
list_del(>next);
+   mstb->num_ports--;
mutex_unlock(>mgr->lock);
/* drop port list reference */
drm_dp_mst_topology_put_port(port);
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[mikita.lipski]

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 function for this

Change-Id: I33ef6f53c44dc32aa869aa9741ba0339aaf5e54f
Cc: amd-gfx@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Reviewed-by: Manasi Navare 
Reviewed-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
Signed-off-by: Mikita Lipski 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  8 +++-
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c|  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c| 16 
 drivers/gpu/drm/i915/intel_dp_mst.c  |  3 ++-
 drivers/gpu/drm/nouveau/dispnv50/disp.c  |  3 ++-
 drivers/gpu/drm/radeon/radeon_dp_mst.c   |  2 +-
 include/drm/drm_dp_mst_helper.h  |  3 +--
 7 files changed, 26 insertions(+), 11 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 39c239a08633..1130298c6930 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4482,7 +4482,13 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
 
bpp *= 3;
clock = adjusted_mode->clock;
-   pbn = drm_dp_calc_pbn_mode(clock, bpp);
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+   if (aconnector->dc_sink &&
+   aconnector->dc_sink->sink_dsc_caps.dsc_dec_caps.is_dsc_supported)
+   pbn = drm_dp_calc_pbn_mode(clock, bpp, true);
+   else
+#endif
+   pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
slots = drm_dp_atomic_find_vcpi_slots(state,
mst_mgr,
mst_port,
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 555af4a8c0ef..b151a5a51a94 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -235,7 +235,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
 
/* TODO need to know link rate */
 
-   pbn = drm_dp_calc_pbn_mode(clock, bpp);
+   pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
 
slots = drm_dp_find_vcpi_slots(mst_mgr, pbn);
ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port, pbn, slots);
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 398e7314ea8b..659099366f8b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3531,10 +3531,11 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
  * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
  * @clock: dot clock for the mode
  * @bpp: bpp for the mode.
+ * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
  *
  * This uses the formula in the spec to calculate the PBN value for a mode.
  */
-int drm_dp_calc_pbn_mode(int clock, int bpp)
+int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
 {
u64 kbps;
s64 peak_kbps;
@@ -3552,11 +3553,18 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
 * peak_kbps *= (1006/1000)
 * peak_kbps *= (64/54)
 * peak_kbps *= 8convert to bytes
+*
+* If the bpp is in units of 1/16, further divide by 16. Put this
+* factor in the numerator rather than the denominator to avoid
+* integer overflow
 */
 
numerator = 64 * 1006;
denominator = 54 * 8 * 1000 * 1000;
 
+   if (dsc)
+   numerator /= 16;
+
kbps *= numerator;
peak_kbps = drm_fixp_from_fraction(kbps, denominator);
 
@@ -3567,19 +3575,19 @@ EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
 static int test_calc_pbn_mode(void)
 {
int ret;
-   ret = drm_dp_calc_pbn_mode(154000, 30);
+   ret = drm_dp_calc_pbn_mode(154000, 30, false);
if (ret != 689) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
expected PBN %d, actual PBN %d.\n",
154000, 30, 689, ret);
return -EINVAL;
}
-   ret = drm_dp_calc_pbn_mode(234000, 30);
+   ret = drm_dp_calc_pbn_mode(234000, 30, false);
if (ret != 1047) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
expected PBN %d, actual PBN %d.\n",
234000, 30, 1047, ret);
return -EINVAL;
}
-   ret = drm_dp_calc_pbn_mode(297000, 24);
+   ret = drm_dp_calc_pbn_mode(297000, 24, false);
if (ret != 1063) {
DRM_ERROR("PBN 

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

[mikita.lipski]

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 stream parameters
- Find and add VCPI slots to the state

Cc: Lyude Paul 
Signed-off-by: Mikita Lipski 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 +++
 1 file changed, 59 insertions(+)

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 7b0ca2e1ed8b..d700b962d338 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4432,6 +4432,65 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
  struct drm_crtc_state *crtc_state,
  struct drm_connector_state 
*conn_state)
 {
+   struct drm_atomic_state *state = crtc_state->state;
+   struct drm_connector *connector = conn_state->connector;
+   struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
+   struct dm_crtc_state *dm_new_crtc_state = to_dm_crtc_state(crtc_state);
+   const struct drm_display_mode *adjusted_mode = 
_state->adjusted_mode;
+   struct drm_dp_mst_topology_mgr *mst_mgr;
+   struct drm_dp_mst_port *mst_port;
+   int pbn, slots,clock, bpp = 0;
+
+   if (!dm_new_crtc_state)
+   return 0;
+
+   if (!aconnector || !aconnector->port)
+   return 0;
+
+   mst_port = aconnector->port;
+   mst_mgr = >mst_port->mst_mgr;
+
+   if (!mst_mgr->mst_state)
+   return 0;
+
+   if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
+   return 0;
+
+   switch (convert_color_depth_from_display_info(connector, conn_state)) {
+   case COLOR_DEPTH_666:
+   bpp = 6;
+   break;
+   case COLOR_DEPTH_888:
+   bpp = 8;
+   break;
+   case COLOR_DEPTH_101010:
+   bpp = 10;
+   break;
+   case COLOR_DEPTH_121212:
+   bpp = 12;
+   break;
+   case COLOR_DEPTH_141414:
+   bpp = 14;
+   break;
+   case COLOR_DEPTH_161616:
+   bpp = 16;
+   break;
+   default:
+   ASSERT(bpp != 0);
+   break;
+   }
+
+   bpp *= 3;
+   clock = adjusted_mode->clock;
+   pbn = drm_dp_calc_pbn_mode(clock, bpp);
+   slots = drm_dp_atomic_find_vcpi_slots(state,
+   mst_mgr,
+   mst_port,
+   pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
+   return slots;
+   }
return 0;
 }
 
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 00/15] DSC MST support for AMDGPU

[mikita.lipski]

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 drm_mst_helper functions for
better tracking of VCPI slots.

Other 12 patches have been introduced in multiple
iterations to the mailing list before. These patches were
developed by David Francis as part of his work on DSC.

David Francis (12):
  drm/dp_mst: Add PBN calculation for DSC modes
  drm/dp_mst: Parse FEC capability on MST ports
  drm/dp_mst: Add MST support to DP DPCD R/W functions
  drm/dp_mst: Fill branch->num_ports
  drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
  drm/dp_mst: Add new quirk for Synaptics MST hubs
  drm/amd/display: Use correct helpers to compute timeslots
  drm/amd/display: Initialize DSC PPS variables to 0
  drm/amd/display: Validate DSC caps on MST endpoints
  drm/amd/display: Write DSC enable to MST DPCD
  drm/amd/display: MST DSC compute fair share
  drm/amd/display: Trigger modesets on MST DSC connectors

Mikita Lipski (3):
  drm/amdgpu: Add encoder atomic check
  drm/amdgpu: Add connector atomic check
  drm/amdgpu: validate mst topology in atomic check

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 153 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  37 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 451 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |   4 +
 .../drm/amd/display/dc/core/dc_link_hwss.c|   3 +
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c  |   3 +
 .../drm/amd/display/dc/dcn20/dcn20_resource.c |   7 +-
 .../drm/amd/display/dc/dcn20/dcn20_resource.h |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c  |  12 +-
 drivers/gpu/drm/drm_dp_helper.c   |  34 +-
 drivers/gpu/drm/drm_dp_mst_topology.c | 174 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |   3 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c|   2 +-
 include/drm/drm_dp_helper.h   |   7 +
 include/drm/drm_dp_mst_helper.h   |   8 +-
 17 files changed, 866 insertions(+), 39 deletions(-)

-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm: add drm device name

[Marek Olšák]

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 modesetting driver, that code doesn't need this kernel
> functionality or new PCI IDs. It can just select the current driver for
> all devices which aren't supported by older drivers (which is a fixed
> set at this point).
>
>
> > The AMD-specific Mesa code will use desc to identify the chip.
>
> Doesn't libdrm_amdgpu's struct amdgpu_gpu_info::family_id provide the
> same information?
>

Not for the common code, though I guess common Mesa code could use the INFO
ioctl. Is that what you mean?

Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Arnd Bergmann]

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 functionality to grab DPRX CRC 
entries.")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
 1 file changed, 2 insertions(+)

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 e1b09bb432bd..74252f57bafb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6017,7 +6017,9 @@ static void amdgpu_dm_enable_crtc_interrupts(struct 
drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
int i;
+#ifdef CONFIG_DEBUG_FS
enum amdgpu_dm_pipe_crc_source source;
+#endif
 
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
-- 
2.20.0

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

[Sven Van Asbroeck]

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;
> +   ret = -ENOMEM;
> +   goto out3;
> }

I don't see a corresponding kfree() for i2s_pdata in acp_hw_fini().
Could this be a memory leak?

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

[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 allocations should be released if pm_genpd_add_device
fails.

v2: moved the released into goto error handlings

Signed-off-by: Navid Emamdoost 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 30 +
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index eba42c752bca..c0db75b71859 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -184,7 +184,7 @@ static struct device *get_mfd_cell_dev(const char 
*device_name, int r)
  */
 static int acp_hw_init(void *handle)
 {
-   int r, i;
+   int r, i, ret;
uint64_t acp_base;
u32 val = 0;
u32 count = 0;
@@ -231,20 +231,21 @@ static int acp_hw_init(void *handle)
adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
GFP_KERNEL);
 
-   if (adev->acp.acp_cell == NULL)
-   return -ENOMEM;
+   if (adev->acp.acp_cell == NULL) {
+   ret = -ENOMEM;
+   goto out1;
+   }
 
adev->acp.acp_res = kcalloc(5, sizeof(struct resource), GFP_KERNEL);
if (adev->acp.acp_res == NULL) {
-   kfree(adev->acp.acp_cell);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto out2;
}
 
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;
+   ret = -ENOMEM;
+   goto out3;
}
 
switch (adev->asic_type) {
@@ -348,7 +349,8 @@ static int acp_hw_init(void *handle)
r = pm_genpd_add_device(>acp.acp_genpd->gpd, dev);
if (r) {
dev_err(dev, "Failed to add dev to genpd\n");
-   return r;
+   ret = r;
+   goto out4;
}
}
 
@@ -393,6 +395,16 @@ static int acp_hw_init(void *handle)
val &= ~ACP_SOFT_RESET__SoftResetAud_MASK;
cgs_write_register(adev->acp.cgs_device, mmACP_SOFT_RESET, val);
return 0;
+
+out4:
+   kfree(i2s_pdata);
+out3:
+   kfree(adev->acp.acp_res);
+out2:
+   kfree(adev->acp.acp_cell);
+out1:
+   kfree(adev->acp.acp_genpd);
+   return ret;
 }
 
 /**
-- 
2.17.1

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

[Christian König]

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
index d497467b7fc6..94908bf269a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -139,7 +139,12 @@ int amdgpu_bo_list_create(struct amdgpu_device *adev, 
struct drm_file *filp,
return 0;
 
 error_free:
-   while (i--) {
+   for (i = 0; i < last_entry; ++i) {
+   struct amdgpu_bo *bo = ttm_to_amdgpu_bo(array[i].tv.bo);
+
+   amdgpu_bo_unref();
+   }
+   for (i = first_userptr; i < num_entries; ++i) {
struct amdgpu_bo *bo = ttm_to_amdgpu_bo(array[i].tv.bo);
 
amdgpu_bo_unref();
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Koenig, Christian]

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 allocations should be released if pm_genpd_add_device
> fails.

Good catch, but please use goto error handling instead of adding more 
and more kfree calls.

Regards,
Christian.

>
> Signed-off-by: Navid Emamdoost 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 10 +-
>   1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index eba42c752bca..dd3fa85b11c5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -231,17 +231,21 @@ static int acp_hw_init(void *handle)
>   adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
>   GFP_KERNEL);
>   
> - if (adev->acp.acp_cell == NULL)
> + if (adev->acp.acp_cell == NULL) {
> + kfree(adev->acp.acp_genpd);
>   return -ENOMEM;
> + }
>   
>   adev->acp.acp_res = kcalloc(5, sizeof(struct resource), GFP_KERNEL);
>   if (adev->acp.acp_res == NULL) {
> + kfree(adev->acp.acp_genpd);
>   kfree(adev->acp.acp_cell);
>   return -ENOMEM;
>   }
>   
>   i2s_pdata = kcalloc(3, sizeof(struct i2s_platform_data), GFP_KERNEL);
>   if (i2s_pdata == NULL) {
> + kfree(adev->acp.acp_genpd);
>   kfree(adev->acp.acp_res);
>   kfree(adev->acp.acp_cell);
>   return -ENOMEM;
> @@ -348,6 +352,10 @@ static int acp_hw_init(void *handle)
>   r = pm_genpd_add_device(>acp.acp_genpd->gpd, dev);
>   if (r) {
>   dev_err(dev, "Failed to add dev to genpd\n");
> + kfree(adev->acp.acp_genpd);
> + kfree(adev->acp.acp_res);
> + kfree(adev->acp.acp_cell);
> + kfree(i2s_pdata);
>   return r;
>   }
>   }

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Allen Pais]

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 
b/drivers/gpu/drm/radeon/radeon_display.c
index bd52f15..1a41764 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -683,6 +683,10 @@ static void radeon_crtc_init(struct drm_device *dev, int 
index)
drm_mode_crtc_set_gamma_size(_crtc->base, 256);
radeon_crtc->crtc_id = index;
radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
+   if (unlikely(!radeon_crtc->flip_queue)) {
+   kfree(radeon_crtc);
+   return;
+   }
rdev->mode_info.crtcs[index] = radeon_crtc;
 
if (rdev->family >= CHIP_BONAIRE) {
-- 
1.9.1

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

[Allen Pais]

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 
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index c56ac47..caa82a8 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -62,6 +62,11 @@ int kfd_interrupt_init(struct kfd_dev *kfd)
}
 
kfd->ih_wq = alloc_workqueue("KFD IH", WQ_HIGHPRI, 1);
+   if (unlikely(!kfd->ih_wq)) {
+   fifo_free(>ih_fifo);
+   dev_err(kfd_chardev(), "Failed to allocate KFD IH workqueue\n");
+   return kfd->ih_wq;
+   }
spin_lock_init(>interrupt_lock);
 
INIT_WORK(>interrupt_work, interrupt_wq);
-- 
1.9.1

[PATCH] drm/amdgpu: fix multiple memory leaks

[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 allocations should be released if pm_genpd_add_device
fails.

Signed-off-by: Navid Emamdoost 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index eba42c752bca..dd3fa85b11c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -231,17 +231,21 @@ static int acp_hw_init(void *handle)
adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
GFP_KERNEL);
 
-   if (adev->acp.acp_cell == NULL)
+   if (adev->acp.acp_cell == NULL) {
+   kfree(adev->acp.acp_genpd);
return -ENOMEM;
+   }
 
adev->acp.acp_res = kcalloc(5, sizeof(struct resource), GFP_KERNEL);
if (adev->acp.acp_res == NULL) {
+   kfree(adev->acp.acp_genpd);
kfree(adev->acp.acp_cell);
return -ENOMEM;
}
 
i2s_pdata = kcalloc(3, sizeof(struct i2s_platform_data), GFP_KERNEL);
if (i2s_pdata == NULL) {
+   kfree(adev->acp.acp_genpd);
kfree(adev->acp.acp_res);
kfree(adev->acp.acp_cell);
return -ENOMEM;
@@ -348,6 +352,10 @@ static int acp_hw_init(void *handle)
r = pm_genpd_add_device(>acp.acp_genpd->gpd, dev);
if (r) {
dev_err(dev, "Failed to add dev to genpd\n");
+   kfree(adev->acp.acp_genpd);
+   kfree(adev->acp.acp_res);
+   kfree(adev->acp.acp_cell);
+   kfree(i2s_pdata);
return r;
}
}
-- 
2.17.1

Re: [PATCH] drm: add drm device name

[Michel Dänzer]

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 or new PCI IDs. It can just select the current driver for
all devices which aren't supported by older drivers (which is a fixed
set at this point).


> The AMD-specific Mesa code will use desc to identify the chip.

Doesn't libdrm_amdgpu's struct amdgpu_gpu_info::family_id provide the
same information?


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Andrzej Pietrasiewicz]

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 from me have their Acked-by and Reviewed-by tags
and deal with providing a ddc symlink in connector's sysfs directory.

Rebased onto drm-misc-next as of 26th August.

Andrzej Pietrasiewicz (13):
   drm/radeon: Provide ddc symlink in connector sysfs directory
   drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory
   drm/exynos: Provide ddc symlink in connector's sysfs
   drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
   drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
   drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
   drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
   drm/tegra: Provide ddc symlink in output connector sysfs directory
   drm/vc4: Provide ddc symlink in connector sysfs directory
   drm: zte: Provide ddc symlink in hdmi connector sysfs directory
   drm: zte: Provide ddc symlink in vga connector sysfs directory
   drm/tilcdc: Provide ddc symlink in connector sysfs directory
   drm/i915: Provide ddc symlink in hdmi connector sysfs directory

Geert Uytterhoeven (1):
   drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error
 message

  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   5 +-
  drivers/gpu/drm/bridge/ti-tfp410.c|   3 +-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |   6 +-
  drivers/gpu/drm/i915/display/intel_hdmi.c |  12 +-
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |   7 +-
  drivers/gpu/drm/msm/hdmi/hdmi_connector.c |   6 +-
  drivers/gpu/drm/radeon/radeon_connectors.c| 143 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |   6 +-
  drivers/gpu/drm/rockchip/rk3066_hdmi.c|   7 +-
  drivers/gpu/drm/tegra/hdmi.c  |   7 +-
  drivers/gpu/drm/tegra/sor.c   |   7 +-
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c|   6 +-
  drivers/gpu/drm/vc4/vc4_hdmi.c|  12 +-
  drivers/gpu/drm/zte/zx_hdmi.c |   6 +-
  drivers/gpu/drm/zte/zx_vga.c  |   6 +-
  15 files changed, 168 insertions(+), 71 deletions(-)

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

[Deucher, Alexander]

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 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 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 7901530d07f0..121824b47d02 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -161,7 +161,7 @@ static const struct soc15_reg_golden 
golden_settings_gc_10_1_1[] =
 SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_LDS_CLK_CTRL, 0x, 
0x),
 SOC15_REG_GOLDEN_VALUE(GC, 0, mmTA_CNTL_AUX, 0xfff7, 0x0103),
 SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CNTL, 0x6010, 0x479c0010),
-   SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0x0080, 0x0080),
+   SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0x00c0, 0x00c0),
 };

 static const struct soc15_reg_golden golden_settings_gc_10_1_nv14[] =
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: libdrm patch merge request

[Deucher, Alexander]

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 
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
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Deucher, Alexander]

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) 
Cc: Deng, Emily ; Cui, Flora ; Teng, Rui 
; amd-gfx@lists.freedesktop.org 

Subject: 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.

Regards,
Christian.



Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" :
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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang 
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) 
Subject: [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 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of
+fbcon\n");
 drm_dev_unplug(dev);
 drm_dev_put(dev);
 pci_disable_device(pdev);
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Kazlauskas, Nicholas]

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 otherwise properly supported, just needs exposing to userspace.
>
> Signed-off-by: Pierre-Loup A. Griffais 
 I know IGT has some tests for plane rotation, do you happen to know 
 what
 tests pass or fail when exposing this?

 I think DCN1 (Raven) should work as expected but I'd be concerned about
 DCE or DCN2. I think we have had some cursor bugs in the past with
 cursor rotation but they might only be exposed when used in conjunction
 with overlay planes.

>>>
>>> Windows guys had a fix (in DC) for cursor with HW rotation on DCN a few
>>> weeks ago. That might have fixed these issues.
>>>
>>> We should still make sure we can pass IGT tests that do rotation.
>>>
>>> How did you test? Weston?
>>
>> I've tested it with a patched kmscube to add the rotation property in 
>> the atomic path. 90, 180 and 270 all seem happy on Raven with that 
>> setup. I've not tested any other chip at this point.
> 
> If there's more testing you'd like me to do, would anyone point me in 
> the right direction? I'm new to all this, sorry.

I'd be mostly interested in getting IGT tests going for our CI so we 
have regular automated testing on the feature. The "kms_rotation_crc" test:

https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_rotation_crc.c

...looks like the correct test for this property but it seems like the 
test would need to be modified to use DRIVER_ANY instead of DRIVER_INTEL 
for drm_open_driver_master.

It probably needs a few "is_i915_device(...)" checks placed before 
"intel_gen(...") checks as well since we don't support i915 tiling 
modifiers nor Intel generation checks. With those modifications I'd 
imagine it'd probably run as expected but I haven't had the chance to 
try it out.

Nicholas Kazlauskas


> 
> Thanks,
>   - Pierre-Loup
> 
>>
>>>
>>> Harry
>>>
 I'd just like to make sure there's suitable testing at least if we're
 going to expose this to userspace.

 Nicholas Kazlauskas

> ---
>    drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 
>    1 file changed, 8 insertions(+)
>
> 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 45be7a2132bb..3772763c6449 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4680,6 +4680,7 @@ static int amdgpu_dm_plane_init(struct 
> amdgpu_display_manager *dm,
>    uint32_t formats[32];
>    int num_formats;
>    int res = -EPERM;
> +    unsigned int supported_rotations;
>    num_formats = get_plane_formats(plane, plane_cap, formats,
>    ARRAY_SIZE(formats));
> @@ -4711,6 +4712,13 @@ static int amdgpu_dm_plane_init(struct 
> amdgpu_display_manager *dm,
>    DRM_COLOR_YCBCR_BT709, DRM_COLOR_YCBCR_LIMITED_RANGE);
>    }
> +    supported_rotations =
> +    DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
> +    DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270;
> +
> +    drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
> +   supported_rotations);
> +
>    drm_plane_helper_add(plane, _plane_helper_funcs);
>    /* Create (reset) the plane state */
>

>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Koenig, Christian]

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
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1074,7 +1074,10 @@ amdgpu_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);

-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+#ifdef MODULE
+   if (THIS_MODULE->state != MODULE_STATE_GOING)
+#endif
+   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
pci_disable_device(pdev);

It's a bit of a hack, but I think that this should work.

Regards,
Christian.

Am 18.09.19 um 12:29 schrieb Christian König:
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 distinct is why the function is called, if it's because of 
pci_unregister_driver(_kms_pci_driver) in amdgpu_exit() then the use 
case is valid and we should not print the error.

But if it's because somebody does something like "echo 1 > 
/sys/bus/pci/devices/\:0b\:00.1/remove" then that is invalid and we should 
print it.

We could do some hack and look at the stack trace, but that is probably not 
reliable either.

Maybe we can look at the module reference count or something like that.

Regards,
Christian.

Am 18.09.19 um 12:04 schrieb Deng, Emily:
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, September 18, 2019 5:45 PM
To: Deng, Emily 
Cc: Zhang, Jack (Jian) ; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
; Cui, Flora 

Subject: 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" 
mailto:emily.d...@amd.com>>:

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 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 4:44 PM
To: Deng, Emily mailto:emily.d...@amd.com>>
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
mailto:rui.t...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.



Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.



I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.



Regards,

Christian.





Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Cc: amd-gfx@lists.freedesktop.org; Teng, 
Rui mailto:rui.t...@amd.com>>; Deng, Emily 
mailto:emily.d...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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 

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

[Tianci Yin]

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 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 7901530d07f0..121824b47d02 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -161,7 +161,7 @@ static const struct soc15_reg_golden 
golden_settings_gc_10_1_1[] =
SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_LDS_CLK_CTRL, 0x, 
0x),
SOC15_REG_GOLDEN_VALUE(GC, 0, mmTA_CNTL_AUX, 0xfff7, 0x0103),
SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CNTL, 0x6010, 0x479c0010),
-   SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0x0080, 0x0080),
+   SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0x00c0, 0x00c0),
 };
 
 static const struct soc15_reg_golden golden_settings_gc_10_1_nv14[] =
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Tianci Yin]

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 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 4e6b48859aca..7901530d07f0 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -111,7 +111,7 @@ static const struct soc15_reg_golden 
golden_settings_gc_10_1[] =
SOC15_REG_GOLDEN_VALUE(GC, 0, mmTA_CNTL_AUX, 0xfff7, 0x0103),
SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CNTL, 0x6010, 0x479c0010),
SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CGTT_CLK_CTRL, 0xfeff0fff, 
0x4100),
-   SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0x0080, 0x0080)
+   SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0x00c0, 0x00c0)
 };
 
 static const struct soc15_reg_golden golden_settings_gc_10_0_nv10[] =
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Koenig, Christian]

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 distinct is why the function is called, if it's because of 
pci_unregister_driver(_kms_pci_driver) in amdgpu_exit() then the use 
case is valid and we should not print the error.

But if it's because somebody does something like "echo 1 > 
/sys/bus/pci/devices/\:0b\:00.1/remove" then that is invalid and we should 
print it.

We could do some hack and look at the stack trace, but that is probably not 
reliable either.

Maybe we can look at the module reference count or something like that.

Regards,
Christian.

Am 18.09.19 um 12:04 schrieb Deng, Emily:
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, September 18, 2019 5:45 PM
To: Deng, Emily 
Cc: Zhang, Jack (Jian) ; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
; Cui, Flora 

Subject: 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" 
mailto:emily.d...@amd.com>>:

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 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 4:44 PM
To: Deng, Emily mailto:emily.d...@amd.com>>
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
mailto:rui.t...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.



Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.



I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.



Regards,

Christian.





Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Cc: amd-gfx@lists.freedesktop.org; Teng, 
Rui mailto:rui.t...@amd.com>>; Deng, Emily 
mailto:emily.d...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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.



Regards,

Christian.







Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" 
mailto:jack.zha...@amd.com>>:

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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang mailto:jack.zha...@amd.com>>
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Subject: [PATCH] drm/amdgpu/sriov: omit fbcon error under sriov or 

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

[Deng, Emily]

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, September 18, 2019 5:45 PM
To: Deng, Emily 
Cc: Zhang, Jack (Jian) ; amd-gfx@lists.freedesktop.org; 
Teng, Rui ; Cui, Flora 
Subject: 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" 
mailto:emily.d...@amd.com>>:

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 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 4:44 PM
To: Deng, Emily mailto:emily.d...@amd.com>>
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>; 
amd-gfx@lists.freedesktop.org; Teng, Rui 
mailto:rui.t...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.



Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.



I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.



Regards,

Christian.





Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Cc: amd-gfx@lists.freedesktop.org; Teng, 
Rui mailto:rui.t...@amd.com>>; Deng, Emily 
mailto:emily.d...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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.



Regards,

Christian.







Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" 
mailto:jack.zha...@amd.com>>:

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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang mailto:jack.zha...@amd.com>>
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Subject: [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 mailto:jack.zha...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently 

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

[Dave Airlie]

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
> >
> > From: Dave Airlie 
> >
> > Purelink FX-D120 (DVI over fibre extendeders) drive the HPD line low on the
> > GPU side when the monitor side device is unplugged or loses the connection.
> > However the GPU side device seems to cache EDID in this case. Per DVI spec
> > the HPD line must be driven in order for EDID to be done, but we've met
> > enough broken devices (mainly
> > VGA->DVI convertors) that do the wrong thing with HPD that we ignore
> > it if a DDC probe succeeds.
> >
> > This patch adds an option to the radeon driver to always respect HPD on DVI
> > connectors such that if the HPD line isn't driven then EDID isn't probed.
>
> Probably cleaner to make this a connector property rather than a global 
> enable, but I'm not too pressed either way.

Just wanted a way to let them set it on the command line, rather than
run a script at bootup, but maybe it's cleaner, will look into it a
bit more.

Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Koenig, Christian]

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 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) ; amd-gfx@lists.freedesktop.org; 
Teng, Rui ; Cui, Flora 
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.



Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.



I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.



Regards,

Christian.





Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Cc: amd-gfx@lists.freedesktop.org; Teng, 
Rui mailto:rui.t...@amd.com>>; Deng, Emily 
mailto:emily.d...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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.



Regards,

Christian.







Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" 
mailto:jack.zha...@amd.com>>:

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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang mailto:jack.zha...@amd.com>>
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Subject: [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 mailto:jack.zha...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of
+fbcon\n");
 drm_dev_unplug(dev);
 drm_dev_put(dev);
 pci_disable_device(pdev);
--
2.7.4



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

libdrm patch merge request

[Ma, Le]

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
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Deng, Emily]

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) ; amd-gfx@lists.freedesktop.org; 
Teng, Rui ; Cui, Flora 
Subject: 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 when amdgpu is only a 
secondary device like in the qxl case.

Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.

I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.

Regards,
Christian.


Am 18.09.2019 10:08 schrieb "Deng, Emily" 
mailto:emily.d...@amd.com>>:

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
mailto:christian.koe...@amd.com>>
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Cc: amd-gfx@lists.freedesktop.org; Teng, 
Rui mailto:rui.t...@amd.com>>; Deng, Emily 
mailto:emily.d...@amd.com>>; Cui, Flora 
mailto:flora@amd.com>>
Subject: 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.



Regards,

Christian.







Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" 
mailto:jack.zha...@amd.com>>:

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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang mailto:jack.zha...@amd.com>>
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Subject: [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 mailto:jack.zha...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of
+fbcon\n");
 drm_dev_unplug(dev);
 drm_dev_put(dev);
 pci_disable_device(pdev);
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Koenig, Christian]

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 when amdgpu is only a 
secondary device like in the qxl case.

Jack is using the correct way of doing it, e.g. using "modprobe -r" or rmmod. 
Both commands check the use count before unloading the driver instances.

I don't see a way to distingt the two cases and what Jack is doing is 
unfortunate not the common one.

Regards,
Christian.


Am 18.09.2019 10:08 schrieb "Deng, Emily" :

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 about driver unloading path?



Best wishes

Emily Deng

From: Koenig, Christian 
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) 
Cc: amd-gfx@lists.freedesktop.org; Teng, Rui ; Deng, Emily 
; Cui, Flora 
Subject: 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.



Regards,

Christian.







Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" 
mailto:jack.zha...@amd.com>>:

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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang mailto:jack.zha...@amd.com>>
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Subject: [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 mailto:jack.zha...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of
+fbcon\n");
 drm_dev_unplug(dev);
 drm_dev_put(dev);
 pci_disable_device(pdev);
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Deng, Emily]

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 about driver unloading path?

Best wishes
Emily Deng
From: Koenig, Christian 
Sent: Wednesday, September 18, 2019 3:54 PM
To: Zhang, Jack (Jian) 
Cc: amd-gfx@lists.freedesktop.org; Teng, Rui ; Deng, Emily 
; Cui, Flora 
Subject: 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.

Regards,
Christian.



Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" 
mailto:jack.zha...@amd.com>>:
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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang mailto:jack.zha...@amd.com>>
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>
Subject: [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 mailto:jack.zha...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of
+fbcon\n");
 drm_dev_unplug(dev);
 drm_dev_put(dev);
 pci_disable_device(pdev);
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Koenig, Christian]

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.

Regards,
Christian.



Am 18.09.2019 09:32 schrieb "Zhang, Jack (Jian)" :
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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang 
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) 
Subject: [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 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
 struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of
+fbcon\n");
 drm_dev_unplug(dev);
 drm_dev_put(dev);
 pci_disable_device(pdev);
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Zhang, Jack (Jian)]

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 help to review this patch?

Best wishes,
Jack

-Original Message-
From: Jack Zhang  
Sent: Wednesday, September 18, 2019 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian) 
Subject: [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 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)  {
struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of 
+fbcon\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
pci_disable_device(pdev);
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Jack Zhang]

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 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 420888e..ada2b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1103,8 +1103,9 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-
-   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
+   struct amdgpu_device *adev = dev->dev_private;
+   if (!amdgpu_sriov_vf(adev) && !amdgpu_passthrough(adev))
+   DRM_ERROR("Device removal is currently not supported outside of 
fbcon\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
pci_disable_device(pdev);
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm: add drm device name

[Pekka Paalanen]

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 Tue, Sep 17, 2019 at 10:12 AM Christian König
> > >>>  wrote:  
> >  Am 17.09.19 um 07:47 schrieb Jani Nikula:  
> > > On Mon, 16 Sep 2019, Marek Olšák  wrote:  
> > >> The purpose is to get rid of all PCI ID tables for all drivers in
> > >> userspace. (or at least stop updating them)
> > >>
> > >> Mesa common code and modesetting will use this.  
> > > I'd think this would warrant a high level description of what you want
> > > to achieve in the commit message.  
> >  And maybe explicitly call it uapi_name or even uapi_driver_name.  
> > >>> If it's uapi_name, then why do we need a new one for every generation?
> > >>> Userspace drivers tend to span a lot more than just 1 generation. And
> > >>> if you want to have per-generation data from the kernel to userspace,
> > >>> then imo that's much better suited in some amdgpu ioctl, instead of
> > >>> trying to encode that into the driver name.  
> > >>
> > >> Well we already have an IOCTL for that, but I thought the intention here
> > >> was to get rid of the PCI-ID tables in userspace to figure out which
> > >> driver to load.  
> > >
> > > That's just unrealistic in general, I'm afraid. See e.g. the ongoing
> > > transition from i965 to iris for recent Intel hardware. How is the
> > > kernel supposed to know which driver is to be used?
> > >
> > >
> > > For the Xorg modesetting driver, there's a simple solution, see
> > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/278 .
> > > Something similar can probably be done in Mesa as well.  
> >
> > Another possibility might be for Xorg to use
> > https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt
> > to determine the driver name. Then only Mesa might need any HW specific
> > code.  
> 
> How are other compositors solving this? I don't expect they have a
> pciid table like modesetting copied to all of them ...

Hi,

other compositors have no driver-specific code at all, so they do not
need to know what the driver in kernel or Mesa is, or what chip they
are running. They may report chip name and stuff in logs for the users'
amusement, but nothing more.

Even the NVIDIA proprietary driver detection happens through EGL
extension search: no-one else exposes EGLStreams.

Unless maybe if someone needs to quirk around driver bugs.


Thanks,
pq


pgpOrP6jKybqJ.pgp
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[Zhou1, Tao]

"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: [PATCH 1/2] drm/amdgpu: avoid null pointer dereference
> 
> null ptr should be checked first to avoid null ptr access
> 
> Change-Id: I85c0a096eef77cad3a34265c995b1845451e04d0
> Signed-off-by: Guchun Chen 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 090daf595469..c3090f0eb604 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1334,13 +1334,13 @@ static int amdgpu_ras_save_bad_pages(struct
> amdgpu_device *adev)  {
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
>   struct ras_err_handler_data *data;
> - struct amdgpu_ras_eeprom_control *control =
> - >psp.ras.ras->eeprom_control;
> + struct amdgpu_ras_eeprom_control *control;
>   int save_count;
> 
>   if (!con || !con->eh_data)
>   return 0;
> 
> + control = >psp.ras.ras->eeprom_control;
>   data = con->eh_data;
>   save_count = data->count - control->num_recs;
>   /* only new entries are saved */
> --
> 2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx