RE: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?

2018-10-25 Thread Zhou, David(ChunMing)
Make igt for cross-driver, I think you should rename it first, not an intel 
specific. NO company wants their employee working on other company stuff.
You can rename it to DGT(drm graphics test), and published following  libdrm, 
or directly merge to libdrm, then everyone  can use it and develop it in same 
page, which is only my personal opinion. 

Regards,
David

> -Original Message-
> From: dri-devel  On Behalf Of Eric
> Anholt
> Sent: Friday, October 26, 2018 12:36 AM
> To: Sean Paul ; Daniel Vetter 
> Cc: IGT development ; Intel Graphics
> Development ; DRI Development  de...@lists.freedesktop.org>; amd-gfx@lists.freedesktop.org
> Subject: Re: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff
> mandatory?
> 
> Sean Paul  writes:
> 
> > On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> >> Hi all,
> >>
> >> This is just to collect feedback on this idea, and see whether the
> >> overall dri-devel community stands on all this. I think the past few
> >> cross-vendor uapi extensions all came with igts attached, and
> >> personally I think there's lots of value in having them: A
> >> cross-vendor interface isn't useful if every driver implements it
> >> slightly differently.
> >>
> >> I think there's 2 questions here:
> >>
> >> - Do we want to make such testcases mandatory?
> >>
> >
> > Yes, more testing == better code.
> >
> >
> >> - If yes, are we there yet, or is there something crucially missing
> >>   still?
> >
> > In my experience, no. Last week while trying to replicate an intel-gfx
> > CI failure, I tried compiling igt for one of my (intel) chromebooks.
> > It seems like cross-compilation (or, in my case, just specifying
> > prefix/ld_library_path/sbin_path) is broken on igt. If we want to
> > impose restrictions across the entire subsystem, we need to make sure
> > that everyone can build and deploy igt easily.
> >
> > I managed to hack around everything and get it working, but I still
> > haven't tried switching out the toolchain. Once we have some GitLab CI
> > to validate cross-compilation, then we can consider making IGT mandatory.
> >
> > It's possible that I'm just a meson n00b and didn't use the right
> > incantation, so maybe it already works, but then we need better
> documentation.
> >
> > I've pasted my horrible hacks below, I also didn't have libunwind, so
> > removed its usage.
> 
> I've also had to cut out libunwind for cross-compiling on many occasions.
> Worst library.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

2018-10-25 Thread Agrawal, Akshu


On 10/26/2018 8:34 AM, Alex Deucher wrote:
> On Thu, Oct 25, 2018 at 10:52 PM Agrawal, Akshu  wrote:
>>
>>
>>
>> On 10/26/2018 8:09 AM, Alex Deucher wrote:
>>> On Thu, Oct 25, 2018 at 12:27 PM S, Shirish  wrote:

 This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.

 Reason for revert:
 This patch sends  msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
 in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
 This leads to SMU failing to service the request as it is
 dependent on UVD to be powered ON, since it accesses UVD
 registers.
>>>
>>> Does this patch that is being reverted actually break something or is
>>> it ok to leave as a workaround?  It supposedly fixed display issues at
>>> 4k with video.  Reverting it will bring that back won't it?
>>>
>>> Alex
>>>
>> Yes Alex, it will break 4k video as there will be underrun. But we are
>> working on patches that will Disable memory NBPstate only for 4k videos.
>> We can have this patch in and will be posting couple of patches to fix
>> 4k videos display issues.
> 
> Can we land them all together?  Otherwise, we'll have a regressed
> state until the later fixes land.
> 
> Alex
> 
Agreed, will push them as a series.

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


Re: [PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

2018-10-25 Thread Alex Deucher
On Thu, Oct 25, 2018 at 10:52 PM Agrawal, Akshu  wrote:
>
>
>
> On 10/26/2018 8:09 AM, Alex Deucher wrote:
> > On Thu, Oct 25, 2018 at 12:27 PM S, Shirish  wrote:
> >>
> >> This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
> >>
> >> Reason for revert:
> >> This patch sends  msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
> >> in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
> >> This leads to SMU failing to service the request as it is
> >> dependent on UVD to be powered ON, since it accesses UVD
> >> registers.
> >
> > Does this patch that is being reverted actually break something or is
> > it ok to leave as a workaround?  It supposedly fixed display issues at
> > 4k with video.  Reverting it will bring that back won't it?
> >
> > Alex
> >
> Yes Alex, it will break 4k video as there will be underrun. But we are
> working on patches that will Disable memory NBPstate only for 4k videos.
> We can have this patch in and will be posting couple of patches to fix
> 4k videos display issues.

Can we land them all together?  Otherwise, we'll have a regressed
state until the later fixes land.

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


[pull] amdgpu drm-next-4.20

2018-10-25 Thread Alex Deucher
Hi Dave,

Fixes for 4.20:
- Powerplay updates for vega20
- Powerplay fixes
- DC fix for CZ and ST
- GPUVM fix
- SR-IOV fix

The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d:

  Merge tag 'drm-intel-next-fixes-2018-10-18' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-10-19 14:28:11 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.20

for you to fetch changes up to 0af5c656fdb797f74ee57414e0c07cd57406d0c3:

  drm/amdgpu: fix amdgpu_vm_fini (2018-10-25 14:04:40 -0500)


Christian König (1):
  drm/amdgpu: fix amdgpu_vm_fini

David Francis (2):
  powerplay: Respect units on max dcfclk watermark
  drm/amd/display: Disable 4k 60 HDMI on DCE11

Emily Deng (1):
  drm/amdgpu: Fix null pointer amdgpu_device_fw_loading

Evan Quan (6):
  drm/amd/powerplay: error out when force clock level under auto dpm mode V2
  drm/amd/powerplay: drop highest UCLK setting after display configuration 
change
  drm/amd/powerplay: bump the PPtable version supported
  drm/amd/powerplay: commit get_performance_level API as DAL needed
  drm/amd/powerplay: correct the clocks for DAL to be Khz unit
  drm/amd/powerplay: commonize the API for retrieving current clocks

Joseph Greathouse (1):
  drm/amd/pp: enable power limit increase in OD mode

Rex Zhu (2):
  drm/amd/display: Fix Null point error if smu ip was disabled
  drm/amdgpu: Fix null point error

 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c|  6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |  6 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c   | 16 ++--
 .../drm/amd/display/dc/dce110/dce110_resource.c|  2 +-
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 27 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c |  8 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 85 --
 .../amd/powerplay/hwmgr/vega20_processpptables.c   | 46 +---
 .../gpu/drm/amd/powerplay/inc/smu11_driver_if.h|  2 +-
 15 files changed, 131 insertions(+), 94 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

2018-10-25 Thread Agrawal, Akshu


On 10/26/2018 8:09 AM, Alex Deucher wrote:
> On Thu, Oct 25, 2018 at 12:27 PM S, Shirish  wrote:
>>
>> This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
>>
>> Reason for revert:
>> This patch sends  msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
>> in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
>> This leads to SMU failing to service the request as it is
>> dependent on UVD to be powered ON, since it accesses UVD
>> registers.
> 
> Does this patch that is being reverted actually break something or is
> it ok to leave as a workaround?  It supposedly fixed display issues at
> 4k with video.  Reverting it will bring that back won't it?
> 
> Alex
>
Yes Alex, it will break 4k video as there will be underrun. But we are
working on patches that will Disable memory NBPstate only for 4k videos.
We can have this patch in and will be posting couple of patches to fix
4k videos display issues.

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


Re: [PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

2018-10-25 Thread Alex Deucher
On Thu, Oct 25, 2018 at 12:27 PM S, Shirish  wrote:
>
> This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
>
> Reason for revert:
> This patch sends  msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
> in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
> This leads to SMU failing to service the request as it is
> dependent on UVD to be powered ON, since it accesses UVD
> registers.

Does this patch that is being reverted actually break something or is
it ok to leave as a workaround?  It supposedly fixed display issues at
4k with video.  Reverting it will bring that back won't it?

Alex

>
> This msg should ideally be sent only when the UVD is about to decode
> a 4k video.
>
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> index fef111d..53cf787 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> @@ -1228,17 +1228,14 @@ static int smu8_dpm_force_dpm_level(struct pp_hwmgr 
> *hwmgr,
>
>  static int smu8_dpm_powerdown_uvd(struct pp_hwmgr *hwmgr)
>  {
> -   if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
> -   smu8_nbdpm_pstate_enable_disable(hwmgr, true, true);
> +   if (PP_CAP(PHM_PlatformCaps_UVDPowerGating))
> return smum_send_msg_to_smc(hwmgr, PPSMC_MSG_UVDPowerOFF);
> -   }
> return 0;
>  }
>
>  static int smu8_dpm_powerup_uvd(struct pp_hwmgr *hwmgr)
>  {
> if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
> -   smu8_nbdpm_pstate_enable_disable(hwmgr, false, true);
> return smum_send_msg_to_smc_with_parameter(
> hwmgr,
> PPSMC_MSG_UVDPowerON,
> --
> 2.7.4
>
> ___
> 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] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

2018-10-25 Thread Zhu, Rex
Patch is Acked-by: Rex Zhu 

Regards
Rex

> -Original Message-
> From: S, Shirish
> Sent: Friday, October 26, 2018 12:28 AM
> To: Zhu, Rex ; Agrawal, Akshu
> ; Deucher, Alexander
> 
> Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
> Subject: [PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on
> On/OFF of UVD"
> 
> This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
> 
> Reason for revert:
> This patch sends  msg PPSMC_MSG_Disabl eLowMemoryPstate(0x002e)
> in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON
> (0x0008).
> This leads to SMU failing to service the request as it is dependent on UVD to
> be powered ON, since it accesses UVD registers.
> 
> This msg should ideally be sent only when the UVD is about to decode a 4k
> video.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> index fef111d..53cf787 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> @@ -1228,17 +1228,14 @@ static int smu8_dpm_force_dpm_level(struct
> pp_hwmgr *hwmgr,
> 
>  static int smu8_dpm_powerdown_uvd(struct pp_hwmgr *hwmgr)  {
> - if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
> - smu8_nbdpm_pstate_enable_disable(hwmgr, true, true);
> + if (PP_CAP(PHM_PlatformCaps_UVDPowerGating))
>   return smum_send_msg_to_smc(hwmgr,
> PPSMC_MSG_UVDPowerOFF);
> - }
>   return 0;
>  }
> 
>  static int smu8_dpm_powerup_uvd(struct pp_hwmgr *hwmgr)  {
>   if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
> - smu8_nbdpm_pstate_enable_disable(hwmgr, false, true);
>   return smum_send_msg_to_smc_with_parameter(
>   hwmgr,
>   PPSMC_MSG_UVDPowerON,
> --
> 2.7.4

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


RE: [PATCH] drm/amdgpu: fix reporting of failed msg sent to SMU

2018-10-25 Thread Zhu, Rex
Patch is Reviewed-by: Rex Zhu 

Rex
> -Original Message-
> From: amd-gfx  On Behalf Of S,
> Shirish
> Sent: Friday, October 26, 2018 6:37 AM
> To: Deucher, Alexander ; Zhu, Rex
> 
> Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
> Subject: [PATCH] drm/amdgpu: fix reporting of failed msg sent to SMU
> 
> Currently send_msg_to_smc_async() only report which message failed, but
> the actual failing message is the previous one, which SMU is unable to 
> service.
> 
> This patch reads the contents of register where the SMU is stuck and report
> appropriately.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> index f836d30..b1007b8 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> @@ -64,6 +64,7 @@ static uint32_t smu8_get_argument(struct pp_hwmgr
> *hwmgr)  static int smu8_send_msg_to_smc_async(struct pp_hwmgr
> *hwmgr, uint16_t msg)  {
>   int result = 0;
> + uint32_t = val;
> 
>   if (hwmgr == NULL || hwmgr->device == NULL)
>   return -EINVAL;
> @@ -71,7 +72,11 @@ static int smu8_send_msg_to_smc_async(struct
> pp_hwmgr *hwmgr, uint16_t msg)
>   result = PHM_WAIT_FIELD_UNEQUAL(hwmgr,
>   SMU_MP1_SRBM2P_RESP_0,
> CONTENT, 0);
>   if (result != 0) {
> + /* Read the last message to SMU, to report actual cause */
> + val = cgs_read_register(hwmgr->device,
> + mmSMU_MP1_SRBM2P_MSG_0);
>   pr_err("smu8_send_msg_to_smc_async (0x%04x) failed\n",
> msg);
> + pr_err("SMU still servicing msg (0x%04x)\n", val);
>   return result;
>   }
> 
> --
> 2.7.4
> 
> ___
> 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: fix reporting of failed msg sent to SMU

2018-10-25 Thread S, Shirish
Currently send_msg_to_smc_async() only report which message
failed, but the actual failing message is the previous one,
which SMU is unable to service.

This patch reads the contents of register where the SMU is stuck
and report appropriately.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
index f836d30..b1007b8 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
@@ -64,6 +64,7 @@ static uint32_t smu8_get_argument(struct pp_hwmgr *hwmgr)
 static int smu8_send_msg_to_smc_async(struct pp_hwmgr *hwmgr, uint16_t msg)
 {
int result = 0;
+   uint32_t = val;
 
if (hwmgr == NULL || hwmgr->device == NULL)
return -EINVAL;
@@ -71,7 +72,11 @@ static int smu8_send_msg_to_smc_async(struct pp_hwmgr 
*hwmgr, uint16_t msg)
result = PHM_WAIT_FIELD_UNEQUAL(hwmgr,
SMU_MP1_SRBM2P_RESP_0, CONTENT, 0);
if (result != 0) {
+   /* Read the last message to SMU, to report actual cause */
+   val = cgs_read_register(hwmgr->device,
+   mmSMU_MP1_SRBM2P_MSG_0);
pr_err("smu8_send_msg_to_smc_async (0x%04x) failed\n", msg);
+   pr_err("SMU still servicing msg (0x%04x)\n", val);
return result;
}
 
-- 
2.7.4

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


Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object

2018-10-25 Thread Chris Wilson
Quoting Chris Wilson (2018-10-25 21:20:21)
> Quoting Chris Wilson (2018-10-25 21:15:17)
> > Quoting Christian König (2018-10-04 14:12:43)
> > > No need for that any more. Just replace the list when there isn't enough
> > > room any more for the additional fence.
> > 
> > Just a heads up. After this series landed, we started hitting a
> > use-after-free when iterating the shared list.
> > 
> > <4> [109.613162] general protection fault:  [#1] PREEMPT SMP PTI
> > <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U   
> >  4.19.0-rc8-CI-CI_DRM_5035+ #1
> > <4> [109.613189] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
> > 10/17/2011
> > <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915]
> > <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 
> > 3e e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 
> > <49> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00
> > <4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246
> > <4> [109.613292] RAX:  RBX: c944bdc0 RCX: 
> > 0001
> > <4> [109.613302] RDX:  RSI:  RDI: 
> > 822474a0
> > <4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: 
> > 0001
> > <4> [109.613321] R10: 0040 R11:  R12: 
> > 88021e1641b8
> > <4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: 
> > 6b6b6b6b6b6b6b6b
> > <4> [109.613341] FS:  7f9c9fc84980() GS:880227a4() 
> > knlGS:
> > <4> [109.613352] CS:  0010 DS:  ES:  CR0: 80050033
> > <4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: 
> > 000606e0
> 
> First guess would be
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 5fb4fd461908..833698a0d548 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -169,7 +169,6 @@ void reservation_object_add_shared_fence(struct 
> reservation_object *obj,
> }
> 
> BUG_ON(fobj->shared_count >= fobj->shared_max);
> -   fobj->shared_count++;
> 
>  replace:
> /*
> @@ -177,6 +176,8 @@ void reservation_object_add_shared_fence(struct 
> reservation_object *obj,
>  * fobj->shared_count is protected by this lock too
>  */
> RCU_INIT_POINTER(fobj->shared[i], fence);
> +   if (i == fobj->shared_count)
> +   fobj->shared_count++;
> write_seqcount_end(>seq);
> preempt_enable();
>  }
> 
> Strictly, perhaps WRITE_ONCE(fobj->shared_count, i + 1); ?

Updating shared_count after setting the fence does the trick.
-Chris
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdgpu: Fix compute ring 1.0.0 failure after reset

2018-10-25 Thread Andrey Grodzovsky
Problem: After GPU reset on dGPUs with gfx8 compute ring
1.0.0 fails to pass the ring test. Ring registers inspection
shows that it's active and no hang is observed (rptr == wptr)
No significant diffs were observed between CP_HQD* registers
for the ring in good and bad shape.

Fix: No clear reason why but reversing the order of ring tests
fixes the problem.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index b2e1376..02f8ca5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -4811,8 +4811,10 @@ static int gfx_v8_0_kcq_resume(struct amdgpu_device 
*adev)
if (r)
goto done;
 
-   /* Test KCQs */
-   for (i = 0; i < adev->gfx.num_compute_rings; i++) {
+   /* Test KCQs - reversing the order of rings seems to fix ring test 
failure
+* after GPU reset
+*/
+   for (i = adev->gfx.num_compute_rings - 1; i >= 0; i--) {
ring = >gfx.compute_ring[i];
r = amdgpu_ring_test_helper(ring);
}
-- 
2.7.4

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


Re: amdgpu: [powerplay] failed to send message 148 ret is 0

2018-10-25 Thread Mikulas Patocka


On Wed, 24 Oct 2018, Mikulas Patocka wrote:

> Hi
> 
> I have a Sapphire Pulse RX 570 ITX graphics card.
> 
> On Linux, I get errors "amdgpu: [powerplay] failed to send message 148 ret 
> is 0" and the system is stuck for several seconds when they happen. The 
> card works, except for these errors and occasional delays.

I've found that PP_PCIE_DPM_MASK causes there errors. If I turn this bit 
off in amdgpu.ppfeaturemask, there are no more any errors. (and turning it 
off also fixes hibernation problems)

Should it be turned off automatically in response to these errors?

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


Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object

2018-10-25 Thread Chris Wilson
Quoting Chris Wilson (2018-10-25 21:15:17)
> Quoting Christian König (2018-10-04 14:12:43)
> > No need for that any more. Just replace the list when there isn't enough
> > room any more for the additional fence.
> 
> Just a heads up. After this series landed, we started hitting a
> use-after-free when iterating the shared list.
> 
> <4> [109.613162] general protection fault:  [#1] PREEMPT SMP PTI
> <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U
> 4.19.0-rc8-CI-CI_DRM_5035+ #1
> <4> [109.613189] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
> 10/17/2011
> <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915]
> <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 3e 
> e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 <49> 
> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00
> <4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246
> <4> [109.613292] RAX:  RBX: c944bdc0 RCX: 
> 0001
> <4> [109.613302] RDX:  RSI:  RDI: 
> 822474a0
> <4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: 
> 0001
> <4> [109.613321] R10: 0040 R11:  R12: 
> 88021e1641b8
> <4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: 
> 6b6b6b6b6b6b6b6b
> <4> [109.613341] FS:  7f9c9fc84980() GS:880227a4() 
> knlGS:
> <4> [109.613352] CS:  0010 DS:  ES:  CR0: 80050033
> <4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: 
> 000606e0

First guess would be

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 5fb4fd461908..833698a0d548 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -169,7 +169,6 @@ void reservation_object_add_shared_fence(struct 
reservation_object *obj,
}

BUG_ON(fobj->shared_count >= fobj->shared_max);
-   fobj->shared_count++;

 replace:
/*
@@ -177,6 +176,8 @@ void reservation_object_add_shared_fence(struct 
reservation_object *obj,
 * fobj->shared_count is protected by this lock too
 */
RCU_INIT_POINTER(fobj->shared[i], fence);
+   if (i == fobj->shared_count)
+   fobj->shared_count++;
write_seqcount_end(>seq);
preempt_enable();
 }

Strictly, perhaps WRITE_ONCE(fobj->shared_count, i + 1); ?
-Chris
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object

2018-10-25 Thread Chris Wilson
Quoting Christian König (2018-10-04 14:12:43)
> No need for that any more. Just replace the list when there isn't enough
> room any more for the additional fence.

Just a heads up. After this series landed, we started hitting a
use-after-free when iterating the shared list.

<4> [109.613162] general protection fault:  [#1] PREEMPT SMP PTI
<4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U
4.19.0-rc8-CI-CI_DRM_5035+ #1
<4> [109.613189] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
<4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915]
<4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 3e e8 
5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 <49> 81 7f 
08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00
<4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246
<4> [109.613292] RAX:  RBX: c944bdc0 RCX: 
0001
<4> [109.613302] RDX:  RSI:  RDI: 
822474a0
<4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: 
0001
<4> [109.613321] R10: 0040 R11:  R12: 
88021e1641b8
<4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: 
6b6b6b6b6b6b6b6b
<4> [109.613341] FS:  7f9c9fc84980() GS:880227a4() 
knlGS:
<4> [109.613352] CS:  0010 DS:  ES:  CR0: 80050033
<4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: 
000606e0
-Chris
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu/amdkfd: clean up mmhub and gfxhub includes

2018-10-25 Thread Kuehling, Felix
On 2018-10-25 2:27 p.m., Alex Deucher wrote:
> On Mon, Oct 22, 2018 at 6:25 PM Alex Deucher  wrote:
>> Use the appropriate mmhub and gfxhub headers rather than adding
>> them to the gmc9 header.
>>
>> Signed-off-by: Alex Deucher 
> Ping?

Reviewed-by: Felix Kuehling 


>
> Alex
>
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 3 ++-
>>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h  | 2 ++
>>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h | 6 --
>>  drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h   | 2 ++
>>  4 files changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
>> index 54c369091f6c..02d1d363931b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
>> @@ -46,7 +46,8 @@
>>  #include "v9_structs.h"
>>  #include "soc15.h"
>>  #include "soc15d.h"
>> -#include "gmc_v9_0.h"
>> +#include "mmhub_v1_0.h"
>> +#include "gfxhub_v1_0.h"
>>
>>  /* HACK: MMHUB and GC both have VM-related register with the same
>>   * names but different offsets. Define the MMHUB register we need here
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h 
>> b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h
>> index 206e29cad753..92d3a70cd9b1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h
>> @@ -30,5 +30,7 @@ void gfxhub_v1_0_set_fault_enable_default(struct 
>> amdgpu_device *adev,
>>   bool value);
>>  void gfxhub_v1_0_init(struct amdgpu_device *adev);
>>  u64 gfxhub_v1_0_get_mc_fb_offset(struct amdgpu_device *adev);
>> +void gfxhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
>> +   uint64_t page_table_base);
>>
>>  #endif
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h 
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h
>> index 1fd178a65e66..b030ca5ea107 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h
>> @@ -27,10 +27,4 @@
>>  extern const struct amd_ip_funcs gmc_v9_0_ip_funcs;
>>  extern const struct amdgpu_ip_block_version gmc_v9_0_ip_block;
>>
>> -/* amdgpu_amdkfd*.c */
>> -void gfxhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
>> -   uint64_t page_table_base);
>> -void mmhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
>> -   uint64_t page_table_base);
>> -
>>  #endif
>> diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h 
>> b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h
>> index bef3d0c0c117..0de0fdf98c00 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h
>> @@ -34,5 +34,7 @@ int mmhub_v1_0_set_clockgating(struct amdgpu_device *adev,
>>  void mmhub_v1_0_get_clockgating(struct amdgpu_device *adev, u32 *flags);
>>  void mmhub_v1_0_update_power_gating(struct amdgpu_device *adev,
>>  bool enable);
>> +void mmhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
>> +   uint64_t page_table_base);
>>
>>  #endif
>> --
>> 2.13.6
>>
> ___
> 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/amd/display: set backlight level limit to 1

2018-10-25 Thread Wentland, Harry
On 2018-10-25 2:58 a.m., Guttula, Suresh wrote:
> This patch will work as workaround for silicon limitation
> related to PWM dutycycle when the backlight level goes to 0.
> 
> Actually PWM value is 16 bit value and valid range from 1-65535.
> when ever user requested to set this PWM value to 0 which is not
> fall in the range, in VBIOS taken care this by limiting to 1.
> This patch here will do the same. Either driver or VBIOS can not
> pass 0 value as it is not a valid range for PWM and it will
> give a high PWM pulse which is not the intented behaviour as
> per HW constraints.
> 


Comments from Windows dev, Anthony, CCed here as well:
> In Windows, we typically never set backlight PWM value to 0.
> Windows brightness slider is from 0 - 100% brightness.
> 0% brightness maps to some non-zero value. So user never gets the chance to 
> set value to 0.
> 
> I'm not 100% sure what kind of flashing they are seeing.
> I thought 0 PWM works, and just means PWM signal always low, I think it would 
> equate to panel backlight completely being off.
> I do know of a flashing issue caused by fractional PWM at low PWM values, but 
> this would not even be at 0. The flashing problem would be anywhere from 1 - 
> 300 for example. (out of 65535)

Do you see flickering when value is at 0 or in the 1 > 0 transition? 1 would be 
65535/256 = 256 and put us right in the 1-300 range that has a flashing problem.

Harry

> Signed-off-by: suresh guttula 
> ---
>  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 492230c..38f84b2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1518,6 +1518,14 @@ static int amdgpu_dm_backlight_update_status(struct 
> backlight_device *bd)
>  {
>   struct amdgpu_display_manager *dm = bl_get_data(bd);
>  
> + /*
> +  * When we use brightness low key to reduce the brightness,
> +  * brightness level reaching to 0, with which we can see flash
> +  * screen on ui beacuse of HW limitation.To avoid that  we are
> +  * limiting level to 1
> +  */
> + if (bd->props.brightness < 1)
> + return 1;
>   if (dc_link_set_backlight_level(dm->backlight_link,
>   bd->props.brightness, 0, 0))
>   return 0;
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu/amdkfd: clean up mmhub and gfxhub includes

2018-10-25 Thread Alex Deucher
On Mon, Oct 22, 2018 at 6:25 PM Alex Deucher  wrote:
>
> Use the appropriate mmhub and gfxhub headers rather than adding
> them to the gmc9 header.
>
> Signed-off-by: Alex Deucher 

Ping?

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 3 ++-
>  drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h  | 2 ++
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h | 6 --
>  drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h   | 2 ++
>  4 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> index 54c369091f6c..02d1d363931b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> @@ -46,7 +46,8 @@
>  #include "v9_structs.h"
>  #include "soc15.h"
>  #include "soc15d.h"
> -#include "gmc_v9_0.h"
> +#include "mmhub_v1_0.h"
> +#include "gfxhub_v1_0.h"
>
>  /* HACK: MMHUB and GC both have VM-related register with the same
>   * names but different offsets. Define the MMHUB register we need here
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h 
> b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h
> index 206e29cad753..92d3a70cd9b1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h
> +++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h
> @@ -30,5 +30,7 @@ void gfxhub_v1_0_set_fault_enable_default(struct 
> amdgpu_device *adev,
>   bool value);
>  void gfxhub_v1_0_init(struct amdgpu_device *adev);
>  u64 gfxhub_v1_0_get_mc_fb_offset(struct amdgpu_device *adev);
> +void gfxhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
> +   uint64_t page_table_base);
>
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h
> index 1fd178a65e66..b030ca5ea107 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.h
> @@ -27,10 +27,4 @@
>  extern const struct amd_ip_funcs gmc_v9_0_ip_funcs;
>  extern const struct amdgpu_ip_block_version gmc_v9_0_ip_block;
>
> -/* amdgpu_amdkfd*.c */
> -void gfxhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
> -   uint64_t page_table_base);
> -void mmhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
> -   uint64_t page_table_base);
> -
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h 
> b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h
> index bef3d0c0c117..0de0fdf98c00 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h
> +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.h
> @@ -34,5 +34,7 @@ int mmhub_v1_0_set_clockgating(struct amdgpu_device *adev,
>  void mmhub_v1_0_get_clockgating(struct amdgpu_device *adev, u32 *flags);
>  void mmhub_v1_0_update_power_gating(struct amdgpu_device *adev,
>  bool enable);
> +void mmhub_v1_0_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
> +   uint64_t page_table_base);
>
>  #endif
> --
> 2.13.6
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH -next] drm/amd/powerplay: remove duplicated includes

2018-10-25 Thread Alex Deucher
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing  wrote:
>
> Remove some duplicated include.
>
> Signed-off-by: YueHaibing 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h   | 1 -
>  drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4 
>  drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 -
>  drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c | 1 -
>  drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 1 -
>  5 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
> b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> index e5a60aa..07d180ce 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> @@ -28,7 +28,6 @@
>  #include "hardwaremanager.h"
>  #include "hwmgr_ppt.h"
>  #include "ppatomctrl.h"
> -#include "hwmgr_ppt.h"
>  #include "power_state.h"
>  #include "smu_helper.h"
>
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h 
> b/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h
> index 65eb630..94bf7b6 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h
> @@ -40,10 +40,6 @@
>  #include "bif/bif_5_0_d.h"
>  #include "bif/bif_5_0_sh_mask.h"
>
> -
> -#include "bif/bif_5_0_d.h"
> -#include "bif/bif_5_0_sh_mask.h"
> -
>  #include "dce/dce_10_0_d.h"
>  #include "dce/dce_10_0_sh_mask.h"
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> index 872d382..2b2c266 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> @@ -44,7 +44,6 @@
>
>  #include "smu7_hwmgr.h"
>  #include "hardwaremanager.h"
> -#include "ppatomctrl.h"
>  #include "atombios.h"
>  #include "pppcielanes.h"
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
> index d0eb8ab..d111dd4 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
> @@ -29,7 +29,6 @@
>  #include "rv_ppsmc.h"
>  #include "smu10_driver_if.h"
>  #include "smu10.h"
> -#include "ppatomctrl.h"
>  #include "pp_debug.h"
>
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> index 9f71512..1e69300 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> @@ -40,7 +40,6 @@
>
>  #include "smu7_hwmgr.h"
>  #include "hardwaremanager.h"
> -#include "ppatomctrl.h"
>  #include "atombios.h"
>  #include "pppcielanes.h"
>
> --
> 1.8.3.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: [PATCH -next] drm/radeon/kms: remove set but not used variable 'pll'

2018-10-25 Thread Alex Deucher
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing  wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function 
> 'radeon_legacy_tv_init_restarts':
> drivers/gpu/drm/radeon/radeon_legacy_tv.c:435:21: warning:
>  variable 'pll' set but not used [-Wunused-but-set-variable]
>   struct radeon_pll *pll;
>
> It never used since introduction in commit
> 4ce001abafaf ("drm/radeon/kms: add initial radeon tv-out support.")
> Also remove related variables 'dev, rdev, radeon_crtc'
>
> Signed-off-by: YueHaibing 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_legacy_tv.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> index 4278272..3dae2c4 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> @@ -421,24 +421,14 @@ static void radeon_legacy_write_tv_restarts(struct 
> radeon_encoder *radeon_encode
>
>  static bool radeon_legacy_tv_init_restarts(struct drm_encoder *encoder)
>  {
> -   struct drm_device *dev = encoder->dev;
> -   struct radeon_device *rdev = dev->dev_private;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_tv_dac *tv_dac = radeon_encoder->enc_priv;
> -   struct radeon_crtc *radeon_crtc;
> int restart;
> unsigned int h_total, v_total, f_total;
> int v_offset, h_offset;
> u16 p1, p2, h_inc;
> bool h_changed;
> const struct radeon_tv_mode_constants *const_ptr;
> -   struct radeon_pll *pll;
> -
> -   radeon_crtc = to_radeon_crtc(radeon_encoder->base.crtc);
> -   if (radeon_crtc->crtc_id == 1)
> -   pll = >clock.p2pll;
> -   else
> -   pll = >clock.p1pll;
>
> const_ptr = radeon_legacy_tv_get_std_mode(radeon_encoder, NULL);
> if (!const_ptr)
>
> ___
> 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 v5 4/4] drm/amdgpu: Set FreeSync state using drm VRR properties

2018-10-25 Thread Wentland, Harry
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
> 
> The notify_freesync and set_freesync_property functions are dropped
> from amdgpu_display_funcs.
> 
> The drm vrr_capable property is now attached to any DP/HDMI connector.
> Its value is updated accordingly to the connector's FreeSync capabiltiy.
> 
> The freesync_enable logic and ioctl control has has been dropped in
> favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
> fine grained atomic control over which CRTCs should support variable
> refresh rate.
> 
> To handle state changes for vrr_enabled it was easiest to drop the
> forced modeset on freesync_enabled change. This patch now performs the
> required stream updates when planes are flipped.
> 
> This is done for a few reasons:
> 
> (1) VRR stream updates can be done in the fast update path
> 
> (2) amdgpu_dm_atomic_check would need to be hacked apart to check
> desired variable refresh state and capability before the CRTC
> disable pass.
> 
> (3) Performing VRR stream updates on-flip is needed for enabling BTR
> support.
> 
> VRR packets and timing adjustments are now tracked and compared to
> previous values sent to the hardware.
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   7 -
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
>  3 files changed, 138 insertions(+), 131 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index b9e9e8b02fb7..0cbe867ec375 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -295,13 +295,6 @@ struct amdgpu_display_funcs {
> uint16_t connector_object_id,
> struct amdgpu_hpd *hpd,
> struct amdgpu_router *router);
> - /* it is used to enter or exit into free sync mode */
> - int (*notify_freesync)(struct drm_device *dev, void *data,
> -struct drm_file *filp);
> - /* it is used to allow enablement of freesync mode */
> - int (*set_freesync_property)(struct drm_connector *connector,
> -  struct drm_property *property,
> -  uint64_t val);
>  
>  
>  };
> 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 e224f23e2215..f6af388cc32d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
> *adev)
>   /* TODO: implement later */
>  }
>  
> -static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
> - struct drm_file *filp)
> -{
> - struct drm_atomic_state *state;
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_crtc *crtc;
> - struct drm_connector *connector;
> - struct drm_connector_state *old_con_state, *new_con_state;
> - int ret = 0;
> - uint8_t i;
> - bool enable = false;
> -
> - drm_modeset_acquire_init(, 0);
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state) {
> - ret = -ENOMEM;
> - goto out;
> - }
> - state->acquire_ctx = 
> -
> -retry:
> - drm_for_each_crtc(crtc, dev) {
> - ret = drm_atomic_add_affected_connectors(state, crtc);
> - if (ret)
> - goto fail;
> -
> - /* TODO rework amdgpu_dm_commit_planes so we don't need this */
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - goto fail;
> - }
> -
> - for_each_oldnew_connector_in_state(state, connector, old_con_state, 
> new_con_state, i) {
> - struct dm_connector_state *dm_new_con_state = 
> to_dm_connector_state(new_con_state);
> - struct drm_crtc_state *new_crtc_state;
> - struct amdgpu_crtc *acrtc = 
> to_amdgpu_crtc(dm_new_con_state->base.crtc);
> - struct dm_crtc_state *dm_new_crtc_state;
> -
> - if (!acrtc) {
> - ASSERT(0);
> - continue;
> - }
> -
> - new_crtc_state = drm_atomic_get_new_crtc_state(state, 
> >base);
> - dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
> -
> - dm_new_crtc_state->freesync_enabled = enable;
> - }
> -
> - ret = drm_atomic_commit(state);
> -
> -fail:
> - if (ret == -EDEADLK) {
> - drm_atomic_state_clear(state);
> - drm_modeset_backoff();
> -

Re: [PATCH v3] drm/amdgpu: Modify the argument of emit_ib interface

2018-10-25 Thread Alex Deucher
On Wed, Oct 24, 2018 at 10:58 AM Rex Zhu  wrote:
>
> use the point of struct amdgpu_job as the function
> argument instand of vmid, so the other members of
> struct amdgpu_job can be visit in emit_ib function.
>
> v2: add a wrapper for getting the VMID
> add the job before the ib on the parameter list.
> v3: refine the wrapper name
>
> Signed-off-by: Rex Zhu 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   |  3 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.h  |  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c  |  6 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h  |  4 ++--
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c|  4 +++-
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c|  4 +++-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c| 10 +++---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 10 +++---
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 26 +++---
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c   |  5 -
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   |  5 -
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  7 +--
>  drivers/gpu/drm/amd/amdgpu/si_dma.c  |  4 +++-
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c|  3 ++-
>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c|  3 ++-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 11 +--
>  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c| 10 --
>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c|  6 +-
>  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c|  6 --
>  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 18 +-
>  21 files changed, 106 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index b8963b7..ba277cd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -221,8 +221,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
> num_ibs,
> !amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
> Preamble CE ib must be inserted anyway */
> continue;
>
> -   amdgpu_ring_emit_ib(ring, ib, job ? job->vmid : 0,
> -   need_ctx_switch);
> +   amdgpu_ring_emit_ib(ring, job, ib, need_ctx_switch);
> need_ctx_switch = false;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> index 57cfe78..e1b46a6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> @@ -33,6 +33,8 @@
>  #define to_amdgpu_job(sched_job)   \
> container_of((sched_job), struct amdgpu_job, base)
>
> +#define AMDGPU_JOB_GET_VMID(job) ((job) ? (job)->vmid : 0)
> +
>  struct amdgpu_fence;
>
>  struct amdgpu_job {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 4caa301..ef7252a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -129,8 +129,9 @@ struct amdgpu_ring_funcs {
> unsigned emit_ib_size;
> /* command emit functions */
> void (*emit_ib)(struct amdgpu_ring *ring,
> +   struct amdgpu_job *job,
> struct amdgpu_ib *ib,
> -   unsigned vmid, bool ctx_switch);
> +   bool ctx_switch);
> void (*emit_fence)(struct amdgpu_ring *ring, uint64_t addr,
>uint64_t seq, unsigned flags);
> void (*emit_pipeline_sync)(struct amdgpu_ring *ring);
> @@ -229,7 +230,7 @@ struct amdgpu_ring {
>  #define amdgpu_ring_get_rptr(r) (r)->funcs->get_rptr((r))
>  #define amdgpu_ring_get_wptr(r) (r)->funcs->get_wptr((r))
>  #define amdgpu_ring_set_wptr(r) (r)->funcs->set_wptr((r))
> -#define amdgpu_ring_emit_ib(r, ib, vmid, c) (r)->funcs->emit_ib((r), (ib), 
> (vmid), (c))
> +#define amdgpu_ring_emit_ib(r, job, ib, c) ((r)->funcs->emit_ib((r), (job), 
> (ib), (c)))
>  #define amdgpu_ring_emit_pipeline_sync(r) (r)->funcs->emit_pipeline_sync((r))
>  #define amdgpu_ring_emit_vm_flush(r, vmid, addr) 
> (r)->funcs->emit_vm_flush((r), (vmid), (addr))
>  #define amdgpu_ring_emit_fence(r, addr, seq, flags) 
> (r)->funcs->emit_fence((r), (addr), (seq), (flags))
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index 5f3f540..56675ec 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> @@ -1032,8 +1032,10 @@ int amdgpu_vce_ring_parse_cs_vm(struct 
> amdgpu_cs_parser *p, uint32_t ib_idx)
>   * @ib: the IB to execute
>   *
>   */
> -void amdgpu_vce_ring_emit_ib(struct amdgpu_ring *ring, struct amdgpu_ib *ib,
> -unsigned vmid, bool ctx_switch)
> +void amdgpu_vce_ring_emit_ib(struct amdgpu_ring *ring,
> +   struct 

Re: [PATCH] drm/amdgpu: Change AMDGPU_CSA_SIZE to 128K

2018-10-25 Thread Alex Deucher
On Wed, Oct 24, 2018 at 8:11 AM Rex Zhu  wrote:
>
> In order to support new asics and MCBP feature
> enablement on baremetal.
>
> Signed-off-by: Rex Zhu 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> index ef2dfb0..524b443 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> @@ -25,7 +25,7 @@
>  #ifndef AMDGPU_CSA_MANAGER_H
>  #define AMDGPU_CSA_MANAGER_H
>
> -#define AMDGPU_CSA_SIZE(8 * 1024)
> +#define AMDGPU_CSA_SIZE(128 * 1024)
>
>  uint32_t amdgpu_get_total_csa_size(struct amdgpu_device *adev);
>  uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev);
> --
> 1.9.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: [PATCH v5 3/4] drm: Document variable refresh properties

2018-10-25 Thread Wentland, Harry


On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
> 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  Documentation/gpu/drm-kms.rst   |  7 +++
>  drivers/gpu/drm/drm_connector.c | 22 ++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 4b1501b4835b..8da2a178cf85 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
> :doc: explicit fencing properties
>  
> +
> +Variable Refresh Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: Variable refresh properties
> +
>  Existing KMS Properties
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f0deeb7298d0..2a12853ca917 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
> +/**
> + * DOC: Variable refresh properties
> + *
> + * Variable refresh rate control is supported via properties on the
> + * _connector and _crtc objects.
> + *
> + * "vrr_capable":
> + *   Optional _connector boolean property that drivers should attach
> + *   with drm_connector_attach_vrr_capable_property() on connectors that
> + *   could support variable refresh rates. Drivers should update the
> + *   property value by calling drm_connector_set_vrr_capable_property().
> + *
> + *   Absence of the property should indicate absence of support.
> + *
> + * "vrr_enabled":
> + *   Default _crtc boolean property that notifies the driver that the
> + *   variable refresh rate adjustment should be enabled for the CRTC.
> + *
> + *   Support for variable refresh rate will depend on the "vrr_capable"
> + *   property exposed on the _connector object.

We probably want to make it clear that this is a content hint. Maybe something 
like:

 * "vrr_enabled":
 *  Default _crtc boolean property that notifies the driver that the
 *  content on the CRTC is suitable for variable refresh presentation.
 *  The driver will take that as a hint to enable variable refresh rate
 *  if the receiver supports it, i.e. the "vrr_capable" property on the
 *  _connector_object is true.


Harry

> + */
> +
>  /**
>   * drm_connector_attach_vrr_capable_property - creates the
>   * vrr_capable property
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC

2018-10-25 Thread Wentland, Harry
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
> 
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not capable of driving variable refresh
> timings then this is not considered an error.
> 
> Capability for variable refresh rate support should be determined
> by querying the vrr_capable drm connector property.
> 
> It is worth noting that while the property is intended for atomic use
> it isn't filtered from legacy userspace queries. This allows for Xorg
> userspace drivers to implement support.
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 4 
>  drivers/gpu/drm/drm_crtc.c| 2 ++
>  drivers/gpu/drm/drm_mode_config.c | 6 ++
>  include/drm/drm_crtc.h| 9 +
>  include/drm/drm_mode_config.h | 5 +
>  5 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..eec396a57b88 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
> *crtc,
>   ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
>   drm_property_blob_put(mode);
>   return ret;
> + } else if (property == config->prop_vrr_enabled) {
> + state->vrr_enabled = val;
>   } else if (property == config->degamma_lut_property) {
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >degamma_lut,
> @@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>   *val = state->active;
>   else if (property == config->prop_mode_id)
>   *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> + else if (property == config->prop_vrr_enabled)
> + *val = state->vrr_enabled;
>   else if (property == config->degamma_lut_property)
>   *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
>   else if (property == config->ctm_property)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5f488aa80bcd..e4eb2c897ff4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   drm_object_attach_property(>base, config->prop_mode_id, 
> 0);
>   drm_object_attach_property(>base,
>  config->prop_out_fence_ptr, 0);
> + drm_object_attach_property(>base,
> +config->prop_vrr_enabled, 0);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..5670c67f28d4 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_mode_id = prop;
>  
> + prop = drm_property_create_bool(dev, 0,
> + "VRR_ENABLED");
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_vrr_enabled = prop;
> +
>   prop = drm_property_create(dev,
>   DRM_MODE_PROP_BLOB,
>   "DEGAMMA_LUT", 0);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..39c3900aab3c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -290,6 +290,15 @@ struct drm_crtc_state {
>*/
>   u32 pageflip_flags;
>  
> + /**
> +  * @vrr_enabled:
> +  *
> +  * Indicates if variable refresh rate should be enabled for the CRTC.
> +  * Support for the requested vrr state will depend on driver and
> +  * hardware capabiltiy - lacking support is not treated as failure.
> +  */
> + bool vrr_enabled;
> +
>   /**
>* @event:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 928e4172a0bb..49f2fcfdb5fc 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -639,6 +639,11 @@ struct drm_mode_config {
>* connectors must be of and active must be set to disabled, too.
>*/
>   struct drm_property *prop_mode_id;
> + /**
> +  * @prop_vrr_enabled: Default atomic CRTC property to indicate
> +  * whether variable refresh rate should be enabled on the CRTC.
> +  */
> + struct drm_property *prop_vrr_enabled;
>  
>   /**
>* @dvi_i_subconnector_property: Optional DVI-I property to
> 

Re: [PATCH v5 1/4] drm: Add vrr_capable property to the drm connector

2018-10-25 Thread Wentland, Harry
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
> 
> Atomic drivers should attach this property to connectors that are
> capable of driving variable refresh rates using
> drm_connector_attach_vrr_capable_property().
> 
> The value should be updated based on driver and hardware capabiltiy
> by using drm_connector_set_vrr_capable_property().
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_connector.c | 49 +
>  include/drm/drm_connector.h | 15 ++
>  2 files changed, 64 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..f0deeb7298d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,37 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
> +/**
> + * drm_connector_attach_vrr_capable_property - creates the
> + * vrr_capable property
> + * @connector: connector to create the vrr_capable property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * variable refresh rate capability for a connector.
> + *
> + * Returns:
> + * Zero on success, negative errono on failure.
> + */
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (!connector->vrr_capable_property) {
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
> + "vrr_capable");
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->vrr_capable_property = prop;
> + drm_object_attach_property(>base, prop, 0);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
> +
>  /**
>   * drm_connector_attach_scaling_mode_property - attach atomic scaling mode 
> property
>   * @connector: connector to attach scaling mode property on.
> @@ -1582,6 +1613,24 @@ void drm_connector_set_link_status_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_connector_set_link_status_property);
>  
> +/**
> + * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> + * capable property for a connector
> + * @connector: drm connector
> + * @capable: True if the connector is variable refresh rate capable
> + *
> + * Should be used by atomic drivers to update the indicated support for
> + * variable refresh rate over a connector.
> + */
> +void drm_connector_set_vrr_capable_property(
> + struct drm_connector *connector, bool capable)
> +{
> + drm_object_property_set_value(>base,
> +   connector->vrr_capable_property,
> +   capable);
> +}
> +EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> +
>  /**
>   * drm_connector_init_panel_orientation_property -
>   *   initialize the connecters panel_orientation property
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 91a877fa00cb..b2263005234a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -910,6 +910,17 @@ struct drm_connector {
>*/
>   struct drm_property *scaling_mode_property;
>  
> + /**
> +  * @vrr_capable_property: Optional property to help userspace
> +  * query hardware support for variable refresh rate on a connector.
> +  * connector. Drivers can add the property to a connector by
> +  * calling drm_connector_attach_vrr_capable_property().
> +  *
> +  * This should be updated only by calling
> +  * drm_connector_set_vrr_capable_property().
> +  */
> + struct drm_property *vrr_capable_property;
> +
>   /**
>* @content_protection_property: DRM ENUM property for content
>* protection. See drm_connector_attach_content_protection_property().
> @@ -1183,6 +1194,8 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev);
>  int drm_connector_attach_content_type_property(struct drm_connector *dev);
>  int drm_connector_attach_scaling_mode_property(struct drm_connector 
> *connector,
>  u32 scaling_mode_mask);
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector);
>  int drm_connector_attach_content_protection_property(
>   struct drm_connector *connector);
>  int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> @@ -1199,6 +1212,8 @@ int drm_connector_update_edid_property(struct 
> drm_connector *connector,
>  

Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support

2018-10-25 Thread Wentland, Harry


On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
 I'm curious to know whether this will/could work over PRIME
>>> I don't see why this shouldn't work over PRIME as long as the
>>> presenting GPU supports the new variable refresh rate API, but I know
>>> very little about prime, so maybe someone else can chime in and give
>>> a better opinion.
>> It won't work for displays connected to a secondary GPU, because those
>> aren't hooked up to the Present extension directly.
>>
>> It can theoretically work with render offloading, if the primary GPU can
>> scan out directly from the shared pixmap. This is only possible with
>> current AMD APUs which support scatter/gather scanout (Carrizo and
>> newer?).
> 
> Actually only Carizzo and Stoney at the moment because this is buggy on 
> Raven. Not sure if that is a pure software or a hardware problem.
> 
> Christian.
> 
>> One gotcha is that xf86-video-amdgpu currently doesn't allow
>> flipping between buffers with different tiling parameters (BTW Harry,
>> does that work with DC?), but that should be easy to fix.
> 

Not currently. Fixable, but unfortunately not as easy as I'd hope. The good 
news is that I'm planning to rework that code so it would be easy to fix or 
should just happen on a per-flip basis.

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


Re: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?

2018-10-25 Thread Eric Anholt
Sean Paul  writes:

> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
>> Hi all,
>> 
>> This is just to collect feedback on this idea, and see whether the
>> overall dri-devel community stands on all this. I think the past few
>> cross-vendor uapi extensions all came with igts attached, and
>> personally I think there's lots of value in having them: A
>> cross-vendor interface isn't useful if every driver implements it
>> slightly differently.
>> 
>> I think there's 2 questions here:
>> 
>> - Do we want to make such testcases mandatory?
>> 
>
> Yes, more testing == better code.
>
>
>> - If yes, are we there yet, or is there something crucially missing
>>   still?
>
> In my experience, no. Last week while trying to replicate an intel-gfx CI
> failure, I tried compiling igt for one of my (intel) chromebooks. It seems 
> like
> cross-compilation (or, in my case, just specifying
> prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose
> restrictions across the entire subsystem, we need to make sure that everyone 
> can
> build and deploy igt easily.
>
> I managed to hack around everything and get it working, but I still haven't
> tried switching out the toolchain. Once we have some GitLab CI to validate
> cross-compilation, then we can consider making IGT mandatory.
>
> It's possible that I'm just a meson n00b and didn't use the right incantation,
> so maybe it already works, but then we need better documentation.
>
> I've pasted my horrible hacks below, I also didn't have libunwind, so removed
> its usage.

I've also had to cut out libunwind for cross-compiling on many
occasions.  Worst library.


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


[PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

2018-10-25 Thread S, Shirish
This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.

Reason for revert:
This patch sends  msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
This leads to SMU failing to service the request as it is
dependent on UVD to be powered ON, since it accesses UVD
registers.

This msg should ideally be sent only when the UVD is about to decode
a 4k video.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
index fef111d..53cf787 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
@@ -1228,17 +1228,14 @@ static int smu8_dpm_force_dpm_level(struct pp_hwmgr 
*hwmgr,
 
 static int smu8_dpm_powerdown_uvd(struct pp_hwmgr *hwmgr)
 {
-   if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
-   smu8_nbdpm_pstate_enable_disable(hwmgr, true, true);
+   if (PP_CAP(PHM_PlatformCaps_UVDPowerGating))
return smum_send_msg_to_smc(hwmgr, PPSMC_MSG_UVDPowerOFF);
-   }
return 0;
 }
 
 static int smu8_dpm_powerup_uvd(struct pp_hwmgr *hwmgr)
 {
if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
-   smu8_nbdpm_pstate_enable_disable(hwmgr, false, true);
return smum_send_msg_to_smc_with_parameter(
hwmgr,
PPSMC_MSG_UVDPowerON,
-- 
2.7.4

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


Re: [PATCH] drm/amdgpu: fix VM leaf walking

2018-10-25 Thread Kuehling, Felix
On 2018-10-25 10:38 a.m., Christian König wrote:
> Make sure we don't try to go down further after the leave walk already
> ended. This fixes a crash with a new VM test.
>
> Signed-off-by: Christian König 

Reviewed-by: Felix Kuehling 

Regards,
  Felix

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index db0cbf8d219d..352b30409060 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
> *adev,
>  struct amdgpu_vm_pt_cursor *cursor)
>  {
>   amdgpu_vm_pt_next(adev, cursor);
> - while (amdgpu_vm_pt_descendant(adev, cursor));
> + if (cursor->pfn != ~0ll)
> + while (amdgpu_vm_pt_descendant(adev, cursor));
>  }
>  
>  /**
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amdgpu: fix VM leaf walking

2018-10-25 Thread Zhu, Rex
How about add a return value for the function amdgpu_vm_pt_next?
And change the code as:

 ret = amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (!ret)
+   while (amdgpu_vm_pt_descendant(adev, cursor));

Best Regards
Rex
From: amd-gfx  On Behalf Of Zhu, Rex
Sent: Thursday, October 25, 2018 11:34 PM
To: Deucher, Alexander ; Christian König 
; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: fix VM leaf walking

Patch is Tested-by:  Rex Zhu rex@amd.com

Regards
Rex

From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Deucher, Alexander
Sent: Thursday, October 25, 2018 11:08 PM
To: Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix VM leaf walking


Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>
Sent: Thursday, October 25, 2018 10:38 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix VM leaf walking

Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
mailto:christian.koe...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
struct amdgpu_vm_pt_cursor *cursor)
 {
 amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }

 /**
--
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: [PATCH] drm/amdgpu: fix VM leaf walking

2018-10-25 Thread Zhu, Rex
Patch is Tested-by:  Rex Zhu rex@amd.com

Regards
Rex

From: amd-gfx  On Behalf Of Deucher, 
Alexander
Sent: Thursday, October 25, 2018 11:08 PM
To: Christian König ; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix VM leaf walking


Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>
Sent: Thursday, October 25, 2018 10:38 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix VM leaf walking

Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
mailto:christian.koe...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
struct amdgpu_vm_pt_cursor *cursor)
 {
 amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }

 /**
--
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: [PATCH] drm/amdgpu: fix VM leaf walking

2018-10-25 Thread Deucher, Alexander
Acked-by: Alex Deucher 


From: amd-gfx  on behalf of Christian 
König 
Sent: Thursday, October 25, 2018 10:38 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix VM leaf walking

Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
struct amdgpu_vm_pt_cursor *cursor)
 {
 amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }

 /**
--
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: fix VM leaf walking

2018-10-25 Thread Christian König
Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
   struct amdgpu_vm_pt_cursor *cursor)
 {
amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }
 
 /**
-- 
2.17.1

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


[PATCH 21/21] drm/amd/display: Add condition to sync eDP SW status and HW status

2018-10-25 Thread sunpeng.li
From: Lewis Huang 

[Why]
Need to disable EDP backlight when enter S4 with EDP only
and resume from S4 with secondary only.

[How]
Align the real hw and sw state via vBios scratch register in
function enable_accelerated_mode when resume from S4.

Signed-off-by: Lewis Huang 
Reviewed-by: Charlene Liu 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c |  2 +
 .../drm/amd/display/dc/bios/bios_parser_helper.c   | 93 ++
 .../drm/amd/display/dc/bios/bios_parser_helper.h   |  4 +
 drivers/gpu/drm/amd/display/dc/dc_bios_types.h |  5 ++
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 15 
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  1 +
 6 files changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index ff764da..751bb61 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1884,6 +1884,8 @@ static const struct dc_vbios_funcs vbios_funcs = {
 
.is_accelerated_mode = bios_parser_is_accelerated_mode,
 
+   .is_active_display = bios_is_active_display,
+
.set_scratch_critical_state = bios_parser_set_scratch_critical_state,
 
 
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
index d458947..fdda8aa 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
@@ -88,3 +88,96 @@ uint32_t bios_get_vga_enabled_displays(
return active_disp;
 }
 
+bool bios_is_active_display(
+   struct dc_bios *bios,
+   enum signal_type signal,
+   const struct connector_device_tag_info *device_tag)
+{
+   uint32_t active = 0;
+   uint32_t connected = 0;
+   uint32_t bios_scratch_0 = 0;
+   uint32_t bios_scratch_3 = 0;
+
+   switch (signal) {
+   case SIGNAL_TYPE_DVI_SINGLE_LINK:
+   case SIGNAL_TYPE_DVI_DUAL_LINK:
+   case SIGNAL_TYPE_HDMI_TYPE_A:
+   case SIGNAL_TYPE_DISPLAY_PORT:
+   case SIGNAL_TYPE_DISPLAY_PORT_MST:
+   {
+   if (device_tag->dev_id.device_type == DEVICE_TYPE_DFP) {
+   switch (device_tag->dev_id.enum_id) {
+   case 1:
+   {
+   active= ATOM_S3_DFP1_ACTIVE;
+   connected = 0x0008; 
//ATOM_DISPLAY_DFP1_CONNECT
+   }
+   break;
+
+   case 2:
+   {
+   active= ATOM_S3_DFP2_ACTIVE;
+   connected = 0x0080; 
//ATOM_DISPLAY_DFP2_CONNECT
+   }
+   break;
+
+   case 3:
+   {
+   active= ATOM_S3_DFP3_ACTIVE;
+   connected = 0x0200; 
//ATOM_DISPLAY_DFP3_CONNECT
+   }
+   break;
+
+   case 4:
+   {
+   active= ATOM_S3_DFP4_ACTIVE;
+   connected = 0x0400; 
//ATOM_DISPLAY_DFP4_CONNECT
+   }
+   break;
+
+   case 5:
+   {
+   active= ATOM_S3_DFP5_ACTIVE;
+   connected = 0x0800; 
//ATOM_DISPLAY_DFP5_CONNECT
+   }
+   break;
+
+   case 6:
+   {
+   active= ATOM_S3_DFP6_ACTIVE;
+   connected = 0x0040; 
//ATOM_DISPLAY_DFP6_CONNECT
+   }
+   break;
+
+   default:
+   break;
+   }
+   }
+   }
+   break;
+
+   case SIGNAL_TYPE_LVDS:
+   case SIGNAL_TYPE_EDP:
+   {
+   active= ATOM_S3_LCD1_ACTIVE;
+   connected = 0x0002; //ATOM_DISPLAY_LCD1_CONNECT
+   }
+   break;
+
+   default:
+   

[PATCH 20/21] drm/amd/display: Remove the check to see if pp_display_cfg is changed

2018-10-25 Thread sunpeng.li
From: Fatemeh Darbehani 

[Why]
When going to full-screen mode commit_planes_for_stream tries to decrease
dcf_deep_sleep value, but safe_to_lower is false, so we don't send the new value
to SMU but dc context gets updated.
Later when dc_post_update_surfaces_to_stream tries to lower dcf_ds when
safe_to_lower is true, this check prevents the message from being sent.

[How]
Remove the check that compares new value with what is stored in dc_context.
This check is not necessary as dcn1_update_clocks already checks if the value
is different from the current dcf_dp value.

Signed-off-by: Fatemeh Darbehani 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c
index 98a1e2c..20f531d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c
@@ -57,8 +57,7 @@ void dcn1_pplib_apply_display_requirements(
pp_display_cfg->disp_clk_khz = dc->res_pool->clk_mgr->clks.dispclk_khz;
dce110_fill_display_configs(context, pp_display_cfg);
 
-   if (memcmp(>current_state->pp_display_cfg, pp_display_cfg, 
sizeof(*pp_display_cfg)) !=  0)
-   dm_pp_apply_display_requirements(dc->ctx, pp_display_cfg);
+   dm_pp_apply_display_requirements(dc->ctx, pp_display_cfg);
 }
 
 static int dcn1_determine_dppclk_threshold(struct clk_mgr *clk_mgr, struct 
dc_clocks *new_clocks)
-- 
2.7.4

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


[PATCH 19/21] drm/amd/display: remove CRTC_3D_STRUCTURE_V_UPDATE_MODE bit programming.

2018-10-25 Thread sunpeng.li
From: Charlene Liu 

[Description]
This is based on HW programming guide update.

Signed-off-by: Charlene Liu 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
index 47f80e0..7d1f667 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c
@@ -87,9 +87,8 @@ static void optc1_disable_stereo(struct timing_generator 
*optc)
REG_SET(OTG_STEREO_CONTROL, 0,
OTG_STEREO_EN, 0);
 
-   REG_SET_3(OTG_3D_STRUCTURE_CONTROL, 0,
+   REG_SET_2(OTG_3D_STRUCTURE_CONTROL, 0,
OTG_3D_STRUCTURE_EN, 0,
-   OTG_3D_STRUCTURE_V_UPDATE_MODE, 0,
OTG_3D_STRUCTURE_STEREO_SEL_OVR, 0);
 }
 
@@ -1154,9 +1153,8 @@ static void optc1_enable_stereo(struct timing_generator 
*optc,
OTG_DISABLE_STEREOSYNC_OUTPUT_FOR_DP, 1);
 
if (flags->PROGRAM_STEREO)
-   REG_UPDATE_3(OTG_3D_STRUCTURE_CONTROL,
+   REG_UPDATE_2(OTG_3D_STRUCTURE_CONTROL,
OTG_3D_STRUCTURE_EN, flags->FRAME_PACKED,
-   OTG_3D_STRUCTURE_V_UPDATE_MODE, 
flags->FRAME_PACKED,
OTG_3D_STRUCTURE_STEREO_SEL_OVR, 
flags->FRAME_PACKED);
 
}
-- 
2.7.4

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


[PATCH 16/21] drm/amd/display: fix mirror rotation scaling math

2018-10-25 Thread sunpeng.li
From: Dmytro Laktyushkin 

Curretly dc will incorrectly calculate viewport when there is
rotation or mirror being applied

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Su Chung 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 65 +--
 1 file changed, 24 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index d68906b..fc65b00 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -499,8 +499,13 @@ static void calculate_viewport(struct pipe_ctx *pipe_ctx)
pipe_ctx->top_pipe->plane_state == 
pipe_ctx->plane_state;
bool flip_vert_scan_dir = false, flip_horz_scan_dir = false;
 
+
/*
-* Need to calculate the scan direction for viewport to properly 
determine offset
+* We need take horizontal mirror into account. On an unrotated surface 
this means
+* that the viewport offset is actually the offset from the other side 
of source
+* image so we have to subtract the right edge of the viewport from the 
right edge of
+* the source window. Similar to mirror we need to take into account 
how offset is
+* affected for 270/180 rotations
 */
if (pipe_ctx->plane_state->rotation == ROTATION_ANGLE_180) {
flip_vert_scan_dir = true;
@@ -510,6 +515,9 @@ static void calculate_viewport(struct pipe_ctx *pipe_ctx)
else if (pipe_ctx->plane_state->rotation == ROTATION_ANGLE_270)
flip_horz_scan_dir = true;
 
+   if (pipe_ctx->plane_state->horizontal_mirror)
+   flip_horz_scan_dir = !flip_horz_scan_dir;
+
if (stream->view_format == VIEW_3D_FORMAT_SIDE_BY_SIDE ||
stream->view_format == VIEW_3D_FORMAT_TOP_AND_BOTTOM) {
pri_split = false;
@@ -540,45 +548,27 @@ static void calculate_viewport(struct pipe_ctx *pipe_ctx)
plane_state->clip_rect.y + 
plane_state->clip_rect.height - clip.y ;
 
/* offset = surf_src.ofs + (clip.ofs - surface->dst_rect.ofs) * 
scl_ratio
+* note: surf_src.ofs should be added after rotation/mirror offset 
direction
+*   adjustment since it is already in viewport space
 * num_pixels = clip.num_pix * scl_ratio
 */
-   data->viewport.x = surf_src.x + (clip.x - plane_state->dst_rect.x) *
+   data->viewport.x = (clip.x - plane_state->dst_rect.x) *
surf_src.width / plane_state->dst_rect.width;
data->viewport.width = clip.width *
surf_src.width / plane_state->dst_rect.width;
 
-   data->viewport.y = surf_src.y + (clip.y - plane_state->dst_rect.y) *
+   data->viewport.y = (clip.y - plane_state->dst_rect.y) *
surf_src.height / plane_state->dst_rect.height;
data->viewport.height = clip.height *
surf_src.height / plane_state->dst_rect.height;
 
-   /* To transfer the x, y to correct coordinate on mirror image (camera).
-* deg  0 : transfer x,
-* deg 90 : don't need to transfer,
-* deg180 : transfer y,
-* deg270 : transfer x and y.
-* To transfer the x, y to correct coordinate on non-mirror image 
(video).
-* deg  0 : don't need to transfer,
-* deg 90 : transfer y,
-* deg180 : transfer x and y,
-* deg270 : transfer x.
-*/
-   if (pipe_ctx->plane_state->horizontal_mirror) {
-   if (flip_horz_scan_dir && !flip_vert_scan_dir) {
-   data->viewport.y = surf_src.height - data->viewport.y - 
data->viewport.height;
-   data->viewport.x = surf_src.width - data->viewport.x - 
data->viewport.width;
-   } else if (flip_horz_scan_dir && flip_vert_scan_dir)
-   data->viewport.y = surf_src.height - data->viewport.y - 
data->viewport.height;
-   else {
-   if (!flip_horz_scan_dir && !flip_vert_scan_dir)
-   data->viewport.x = surf_src.width - 
data->viewport.x - data->viewport.width;
-   }
-   } else {
-   if (flip_horz_scan_dir)
-   data->viewport.x = surf_src.width - data->viewport.x - 
data->viewport.width;
-   if (flip_vert_scan_dir)
-   data->viewport.y = surf_src.height - data->viewport.y - 
data->viewport.height;
-   }
+   if (flip_vert_scan_dir)
+   data->viewport.y = surf_src.height - data->viewport.y - 
data->viewport.height;
+   if (flip_horz_scan_dir)
+   data->viewport.x = surf_src.width - data->viewport.x - 
data->viewport.width;
+
+   data->viewport.x += surf_src.x;
+   data->viewport.y += surf_src.y;
 
/* Round down, compensate in init */
data->viewport_c.x = 

[PATCH 18/21] drm/amd/display: Expose target backlight level

2018-10-25 Thread sunpeng.li
From: Anthony Koo 

[Why]
DM may want to understand any backlight optimizations
applied, so DM needs a way to query from the HW both
the real current backlight, which may be value during
transition.
And also target backlight, which may be after some
backlight optimizations applied.

[How]
Add interface to query current and target backlight levels
Target level may indicate backlight level after backlight
optimization and reductions are applied.

Signed-off-by: Anthony Koo 
Reviewed-by: Krunoslav Kovac 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 12 
 drivers/gpu/drm/amd/display/dc/inc/hw/abm.h  |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
index e9765bb..2a342ea 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
@@ -276,6 +276,17 @@ static unsigned int dce_abm_get_current_backlight(struct 
abm *abm)
return backlight;
 }
 
+static unsigned int dce_abm_get_target_backlight(struct abm *abm)
+{
+   struct dce_abm *abm_dce = TO_DCE_ABM(abm);
+   unsigned int backlight = REG_READ(BL1_PWM_TARGET_ABM_LEVEL);
+
+   /* return backlight in hardware format which is unsigned 17 bits, with
+* 1 bit integer and 16 bit fractional
+*/
+   return backlight;
+}
+
 static bool dce_abm_set_level(struct abm *abm, uint32_t level)
 {
struct dce_abm *abm_dce = TO_DCE_ABM(abm);
@@ -410,6 +421,7 @@ static const struct abm_funcs dce_funcs = {
.init_backlight = dce_abm_init_backlight,
.set_backlight_level_pwm = dce_abm_set_backlight_level_pwm,
.get_current_backlight = dce_abm_get_current_backlight,
+   .get_target_backlight = dce_abm_get_target_backlight,
.set_abm_immediate_disable = dce_abm_immediate_disable
 };
 
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/abm.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/abm.h
index 458a641..abc961c 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/abm.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/abm.h
@@ -58,6 +58,7 @@ struct abm_funcs {
bool use_smooth_brightness);
 
unsigned int (*get_current_backlight)(struct abm *abm);
+   unsigned int (*get_target_backlight)(struct abm *abm);
 };
 
 #endif
-- 
2.7.4

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


[PATCH 17/21] drm/amd/display: Guard against null stream_state in set_crc_source

2018-10-25 Thread sunpeng.li
From: Nicholas Kazlauskas 

[Why]

The igt@kms_plane@pixel-format-pipe tests can create a sequence where
stream_state is NULL during amdgpu_dm_crtc_set_crc_source which results
in a null pointer dereference.

[How]

Guard against stream_state being NULL before accessing its fields. This
doesn't fix the root cause of the issue so a DRM_ERROR is generated
to still fail the tests.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 9bfb040..6a6d977 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -60,6 +60,11 @@ int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, 
const char *src_name,
return -EINVAL;
}
 
+   if (!stream_state) {
+   DRM_ERROR("No stream state for CRTC%d\n", crtc->index);
+   return -EINVAL;
+   }
+
/* When enabling CRC, we should also disable dithering. */
if (source == AMDGPU_DM_PIPE_CRC_SOURCE_AUTO) {
if (dc_stream_configure_crc(stream_state->ctx->dc,
-- 
2.7.4

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


[PATCH 15/21] drm/amd/display: Retiring set_display_requirements in dm_pp_smu.h - part4

2018-10-25 Thread sunpeng.li
From: Fatemeh Darbehani 

[Why]
In DCN we want direct DC to SMU calls, with minimal interference from
pplib.
The reason for each pp_smu interface mapping to 1 SMU message is so we
can have the sequencing of different SMU message in DC and shared across
different OS's.
This will also simplify debugging as DAL owns this interaction and
there's no confusion about division of ownership.

[How]
Part 4: Change clock units so they match the values PPLib sends to SMU.

Signed-off-by: Fatemeh Darbehani 
Signed-off-by: David Francis 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c   | 20 +++---
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   | 32 +++---
 .../gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c   |  6 ++--
 drivers/gpu/drm/amd/display/dc/dm_pp_smu.h | 16 +--
 4 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index 12001a0..9d2d698 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -485,11 +485,11 @@ void pp_rv_set_display_requirement(struct pp_smu *pp,
return;
 
clock.clock_type = amd_pp_dcf_clock;
-   clock.clock_freq_in_khz = req->hard_min_dcefclk_khz;
+   clock.clock_freq_in_khz = req->hard_min_dcefclk_mhz * 1000;
pp_funcs->display_clock_voltage_request(pp_handle, );
 
clock.clock_type = amd_pp_f_clock;
-   clock.clock_freq_in_khz = req->hard_min_fclk_khz;
+   clock.clock_freq_in_khz = req->hard_min_fclk_mhz * 1000;
pp_funcs->display_clock_voltage_request(pp_handle, );
 }
 
@@ -518,13 +518,13 @@ void pp_rv_set_wm_ranges(struct pp_smu *pp,
wm_dce_clocks[i].wm_set_id =
ranges->reader_wm_sets[i].wm_inst;
wm_dce_clocks[i].wm_max_dcfclk_clk_in_khz =
-   ranges->reader_wm_sets[i].max_drain_clk_khz;
+   ranges->reader_wm_sets[i].max_drain_clk_mhz * 
1000;
wm_dce_clocks[i].wm_min_dcfclk_clk_in_khz =
-   ranges->reader_wm_sets[i].min_drain_clk_khz;
+   ranges->reader_wm_sets[i].min_drain_clk_mhz * 
1000;
wm_dce_clocks[i].wm_max_mem_clk_in_khz =
-   ranges->reader_wm_sets[i].max_fill_clk_khz;
+   ranges->reader_wm_sets[i].max_fill_clk_mhz * 
1000;
wm_dce_clocks[i].wm_min_mem_clk_in_khz =
-   ranges->reader_wm_sets[i].min_fill_clk_khz;
+   ranges->reader_wm_sets[i].min_fill_clk_mhz * 
1000;
}
 
for (i = 0; i < wm_with_clock_ranges.num_wm_mcif_sets; i++) {
@@ -534,13 +534,13 @@ void pp_rv_set_wm_ranges(struct pp_smu *pp,
wm_soc_clocks[i].wm_set_id =
ranges->writer_wm_sets[i].wm_inst;
wm_soc_clocks[i].wm_max_socclk_clk_in_khz =
-   ranges->writer_wm_sets[i].max_fill_clk_khz;
+   ranges->writer_wm_sets[i].max_fill_clk_mhz * 
1000;
wm_soc_clocks[i].wm_min_socclk_clk_in_khz =
-   ranges->writer_wm_sets[i].min_fill_clk_khz;
+   ranges->writer_wm_sets[i].min_fill_clk_mhz * 
1000;
wm_soc_clocks[i].wm_max_mem_clk_in_khz =
-   ranges->writer_wm_sets[i].max_drain_clk_khz;
+   ranges->writer_wm_sets[i].max_drain_clk_mhz * 
1000;
wm_soc_clocks[i].wm_min_mem_clk_in_khz =
-   ranges->writer_wm_sets[i].min_drain_clk_khz;
+   ranges->writer_wm_sets[i].min_drain_clk_mhz * 
1000;
}
 
pp_funcs->set_watermarks_for_clocks_ranges(pp_handle, 
_with_clock_ranges);
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
index 3208188..43e4a2b 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
@@ -1423,27 +1423,27 @@ void dcn_bw_notify_pplib_of_wm_ranges(struct dc *dc)
ranges.num_reader_wm_sets = WM_SET_COUNT;
ranges.num_writer_wm_sets = WM_SET_COUNT;
ranges.reader_wm_sets[0].wm_inst = WM_A;
-   ranges.reader_wm_sets[0].min_drain_clk_khz = min_dcfclk_khz;
-   ranges.reader_wm_sets[0].max_drain_clk_khz = overdrive;
-   ranges.reader_wm_sets[0].min_fill_clk_khz = min_fclk_khz;
-   ranges.reader_wm_sets[0].max_fill_clk_khz = overdrive;
+   ranges.reader_wm_sets[0].min_drain_clk_mhz = min_dcfclk_khz / 1000;
+   ranges.reader_wm_sets[0].max_drain_clk_mhz = overdrive / 1000;
+   

[PATCH 14/21] drm/amd/display: Remove program_csc_matrix

2018-10-25 Thread sunpeng.li
From: Krunoslav Kovac 

[Why] On DCN1/DCE, There are two functions programming OCSC:
program_csc_matrix and program_output_csc. They do the same thing.

[How] Consolidate to use only program_output_csc.

Signed-off-by: Krunoslav Kovac 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c   |  8 +---
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 23 -
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 24 ++
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |  5 -
 4 files changed, 11 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 503bb16..3279e26 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -391,9 +391,11 @@ bool dc_stream_program_csc_matrix(struct dc *dc, struct 
dc_stream_state *stream)
== stream) {
 
pipes = >current_state->res_ctx.pipe_ctx[i];
-   dc->hwss.program_csc_matrix(pipes,
-   stream->output_color_space,
-   stream->csc_color_matrix.matrix);
+   dc->hwss.program_output_csc(dc,
+   pipes,
+   stream->output_color_space,
+   stream->csc_color_matrix.matrix,
+   pipes->plane_res.hubp->opp_id);
ret = true;
}
}
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index de22077..8873a609 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -2582,28 +2582,6 @@ static void dce110_wait_for_mpcc_disconnect(
/* do nothing*/
 }
 
-static void program_csc_matrix(struct pipe_ctx *pipe_ctx,
-   enum dc_color_space colorspace,
-   uint16_t *matrix)
-{
-   int i;
-   struct out_csc_color_matrix tbl_entry;
-
-   if (pipe_ctx->stream->csc_color_matrix.enable_adjustment
-   == true) {
-   enum dc_color_space color_space =
-   pipe_ctx->stream->output_color_space;
-
-   //uint16_t matrix[12];
-   for (i = 0; i < 12; i++)
-   tbl_entry.regval[i] = 
pipe_ctx->stream->csc_color_matrix.matrix[i];
-
-   tbl_entry.color_space = color_space;
-   //tbl_entry.regval = matrix;
-   
pipe_ctx->plane_res.xfm->funcs->opp_set_csc_adjustment(pipe_ctx->plane_res.xfm, 
_entry);
-   }
-}
-
 void dce110_set_cursor_position(struct pipe_ctx *pipe_ctx)
 {
struct dc_cursor_position pos_cpy = pipe_ctx->stream->cursor_position;
@@ -2654,7 +2632,6 @@ void dce110_set_cursor_attribute(struct pipe_ctx 
*pipe_ctx)
 
 static const struct hw_sequencer_funcs dce110_funcs = {
.program_gamut_remap = program_gamut_remap,
-   .program_csc_matrix = program_csc_matrix,
.init_hw = init_hw,
.apply_ctx_to_hw = dce110_apply_ctx_to_hw,
.apply_ctx_for_surface = dce110_apply_ctx_for_surface,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index e3e0fd4..87495de 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1704,32 +1704,21 @@ static void program_gamut_remap(struct pipe_ctx 
*pipe_ctx)

pipe_ctx->plane_res.dpp->funcs->dpp_set_gamut_remap(pipe_ctx->plane_res.dpp, 
);
 }
 
-
-static void program_csc_matrix(struct pipe_ctx *pipe_ctx,
+static void dcn10_program_output_csc(struct dc *dc,
+   struct pipe_ctx *pipe_ctx,
enum dc_color_space colorspace,
-   uint16_t *matrix)
+   uint16_t *matrix,
+   int opp_id)
 {
if (pipe_ctx->stream->csc_color_matrix.enable_adjustment == true) {
-   if 
(pipe_ctx->plane_res.dpp->funcs->dpp_set_csc_adjustment != NULL)
-   
pipe_ctx->plane_res.dpp->funcs->dpp_set_csc_adjustment(pipe_ctx->plane_res.dpp, 
matrix);
+   if (pipe_ctx->plane_res.dpp->funcs->dpp_set_csc_adjustment != 
NULL)
+   
pipe_ctx->plane_res.dpp->funcs->dpp_set_csc_adjustment(pipe_ctx->plane_res.dpp, 
matrix);
} else {
if (pipe_ctx->plane_res.dpp->funcs->dpp_set_csc_default != NULL)

pipe_ctx->plane_res.dpp->funcs->dpp_set_csc_default(pipe_ctx->plane_res.dpp, 
colorspace);
}
 }
 
-static void dcn10_program_output_csc(struct dc *dc,
-   struct 

[PATCH 13/21] drm/amd/display: Fix some backlight variable styling

2018-10-25 Thread sunpeng.li
From: Anthony Koo 

variableNamingsLikeSo aren't to convention. use_this_instead.

Signed-off-by: Anthony Koo 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dm_services_types.h | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dm_services_types.h 
b/drivers/gpu/drm/amd/display/dc/dm_services_types.h
index 2b83f92..1af8c77 100644
--- a/drivers/gpu/drm/amd/display/dc/dm_services_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dm_services_types.h
@@ -208,22 +208,20 @@ struct dm_bl_data_point {
/* Brightness level as effective value in range 0-255,
 * corresponding to above percentage
 */
-   uint8_t signalLevel;
+   uint8_t signal_level;
 };
 
 /* Total size of the structure should not exceed 256 bytes */
 struct dm_acpi_atif_backlight_caps {
-
-
uint16_t size; /* Bytes 0-1 (2 bytes) */
uint16_t flags; /* Byted 2-3 (2 bytes) */
-   uint8_t  errorCode; /* Byte 4 */
-   uint8_t  acLevelPercentage; /* Byte 5 */
-   uint8_t  dcLevelPercentage; /* Byte 6 */
-   uint8_t  minInputSignal; /* Byte 7 */
-   uint8_t  maxInputSignal; /* Byte 8 */
-   uint8_t  numOfDataPoints; /* Byte 9 */
-   struct dm_bl_data_point dataPoints[99]; /* Bytes 10-207 (198 bytes)*/
+   uint8_t  error_code; /* Byte 4 */
+   uint8_t  ac_level_percentage; /* Byte 5 */
+   uint8_t  dc_level_percentage; /* Byte 6 */
+   uint8_t  min_input_signal; /* Byte 7 */
+   uint8_t  max_input_signal; /* Byte 8 */
+   uint8_t  num_data_points; /* Byte 9 */
+   struct dm_bl_data_point data_points[99]; /* Bytes 10-207 (198 bytes)*/
 };
 
 enum dm_acpi_display_type {
-- 
2.7.4

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


[PATCH 11/21] drm/amd/display: Remove some old TODO's

2018-10-25 Thread sunpeng.li
From: Eric Bernstein 

They are no longer relevant

Signed-off-by: Eric Bernstein 
Reviewed-by: Dmytro Laktyushkin 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 345fc03..e3e0fd4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1944,10 +1944,6 @@ static void dcn10_update_mpcc(struct dc *dc, struct 
pipe_ctx *pipe_ctx)
struct mpc *mpc = dc->res_pool->mpc;
struct mpc_tree *mpc_tree_params = 
&(pipe_ctx->stream_res.opp->mpc_tree_params);
 
-
-
-   /* TODO: proper fix once fpga works */
-
if (dc->debug.visual_confirm == VISUAL_CONFIRM_HDR) {
dcn10_get_hdr_visual_confirm_color(
pipe_ctx, _cfg.black_color);
@@ -2027,8 +2023,6 @@ static void update_scaler(struct pipe_ctx *pipe_ctx)
bool per_pixel_alpha =
pipe_ctx->plane_state->per_pixel_alpha && 
pipe_ctx->bottom_pipe;
 
-   /* TODO: proper fix once fpga works */
-
pipe_ctx->plane_res.scl_data.lb_params.alpha_en = per_pixel_alpha;
pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_30BPP;
/* scaler configuration */
-- 
2.7.4

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


[PATCH 12/21] drm/amd/display: Expand dc to use 16.16 bit backlight

2018-10-25 Thread sunpeng.li
From: Anthony Koo 

[Why] We want to increase precision for backlight setting.
But DC interface takes 8 bit backlight level value only.

[How] DMCU already takes 16 bit backlight level.
Expand the DC interface to take 16.16 bit value.
Max 32 bit backlight value (0x) will represent
max backlight (100%)

Signed-off-by: Anthony Koo 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  7 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  | 34 
 drivers/gpu/drm/amd/display/dc/dc_link.h   | 11 ++-
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c   | 92 +-
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  1 -
 drivers/gpu/drm/amd/display/dc/inc/hw/abm.h| 11 ++-
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |  2 -
 7 files changed, 79 insertions(+), 79 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 c19adde..cb4a97e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1567,8 +1567,13 @@ static int amdgpu_dm_backlight_update_status(struct 
backlight_device *bd)
 {
struct amdgpu_display_manager *dm = bl_get_data(bd);
 
+   /* backlight_pwm_u16_16 parameter is in unsigned 32 bit, 16 bit integer
+* and 16 bit fractional, where 1.0 is max backlight value.
+* bd->props.brightness is 8 bit format and needs to be converted by
+* scaling via copy lower byte to upper byte of 16 bit value.
+*/
if (dc_link_set_backlight_level(dm->backlight_link,
-   bd->props.brightness, 0, 0))
+   (bd->props.brightness * 0x101), 0, 0))
return 0;
else
return 1;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index f4936f7..643407d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2141,14 +2141,16 @@ int dc_link_get_backlight_level(const struct dc_link 
*link)
 {
struct abm *abm = link->ctx->dc->res_pool->abm;
 
-   if (abm == NULL || abm->funcs->get_current_backlight_8_bit == NULL)
+   if (abm == NULL || abm->funcs->get_current_backlight == NULL)
return DC_ERROR_UNEXPECTED;
 
-   return (int) abm->funcs->get_current_backlight_8_bit(abm);
+   return (int) abm->funcs->get_current_backlight(abm);
 }
 
-bool dc_link_set_backlight_level(const struct dc_link *link, uint32_t level,
-   uint32_t frame_ramp, const struct dc_stream_state *stream)
+bool dc_link_set_backlight_level(const struct dc_link *link,
+   uint32_t backlight_pwm_u16_16,
+   uint32_t frame_ramp,
+   const struct dc_stream_state *stream)
 {
struct dc  *core_dc = link->ctx->dc;
struct abm *abm = core_dc->res_pool->abm;
@@ -2160,19 +2162,17 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link, uint32_t level,
 
if ((dmcu == NULL) ||
(abm == NULL) ||
-   (abm->funcs->set_backlight_level == NULL))
+   (abm->funcs->set_backlight_level_pwm == NULL))
return false;
 
-   if (stream) {
-   if (stream->bl_pwm_level == EDP_BACKLIGHT_RAMP_DISABLE_LEVEL)
-   frame_ramp = 0;
-
-   ((struct dc_stream_state *)stream)->bl_pwm_level = level;
-   }
+   if (stream)
+   ((struct dc_stream_state *)stream)->bl_pwm_level =
+   backlight_pwm_u16_16;
 
use_smooth_brightness = dmcu->funcs->is_dmcu_initialized(dmcu);
 
-   DC_LOG_BACKLIGHT("New Backlight level: %d (0x%X)\n", level, level);
+   DC_LOG_BACKLIGHT("New Backlight level: %d (0x%X)\n",
+   backlight_pwm_u16_16, backlight_pwm_u16_16);
 
if (dc_is_embedded_signal(link->connector_signal)) {
if (stream != NULL) {
@@ -2189,9 +2189,9 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link, uint32_t level,
1;
}
}
-   abm->funcs->set_backlight_level(
+   abm->funcs->set_backlight_level_pwm(
abm,
-   level,
+   backlight_pwm_u16_16,
frame_ramp,
controller_id,
use_smooth_brightness);
@@ -2205,7 +2205,7 @@ bool dc_link_set_abm_disable(const struct dc_link *link)
struct dc  *core_dc = link->ctx->dc;
struct abm *abm = core_dc->res_pool->abm;
 
-   if ((abm == NULL) || (abm->funcs->set_backlight_level == NULL))
+   if ((abm == NULL) || (abm->funcs->set_backlight_level_pwm == NULL))
  

[PATCH 10/21] drm/amd/display: Initial documentation for AMDgpu DC

2018-10-25 Thread sunpeng.li
From: Leo Li 

[Why]
Documentation is helpful for the community to understand our code.
This change does some high-level documentation of some DM interfaces
with DRM, and the amdgpu base driver.

[How]
An entry for AMDgpu DC has been added to Documentation/gpu/drivers.rst
TOC. amdgpu-dc.rst is created to pull in inline doc-strings, which:
- Provides an overview for "What is DM?"
- Documents AMDgpu DM lifecyle
- Documents IRQ management
- Documents atomic_check and commit_tail interfaces

Signed-off-by: Leo Li 
Reviewed-by: David Francis 
Acked-by: Leo Li 
---
 Documentation/gpu/amdgpu-dc.rst|  68 
 Documentation/gpu/drivers.rst  |   1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 101 +++---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  76 +++---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  | 115 ++---
 5 files changed, 320 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/gpu/amdgpu-dc.rst

diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst
new file mode 100644
index 000..cc89b0f
--- /dev/null
+++ b/Documentation/gpu/amdgpu-dc.rst
@@ -0,0 +1,68 @@
+===
+drm/amd/display - Display Core (DC)
+===
+
+*placeholder - general description of supported platforms, what dc is, etc.*
+
+Because it is partially shared with other operating systems, the Display Core
+Driver is divided in two pieces.
+
+1. **Display Core (DC)** contains the OS-agnostic components. Things like
+   hardware programming and resource management are handled here.
+2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the
+   amdgpu base driver and DRM are implemented here.
+
+It doesn't help that the entire package is frequently referred to as DC. But
+with the context in mind, it should be clear.
+
+When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for
+supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line.
+Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`.
+
+To determine if DC is loaded, search dmesg for the following entry:
+
+``Display Core initialized with ``
+
+AMDgpu Display Manager
+==
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+   :internal:
+
+Lifecycle
+-
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+   :doc: DM Lifecycle
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+   :functions: dm_hw_init dm_hw_fini
+
+Interrupts
+--
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+   :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq
+
+Atomic Implementation
+-
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+   :doc: atomic
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+   :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail
+
+Display Core
+
+
+**WIP**
diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
index 65be325..95bbdf7 100644
--- a/Documentation/gpu/drivers.rst
+++ b/Documentation/gpu/drivers.rst
@@ -5,6 +5,7 @@ GPU Driver Documentation
 .. toctree::
 
amdgpu
+   amdgpu-dc
i915
meson
pl111
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 84201f4..c19adde 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -76,6 +76,16 @@
 #define FIRMWARE_RAVEN_DMCU"amdgpu/raven_dmcu.bin"
 MODULE_FIRMWARE(FIRMWARE_RAVEN_DMCU);
 
+/**
+ * DOC: overview
+ *
+ * The AMDgpu display manager, **amdgpu_dm** (or even simpler,
+ * **dm**) sits between DRM and DC. It acts as a liason, converting DRM
+ * requests into DC requests, and DC responses into DRM responses.
+ *
+ * The root control structure is  amdgpu_display_manager.
+ */
+
 /* basic init/fini API */
 static int amdgpu_dm_init(struct amdgpu_device *adev);
 static void amdgpu_dm_fini(struct amdgpu_device *adev);
@@ -379,11 +389,6 @@ static void amdgpu_dm_fbc_init(struct drm_connector 
*connector)
 
 }
 
-/*
- * Init display KMS
- *
- * Returns 0 on success
- */
 static int amdgpu_dm_init(struct amdgpu_device *adev)
 {
struct dc_init_data init_data;
@@ -660,6 +665,26 @@ static void s3_handle_mst(struct drm_device *dev, bool 
suspend)
drm_modeset_unlock(>mode_config.connection_mutex);
 }
 
+/**
+ * dm_hw_init() - Initialize DC device
+ * @handle: The base driver device containing the amdpgu_dm device.
+ 

[PATCH 09/21] drm/amd/display: Fix potential nullptr error

2018-10-25 Thread sunpeng.li
From: Bhawanpreet Lakha 

[Why]
Fix surface/plane potential nullptr

[How]
add null check

Signed-off-by: Bhawanpreet Lakha 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
 1 file changed, 6 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 492230c..84201f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5321,6 +5321,12 @@ enum surface_update_type 
dm_determine_update_type_for_commit(struct dc *dc, stru
struct dc_stream_update stream_update;
enum surface_update_type update_type = UPDATE_TYPE_FAST;
 
+   if (!updates || !surface) {
+   DRM_ERROR("Plane or surface update failed to allocate");
+   /* Set type to FULL to avoid crashing in DC*/
+   update_type = UPDATE_TYPE_FULL;
+   goto ret;
+   }
 
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
new_dm_crtc_state = to_dm_crtc_state(new_crtc_state);
-- 
2.7.4

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


[PATCH 08/21] drm/amd/display: 3.2.04

2018-10-25 Thread sunpeng.li
From: Steven Chiu 

Signed-off-by: Steven Chiu 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 4750a29..02db008 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -38,7 +38,7 @@
 #include "inc/compressor.h"
 #include "dml/display_mode_lib.h"
 
-#define DC_VER "3.2.03"
+#define DC_VER "3.2.04"
 
 #define MAX_SURFACES 3
 #define MAX_STREAMS 6
-- 
2.7.4

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


[PATCH 07/21] drm/amd/display: Fix up coverity issues

2018-10-25 Thread sunpeng.li
From: Aric Cyr 

[Why]
Coverity found various high-impact issues that need resolving.

[How]
Fix  some buffer overruns and uninitialized variables.

Signed-off-by: Aric Cyr 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c   | 2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_debug.c  | 7 +++
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 6 +++---
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 0e1dc1b..c2ab026 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -2030,7 +2030,7 @@ static uint32_t get_src_obj_list(struct bios_parser *bp, 
ATOM_OBJECT *object,
 static struct device_id device_type_from_device_id(uint16_t device_id)
 {
 
-   struct device_id result_device_id;
+   struct device_id result_device_id = {0};
 
switch (device_id) {
case ATOM_DEVICE_LCD1_SUPPORT:
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
index e1ebdf7..73d0495 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
@@ -311,7 +311,7 @@ void context_timing_trace(
 {
int i;
struct dc  *core_dc = dc;
-   int h_pos[MAX_PIPES], v_pos[MAX_PIPES];
+   int h_pos[MAX_PIPES] = {0}, v_pos[MAX_PIPES] = {0};
struct crtc_position position;
unsigned int underlay_idx = core_dc->res_pool->underlay_pipe_index;
DC_LOGGER_INIT(dc->ctx->logger);
@@ -322,8 +322,7 @@ void context_timing_trace(
/* get_position() returns CRTC vertical/horizontal counter
 * hence not applicable for underlay pipe
 */
-   if (pipe_ctx->stream == NULL
-|| pipe_ctx->pipe_idx == underlay_idx)
+   if (pipe_ctx->stream == NULL || pipe_ctx->pipe_idx == 
underlay_idx)
continue;
 

pipe_ctx->stream_res.tg->funcs->get_position(pipe_ctx->stream_res.tg, 
);
@@ -333,7 +332,7 @@ void context_timing_trace(
for (i = 0; i < core_dc->res_pool->pipe_count; i++) {
struct pipe_ctx *pipe_ctx = _ctx->pipe_ctx[i];
 
-   if (pipe_ctx->stream == NULL)
+   if (pipe_ctx->stream == NULL || pipe_ctx->pipe_idx == 
underlay_idx)
continue;
 
TIMING_TRACE("OTG_%d   H_tot:%d  V_tot:%d   H_pos:%d  
V_pos:%d\n",
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index e8c3620..de3c327 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -548,14 +548,14 @@ dce110_translate_regamma_to_hw_format(const struct 
dc_transfer_func *output_tf,
 
regamma_params->hw_points_num = hw_points;
 
-   i = 1;
-   for (k = 0; k < 16 && i < 16; k++) {
+   k = 0;
+   for (i = 1; i < 16; i++) {
if (seg_distr[k] != -1) {
regamma_params->arr_curve_points[k].segments_num = 
seg_distr[k];
regamma_params->arr_curve_points[i].offset =

regamma_params->arr_curve_points[k].offset + (1 << seg_distr[k]);
}
-   i++;
+   k++;
}
 
if (seg_distr[k] != -1)
-- 
2.7.4

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


[PATCH 06/21] drm/amd/display: remove interlace scaling adjustment

2018-10-25 Thread sunpeng.li
From: Dmytro Laktyushkin 

We do not need to adjust surface scaling when p2i is enabled
and we do not support interlaced timing otherwise

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index a5eb80a..d68906b 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1115,9 +1115,6 @@ bool resource_build_scaling_params(struct pipe_ctx 
*pipe_ctx)
pipe_ctx->plane_res.scl_data.format = 
convert_pixel_format_to_dalsurface(
pipe_ctx->plane_state->format);
 
-   if (pipe_ctx->stream->timing.flags.INTERLACE)
-   pipe_ctx->stream->dst.height *= 2;
-
calculate_scaling_ratios(pipe_ctx);
 
calculate_viewport(pipe_ctx);
@@ -1138,9 +1135,6 @@ bool resource_build_scaling_params(struct pipe_ctx 
*pipe_ctx)
 
pipe_ctx->plane_res.scl_data.h_active = timing->h_addressable + 
timing->h_border_left + timing->h_border_right;
pipe_ctx->plane_res.scl_data.v_active = timing->v_addressable + 
timing->v_border_top + timing->v_border_bottom;
-   if (pipe_ctx->stream->timing.flags.INTERLACE)
-   pipe_ctx->plane_res.scl_data.v_active *= 2;
-
 
/* Taps calculations */
if (pipe_ctx->plane_res.xfm != NULL)
@@ -1185,9 +1179,6 @@ bool resource_build_scaling_params(struct pipe_ctx 
*pipe_ctx)
plane_state->dst_rect.x,
plane_state->dst_rect.y);
 
-   if (pipe_ctx->stream->timing.flags.INTERLACE)
-   pipe_ctx->stream->dst.height /= 2;
-
return res;
 }
 
-- 
2.7.4

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


[PATCH 05/21] drm/amd/display: Add missing pipes registers for VGA enable/disable

2018-10-25 Thread sunpeng.li
From: Nevenko Stupar 

Signed-off-by: Nevenko Stupar 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h 
b/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h
index 7d97787..c83a7f0 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h
@@ -282,6 +282,8 @@ struct dce_hwseq_registers {
uint32_t D2VGA_CONTROL;
uint32_t D3VGA_CONTROL;
uint32_t D4VGA_CONTROL;
+   uint32_t D5VGA_CONTROL;
+   uint32_t D6VGA_CONTROL;
uint32_t VGA_TEST_CONTROL;
/* MMHUB registers. read only. temporary hack */
uint32_t VM_CONTEXT0_PAGE_TABLE_BASE_ADDR_HI32;
-- 
2.7.4

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


[PATCH 02/21] drm/amd/display: 3.2.03

2018-10-25 Thread sunpeng.li
From: SivapiriyanKumarasamy 

Signed-off-by: SivapiriyanKumarasamy 
Reviewed-by: Tony Cheng 
Reviewed-by: Steven Chiu 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 7c01f01..4750a29 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -38,7 +38,7 @@
 #include "inc/compressor.h"
 #include "dml/display_mode_lib.h"
 
-#define DC_VER "3.2.02"
+#define DC_VER "3.2.03"
 
 #define MAX_SURFACES 3
 #define MAX_STREAMS 6
-- 
2.7.4

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


[PATCH 03/21] drm/amd/display: Clip all remaining regamma points after first clipped point

2018-10-25 Thread sunpeng.li
From: SivapiriyanKumarasamy 

[Why]
All values computed in the gamma curve after the first upperbound
clipped point will need to be clipped anyways. We can avoid
unnecessary computations and potential fixed point
overflow by instead clipping these values to 1 automatically.

[How]
Track if upper-bound clipping has been done, and clip all values after
this threshold is reached without computing the output gamma
point.

Signed-off-by: SivapiriyanKumarasamy 
Reviewed-by: Krunoslav Kovac 
Acked-by: Leo Li 
---
 .../drm/amd/display/modules/color/color_gamma.c| 44 +-
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c 
b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
index 81b8422..7480f07 100644
--- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
+++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
@@ -820,6 +820,7 @@ static bool build_freesync_hdr(struct pwl_float_data_ex 
*rgb_regamma,
struct fixed31_32 clip = dc_fixpt_one;
struct fixed31_32 output;
bool use_eetf = false;
+   bool is_clipped = false;
struct fixed31_32 sdr_white_level = 
dc_fixpt_from_int(fs_params->sdr_white_level);
 
if (fs_params == NULL || fs_params->max_content == 0 ||
@@ -844,25 +845,32 @@ static bool build_freesync_hdr(struct pwl_float_data_ex 
*rgb_regamma,
rgb += 32; // first 32 points have problems with fixed point, too small
coord_x += 32;
for (i = 32; i <= hw_points_num; i++) {
-   if (use_eetf) {
-   /*max content is equal 1 */
-   scaledX1 = dc_fixpt_div(coord_x->x,
-   dc_fixpt_div(max_content, 
sdr_white_level));
-   hermite_spline_eetf(scaledX1, max_display, min_display,
-   max_content, );
-   } else
-   scaledX = dc_fixpt_div(coord_x->x,
-   dc_fixpt_div(max_display, 
sdr_white_level));
-
-   if (dc_fixpt_lt(scaledX, clip)) {
-   if (dc_fixpt_lt(scaledX, dc_fixpt_zero))
-   output = dc_fixpt_zero;
-   else
-   output = calculate_gamma22(scaledX);
+   if (!is_clipped) {
+   if (use_eetf) {
+   /*max content is equal 1 */
+   scaledX1 = dc_fixpt_div(coord_x->x,
+   dc_fixpt_div(max_content, 
sdr_white_level));
+   hermite_spline_eetf(scaledX1, max_display, 
min_display,
+   max_content, );
+   } else
+   scaledX = dc_fixpt_div(coord_x->x,
+   dc_fixpt_div(max_display, 
sdr_white_level));
+
+   if (dc_fixpt_lt(scaledX, clip)) {
+   if (dc_fixpt_lt(scaledX, dc_fixpt_zero))
+   output = dc_fixpt_zero;
+   else
+   output = calculate_gamma22(scaledX);
 
-   rgb->r = output;
-   rgb->g = output;
-   rgb->b = output;
+   rgb->r = output;
+   rgb->g = output;
+   rgb->b = output;
+   } else {
+   is_clipped = true;
+   rgb->r = clip;
+   rgb->g = clip;
+   rgb->b = clip;
+   }
} else {
rgb->r = clip;
rgb->g = clip;
-- 
2.7.4

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


[PATCH 04/21] drm/amd/display: fix dml max voltage state

2018-10-25 Thread sunpeng.li
From: Dmytro Laktyushkin 

Gabe's formula sometimes uses values from non-existent 'unsupported'
state to do validation.

This change adds this extra state so validation can work correctly.

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Tony Cheng 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h 
b/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
index cbafce6..5dd0452 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/display_mode_structs.h
@@ -113,7 +113,8 @@ struct _vcs_dpi_soc_bounding_box_st {
int use_urgent_burst_bw;
double max_hscl_ratio;
double max_vscl_ratio;
-   struct _vcs_dpi_voltage_scaling_st clock_limits[7];
+   unsigned int num_states;
+   struct _vcs_dpi_voltage_scaling_st clock_limits[8];
 };
 
 struct _vcs_dpi_ip_params_st {
-- 
2.7.4

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


[PATCH 01/21] drm/amd/display: Set gamma not working on MPO planes

2018-10-25 Thread sunpeng.li
From: Krunoslav Kovac 

[Why]
Set gamma not working on certain planes in MPO configuration
Root cause is that video format (YUV-420) isn't allowed for IGAM where
gamma is applied.
Fix is not easy though:
1. allowing will not work because IGAM is before ICSC so RGB gamma would
be applied on YUV pixels.
2. Moving OS gamma to DGAM or RGAM resulted in weird artifacts.

Ultimately the root cause for these artifacts was due to handling end
points and the fact that YUV->RGB conversion will frequently "overshoot"
FP 1.0 value. DCE  has a single end point and slope, so we would take max.
In nightlight mode, blue channel is reduced, sometimes to flat 0 line,
but red is virtually unchanged. Any "overshot" in blue will be clipped
to 1 (max R,G,B) instead of max blue value.

[How]
Fortunately, this can be fixed on DCN where we have end point and slope
for all three color channels. We cannot fix this problem on DCE.

Other things fixed:
- switch (back) to using RGAM for OS gamma instead of IGAM
- add coeffs for 709 YUV->RGB (we used RGB->YUV for both conversions)
- switch color temperature method to scaled bradford - otherwise we would
have clipping problems that caused us to switch to IGAM for OS gamma
in the first place.
- comments and some minor improvements - there are some more issues but
they will be addressed in separate commits.

Signed-off-by: Krunoslav Kovac 
Reviewed-by: Aric Cyr 
Acked-by: Leo Li 
---
 .../gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c | 251 +
 .../gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.h |   2 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h  |  16 +-
 .../drm/amd/display/modules/color/color_gamma.c|   2 +-
 4 files changed, 180 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c
index 97c05993..3eea440 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c
@@ -71,39 +71,39 @@ void cm_helper_program_xfer_func(
unsigned int i = 0;
 
REG_SET_2(reg->start_cntl_b, 0,
-   exp_region_start, params->arr_points[0].custom_float_x,
+   exp_region_start, 
params->corner_points[0].blue.custom_float_x,
exp_resion_start_segment, 0);
REG_SET_2(reg->start_cntl_g, 0,
-   exp_region_start, params->arr_points[0].custom_float_x,
+   exp_region_start, 
params->corner_points[0].green.custom_float_x,
exp_resion_start_segment, 0);
REG_SET_2(reg->start_cntl_r, 0,
-   exp_region_start, params->arr_points[0].custom_float_x,
+   exp_region_start, 
params->corner_points[0].red.custom_float_x,
exp_resion_start_segment, 0);
 
REG_SET(reg->start_slope_cntl_b, 0,
-   field_region_linear_slope, 
params->arr_points[0].custom_float_slope);
+   field_region_linear_slope, 
params->corner_points[0].blue.custom_float_slope);
REG_SET(reg->start_slope_cntl_g, 0,
-   field_region_linear_slope, 
params->arr_points[0].custom_float_slope);
+   field_region_linear_slope, 
params->corner_points[0].green.custom_float_slope);
REG_SET(reg->start_slope_cntl_r, 0,
-   field_region_linear_slope, 
params->arr_points[0].custom_float_slope);
+   field_region_linear_slope, 
params->corner_points[0].red.custom_float_slope);
 
REG_SET(reg->start_end_cntl1_b, 0,
-   field_region_end, params->arr_points[1].custom_float_x);
+   field_region_end, 
params->corner_points[1].blue.custom_float_x);
REG_SET_2(reg->start_end_cntl2_b, 0,
-   field_region_end_slope, 
params->arr_points[1].custom_float_slope,
-   field_region_end_base, 
params->arr_points[1].custom_float_y);
+   field_region_end_slope, 
params->corner_points[1].blue.custom_float_slope,
+   field_region_end_base, 
params->corner_points[1].blue.custom_float_y);
 
REG_SET(reg->start_end_cntl1_g, 0,
-   field_region_end, params->arr_points[1].custom_float_x);
+   field_region_end, 
params->corner_points[1].green.custom_float_x);
REG_SET_2(reg->start_end_cntl2_g, 0,
-   field_region_end_slope, 
params->arr_points[1].custom_float_slope,
-   field_region_end_base, params->arr_points[1].custom_float_y);
+   field_region_end_slope, 
params->corner_points[1].green.custom_float_slope,
+   field_region_end_base, 
params->corner_points[1].green.custom_float_y);
 
REG_SET(reg->start_end_cntl1_r, 0,
-   field_region_end, params->arr_points[1].custom_float_x);

[PATCH 00/21] DC Patches Oct 25, 2018

2018-10-25 Thread sunpeng.li
From: Leo Li 

Summary of change:
* Initial documentation of AMDgpu DM
* Clean-up output CSC programming code
* Some coverity fixes
* Fix for possible null derefs in crc configuration and plane update paths

Anthony Koo (3):
  drm/amd/display: Expand dc to use 16.16 bit backlight
  drm/amd/display: Fix some backlight variable styling
  drm/amd/display: Expose target backlight level

Aric Cyr (1):
  drm/amd/display: Fix up coverity issues

Bhawanpreet Lakha (1):
  drm/amd/display: Fix potential nullptr error

Charlene Liu (1):
  drm/amd/display: remove CRTC_3D_STRUCTURE_V_UPDATE_MODE bit
programming.

Dmytro Laktyushkin (3):
  drm/amd/display: fix dml max voltage state
  drm/amd/display: remove interlace scaling adjustment
  drm/amd/display: fix mirror rotation scaling math

Eric Bernstein (1):
  drm/amd/display: Remove some old TODO's

Fatemeh Darbehani (2):
  drm/amd/display: Retiring set_display_requirements in dm_pp_smu.h -
part4
  drm/amd/display: Remove the check to see if pp_display_cfg is changed

Krunoslav Kovac (2):
  drm/amd/display: Set gamma not working on MPO planes
  drm/amd/display: Remove program_csc_matrix

Leo Li (1):
  drm/amd/display: Initial documentation for AMDgpu DC

Lewis Huang (1):
  drm/amd/display: Add condition to sync eDP SW status and HW status

Nevenko Stupar (1):
  drm/amd/display: Add missing pipes registers for VGA enable/disable

Nicholas Kazlauskas (1):
  drm/amd/display: Guard against null stream_state in set_crc_source

SivapiriyanKumarasamy (2):
  drm/amd/display: 3.2.03
  drm/amd/display: Clip all remaining regamma points after first clipped
point

Steven Chiu (1):
  drm/amd/display: 3.2.04

 Documentation/gpu/amdgpu-dc.rst|  68 ++
 Documentation/gpu/drivers.rst  |   1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 114 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  76 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |   5 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  | 115 --
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c   |  20 +-
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  |   2 +-
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c |   2 +
 .../drm/amd/display/dc/bios/bios_parser_helper.c   |  93 
 .../drm/amd/display/dc/bios/bios_parser_helper.h   |   4 +
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  32 +--
 drivers/gpu/drm/amd/display/dc/core/dc.c   |   8 +-
 drivers/gpu/drm/amd/display/dc/core/dc_debug.c |   7 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  34 +--
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  74 ++
 drivers/gpu/drm/amd/display/dc/dc.h|   2 +-
 drivers/gpu/drm/amd/display/dc/dc_bios_types.h |   5 +
 drivers/gpu/drm/amd/display/dc/dc_link.h   |  11 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c   | 104 -
 drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h |   2 +
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  45 ++--
 .../gpu/drm/amd/display/dc/dcn10/dcn10_clk_mgr.c   |   9 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c | 251 +
 .../gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.h |   2 +-
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  30 +--
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c  |   6 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |   1 +
 drivers/gpu/drm/amd/display/dc/dm_pp_smu.h |  16 +-
 drivers/gpu/drm/amd/display/dc/dm_services_types.h |  18 +-
 .../drm/amd/display/dc/dml/display_mode_structs.h  |   3 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/abm.h|  12 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h  |  16 +-
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |   7 -
 .../drm/amd/display/modules/color/color_gamma.c|  46 ++--
 35 files changed, 844 insertions(+), 397 deletions(-)
 create mode 100644 Documentation/gpu/amdgpu-dc.rst

-- 
2.7.4

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


Re: [PATCH] RFC: Make igts for cross-driver stuff mandatory?

2018-10-25 Thread Sean Paul
On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> Hi all,
> 
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I think there's lots of value in having them: A
> cross-vendor interface isn't useful if every driver implements it
> slightly differently.
> 
> I think there's 2 questions here:
> 
> - Do we want to make such testcases mandatory?
> 

Yes, more testing == better code.


> - If yes, are we there yet, or is there something crucially missing
>   still?

In my experience, no. Last week while trying to replicate an intel-gfx CI
failure, I tried compiling igt for one of my (intel) chromebooks. It seems like
cross-compilation (or, in my case, just specifying
prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose
restrictions across the entire subsystem, we need to make sure that everyone can
build and deploy igt easily.

I managed to hack around everything and get it working, but I still haven't
tried switching out the toolchain. Once we have some GitLab CI to validate
cross-compilation, then we can consider making IGT mandatory.

It's possible that I'm just a meson n00b and didn't use the right incantation,
so maybe it already works, but then we need better documentation.

I've pasted my horrible hacks below, I also didn't have libunwind, so removed
its usage.

Sean


/snip


From ab8c7d274c32559295b38d6ceeaabded14b207d4 Mon Sep 17 00:00:00 2001
From: Sean Paul 
Date: Thu, 25 Oct 2018 08:40:28 -0400
Subject: [PATCH] igt: Hacks to compile in CrOS chroot

Signed-off-by: Sean Paul 
---
 lib/igt_core.c| 78 ---
 lib/meson.build   |  1 -
 meson.build   |  4 +-
 tests/gem_userptr_blits.c |  2 +
 tools/meson.build |  7 
 5 files changed, 5 insertions(+), 87 deletions(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 23bb858f..ca65d7cc 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -71,8 +71,6 @@
 #include "igt_sysrq.h"
 #include "igt_rc.h"
 
-#define UNW_LOCAL_ONLY
-#include 
 #include 
 
 #ifdef HAVE_LIBGEN_H
@@ -1209,63 +1207,6 @@ static void write_stderr(const char *str)
 
 static void print_backtrace(void)
 {
-   unw_cursor_t cursor;
-   unw_context_t uc;
-   int stack_num = 0;
-
-   Dwfl_Callbacks cbs = {
-   .find_elf = dwfl_linux_proc_find_elf,
-   .find_debuginfo = dwfl_standard_find_debuginfo,
-   };
-
-   Dwfl *dwfl = dwfl_begin();
-
-   if (dwfl_linux_proc_report(dwfl, getpid())) {
-   dwfl_end(dwfl);
-   dwfl = NULL;
-   } else
-   dwfl_report_end(dwfl, NULL, NULL);
-
-   igt_info("Stack trace:\n");
-
-   unw_getcontext();
-   unw_init_local(, );
-   while (unw_step() > 0) {
-   char name[255];
-   unw_word_t off, ip;
-   Dwfl_Module *mod = NULL;
-
-   unw_get_reg(, UNW_REG_IP, );
-
-   if (dwfl)
-   mod = dwfl_addrmodule(dwfl, ip);
-
-   if (mod) {
-   const char *src, *dwfl_name;
-   Dwfl_Line *line;
-   int lineno;
-   GElf_Sym sym;
-
-   line = dwfl_module_getsrc(mod, ip);
-   dwfl_name = dwfl_module_addrsym(mod, ip, , NULL);
-
-   if (line && dwfl_name) {
-   src = dwfl_lineinfo(line, NULL, , NULL, 
NULL, NULL);
-   igt_info("  #%d %s:%d %s()\n", stack_num++, 
src, lineno, dwfl_name);
-   continue;
-   }
-   }
-
-   if (unw_get_proc_name(, name, 255, ) < 0)
-   igt_info("  #%d [+0x%x]\n", stack_num++,
-(unsigned int) ip);
-   else
-   igt_info("  #%d [%s+0x%x]\n", stack_num++, name,
-(unsigned int) off);
-   }
-
-   if (dwfl)
-   dwfl_end(dwfl);
 }
 
 static const char hex[] = "0123456789abcdef";
@@ -1420,25 +1361,6 @@ xprintf(const char *fmt, ...)
 
 static void print_backtrace_sig_safe(void)
 {
-   unw_cursor_t cursor;
-   unw_context_t uc;
-   int stack_num = 0;
-
-   write_stderr("Stack trace: \n");
-
-   unw_getcontext();
-   unw_init_local(, );
-   while (unw_step() > 0) {
-   char name[255];
-   unw_word_t off;
-
-   if (unw_get_proc_name(, name, 255, ) < 0)
-   xstrlcpy(name, "", 10);
-
-   xprintf(" #%d [%s+0x%x]\n", stack_num++, name,
-   (unsigned int) off);
-
-   }
 }
 
 void __igt_fail_assert(const char *domain, const char *file, const int line,
diff --git a/lib/meson.build 

Re: [PATCH] RFC: Make igts for cross-driver stuff mandatory?

2018-10-25 Thread Daniel Vetter
On Thu, Oct 25, 2018 at 11:58 AM Liviu Dudau  wrote:
> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> > Hi all,
>
> Hi,
>
> (Replying from my personal address as the work email seems to have let
> this one go to /dev/null)
>
> >
> > This is just to collect feedback on this idea, and see whether the
> > overall dri-devel community stands on all this. I think the past few
> > cross-vendor uapi extensions all came with igts attached, and
> > personally I think there's lots of value in having them: A
> > cross-vendor interface isn't useful if every driver implements it
> > slightly differently.
>
> I would like to also get some clarification on where we are standing on
> "tests vs 'real code'" stanza. Does making igt tests mandatory replace
> the need for 'real code' or does it add to the list of requirements? If
> the later, then I think the bar rises in terms of showing igts'
> usefulness / benefits.

It would be in addition. The "real code" userspace is for validating
the overall design. Igt (and unit tests) are more for checking all the
details, error handling, and having a regression test suite going
forward.

> > I think there's 2 questions here:
> >
> > - Do we want to make such testcases mandatory?
>
> I'm a bit reluctant to make it so by fiat. I think that showing the
> usefulness of having igts tests to newcomers (by adding with this patch
> some more information about why IGT is a good place to add your testing to)
> and getting more mature drivers to get tested under IGT on a regular basis
> would make adoption of IGT for testing a community standard.

There's 2 motivations here for me:
- Most of the generic features in the past 1-2 did come with igts, but
sometimes those igts have been treated as 2nd class and forgotten. I
think it's at least the right time to discuss whether we should make
them an integral part of uapi development.

- The other bit is that our intel CI is catching a lot of regressions,
and people have started to cc: intel-gfx to get their non-intel
patches validated too. So all these igts we have do seem to provide
real value in keeping things working.

> > - If yes, are we there yet, or is there something crucially missing
> >   still?
>
> I'm just getting back into IGT by refreshing the writeback patches, but
> by looking at the commit log I get the impression that there aren't that
> many patches that target drivers other than Intel's. Are all the non-Intel
> patches so generic that one doesn't need to specify a target driver for
> those changes (in which case great, but then why is Intel's so different?),
> or are the others not bothered with IGT support?

So this discussion isn't about igt overall, but just about
cross-driver features. The tests we have in igt for intel are a lot
more:
- We also validate all the intel-specific bits with igts.
- We validate all the interactions between generic stuff and
intel-specific uapi with igts.
- We validate hw features with igt.

And finally we've made igts mandatory for all things intel more than 5
years ago. So there's considerable head start.

The other side is that I'm only suggesting that we make igts mandatory
for cross-driver interfaces. Naturally the tests for those aren't
aimed at a specific driver, but use the DRIVER_ANY flag. And the work
needed to make that work on a specific driver is usually rather small
- e.g. vmwgfx (which doesn't support GEM at all) required very small
changes to get things going. Now we do have some tests for other
drivers (vc4 and a few amdgpu), but not anything else. So I'd say the
lack of non-intel targetted patches is a good thing.

> At the moment I'm a bit on the fence on this. Not having spent too much
> time with IGT in the last 6 months, I'm probably closer to a newcomer in
> my attitude towards IGT and at the moment I'm not clear on how to answer the
> "Why?" and "What is in it for me?" questions.

Well all the usual reasons for testing:
- Only way to make sure different implementations are working correct.
- Only real way to make sure regressions are caught before everything
is on fire.

Of course this gets a lot better if there's also CI running them
(which we do for intel, and are open to anyone submitting stuff to
it), but just having the tests is already a big step.

Cheers, Daniel

> Best regards,
> Liviu
>
> >
> > And of course there's a bunch of details to figure out. Like we
> > probably want to also recommend the selftests/unit-tests in
> > drivers/gpu/drm/selftest, since fairly often that's a much more
> > effective approach to checking the details than from userspace.
> >
> > Feedback and thoughts very much appreciated.
> >
> > Cheers, Daniel
> > ---
> >  Documentation/gpu/drm-uapi.rst | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 4b4bf2c5eac5..91cf6e4b6303 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -238,6 

Re: [PATCH] RFC: Make igts for cross-driver stuff mandatory?

2018-10-25 Thread Liviu Dudau
On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
> Hi all,

Hi,

(Replying from my personal address as the work email seems to have let
this one go to /dev/null)

> 
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I think there's lots of value in having them: A
> cross-vendor interface isn't useful if every driver implements it
> slightly differently.

I would like to also get some clarification on where we are standing on 
"tests vs 'real code'" stanza. Does making igt tests mandatory replace
the need for 'real code' or does it add to the list of requirements? If
the later, then I think the bar rises in terms of showing igts' 
usefulness / benefits.

> 
> I think there's 2 questions here:
> 
> - Do we want to make such testcases mandatory?

I'm a bit reluctant to make it so by fiat. I think that showing the
usefulness of having igts tests to newcomers (by adding with this patch
some more information about why IGT is a good place to add your testing to)
and getting more mature drivers to get tested under IGT on a regular basis
would make adoption of IGT for testing a community standard.

> 
> - If yes, are we there yet, or is there something crucially missing
>   still?

I'm just getting back into IGT by refreshing the writeback patches, but
by looking at the commit log I get the impression that there aren't that
many patches that target drivers other than Intel's. Are all the non-Intel
patches so generic that one doesn't need to specify a target driver for
those changes (in which case great, but then why is Intel's so different?),
or are the others not bothered with IGT support?

At the moment I'm a bit on the fence on this. Not having spent too much
time with IGT in the last 6 months, I'm probably closer to a newcomer in
my attitude towards IGT and at the moment I'm not clear on how to answer the
"Why?" and "What is in it for me?" questions.

Best regards,
Liviu

> 
> And of course there's a bunch of details to figure out. Like we
> probably want to also recommend the selftests/unit-tests in
> drivers/gpu/drm/selftest, since fairly often that's a much more
> effective approach to checking the details than from userspace.
> 
> Feedback and thoughts very much appreciated.
> 
> Cheers, Daniel
> ---
>  Documentation/gpu/drm-uapi.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 4b4bf2c5eac5..91cf6e4b6303 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -238,6 +238,13 @@ DRM specific patterns. Note that ENOTTY has the slightly 
> unintuitive meaning of
>  Testing and validation
>  ==
>  
> +Testing Requirements for userspace API
> +--
> +
> +New cross-driver userspace interface extensions, like new IOCTL, new KMS
> +properties, new files in sysfs or anything else that constitutes an API 
> change
> +need to have driver-agnostic testcases in IGT for that feature.
> +
>  Validating changes with IGT
>  ---
>  
> -- 
> 2.19.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
 /`\
/ : |
   _.._ | '/
 /`\| /
|  .-._ '-"` (
|_/   /   o  o\
  |  == () ==
   \   -- /   __
   / ---<_  |  
|___
  |  \\ \   |  I would like to fix the world but   |
  /
  | | \\__   \  |   no one gives me the source code.   |
 /
  / ; |.__)  /  |__|
 \
 (_/.-.   ; /__)
(_\
{ `|   \_/
 '-\   / |
| /  |
   /  \  '-.
   \__|-'
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 4/4] drm/amdgpu: use GMC v9 KIQ workaround only for the GFXHUB

2018-10-25 Thread Deng, Emily
Add Wentao.

Best wishes
Emily Deng



>-Original Message-
>From: amd-gfx  On Behalf Of
>Christian König
>Sent: Thursday, October 25, 2018 5:15 PM
>To: amd-gfx@lists.freedesktop.org
>Subject: [PATCH 4/4] drm/amdgpu: use GMC v9 KIQ workaround only for the
>GFXHUB
>
>The MMHUB is not affected by this.
>
>Signed-off-by: Christian König 
>---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>index ff5e5f69b403..9ea73fb36572 100644
>--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>@@ -338,9 +338,9 @@ static void gmc_v9_0_flush_gpu_tlb(struct
>amdgpu_device *adev,
>   struct amdgpu_vmhub *hub = >vmhub[i];
>   u32 tmp = gmc_v9_0_get_invalidate_req(vmid, flush_type);
>
>-  if (adev->gfx.kiq.ring.ready &&
>-  (amdgpu_sriov_runtime(adev) || !amdgpu_sriov_vf(adev))
>&&
>-  !adev->in_gpu_reset) {
>+  if (i == AMDGPU_GFXHUB && !adev->in_gpu_reset &&
>+  adev->gfx.kiq.ring.ready &&
>+  (amdgpu_sriov_runtime(adev) || !amdgpu_sriov_vf(adev)))
>{
>   uint32_t req = hub->vm_inv_eng0_req + eng;
>   uint32_t ack = hub->vm_inv_eng0_ack + eng;
>
>--
>2.14.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: [PATCH 1/4] drm/amdgpu: remove nonsense in_interrupt() checks

2018-10-25 Thread Deng, Emily
Add Wentao.

Best wishes
Emily Deng



>-Original Message-
>From: amd-gfx  On Behalf Of
>Christian König
>Sent: Thursday, October 25, 2018 5:15 PM
>To: amd-gfx@lists.freedesktop.org
>Subject: [PATCH 1/4] drm/amdgpu: remove nonsense in_interrupt() checks
>
>might_sleep() is supposed to raise if warning if called in interrupt or atomic
>context.
>
>Signed-off-by: Christian König 
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>index f2f358aa0597..8f50bc245dd6 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>@@ -162,9 +162,7 @@ uint32_t amdgpu_virt_kiq_rreg(struct amdgpu_device
>*adev, uint32_t reg)
>   if (r < 1 && (adev->in_gpu_reset || in_interrupt()))
>   goto failed_kiq_read;
>
>-  if (in_interrupt())
>-  might_sleep();
>-
>+  might_sleep();
>   while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
>   msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
>   r = amdgpu_fence_wait_polling(ring, seq,
>MAX_KIQ_REG_WAIT); @@ -210,9 +208,7 @@ void
>amdgpu_virt_kiq_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v)
>   if (r < 1 && (adev->in_gpu_reset || in_interrupt()))
>   goto failed_kiq_write;
>
>-  if (in_interrupt())
>-  might_sleep();
>-
>+  might_sleep();
>   while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
>
>   msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
>--
>2.14.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: [PATCH 3/4] drm/amdgpu: drop the busy wait for GMC v9 TLB invalidations

2018-10-25 Thread Deng, Emily
Add Wentao.

Best wishes
Emily Deng



>-Original Message-
>From: amd-gfx  On Behalf Of
>Christian König
>Sent: Thursday, October 25, 2018 5:15 PM
>To: amd-gfx@lists.freedesktop.org
>Subject: [PATCH 3/4] drm/amdgpu: drop the busy wait for GMC v9 TLB
>invalidations
>
>This code is not performance critical.
>
>Signed-off-by: Christian König 
>---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 26 --
> 1 file changed, 4 insertions(+), 22 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>index 7dee74f1937c..ff5e5f69b403 100644
>--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>@@ -350,35 +350,17 @@ static void gmc_v9_0_flush_gpu_tlb(struct
>amdgpu_device *adev,
>   }
>
>   spin_lock(>gmc.invalidate_lock);
>-
>   WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
>-
>-  /* Busy wait for ACK.*/
>-  for (j = 0; j < 100; j++) {
>-  tmp = RREG32_NO_KIQ(hub->vm_inv_eng0_ack +
>eng);
>-  tmp &= 1 << vmid;
>-  if (tmp)
>-  break;
>-  cpu_relax();
>-  }
>-  if (j < 100) {
>-  spin_unlock(>gmc.invalidate_lock);
>-  continue;
>-  }
>-
>-  /* Wait for ACK with a delay.*/
>   for (j = 0; j < adev->usec_timeout; j++) {
>   tmp = RREG32_NO_KIQ(hub->vm_inv_eng0_ack +
>eng);
>-  tmp &= 1 << vmid;
>-  if (tmp)
>+  if (tmp & (1 << vmid))
>   break;
>   udelay(1);
>   }
>-  if (j < adev->usec_timeout) {
>-  spin_unlock(>gmc.invalidate_lock);
>-  continue;
>-  }
>   spin_unlock(>gmc.invalidate_lock);
>+  if (j < adev->usec_timeout)
>+  continue;
>+
>   DRM_ERROR("Timeout waiting for VM flush ACK!\n");
>   }
> }
>--
>2.14.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: [PATCH 2/4] drm/amdgpu: cleanup GMC v9 TLB invalidation

2018-10-25 Thread Deng, Emily
Add Wentao.

Best wishes
Emily Deng



>-Original Message-
>From: amd-gfx  On Behalf Of
>Christian König
>Sent: Thursday, October 25, 2018 5:15 PM
>To: amd-gfx@lists.freedesktop.org
>Subject: [PATCH 2/4] drm/amdgpu: cleanup GMC v9 TLB invalidation
>
>Move the kiq handling into amdgpu_virt.c and drop the fallback.
>
>Signed-off-by: Christian König 
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 40
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |
>3 ++
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 53 ---
>-
> 3 files changed, 49 insertions(+), 47 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>index 8f50bc245dd6..17524d799a30 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>@@ -224,6 +224,46 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device
>*adev, uint32_t reg, uint32_t v)
>   pr_err("failed to write reg:%x\n", reg);  }
>
>+void amdgpu_virt_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
>+  uint32_t reg0, uint32_t reg1,
>+  uint32_t ref, uint32_t mask)
>+{
>+  struct amdgpu_kiq *kiq = >gfx.kiq;
>+  struct amdgpu_ring *ring = >ring;
>+  signed long r, cnt = 0;
>+  unsigned long flags;
>+  uint32_t seq;
>+
>+  spin_lock_irqsave(>ring_lock, flags);
>+  amdgpu_ring_alloc(ring, 32);
>+  amdgpu_ring_emit_reg_write_reg_wait(ring, reg0, reg1,
>+  ref, mask);
>+  amdgpu_fence_emit_polling(ring, );
>+  amdgpu_ring_commit(ring);
>+  spin_unlock_irqrestore(>ring_lock, flags);
>+
>+  r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
>+
>+  /* don't wait anymore for IRQ context */
>+  if (r < 1 && in_interrupt())
>+  goto failed_kiq;
>+
>+  might_sleep();
>+  while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
>+
>+  msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
>+  r = amdgpu_fence_wait_polling(ring, seq,
>MAX_KIQ_REG_WAIT);
>+  }
>+
>+  if (cnt > MAX_KIQ_REG_TRY)
>+  goto failed_kiq;
>+
>+  return;
>+
>+failed_kiq:
>+  pr_err("failed to write reg %x wait reg %x\n", reg0, reg1); }
>+
> /**
>  * amdgpu_virt_request_full_gpu() - request full gpu access
>  * @amdgpu:   amdgpu device.
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
>index 880ac113a3a9..bcae2341c725 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
>@@ -288,6 +288,9 @@ void amdgpu_free_static_csa(struct amdgpu_device
>*adev);  void amdgpu_virt_init_setting(struct amdgpu_device *adev);
>uint32_t amdgpu_virt_kiq_rreg(struct amdgpu_device *adev, uint32_t reg);
>void amdgpu_virt_kiq_wreg(struct amdgpu_device *adev, uint32_t reg,
>uint32_t v);
>+void amdgpu_virt_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
>+  uint32_t reg0, uint32_t rreg1,
>+  uint32_t ref, uint32_t mask);
> int amdgpu_virt_request_full_gpu(struct amdgpu_device *adev, bool init);
>int amdgpu_virt_release_full_gpu(struct amdgpu_device *adev, bool init);  int
>amdgpu_virt_reset_gpu(struct amdgpu_device *adev); diff --git
>a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>index af786b5513bc..7dee74f1937c 100644
>--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>@@ -312,48 +312,6 @@ static uint32_t
>gmc_v9_0_get_invalidate_req(unsigned int vmid,
>   return req;
> }
>
>-static signed long  amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device
>*adev,
>-uint32_t reg0, uint32_t reg1,
>-uint32_t ref, uint32_t mask)
>-{
>-  signed long r, cnt = 0;
>-  unsigned long flags;
>-  uint32_t seq;
>-  struct amdgpu_kiq *kiq = >gfx.kiq;
>-  struct amdgpu_ring *ring = >ring;
>-
>-  spin_lock_irqsave(>ring_lock, flags);
>-
>-  amdgpu_ring_alloc(ring, 32);
>-  amdgpu_ring_emit_reg_write_reg_wait(ring, reg0, reg1,
>-  ref, mask);
>-  amdgpu_fence_emit_polling(ring, );
>-  amdgpu_ring_commit(ring);
>-  spin_unlock_irqrestore(>ring_lock, flags);
>-
>-  r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
>-
>-  /* don't wait anymore for IRQ context */
>-  if (r < 1 && in_interrupt())
>-  goto failed_kiq;
>-
>-  might_sleep();
>-
>-  while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
>-  msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
>-  r = amdgpu_fence_wait_polling(ring, seq,
>MAX_KIQ_REG_WAIT);
>-  }
>-
>-  if (cnt > MAX_KIQ_REG_TRY)
>-  goto failed_kiq;
>-
>-  return 0;
>-
>-failed_kiq:
>-  

[PATCH 3/4] drm/amdgpu: drop the busy wait for GMC v9 TLB invalidations

2018-10-25 Thread Christian König
This code is not performance critical.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 26 --
 1 file changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 7dee74f1937c..ff5e5f69b403 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -350,35 +350,17 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device 
*adev,
}
 
spin_lock(>gmc.invalidate_lock);
-
WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
-
-   /* Busy wait for ACK.*/
-   for (j = 0; j < 100; j++) {
-   tmp = RREG32_NO_KIQ(hub->vm_inv_eng0_ack + eng);
-   tmp &= 1 << vmid;
-   if (tmp)
-   break;
-   cpu_relax();
-   }
-   if (j < 100) {
-   spin_unlock(>gmc.invalidate_lock);
-   continue;
-   }
-
-   /* Wait for ACK with a delay.*/
for (j = 0; j < adev->usec_timeout; j++) {
tmp = RREG32_NO_KIQ(hub->vm_inv_eng0_ack + eng);
-   tmp &= 1 << vmid;
-   if (tmp)
+   if (tmp & (1 << vmid))
break;
udelay(1);
}
-   if (j < adev->usec_timeout) {
-   spin_unlock(>gmc.invalidate_lock);
-   continue;
-   }
spin_unlock(>gmc.invalidate_lock);
+   if (j < adev->usec_timeout)
+   continue;
+
DRM_ERROR("Timeout waiting for VM flush ACK!\n");
}
 }
-- 
2.14.1

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


[PATCH 2/4] drm/amdgpu: cleanup GMC v9 TLB invalidation

2018-10-25 Thread Christian König
Move the kiq handling into amdgpu_virt.c and drop the fallback.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 40 
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  3 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 53 
 3 files changed, 49 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 8f50bc245dd6..17524d799a30 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -224,6 +224,46 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device *adev, 
uint32_t reg, uint32_t v)
pr_err("failed to write reg:%x\n", reg);
 }
 
+void amdgpu_virt_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
+   uint32_t reg0, uint32_t reg1,
+   uint32_t ref, uint32_t mask)
+{
+   struct amdgpu_kiq *kiq = >gfx.kiq;
+   struct amdgpu_ring *ring = >ring;
+   signed long r, cnt = 0;
+   unsigned long flags;
+   uint32_t seq;
+
+   spin_lock_irqsave(>ring_lock, flags);
+   amdgpu_ring_alloc(ring, 32);
+   amdgpu_ring_emit_reg_write_reg_wait(ring, reg0, reg1,
+   ref, mask);
+   amdgpu_fence_emit_polling(ring, );
+   amdgpu_ring_commit(ring);
+   spin_unlock_irqrestore(>ring_lock, flags);
+
+   r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
+
+   /* don't wait anymore for IRQ context */
+   if (r < 1 && in_interrupt())
+   goto failed_kiq;
+
+   might_sleep();
+   while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
+
+   msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
+   r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
+   }
+
+   if (cnt > MAX_KIQ_REG_TRY)
+   goto failed_kiq;
+
+   return;
+
+failed_kiq:
+   pr_err("failed to write reg %x wait reg %x\n", reg0, reg1);
+}
+
 /**
  * amdgpu_virt_request_full_gpu() - request full gpu access
  * @amdgpu:amdgpu device.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
index 880ac113a3a9..bcae2341c725 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
@@ -288,6 +288,9 @@ void amdgpu_free_static_csa(struct amdgpu_device *adev);
 void amdgpu_virt_init_setting(struct amdgpu_device *adev);
 uint32_t amdgpu_virt_kiq_rreg(struct amdgpu_device *adev, uint32_t reg);
 void amdgpu_virt_kiq_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t 
v);
+void amdgpu_virt_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
+   uint32_t reg0, uint32_t rreg1,
+   uint32_t ref, uint32_t mask);
 int amdgpu_virt_request_full_gpu(struct amdgpu_device *adev, bool init);
 int amdgpu_virt_release_full_gpu(struct amdgpu_device *adev, bool init);
 int amdgpu_virt_reset_gpu(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index af786b5513bc..7dee74f1937c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -312,48 +312,6 @@ static uint32_t gmc_v9_0_get_invalidate_req(unsigned int 
vmid,
return req;
 }
 
-static signed long  amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
- uint32_t reg0, uint32_t reg1,
- uint32_t ref, uint32_t mask)
-{
-   signed long r, cnt = 0;
-   unsigned long flags;
-   uint32_t seq;
-   struct amdgpu_kiq *kiq = >gfx.kiq;
-   struct amdgpu_ring *ring = >ring;
-
-   spin_lock_irqsave(>ring_lock, flags);
-
-   amdgpu_ring_alloc(ring, 32);
-   amdgpu_ring_emit_reg_write_reg_wait(ring, reg0, reg1,
-   ref, mask);
-   amdgpu_fence_emit_polling(ring, );
-   amdgpu_ring_commit(ring);
-   spin_unlock_irqrestore(>ring_lock, flags);
-
-   r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
-
-   /* don't wait anymore for IRQ context */
-   if (r < 1 && in_interrupt())
-   goto failed_kiq;
-
-   might_sleep();
-
-   while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
-   msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
-   r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
-   }
-
-   if (cnt > MAX_KIQ_REG_TRY)
-   goto failed_kiq;
-
-   return 0;
-
-failed_kiq:
-   pr_err("failed to invalidate tlb with kiq\n");
-   return r;
-}
-
 /*
  * GART
  * VMID 0 is the physical GPU addresses as used by the kernel.
@@ -375,7 +333,6 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device 
*adev,
 {
const unsigned eng = 17;
unsigned i, j;
-   int r;
 
for (i = 0; i 

[PATCH 4/4] drm/amdgpu: use GMC v9 KIQ workaround only for the GFXHUB

2018-10-25 Thread Christian König
The MMHUB is not affected by this.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index ff5e5f69b403..9ea73fb36572 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -338,9 +338,9 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device 
*adev,
struct amdgpu_vmhub *hub = >vmhub[i];
u32 tmp = gmc_v9_0_get_invalidate_req(vmid, flush_type);
 
-   if (adev->gfx.kiq.ring.ready &&
-   (amdgpu_sriov_runtime(adev) || !amdgpu_sriov_vf(adev)) &&
-   !adev->in_gpu_reset) {
+   if (i == AMDGPU_GFXHUB && !adev->in_gpu_reset &&
+   adev->gfx.kiq.ring.ready &&
+   (amdgpu_sriov_runtime(adev) || !amdgpu_sriov_vf(adev))) {
uint32_t req = hub->vm_inv_eng0_req + eng;
uint32_t ack = hub->vm_inv_eng0_ack + eng;
 
-- 
2.14.1

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


[PATCH 1/4] drm/amdgpu: remove nonsense in_interrupt() checks

2018-10-25 Thread Christian König
might_sleep() is supposed to raise if warning if called in interrupt or
atomic context.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index f2f358aa0597..8f50bc245dd6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -162,9 +162,7 @@ uint32_t amdgpu_virt_kiq_rreg(struct amdgpu_device *adev, 
uint32_t reg)
if (r < 1 && (adev->in_gpu_reset || in_interrupt()))
goto failed_kiq_read;
 
-   if (in_interrupt())
-   might_sleep();
-
+   might_sleep();
while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
@@ -210,9 +208,7 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device *adev, 
uint32_t reg, uint32_t v)
if (r < 1 && (adev->in_gpu_reset || in_interrupt()))
goto failed_kiq_write;
 
-   if (in_interrupt())
-   might_sleep();
-
+   might_sleep();
while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
 
msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
-- 
2.14.1

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


[PATCH 1/5] drm/amdgpu: fix amdgpu_vm_fini

2018-10-25 Thread Christian König
We should not remove mappings in rbtree_postorder_for_each_entry_safe
because that rebalances the tree.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6904d794d60a..db0cbf8d219d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3234,8 +3234,10 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)
}
rbtree_postorder_for_each_entry_safe(mapping, tmp,
 >va.rb_root, rb) {
+   /* Don't remove the mapping here, we don't want to trigger a
+* rebalance and the tree is about to be destroyed anyway.
+*/
list_del(>list);
-   amdgpu_vm_it_remove(mapping, >va);
kfree(mapping);
}
list_for_each_entry_safe(mapping, tmp, >freed, list) {
-- 
2.14.1

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


[PATCH] drm/amd/display: set backlight level limit to 1

2018-10-25 Thread Guttula, Suresh
This patch will work as workaround for silicon limitation
related to PWM dutycycle when the backlight level goes to 0.

Actually PWM value is 16 bit value and valid range from 1-65535.
when ever user requested to set this PWM value to 0 which is not
fall in the range, in VBIOS taken care this by limiting to 1.
This patch here will do the same. Either driver or VBIOS can not
pass 0 value as it is not a valid range for PWM and it will
give a high PWM pulse which is not the intented behaviour as
per HW constraints.

Signed-off-by: suresh guttula 
---
 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 492230c..38f84b2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1518,6 +1518,14 @@ static int amdgpu_dm_backlight_update_status(struct 
backlight_device *bd)
 {
struct amdgpu_display_manager *dm = bl_get_data(bd);
 
+   /*
+* When we use brightness low key to reduce the brightness,
+* brightness level reaching to 0, with which we can see flash
+* screen on ui beacuse of HW limitation.To avoid that  we are
+* limiting level to 1
+*/
+   if (bd->props.brightness < 1)
+   return 1;
if (dc_link_set_backlight_level(dm->backlight_link,
bd->props.brightness, 0, 0))
return 0;
-- 
2.7.4

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