Re: [PATCH] drm/amdgpu: trace amdgpu_job fence details

2017-02-23 Thread Christian König 

Am 23.02.2017 um 00:47 schrieb Andres Rodriguez:

This trace is intended to provide the required information to associate
the completion of an amdgpu_job with its corresponding dma_fence_*
tracepoints.

Signed-off-by: Andres Rodriguez 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 22 ++
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 86a1242..84a04e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -177,6 +177,8 @@ static struct dma_fence *amdgpu_job_run(struct 
amd_sched_job *sched_job)
/* if gpu reset, hw fence will be replaced here */
dma_fence_put(job->fence);
job->fence = dma_fence_get(fence);
+   trace_amdgpu_job_attach_fence(job);
+
amdgpu_job_free_resources(job);
return fence;
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index a18ae1e..0a61ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -147,6 +147,28 @@ TRACE_EVENT(amdgpu_sched_run_job,
  __entry->fence, __entry->ring_name, __entry->num_ibs)
  );
  
+TRACE_EVENT(amdgpu_job_attach_fence,

+   TP_PROTO(struct amdgpu_job *job),
+   TP_ARGS(job),
+   TP_STRUCT__entry(
+__field(struct amdgpu_device *, adev)
+__field(struct amd_sched_job *, sched_job)


Neither add adev nor sched_job pointer to your trace point.

The adev pointer is completely meaningless in the logs and the scheduler 
job might already be freed when the printk is called.


Just checked the source and a couple of other trace points get this 
horrible wrong as well, so that isn't your fault. Going to put it on my 
todo to fix those.


Regards,
Christian.


+__string(timeline, 
job->fence->ops->get_timeline_name(job->fence))
+__field(unsigned int, context)
+__field(unsigned int, seqno)
+),
+
+   TP_fast_assign(
+  __entry->adev = job->adev;
+  __entry->sched_job = &job->base;
+  __assign_str(timeline, 
job->fence->ops->get_timeline_name(job->fence))
+  __entry->context = job->fence->context;
+  __entry->seqno = job->fence->seqno;
+  ),
+   TP_printk("adev=%p, sched_job=%p, timeline:%s, context:%u, 
seqno:%u",
+ __entry->adev, __entry->sched_job,
+ __get_str(timeline), __entry->context, __entry->seqno)
+);
  
  TRACE_EVENT(amdgpu_vm_grab_id,

TP_PROTO(struct amdgpu_vm *vm, int ring, struct amdgpu_job *job),



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

Re: [PATCH] drm/amdgpu: fix double_offchip_lds_buf for gfx v6

2017-02-23 Thread Christian König 

Am 23.02.2017 um 04:07 schrieb Alex Deucher:

On Wed, Feb 22, 2017 at 10:04 PM, Junwei Zhang  wrote:

Signed-off-by: Junwei Zhang 

Reviewed-by: Alex Deucher 


Reviewed-by: Christian König 




---
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index 138e15a..ab8a8c9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -1581,7 +1581,7 @@ static void gfx_v6_0_setup_spi(struct amdgpu_device *adev)

  static void gfx_v6_0_config_init(struct amdgpu_device *adev)
  {
-   adev->gfx.config.double_offchip_lds_buf = 1;
+   adev->gfx.config.double_offchip_lds_buf = 0;
  }

  static void gfx_v6_0_gpu_init(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



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

RE: [PATCH] drm/amdgpu/virt: don't check VALID bit for FLR completion message

2017-02-23 Thread Yu, Xiangliang 

Reviewed-by: Xiangliang Yu 


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Pixel Ding
> Sent: Thursday, February 23, 2017 3:09 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Ding, Pixel 
> Subject: [PATCH] drm/amdgpu/virt: don't check VALID bit for FLR completion
> message
> 
> The interrupt after FLR is missed sometimes due to hardware reason, so
> guest driver get the notification of FLR completion via polling message. Then
> host doesn't write VALID bit to avoid sending interrupt, otherwise the
> completion will be handled twice.
> 
> So there's a valid message without VALID bit for FLR completion, driver
> should handle it without checking.
> 
> Signed-off-by: Pixel Ding 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index 3164d61..3c6b0af 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -368,9 +368,12 @@ static int xgpu_vi_mailbox_rcv_msg(struct
> amdgpu_device *adev,
>   u32 reg;
>   u32 mask = REG_FIELD_MASK(MAILBOX_CONTROL,
> RCV_MSG_VALID);
> 
> - reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
> - if (!(reg & mask))
> - return -ENOENT;
> + /* workaround: host driver doesn't set VALID for CMPL now */
> + if (event != IDH_FLR_NOTIFICATION_CMPL) {
> + reg = RREG32_NO_KIQ(mmMAILBOX_CONTROL);
> + if (!(reg & mask))
> + return -ENOENT;
> + }
> 
>   reg = RREG32_NO_KIQ(mmMAILBOX_MSGBUF_RCV_DW0);
>   if (reg != event)
> --
> 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] drm/amdgpu: fix double_offchip_lds_buf for gfx v6

2017-02-23 Thread Marek Olšák 
Reviewed-by: Marek Olšák 

On Feb 23, 2017 9:24 AM, "Christian König"  wrote:

> Am 23.02.2017 um 04:07 schrieb Alex Deucher:
>
>> On Wed, Feb 22, 2017 at 10:04 PM, Junwei Zhang 
>> wrote:
>>
>>> Signed-off-by: Junwei Zhang 
>>>
>> Reviewed-by: Alex Deucher 
>>
>
> Reviewed-by: Christian König 
>
>
>> ---
>>>   drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>>> index 138e15a..ab8a8c9 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>>> @@ -1581,7 +1581,7 @@ static void gfx_v6_0_setup_spi(struct
>>> amdgpu_device *adev)
>>>
>>>   static void gfx_v6_0_config_init(struct amdgpu_device *adev)
>>>   {
>>> -   adev->gfx.config.double_offchip_lds_buf = 1;
>>> +   adev->gfx.config.double_offchip_lds_buf = 0;
>>>   }
>>>
>>>   static void gfx_v6_0_gpu_init(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
>>
>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards

2017-02-23 Thread Huang Rui 
On Wed, Feb 22, 2017 at 11:22:35AM -0500, Alex Deucher wrote:
> This enables the LEDs that light up based on DPM states
> on some Fiji boards.
> 
> bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=97590
> 
> Signed-off-by: Alex Deucher 

Reviewed-by: Huang Rui 

> ---
>  drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h  |  1 +
>  drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c | 34 
> +
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h 
> b/drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h
> index fbc504c..62f36ba 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/smu7_ppsmc.h
> @@ -377,6 +377,7 @@ typedef uint16_t PPSMC_Result;
>  #define PPSMC_MSG_DisableAvfs ((uint16_t) 0x26B)
>  
>  #define PPSMC_MSG_PerformBtc  ((uint16_t) 0x26C)
> +#define PPSMC_MSG_LedConfig   ((uint16_t) 0x274)
>  #define PPSMC_MSG_VftTableIsValid ((uint16_t) 0x275)
>  #define PPSMC_MSG_UseNewGPIOScheme((uint16_t) 0x277)
>  #define PPSMC_MSG_GetEnabledPsm   ((uint16_t) 0x400)
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> index 0f7a77b..1a9ab43 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> @@ -1721,6 +1721,35 @@ static int fiji_init_arb_table_index(struct pp_smumgr 
> *smumgr)
>   smu_data->smu7_data.arb_table_start,  tmp, SMC_RAM_END);
>  }
>  
> +static int fiji_setup_dpm_led_config(struct pp_hwmgr *hwmgr)
> +{
> + pp_atomctrl_voltage_table param_led_dpm;
> + int result = 0;
> + u32 mask = 0;
> +
> + result = atomctrl_get_voltage_table_v3(hwmgr,
> +VOLTAGE_TYPE_LEDDPM, 
> VOLTAGE_OBJ_GPIO_LUT,
> +¶m_led_dpm);
> + if (result == 0) {
> + int i, j;
> + u32 tmp = param_led_dpm.mask_low;
> +
> + for (i = 0, j = 0; i < 32; i++) {
> + if (tmp & 1) {
> + mask |= (i << (8 * j));
> + if (++j >= 3)
> + break;
> + }
> + tmp >>= 1;
> + }
> + }
> + if (mask)
> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
> + PPSMC_MSG_LedConfig,
> + mask);
> + return 0;
> +}
> +
>  /**
>  * Initializes the SMC table and uploads it
>  *
> @@ -1934,6 +1963,11 @@ int fiji_init_smc_table(struct pp_hwmgr *hwmgr)
>   result = fiji_populate_pm_fuses(hwmgr);
>   PP_ASSERT_WITH_CODE(0 == result,
>   "Failed to  populate PM fuses to SMC memory!", return 
> result);
> +
> + result = fiji_setup_dpm_led_config(hwmgr);
> + PP_ASSERT_WITH_CODE(0 == result,
> + "Failed to setup dpm led config", return result);
> +
>   return 0;
>  }
>  
> -- 
> 2.5.5
> 
> ___
> 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/radeon/dp_auxch: Ratelimit aux transfer debug messages

2017-02-23 Thread Alex Deucher 
On Wed, Feb 22, 2017 at 4:34 PM, Lyude  wrote:
> Aux transfers always fail with non-zero status flags when there's
> nothing connected on the port, so we don't usually need to see all of
> the debugging information from it. Also, we try reprobing a -lot-, so
> without ratelimiting most of the kernel log is filled up with messages
> from radeon_dp_aux_transfer_native.
>
> Signed-off-by: Lyude 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_dp_auxch.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c 
> b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> index 474a8a18..12eac4e 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> @@ -168,7 +168,8 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg
> goto done;
> }
> if (tmp & AUX_RX_ERROR_FLAGS) {
> -   DRM_DEBUG_KMS("dp_aux_ch flags not zero: %08x\n", tmp);
> +   DRM_DEBUG_KMS_RATELIMITED("dp_aux_ch flags not zero: %08x\n",
> + tmp);
> ret = -EIO;
> goto done;
> }
> --
> 2.9.3
>
> ___
> 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 umr] Allow * for ipname in --read/--write/--write-bit

2017-02-23 Thread Tom St Denis 
To simplify scripting you can now use * for ipnames as well.

Signed-off-by: Tom St Denis 
---
 doc/umr.1 |   6 ++-
 src/app/main.c|   5 ++-
 src/app/scan.c|  21 ++
 src/app/set_bit.c | 117 +++---
 src/app/set_reg.c |  91 +-
 5 files changed, 131 insertions(+), 109 deletions(-)

diff --git a/doc/umr.1 b/doc/umr.1
index 5ed2c3bb93ae..a12dfb0a00ff 100644
--- a/doc/umr.1
+++ b/doc/umr.1
@@ -34,7 +34,7 @@ Look up an MMIO register by address and bitfield decode the 
value specified.
 Write a value specified in hex to a register specified with a complete
 register path in the form <
 .B asicname.ipname.regname
->.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname can be
+>.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname and/or 
ipname can be
 .B *
 to simplify scripting.  This command can be used multiple times to
 write to multiple registers in a single invocation.
@@ -52,7 +52,9 @@ command but also allows
 for the regname field.
 .IP "--scan, -s "
 Scan and print an IP block by name, for example,
-.B uvd5.
+.B uvd6
+or
+.B carrizo.uvd6.
 Can be used multiple times in a single invocation.
 .IP "--ring, -R (from:to)"
 Read the contents of a ring named by the string without the
diff --git a/src/app/main.c b/src/app/main.c
index 8364d54c5227..99e014888571 100644
--- a/src/app/main.c
+++ b/src/app/main.c
@@ -364,12 +364,13 @@ int main(int argc, char **argv)
 "\n\t--write, -w  \n\t\tWrite a value in hex to a register 
specified as a register path in the"
"\n\t\tform .  For instance 
\"tonga.uvd5.mmUVD_SOFT_RESET\"."
"\n\t\tCan be used multiple times to set multiple registers.  You can"
-   "\n\t\tspecify * for asicname to simplify scripts.\n"
+   "\n\t\tspecify * for asicname and/or ipname to simplify scripts.\n"
 "\n\t--writebit, -wb  \n\t\tWrite a value in hex to a register 
bitfield specified as in --write but"
"\n\t\tthe addition of the bitfield name.  For instance: 
\"*.gfx80.mmRLC_PG_CNTL.PG_OVERRIDE\"\n"
 "\n\t--read, -r \n\t\tRead a value from a register and print it to 
stdout.  This command"
"\n\t\tuses the same path notation as --write.  It also accepts * for 
regname.\n"
-"\n\t--scan, -s \n\t\tScan and print an ip block by name, e.g. 
\"uvd5\".  Can be used multiple times.\n"
+"\n\t--scan, -s \n\t\tScan and print an ip block by name, e.g. 
\"uvd6\" or \"carrizo.uvd6\"."
+   "\n\t\tCan be used multiple times.\n"
 "\n\t--ring, -R ([from:to])\n\t\tRead the contents of a ring named by 
the string without the amdgpu_ring_ prefix. "
"\n\t\tBy default it will read and display the entire ring.  A starting 
and ending "
"\n\t\taddress can be specified in decimal or a '.' can be used to 
indicate relative "
diff --git a/src/app/scan.c b/src/app/scan.c
index 19c97fe1499d..fbb8f5838069 100644
--- a/src/app/scan.c
+++ b/src/app/scan.c
@@ -31,6 +31,27 @@ int umr_scan_asic(struct umr_asic *asic, char *asicname, 
char *ipname, char *reg
uint64_t addr, scale;
char buf[256];
 
+   // if ipname == '*' scan for a match and stop on first one
+   if (ipname[0] == '*' && regname[0] != '*') {
+   for (i = 0; i < asic->no_blocks; i++) {
+   for (j = 0; j < asic->blocks[i]->no_regs; j++) {
+   if (!strcmp(regname, 
asic->blocks[i]->regs[j].regname) ||
+   (options.many && 
strstr(asic->blocks[i]->regs[j].regname, regname))) {
+   ipname = asic->blocks[i]->ipname;
+   goto ip_found;
+   }
+   }
+   }
+   }
+ip_found:
+   if (ipname[0] == '*') {
+   if (regname[0] == '*')
+   fprintf(stderr, "[ERROR]:  You cannot specify * for 
both ipname and regname\n");
+   else
+   fprintf(stderr, "[ERROR]:  Register name <%s> was not 
found with ANY ip name\n", regname);
+   return -1;
+   }
+
/* scan them all in order */
if (!asicname[0] || !strcmp(asicname, "*") || !strcmp(asicname, 
asic->asicname)) {
for (i = 0; i < asic->no_blocks; i++) {
diff --git a/src/app/set_bit.c b/src/app/set_bit.c
index d9ee7d8f3a55..bed7ee858b6a 100644
--- a/src/app/set_bit.c
+++ b/src/app/set_bit.c
@@ -31,79 +31,78 @@
  */
 int umr_set_register_bit(struct umr_asic *asic, char *regpath, char *regvalue)
 {
-   char rpath[512];
+   char asicname[128], ipname[128], regname[128], bitname[128];
int i, j, k, fd;
uint32_t value, mask, copy;
uint64_t addr, scale;
 
-   /* scan until we compare with regpath... */
-   for (i = 0; i < asic->no_blocks; i++) {
-   if (!memcmp(regpath, "*.", 2))
-   snprintf(rpath, sizeof(rpath)-1, "*.%s.", 
asic->

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

2017-02-23 Thread Alex Deucher 
On Sat, Feb 18, 2017 at 12:03 AM, Edward O'Callaghan
 wrote:
>
>
> On 02/18/2017 01:22 AM, Christian König wrote:
>> Am 17.02.2017 um 08:11 schrieb Joe Perches:
>>> To enable eventual removal of pr_warning
>>>
>>> This makes pr_warn use consistent for drivers/gpu
>>>
>>> Prior to this patch, there were 15 uses of pr_warning and
>>> 20 uses of pr_warn in drivers/gpu
>>>
>>> Signed-off-by: Joe Perches 
>>
>> Acked-by: Christian König .
>
> Reviewed-by: Edward O'Callaghan 

Applied.  thanks!

Alex


>
>>
>>> ---
>>>   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  2 +-
>>>   drivers/gpu/drm/amd/powerplay/inc/pp_debug.h |  2 +-
>>>   drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |  4 ++--
>>>   drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 14
>>> +++---
>>>   drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |  4 ++--
>>>   drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |  4 ++--
>>>   6 files changed, 15 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>>> index b1de9e8ccdbc..83266408634e 100644
>>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>>> @@ -1535,7 +1535,7 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
>>> *hwmgr)
>>>   if (vddc >= 2000 || vddc == 0)
>>>   return -EINVAL;
>>>   } else {
>>> -pr_warning("failed to retrieving EVV voltage!\n");
>>> +pr_warn("failed to retrieving EVV voltage!\n");
>>>   continue;
>>>   }
>>>   diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>>> b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>>> index 072880130cfb..f3f9ebb631a5 100644
>>> --- a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>>> +++ b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>>> @@ -37,7 +37,7 @@
>>>   #define PP_ASSERT_WITH_CODE(cond, msg, code)\
>>>   do {\
>>>   if (!(cond)) {\
>>> -pr_warning("%s\n", msg);\
>>> +pr_warn("%s\n", msg);\
>>>   code;\
>>>   }\
>>>   } while (0)
>>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>>> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>>> index 0f7a77b7312e..5450f5ef8e89 100644
>>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>>> @@ -2131,7 +2131,7 @@ uint32_t fiji_get_offsetof(uint32_t type,
>>> uint32_t member)
>>>   return offsetof(SMU73_Discrete_DpmTable,
>>> LowSclkInterruptThreshold);
>>>   }
>>>   }
>>> -pr_warning("can't get the offset of type %x member %x\n", type,
>>> member);
>>> +pr_warn("can't get the offset of type %x member %x\n", type,
>>> member);
>>>   return 0;
>>>   }
>>>   @@ -2156,7 +2156,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
>>>   return SMU73_MAX_LEVELS_MVDD;
>>>   }
>>>   -pr_warning("can't get the mac of %x\n", value);
>>> +pr_warn("can't get the mac of %x\n", value);
>>>   return 0;
>>>   }
>>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>>> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>>> index ad82161df831..51adf04ab4b3 100644
>>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>>> @@ -122,7 +122,7 @@ static void
>>> iceland_initialize_power_tune_defaults(struct pp_hwmgr *hwmgr)
>>>   break;
>>>   default:
>>>   smu_data->power_tune_defaults = &defaults_iceland;
>>> -pr_warning("Unknown V.I. Device ID.\n");
>>> +pr_warn("Unknown V.I. Device ID.\n");
>>>   break;
>>>   }
>>>   return;
>>> @@ -378,7 +378,7 @@ static int
>>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>>   return -EINVAL);
>>> if (NULL == hwmgr->dyn_state.cac_leakage_table) {
>>> -pr_warning("CAC Leakage Table does not exist, using vddc.\n");
>>> +pr_warn("CAC Leakage Table does not exist, using vddc.\n");
>>>   return 0;
>>>   }
>>>   @@ -394,7 +394,7 @@ static int
>>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>>   *lo =
>>> hwmgr->dyn_state.cac_leakage_table->entries[v_index].Vddc *
>>> VOLTAGE_SCALE;
>>>   *hi =
>>> (uint16_t)(hwmgr->dyn_state.cac_leakage_table->entries[v_index].Leakage *
>>> VOLTAGE_SCALE);
>>>   } else {
>>> -pr_warning("Index from SCLK/VDDC Dependency Table
>>> exceeds the CAC Leakage Table index, using maximum index from CAC
>>> table.\n");
>>> +pr_warn("Index from SCLK/VDDC Dependency Table
>>> exceeds the CAC Leakage Table index, using maximum index from CAC
>>> table.\n");
>>>

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Rob Herring 
On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
>
> Some files not compiled - no cross-compilers
>
> Joe Perches (35):
>   alpha: Convert remaining uses of pr_warning to pr_warn
>   ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
>   arm64: Convert remaining uses of pr_warning to pr_warn
>   arch/blackfin: Convert remaining uses of pr_warning to pr_warn
>   ia64: Convert remaining use of pr_warning to pr_warn
>   powerpc: Convert remaining uses of pr_warning to pr_warn
>   sh: Convert remaining uses of pr_warning to pr_warn
>   sparc: Convert remaining use of pr_warning to pr_warn
>   x86: Convert remaining uses of pr_warning to pr_warn
>   drivers/acpi: Convert remaining uses of pr_warning to pr_warn
>   block/drbd: Convert remaining uses of pr_warning to pr_warn
>   gdrom: Convert remaining uses of pr_warning to pr_warn
>   drivers/char: Convert remaining use of pr_warning to pr_warn
>   clocksource: Convert remaining use of pr_warning to pr_warn
>   drivers/crypto: Convert remaining uses of pr_warning to pr_warn
>   fmc: Convert remaining use of pr_warning to pr_warn
>   drivers/gpu: Convert remaining uses of pr_warning to pr_warn
>   drivers/ide: Convert remaining uses of pr_warning to pr_warn
>   drivers/input: Convert remaining uses of pr_warning to pr_warn
>   drivers/isdn: Convert remaining uses of pr_warning to pr_warn
>   drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
>   drivers/media: Convert remaining use of pr_warning to pr_warn
>   drivers/mfd: Convert remaining uses of pr_warning to pr_warn
>   drivers/mtd: Convert remaining uses of pr_warning to pr_warn
>   drivers/of: Convert remaining uses of pr_warning to pr_warn
>   drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
>   drivers/platform: Convert remaining uses of pr_warning to pr_warn
>   drivers/rapidio: Convert remaining use of pr_warning to pr_warn
>   drivers/scsi: Convert remaining use of pr_warning to pr_warn
>   drivers/sh: Convert remaining use of pr_warning to pr_warn
>   drivers/tty: Convert remaining uses of pr_warning to pr_warn
>   drivers/video: Convert remaining uses of pr_warning to pr_warn
>   kernel/trace: Convert remaining uses of pr_warning to pr_warn
>   lib: Convert remaining uses of pr_warning to pr_warn
>   sound/soc: Convert remaining uses of pr_warning to pr_warn

Where's the removal of pr_warning so we don't have more sneak in?

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

[PATCH 0/8] DC Patches Feb 22, 2017

2017-02-23 Thread Harry Wentland 
* Bunch of color work on common code paths
* Update audio clocks
* Bunch of fixes
* Some minor cleanup

Amy Zhang (1):
  drm/amd/display: Add bypass case for PQ transfer function

Charlene Liu (3):
  drm/amd/display: audio bug fix part 1: Add missing audio ACR
  drm/amd/display: fix 12bpc truncate to 10bpc
  drm/amd/display: fix incorrect programming for YCbCr422 and YCbCr420

Harry Wentland (1):
  drm/amd/display: Remove LINUX_VERSION_CODE check

Ken Chalmers (1):
  drm/amd/display: fix dc_commit_surfaces_to_stream for dcc

Zeyu Fan (2):
  drm/amd/display: Add query_ddc_data function
  drm/amd/display: Fix error where wrong payload size is given.

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 -
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 26 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dc.h| 13 ++-
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.c |  8 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.h |  2 +
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c  |  2 +
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.c   | 18 ++---
 .../drm/amd/display/dc/dce/dce_stream_encoder.c| 93 +++---
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 53 +---
 .../drm/amd/display/dc/dce110/dce110_resource.c|  4 +
 12 files changed, 169 insertions(+), 56 deletions(-)

-- 
2.9.3

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

[PATCH 6/8] drm/amd/display: audio bug fix part 1: Add missing audio ACR

2017-02-23 Thread Harry Wentland 
From: Charlene Liu 

Change-Id: I84757ac7a0caed9826a49678297cf27ab0b14415
Signed-off-by: Charlene Liu 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.c |  8 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_audio.h |  2 +
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c  |  2 +
 .../drm/amd/display/dc/dce/dce_stream_encoder.c| 81 +++---
 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 31 +
 .../drm/amd/display/dc/dce110/dce110_resource.c|  1 +
 6 files changed, 95 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
index 2749c8fa4f1f..596e039ee315 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
@@ -828,11 +828,9 @@ void dce_aud_wall_dto_setup(
REG_UPDATE(DCCG_AUDIO_DTO1_PHASE,
DCCG_AUDIO_DTO1_PHASE, 
clock_info.audio_dto_phase);
 
-   /* DAL2 code separate DCCG_AUDIO_DTO_SEL and
-   DCCG_AUDIO_DTO2_USE_512FBR_DTO programming into two different
-   location. merge together should not hurt */
-   /*value.bits.DCCG_AUDIO_DTO2_USE_512FBR_DTO = 1;
-   dal_write_reg(mmDCCG_AUDIO_DTO_SOURCE, value);*/
+   REG_UPDATE(DCCG_AUDIO_DTO_SOURCE,
+   DCCG_AUDIO_DTO2_USE_512FBR_DTO, 1);
+
}
 }
 
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.h 
b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.h
index c244887ba15e..b98ee2d2a9c7 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.h
@@ -93,6 +93,7 @@ struct dce_audio_shift {
uint8_t DCCG_AUDIO_DTO0_PHASE;
uint8_t DCCG_AUDIO_DTO1_MODULE;
uint8_t DCCG_AUDIO_DTO1_PHASE;
+   uint8_t DCCG_AUDIO_DTO2_USE_512FBR_DTO;
 };
 
 struct dce_aduio_mask {
@@ -109,6 +110,7 @@ struct dce_aduio_mask {
uint32_t DCCG_AUDIO_DTO0_PHASE;
uint32_t DCCG_AUDIO_DTO1_MODULE;
uint32_t DCCG_AUDIO_DTO1_PHASE;
+   uint32_t DCCG_AUDIO_DTO2_USE_512FBR_DTO;
 };
 
 struct dce_audio {
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
index 60fdf58fc5cc..305a9d86a5d2 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
@@ -871,6 +871,8 @@ static bool dce110_link_encoder_validate_hdmi_output(
if (max_deep_color < crtc_timing->display_color_depth)
return false;
 
+   if (crtc_timing->display_color_depth < COLOR_DEPTH_888)
+   return false;
if (adjusted_pix_clk_khz < TMDS_MIN_PIXEL_CLOCK)
return false;
 
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
index a28d9c7ba17e..aba392ff5095 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
@@ -848,7 +848,7 @@ struct audio_clock_info {
 /* 148.5MHz/1.001*/
 /* 148.5MHz*/
 
-static const struct audio_clock_info audio_clock_info_table[12] = {
+static const struct audio_clock_info audio_clock_info_table[16] = {
{2517, 4576, 28125, 7007, 31250, 6864, 28125},
{2518, 4576, 28125, 7007, 31250, 6864, 28125},
{2520, 4096, 25200, 6272, 28000, 6144, 25200},
@@ -860,37 +860,63 @@ static const struct audio_clock_info 
audio_clock_info_table[12] = {
{7417, 11648, 210937, 17836, 234375, 11648, 140625},
{7425, 4096, 74250, 6272, 82500, 6144, 74250},
{14835, 11648, 421875, 8918, 234375, 5824, 140625},
-   {14850, 4096, 148500, 6272, 165000, 6144, 148500}
+   {14850, 4096, 148500, 6272, 165000, 6144, 148500},
+   {29670, 5824, 421875, 4459, 234375, 5824, 281250},
+   {29700, 3072, 222750, 4704, 247500, 5120, 247500},
+   {59340, 5824, 843750, 8918, 937500, 5824, 562500},
+   {59400, 3072, 445500, 9408, 99, 6144, 594000}
 };
 
-static const struct audio_clock_info audio_clock_info_table_36bpc[12] = {
-   {2517, 9152, 84375, 7007, 48875, 9152, 56250},
-   {2518, 9152, 84375, 7007, 48875, 9152, 56250},
-   {2520, 4096, 37800, 6272, 42000, 6144, 37800},
-   {2700, 4096, 40500, 6272, 45000, 6144, 40500},
-   {2702, 8192, 81081, 6272, 45045, 8192, 54054},
-   {2703, 8192, 81081, 6272, 45045, 8192, 54054},
-   {5400, 4096, 81000, 6272, 9, 6144, 81000},
-   {5405, 4096, 81081, 6272, 90090, 6144, 81081},
+static const struct audio_clock_info audio_clock_info_table_30bpc[14] = {
+   {2517, 9152, 70312, 14014, 78125, 9152, 46875},
+   {2518, 9152, 70312, 14014, 78125, 9152, 46875},
+   {2520, 4096, 31500, 6272, 35000, 6144, 31500},
+   {2700, 4096, 33750, 6272, 37500, 6144, 33750},
+

[PATCH 1/8] drm/amd/display: Remove LINUX_VERSION_CODE check

2017-02-23 Thread Harry Wentland 
Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f066e2207b5e..29d1900bc650 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -892,14 +892,12 @@ static void dm_handle_hpd_rx_irq(struct amdgpu_connector 
*aconnector)
process_count++;
 
DRM_DEBUG_KMS("ESI %02x %02x %02x\n", esi[0], esi[1], esi[2]);
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 3, 0)
/* handle HPD short pulse irq */
if (aconnector->mst_mgr.mst_state)
drm_dp_mst_hpd_irq(
&aconnector->mst_mgr,
esi,
&new_irq_handled);
-#endif
 
if (new_irq_handled) {
/* ACK at DPCD to notify down stream */
-- 
2.9.3

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

[PATCH 7/8] drm/amd/display: fix 12bpc truncate to 10bpc

2017-02-23 Thread Harry Wentland 
From: Charlene Liu 

Change-Id: I32427f4c3ea4aa410732aa4837098b5e109a1647
Signed-off-by: Charlene Liu 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
index a2f57cf603aa..121ccbb1ad2d 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
@@ -710,32 +710,32 @@ void dce110_opp_set_dyn_expansion(
enum signal_type signal)
 {
struct dce110_opp *opp110 = TO_DCE110_OPP(opp);
-   bool enable_dyn_exp = false;
 
REG_UPDATE_2(FMT_DYNAMIC_EXP_CNTL,
FMT_DYNAMIC_EXP_EN, 0,
FMT_DYNAMIC_EXP_MODE, 0);
-   /* From HW programming guide:
-   FMT_DYNAMIC_EXP_EN = 0 for limited RGB or YCbCr output
-   FMT_DYNAMIC_EXP_EN = 1 for RGB full range only*/
-   if (color_sp == COLOR_SPACE_SRGB)
-   enable_dyn_exp = true;
 
/*00 - 10-bit -> 12-bit dynamic expansion*/
/*01 - 8-bit  -> 12-bit dynamic expansion*/
-   if (signal == SIGNAL_TYPE_HDMI_TYPE_A) {
+   if (signal == SIGNAL_TYPE_HDMI_TYPE_A ||
+   signal == SIGNAL_TYPE_DISPLAY_PORT ||
+   signal == SIGNAL_TYPE_DISPLAY_PORT_MST) {
switch (color_dpth) {
case COLOR_DEPTH_888:
REG_UPDATE_2(FMT_DYNAMIC_EXP_CNTL,
-   FMT_DYNAMIC_EXP_EN, enable_dyn_exp ? 1:0,
+   FMT_DYNAMIC_EXP_EN, 1,
FMT_DYNAMIC_EXP_MODE, 1);
break;
case COLOR_DEPTH_101010:
REG_UPDATE_2(FMT_DYNAMIC_EXP_CNTL,
-   FMT_DYNAMIC_EXP_EN, enable_dyn_exp ? 1:0,
+   FMT_DYNAMIC_EXP_EN, 1,
FMT_DYNAMIC_EXP_MODE, 0);
break;
case COLOR_DEPTH_121212:
+   REG_UPDATE_2(
+   FMT_DYNAMIC_EXP_CNTL,
+   FMT_DYNAMIC_EXP_EN, 1,/*otherwise last two bits 
are zero*/
+   FMT_DYNAMIC_EXP_MODE, 0);
break;
default:
break;
-- 
2.9.3

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

[PATCH 5/8] drm/amd/display: Fix error where wrong payload size is given.

2017-02-23 Thread Harry Wentland 
From: Zeyu Fan 

Change-Id: I2e0518be0e2ee513d7b001c0259ee41c0d104fd1
Signed-off-by: Zeyu Fan 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index cd66941b2c59..4e9465b630d1 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -198,7 +198,7 @@ struct aux_payloads *dal_ddc_aux_payloads_create(struct 
dc_context *ctx, uint32_
return NULL;
 
if (dal_vector_construct(
-   &payloads->payloads, ctx, count, sizeof(struct aux_payloads)))
+   &payloads->payloads, ctx, count, sizeof(struct aux_payload)))
return payloads;
 
dm_free(payloads);
-- 
2.9.3

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

[PATCH 3/8] drm/amd/display: Add bypass case for PQ transfer function

2017-02-23 Thread Harry Wentland 
From: Amy Zhang 

- Source and destination color space should be the same for
  app control case
- Bypass degamma, regamma, and gamut remap
- Add hdr supported check for info frame

Change-Id: I5bb982159589f21d94a193b048f6a427662bba50
Signed-off-by: Amy Zhang 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c   | 2 +-
 drivers/gpu/drm/amd/display/dc/dc.h | 2 ++
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 5 -
 3 files changed, 7 insertions(+), 2 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 991828f503aa..4d556b379524 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1675,7 +1675,7 @@ static void set_hdr_static_info_packet(
 
hdr_metadata = surface->public.hdr_static_ctx;
 
-   if (!hdr_metadata.is_hdr)
+   if (!hdr_metadata.hdr_supported)
return;
 
if (dc_is_hdmi_signal(signal)) {
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 13e7134fccb8..71d7dde79ae0 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -186,6 +186,7 @@ enum {
 };
 
 struct dc_hdr_static_metadata {
+   bool hdr_supported;
bool is_hdr;
 
/* display chromaticities and white point in units of 0.1 */
@@ -207,6 +208,7 @@ struct dc_hdr_static_metadata {
 enum dc_transfer_func_type {
TF_TYPE_PREDEFINED,
TF_TYPE_DISTRIBUTED_POINTS,
+   TF_TYPE_BYPASS
 };
 
 struct dc_transfer_func_distributed_points {
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 9b6d251a1c22..9c9183f96e04 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
@@ -279,6 +279,8 @@ static bool dce110_set_input_transfer_func(
result = false;
break;
}
+   } else if (tf->public.type == TF_TYPE_BYPASS) {
+   ipp->funcs->ipp_set_degamma(ipp, IPP_DEGAMMA_MODE_BYPASS);
} else {
/*TF_TYPE_DISTRIBUTED_POINTS - Not supported in DCE 11*/
result = false;
@@ -428,7 +430,8 @@ static bool dce110_translate_regamma_to_hw_format(const 
struct dc_transfer_func
int32_t segment_start, segment_end;
uint32_t i, j, k, seg_distr[16], increment, start_index, hw_points;
 
-   if (output_tf == NULL || regamma_params == NULL)
+   if (output_tf == NULL || regamma_params == NULL ||
+   output_tf->type == TF_TYPE_BYPASS)
return false;
 
arr_points = regamma_params->arr_points;
-- 
2.9.3

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

[PATCH 2/8] drm/amd/display: fix dc_commit_surfaces_to_stream for dcc

2017-02-23 Thread Harry Wentland 
From: Ken Chalmers 

Change-Id: Ifd8698dc7d616085988f37a2aea40cbe56f360ba
Signed-off-by: Ken Chalmers 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 4c405f4b880e..84412e752017 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1246,6 +1246,7 @@ bool dc_commit_surfaces_to_stream(
plane_info[i].stereo_format = new_surfaces[i]->stereo_format;
plane_info[i].tiling_info = new_surfaces[i]->tiling_info;
plane_info[i].visible = new_surfaces[i]->visible;
+   plane_info[i].dcc = new_surfaces[i]->dcc;
scaling_info[i].scaling_quality = 
new_surfaces[i]->scaling_quality;
scaling_info[i].src_rect = new_surfaces[i]->src_rect;
scaling_info[i].dst_rect = new_surfaces[i]->dst_rect;
-- 
2.9.3

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

[PATCH 8/8] drm/amd/display: fix incorrect programming for YCbCr422 and YCbCr420

2017-02-23 Thread Harry Wentland 
From: Charlene Liu 

Change-Id: Ifef3ea5e3cfe0dfa1fd1c5574dd0b2d1495a12de
Signed-off-by: Charlene Liu 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 12 +---
 .../gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 17 +
 drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c |  3 +++
 3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
index aba392ff5095..e4092fd458a1 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
@@ -362,9 +362,15 @@ static void 
dce110_stream_encoder_hdmi_set_stream_attribute(
REG_UPDATE(HDMI_CONTROL, HDMI_DEEP_COLOR_DEPTH, 0);
break;
case COLOR_DEPTH_101010:
-   REG_UPDATE_2(HDMI_CONTROL,
-   HDMI_DEEP_COLOR_DEPTH, 1,
-   HDMI_DEEP_COLOR_ENABLE, 1);
+   if (crtc_timing->pixel_encoding == PIXEL_ENCODING_YCBCR422) {
+   REG_UPDATE_2(HDMI_CONTROL,
+   HDMI_DEEP_COLOR_DEPTH, 1,
+   HDMI_DEEP_COLOR_ENABLE, 0);
+   } else {
+   REG_UPDATE_2(HDMI_CONTROL,
+   HDMI_DEEP_COLOR_DEPTH, 1,
+   HDMI_DEEP_COLOR_ENABLE, 1);
+   }
break;
case COLOR_DEPTH_121212:
if (crtc_timing->pixel_encoding == PIXEL_ENCODING_YCBCR422) {
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 76a397d90adc..6915cc46754b 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
@@ -861,10 +861,6 @@ static void build_audio_output(
audio_output->crtc_info.requested_pixel_clock =
pipe_ctx->pix_clk_params.requested_pix_clk;
 
-   /*
-* TODO - Investigate why calculated pixel clk has to be
-* requested pixel clk
-*/
audio_output->crtc_info.calculated_pixel_clock =
pipe_ctx->pix_clk_params.requested_pix_clk;
 
@@ -1044,15 +1040,14 @@ static enum dc_status apply_single_controller_ctx_to_hw(
stream->public.timing.display_color_depth,
pipe_ctx->stream->signal);
 
+   /* FPGA does not program backend */
+   if (IS_FPGA_MAXIMUS_DC(dc->ctx->dce_environment)) {
pipe_ctx->opp->funcs->opp_program_fmt(
pipe_ctx->opp,
&stream->bit_depth_params,
&stream->clamping);
-
-   /* FPGA does not program backend */
-   if (IS_FPGA_MAXIMUS_DC(dc->ctx->dce_environment))
return DC_OK;
-
+   }
/* TODO: move to stream encoder */
if (pipe_ctx->stream->signal != SIGNAL_TYPE_VIRTUAL)
if (DC_OK != bios_parser_crtc_source_select(pipe_ctx)) {
@@ -1065,6 +1060,12 @@ static enum dc_status apply_single_controller_ctx_to_hw(
stream->sink->link->link_enc,
pipe_ctx->stream->signal);
 
+/*vbios crtc_source_selection and encoder_setup will override fmt_C*/
+   pipe_ctx->opp->funcs->opp_program_fmt(
+   pipe_ctx->opp,
+   &stream->bit_depth_params,
+   &stream->clamping);
+
if (dc_is_dp_signal(pipe_ctx->stream->signal))
pipe_ctx->stream_enc->funcs->dp_set_stream_attribute(
pipe_ctx->stream_enc,
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 074fb978e076..478c8d27f3bd 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -777,6 +777,9 @@ static void get_pixel_clock_parameters(
pixel_clk_params->flags.SUPPORT_YCBCR420 = 
(stream->public.timing.pixel_encoding ==
PIXEL_ENCODING_YCBCR420);
pixel_clk_params->pixel_encoding = stream->public.timing.pixel_encoding;
+   if (stream->public.timing.pixel_encoding == PIXEL_ENCODING_YCBCR422) {
+   pixel_clk_params->color_depth = COLOR_DEPTH_888;
+   }
 }
 
 void dce110_resource_build_bit_depth_reduction_params(
-- 
2.9.3

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

[PATCH 4/8] drm/amd/display: Add query_ddc_data function

2017-02-23 Thread Harry Wentland 
From: Zeyu Fan 

Change-Id: I4743f6e829cb9d1c0086f44e505b620f2228d4d8
Signed-off-by: Zeyu Fan 
Reviewed-by: Charlene Liu 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 25 +
 drivers/gpu/drm/amd/display/dc/dc.h  | 11 ++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 84412e752017..6516c275e0c7 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1725,6 +1725,31 @@ bool dc_read_dpcd(
return r == DDC_RESULT_SUCESSFULL;
 }
 
+bool dc_query_ddc_data(
+   struct dc *dc,
+   uint32_t link_index,
+   uint32_t address,
+   uint8_t *write_buf,
+   uint32_t write_size,
+   uint8_t *read_buf,
+   uint32_t read_size) {
+
+   struct core_dc *core_dc = DC_TO_CORE(dc);
+
+   struct core_link *link = core_dc->links[link_index];
+
+   bool result = dal_ddc_service_query_ddc_data(
+   link->ddc,
+   address,
+   write_buf,
+   write_size,
+   read_buf,
+   read_size);
+
+   return result;
+}
+
+
 bool dc_write_dpcd(
struct dc *dc,
uint32_t link_index,
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 71d7dde79ae0..2d84b18f48b0 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -720,7 +720,16 @@ bool dc_write_dpcd(
uint32_t link_index,
uint32_t address,
const uint8_t *data,
-   uint32_t size);
+   uint32_t size);
+
+bool dc_query_ddc_data(
+   struct dc *dc,
+   uint32_t link_index,
+   uint32_t address,
+   uint8_t *write_buf,
+   uint32_t write_size,
+   uint8_t *read_buf,
+   uint32_t read_size);
 
 bool dc_submit_i2c(
struct dc *dc,
-- 
2.9.3

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

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Joe Perches 
On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
> > There are ~4300 uses of pr_warn and ~250 uses of the older
> > pr_warning in the kernel source tree.
> > 
> > Make the use of pr_warn consistent across all kernel files.
> > 
> > This excludes all files in tools/ as there is a separate
> > define pr_warning for that directory tree and pr_warn is
> > not used in tools/.
> > 
> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
[]
> Where's the removal of pr_warning so we don't have more sneak in?

After all of these actually get applied,
and maybe a cycle or two later, one would
get sent.

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

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Emil Velikov 
On 23 February 2017 at 17:18, Joe Perches  wrote:
> On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
>> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
>> > There are ~4300 uses of pr_warn and ~250 uses of the older
>> > pr_warning in the kernel source tree.
>> >
>> > Make the use of pr_warn consistent across all kernel files.
>> >
>> > This excludes all files in tools/ as there is a separate
>> > define pr_warning for that directory tree and pr_warn is
>> > not used in tools/.
>> >
>> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> []
>> Where's the removal of pr_warning so we don't have more sneak in?
>
> After all of these actually get applied,
> and maybe a cycle or two later, one would
> get sent.
>
By which point you'll get a few reincarnation of it. So you'll have to
do the same exercise again :-(

I guess the question is - are you expecting to get the series merged
all together/via one tree ? If not, your plan is perfectly reasonable.
Fwiw in the DRM subsystem, similar cleanups does purge the respective
macros/other with the final commit. But there one can pull the lot in
one go.

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

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Joe Perches 
On Thu, 2017-02-23 at 17:41 +, Emil Velikov wrote:
> On 23 February 2017 at 17:18, Joe Perches  wrote:
> > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
> > > > There are ~4300 uses of pr_warn and ~250 uses of the older
> > > > pr_warning in the kernel source tree.
> > > > 
> > > > Make the use of pr_warn consistent across all kernel files.
> > > > 
> > > > This excludes all files in tools/ as there is a separate
> > > > define pr_warning for that directory tree and pr_warn is
> > > > not used in tools/.
> > > > 
> > > > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> > 
> > []
> > > Where's the removal of pr_warning so we don't have more sneak in?
> > 
> > After all of these actually get applied,
> > and maybe a cycle or two later, one would
> > get sent.
> > 
> 
> By which point you'll get a few reincarnation of it. So you'll have to
> do the same exercise again :-(

Maybe to one or two files.  Not a big deal.

> I guess the question is - are you expecting to get the series merged
> all together/via one tree ?

No.  The only person that could do that effectively is Linus.

> If not, your plan is perfectly reasonable.

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

Re: [PATCH umr] Allow * for ipname in --read/--write/--write-bit

2017-02-23 Thread Andres Rodriguez 



On 2017-02-23 09:46 AM, Tom St Denis wrote:

To simplify scripting you can now use * for ipnames as well.


Thanks for the patch, this change is very welcome.



Signed-off-by: Tom St Denis 
---
 doc/umr.1 |   6 ++-
 src/app/main.c|   5 ++-
 src/app/scan.c|  21 ++
 src/app/set_bit.c | 117 +++---
 src/app/set_reg.c |  91 +-
 5 files changed, 131 insertions(+), 109 deletions(-)

diff --git a/doc/umr.1 b/doc/umr.1
index 5ed2c3bb93ae..a12dfb0a00ff 100644
--- a/doc/umr.1
+++ b/doc/umr.1
@@ -34,7 +34,7 @@ Look up an MMIO register by address and bitfield decode the 
value specified.
 Write a value specified in hex to a register specified with a complete
 register path in the form <
 .B asicname.ipname.regname
->.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname can be
+>.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname and/or 
ipname can be
 .B *
 to simplify scripting.  This command can be used multiple times to
 write to multiple registers in a single invocation.
@@ -52,7 +52,9 @@ command but also allows
 for the regname field.
 .IP "--scan, -s "
 Scan and print an IP block by name, for example,
-.B uvd5.
+.B uvd6
+or
+.B carrizo.uvd6.
 Can be used multiple times in a single invocation.
 .IP "--ring, -R (from:to)"
 Read the contents of a ring named by the string without the
diff --git a/src/app/main.c b/src/app/main.c
index 8364d54c5227..99e014888571 100644
--- a/src/app/main.c
+++ b/src/app/main.c
@@ -364,12 +364,13 @@ int main(int argc, char **argv)
 "\n\t--write, -w  \n\t\tWrite a value in hex to a register 
specified as a register path in the"
"\n\t\tform .  For instance 
\"tonga.uvd5.mmUVD_SOFT_RESET\"."
"\n\t\tCan be used multiple times to set multiple registers.  You can"
-   "\n\t\tspecify * for asicname to simplify scripts.\n"
+   "\n\t\tspecify * for asicname and/or ipname to simplify scripts.\n"
 "\n\t--writebit, -wb  \n\t\tWrite a value in hex to a register 
bitfield specified as in --write but"
"\n\t\tthe addition of the bitfield name.  For instance: 
\"*.gfx80.mmRLC_PG_CNTL.PG_OVERRIDE\"\n"
 "\n\t--read, -r \n\t\tRead a value from a register and print it to stdout.  
This command"
"\n\t\tuses the same path notation as --write.  It also accepts * for 
regname.\n"
-"\n\t--scan, -s \n\t\tScan and print an ip block by name, e.g. \"uvd5\".  
Can be used multiple times.\n"
+"\n\t--scan, -s \n\t\tScan and print an ip block by name, e.g. \"uvd6\" or 
\"carrizo.uvd6\"."
+   "\n\t\tCan be used multiple times.\n"
 "\n\t--ring, -R ([from:to])\n\t\tRead the contents of a ring named by the 
string without the amdgpu_ring_ prefix. "
"\n\t\tBy default it will read and display the entire ring.  A starting and 
ending "
"\n\t\taddress can be specified in decimal or a '.' can be used to indicate 
relative "
diff --git a/src/app/scan.c b/src/app/scan.c
index 19c97fe1499d..fbb8f5838069 100644
--- a/src/app/scan.c
+++ b/src/app/scan.c
@@ -31,6 +31,27 @@ int umr_scan_asic(struct umr_asic *asic, char *asicname, 
char *ipname, char *reg
uint64_t addr, scale;
char buf[256];

+   // if ipname == '*' scan for a match and stop on first one
+   if (ipname[0] == '*' && regname[0] != '*') {
+   for (i = 0; i < asic->no_blocks; i++) {
+   for (j = 0; j < asic->blocks[i]->no_regs; j++) {
+   if (!strcmp(regname, 
asic->blocks[i]->regs[j].regname) ||
+   (options.many && 
strstr(asic->blocks[i]->regs[j].regname, regname))) {
+   ipname = asic->blocks[i]->ipname;
+   goto ip_found;


Since the star globs usually imply a wildcard match, I think it is a 
little weird to truncate the output to only the first match.


If a star glob is requested by the user, I think it should be okay to 
loop and print multiple outputs as usually happens when options.many is 
enabled.


Alternative approach would be to print an 'ambiguous argument' error. 
That way the user will at least have some feedback. Although I think the 
behaviour of printing multiple results is preferable.


Cheers,
Andres


+   }
+   }
+   }
+   }
+ip_found:
+   if (ipname[0] == '*') {
+   if (regname[0] == '*')
+   fprintf(stderr, "[ERROR]:  You cannot specify * for both 
ipname and regname\n");
+   else
+   fprintf(stderr, "[ERROR]:  Register name <%s> was not found 
with ANY ip name\n", regname);
+   return -1;
+   }
+
/* scan them all in order */
if (!asicname[0] || !strcmp(asicname, "*") || !strcmp(asicname, 
asic->asicname)) {
for (i = 0; i < asic->no_blocks; i++) {
diff --git a/src/app/set_bit.c b/src/app/set

Re: [PATCH umr] Allow * for ipname in --read/--write/--write-bit

2017-02-23 Thread Tom St Denis 

On 23/02/17 01:41 PM, Andres Rodriguez wrote:



On 2017-02-23 09:46 AM, Tom St Denis wrote:

To simplify scripting you can now use * for ipnames as well.


Thanks for the patch, this change is very welcome.



Signed-off-by: Tom St Denis 
---
 doc/umr.1 |   6 ++-
 src/app/main.c|   5 ++-
 src/app/scan.c|  21 ++
 src/app/set_bit.c | 117
+++---
 src/app/set_reg.c |  91 +-
 5 files changed, 131 insertions(+), 109 deletions(-)

diff --git a/doc/umr.1 b/doc/umr.1
index 5ed2c3bb93ae..a12dfb0a00ff 100644
--- a/doc/umr.1
+++ b/doc/umr.1
@@ -34,7 +34,7 @@ Look up an MMIO register by address and bitfield
decode the value specified.
 Write a value specified in hex to a register specified with a complete
 register path in the form <
 .B asicname.ipname.regname
->.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname can be
+>.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname
and/or ipname can be
 .B *
 to simplify scripting.  This command can be used multiple times to
 write to multiple registers in a single invocation.
@@ -52,7 +52,9 @@ command but also allows
 for the regname field.
 .IP "--scan, -s "
 Scan and print an IP block by name, for example,
-.B uvd5.
+.B uvd6
+or
+.B carrizo.uvd6.
 Can be used multiple times in a single invocation.
 .IP "--ring, -R (from:to)"
 Read the contents of a ring named by the string without the
diff --git a/src/app/main.c b/src/app/main.c
index 8364d54c5227..99e014888571 100644
--- a/src/app/main.c
+++ b/src/app/main.c
@@ -364,12 +364,13 @@ int main(int argc, char **argv)
 "\n\t--write, -w  \n\t\tWrite a value in hex to a
register specified as a register path in the"
 "\n\t\tform .  For instance
\"tonga.uvd5.mmUVD_SOFT_RESET\"."
 "\n\t\tCan be used multiple times to set multiple registers.  You
can"
-"\n\t\tspecify * for asicname to simplify scripts.\n"
+"\n\t\tspecify * for asicname and/or ipname to simplify scripts.\n"
 "\n\t--writebit, -wb  \n\t\tWrite a value in hex to a
register bitfield specified as in --write but"
 "\n\t\tthe addition of the bitfield name.  For instance:
\"*.gfx80.mmRLC_PG_CNTL.PG_OVERRIDE\"\n"
 "\n\t--read, -r \n\t\tRead a value from a register and print
it to stdout.  This command"
 "\n\t\tuses the same path notation as --write.  It also accepts *
for regname.\n"
-"\n\t--scan, -s \n\t\tScan and print an ip block by name,
e.g. \"uvd5\".  Can be used multiple times.\n"
+"\n\t--scan, -s \n\t\tScan and print an ip block by name,
e.g. \"uvd6\" or \"carrizo.uvd6\"."
+"\n\t\tCan be used multiple times.\n"
 "\n\t--ring, -R ([from:to])\n\t\tRead the contents of a ring
named by the string without the amdgpu_ring_ prefix. "
 "\n\t\tBy default it will read and display the entire ring.  A
starting and ending "
 "\n\t\taddress can be specified in decimal or a '.' can be used
to indicate relative "
diff --git a/src/app/scan.c b/src/app/scan.c
index 19c97fe1499d..fbb8f5838069 100644
--- a/src/app/scan.c
+++ b/src/app/scan.c
@@ -31,6 +31,27 @@ int umr_scan_asic(struct umr_asic *asic, char
*asicname, char *ipname, char *reg
 uint64_t addr, scale;
 char buf[256];

+// if ipname == '*' scan for a match and stop on first one
+if (ipname[0] == '*' && regname[0] != '*') {
+for (i = 0; i < asic->no_blocks; i++) {
+for (j = 0; j < asic->blocks[i]->no_regs; j++) {
+if (!strcmp(regname,
asic->blocks[i]->regs[j].regname) ||
+(options.many &&
strstr(asic->blocks[i]->regs[j].regname, regname))) {
+ipname = asic->blocks[i]->ipname;
+goto ip_found;


Since the star globs usually imply a wildcard match, I think it is a
little weird to truncate the output to only the first match.

If a star glob is requested by the user, I think it should be okay to
loop and print multiple outputs as usually happens when options.many is
enabled.

Alternative approach would be to print an 'ambiguous argument' error.
That way the user will at least have some feedback. Although I think the
behaviour of printing multiple results is preferable.


Now that I think about it is possible that future asics have multiples 
of IP blocks so ideally we should continue on for as many collisions.


I think the '-O named' option should then print the IP name as well.

I'll (v2) this shortly.

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

[PATCH umr] Allow * for ipname in --read/--write/--write-bit (v2)

2017-02-23 Thread Tom St Denis 
To simplify scripting you can now use * for ipnames as well.

(v2) Continue matching other IP blocks after first register hit.

Signed-off-by: Tom St Denis 
---
 doc/umr.1 |   6 ++-
 src/app/main.c|   5 ++-
 src/app/scan.c|  32 ---
 src/app/set_bit.c | 117 +++---
 src/app/set_reg.c |  91 +-
 5 files changed, 128 insertions(+), 123 deletions(-)

diff --git a/doc/umr.1 b/doc/umr.1
index 5ed2c3bb93ae..a12dfb0a00ff 100644
--- a/doc/umr.1
+++ b/doc/umr.1
@@ -34,7 +34,7 @@ Look up an MMIO register by address and bitfield decode the 
value specified.
 Write a value specified in hex to a register specified with a complete
 register path in the form <
 .B asicname.ipname.regname
->.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname can be
+>.  For example, fiji.uvd6.mmUVD_CGC_GATE.  The value of asicname and/or 
ipname can be
 .B *
 to simplify scripting.  This command can be used multiple times to
 write to multiple registers in a single invocation.
@@ -52,7 +52,9 @@ command but also allows
 for the regname field.
 .IP "--scan, -s "
 Scan and print an IP block by name, for example,
-.B uvd5.
+.B uvd6
+or
+.B carrizo.uvd6.
 Can be used multiple times in a single invocation.
 .IP "--ring, -R (from:to)"
 Read the contents of a ring named by the string without the
diff --git a/src/app/main.c b/src/app/main.c
index 8364d54c5227..99e014888571 100644
--- a/src/app/main.c
+++ b/src/app/main.c
@@ -364,12 +364,13 @@ int main(int argc, char **argv)
 "\n\t--write, -w  \n\t\tWrite a value in hex to a register 
specified as a register path in the"
"\n\t\tform .  For instance 
\"tonga.uvd5.mmUVD_SOFT_RESET\"."
"\n\t\tCan be used multiple times to set multiple registers.  You can"
-   "\n\t\tspecify * for asicname to simplify scripts.\n"
+   "\n\t\tspecify * for asicname and/or ipname to simplify scripts.\n"
 "\n\t--writebit, -wb  \n\t\tWrite a value in hex to a register 
bitfield specified as in --write but"
"\n\t\tthe addition of the bitfield name.  For instance: 
\"*.gfx80.mmRLC_PG_CNTL.PG_OVERRIDE\"\n"
 "\n\t--read, -r \n\t\tRead a value from a register and print it to 
stdout.  This command"
"\n\t\tuses the same path notation as --write.  It also accepts * for 
regname.\n"
-"\n\t--scan, -s \n\t\tScan and print an ip block by name, e.g. 
\"uvd5\".  Can be used multiple times.\n"
+"\n\t--scan, -s \n\t\tScan and print an ip block by name, e.g. 
\"uvd6\" or \"carrizo.uvd6\"."
+   "\n\t\tCan be used multiple times.\n"
 "\n\t--ring, -R ([from:to])\n\t\tRead the contents of a ring named by 
the string without the amdgpu_ring_ prefix. "
"\n\t\tBy default it will read and display the entire ring.  A starting 
and ending "
"\n\t\taddress can be specified in decimal or a '.' can be used to 
indicate relative "
diff --git a/src/app/scan.c b/src/app/scan.c
index 19c97fe1499d..e91fbd4649c8 100644
--- a/src/app/scan.c
+++ b/src/app/scan.c
@@ -27,27 +27,30 @@
 int umr_scan_asic(struct umr_asic *asic, char *asicname, char *ipname, char 
*regname)
 {
int r, fd;
-   int i, j, k;
+   int first, i, j, k;
uint64_t addr, scale;
char buf[256];
 
/* scan them all in order */
if (!asicname[0] || !strcmp(asicname, "*") || !strcmp(asicname, 
asic->asicname)) {
for (i = 0; i < asic->no_blocks; i++) {
-   if (!ipname[0] || !strcmp(ipname, 
asic->blocks[i]->ipname)) {
-   if (asic->blocks[i]->grant) {
-   r = asic->blocks[i]->grant(asic);
-   if (r) {
-   if (ipname[0]) {
-   fprintf(stderr, 
"[ERROR] Must specify at least one 'risky' option before scanning specific 
blocks.\n");
-   exit(EXIT_FAILURE);
-   }
-   continue;
-   }
-   }
+   if (!ipname[0] || ipname[0] == '*' || !strcmp(ipname, 
asic->blocks[i]->ipname)) {
+   first = 1;
for (j = 0; j < asic->blocks[i]->no_regs; j++) {
if (!regname[0] || !strcmp(regname, 
"*") || !strcmp(regname, asic->blocks[i]->regs[j].regname) ||
(options.many && 
strstr(asic->blocks[i]->regs[j].regname, regname))) {
+   // only grant if any regspec 
matches otherwise it's a waste
+   if (first && 
asic->blocks[i]->grant) {
+   first = 0;
+

[pull] amdgpu and ttm drm-next-4.11

2017-02-23 Thread Alex Deucher 
Hi Dave,

Just a few fixes for 4.11.

The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c:

  Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000)

are available in the git repository at:

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

for you to fetch changes up to 187368a5c7ad6c41159b85025a87d6d136eb8d4b:

  drm/amd/powerplay: fix PSI feature on Polars12. (2017-02-22 17:54:23 -0500)


Jim Qu (1):
  drm/amd/amdgpu: post card if there is real hw resetting performed

Nicolai Hähnle (2):
  drm/ttm: fix use-after-free races in vm fault handling
  drm/amdgpu: refuse to reserve io mem for split VRAM buffers

Rex Zhu (1):
  drm/amd/powerplay: fix PSI feature on Polars12.

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  3 +++
 drivers/gpu/drm/amd/amdgpu/cik.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/vi.c|  1 +
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c   | 22 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.h   |  3 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  9 +
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h   |  2 +-
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  2 +-
 drivers/gpu/drm/ttm/ttm_bo_vm.c| 12 
 12 files changed, 71 insertions(+), 13 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: trace amdgpu_job fence details

2017-02-23 Thread Andres Rodriguez 



On 2017-02-23 03:20 AM, Christian König wrote:

Am 23.02.2017 um 00:47 schrieb Andres Rodriguez:

This trace is intended to provide the required information to associate
the completion of an amdgpu_job with its corresponding dma_fence_*
tracepoints.

Signed-off-by: Andres Rodriguez 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 22 ++
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c

index 86a1242..84a04e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -177,6 +177,8 @@ static struct dma_fence *amdgpu_job_run(struct 
amd_sched_job *sched_job)

  /* if gpu reset, hw fence will be replaced here */
  dma_fence_put(job->fence);
  job->fence = dma_fence_get(fence);
+trace_amdgpu_job_attach_fence(job);
+
  amdgpu_job_free_resources(job);
  return fence;
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h

index a18ae1e..0a61ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -147,6 +147,28 @@ TRACE_EVENT(amdgpu_sched_run_job,
__entry->fence, __entry->ring_name, __entry->num_ibs)
  );
  +TRACE_EVENT(amdgpu_job_attach_fence,
+TP_PROTO(struct amdgpu_job *job),
+TP_ARGS(job),
+TP_STRUCT__entry(
+ __field(struct amdgpu_device *, adev)
+ __field(struct amd_sched_job *, sched_job)


Neither add adev nor sched_job pointer to your trace point.
Would it be okay then to grab a reference to the scheduler fence in 
amdgpu_job_run and print the sched fence pointer here?


That would give us enough info to correlate other trace points like 
amdgpu_cs_ioctl aor amdgpu_sched_run_job to the respective dma_fence 
tracepoints.





The adev pointer is completely meaningless in the logs and the 
scheduler job might already be freed when the printk is called.


Just checked the source and a couple of other trace points get this 
horrible wrong as well, so that isn't your fault. Going to put it on 
my todo to fix those.


Regards,
Christian.

+ __string(timeline, 
job->fence->ops->get_timeline_name(job->fence))

+ __field(unsigned int, context)
+ __field(unsigned int, seqno)
+ ),
+
+TP_fast_assign(
+   __entry->adev = job->adev;
+   __entry->sched_job = &job->base;
+   __assign_str(timeline, 
job->fence->ops->get_timeline_name(job->fence))

+   __entry->context = job->fence->context;
+   __entry->seqno = job->fence->seqno;
+   ),
+TP_printk("adev=%p, sched_job=%p, timeline:%s, context:%u, 
seqno:%u",

+  __entry->adev, __entry->sched_job,
+  __get_str(timeline), __entry->context, __entry->seqno)
+);
TRACE_EVENT(amdgpu_vm_grab_id,
  TP_PROTO(struct amdgpu_vm *vm, int ring, struct amdgpu_job 
*job),





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

Re: [PATCH] drm/amdgpu: trace amdgpu_job fence details

2017-02-23 Thread Andres Rodriguez 



On 2017-02-23 02:46 PM, Andres Rodriguez wrote:



On 2017-02-23 03:20 AM, Christian König wrote:

Am 23.02.2017 um 00:47 schrieb Andres Rodriguez:

This trace is intended to provide the required information to associate
the completion of an amdgpu_job with its corresponding dma_fence_*
tracepoints.

Signed-off-by: Andres Rodriguez 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 22 ++
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c

index 86a1242..84a04e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -177,6 +177,8 @@ static struct dma_fence *amdgpu_job_run(struct 
amd_sched_job *sched_job)

  /* if gpu reset, hw fence will be replaced here */
  dma_fence_put(job->fence);
  job->fence = dma_fence_get(fence);
+trace_amdgpu_job_attach_fence(job);
+
  amdgpu_job_free_resources(job);
  return fence;
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h

index a18ae1e..0a61ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -147,6 +147,28 @@ TRACE_EVENT(amdgpu_sched_run_job,
__entry->fence, __entry->ring_name, __entry->num_ibs)
  );
  +TRACE_EVENT(amdgpu_job_attach_fence,
+TP_PROTO(struct amdgpu_job *job),
+TP_ARGS(job),
+TP_STRUCT__entry(
+ __field(struct amdgpu_device *, adev)
+ __field(struct amd_sched_job *, sched_job)


Neither add adev nor sched_job pointer to your trace point.
Would it be okay then to grab a reference to the scheduler fence in 
amdgpu_job_run and print the sched fence pointer here?


That would give us enough info to correlate other trace points like 
amdgpu_cs_ioctl aor amdgpu_sched_run_job to the respective dma_fence 
tracepoints.





The adev pointer is completely meaningless in the logs and the 
scheduler job might already be freed when the printk is called.

Hey Christian,

I was just double checking the lifetime of the scheduler job, and it 
should still be valid during amdgpu_job_run. The lifetime of the job is 
tied to the scheduler finished fence which won't be signaled until 
amdgpu_job_run finishes even if the HW fence has signaled.


This is assuming that the trace printks are synchronous.

So I think printing the job and dropping adev should be okay if the 
above holds true, unless I'm missing something else.




Just checked the source and a couple of other trace points get this 
horrible wrong as well, so that isn't your fault. Going to put it on 
my todo to fix those.


Regards,
Christian.

+ __string(timeline, 
job->fence->ops->get_timeline_name(job->fence))

+ __field(unsigned int, context)
+ __field(unsigned int, seqno)
+ ),
+
+TP_fast_assign(
+   __entry->adev = job->adev;
+   __entry->sched_job = &job->base;
+   __assign_str(timeline, 
job->fence->ops->get_timeline_name(job->fence))

+   __entry->context = job->fence->context;
+   __entry->seqno = job->fence->seqno;
+   ),
+TP_printk("adev=%p, sched_job=%p, timeline:%s, context:%u, 
seqno:%u",

+  __entry->adev, __entry->sched_job,
+  __get_str(timeline), __entry->context, __entry->seqno)
+);
TRACE_EVENT(amdgpu_vm_grab_id,
  TP_PROTO(struct amdgpu_vm *vm, int ring, struct amdgpu_job 
*job),







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

[PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards

2017-02-23 Thread Alexandre Demers 
First, sorry for not replying directly as I should normally, but I'm not on
my usual computer, so I can't. That being said...

I may have my eyes in the same socket right now, but I think
fiji_setup_dpm_led_config() always returns 0.

> + if (mask)
> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
> +PPSMC_MSG_LedConfig,
> +mask);
> + return 0;
> +}

Even when "if (mask)" is true, whether
smum_send_msg_to_smc_with_parameter() succeeds or not,
fiji_setup_dpm_led_config() spits a 0 at the end.

Thus,

>* +result = fiji_setup_dpm_led_config(hwmgr);
*>* +   PP_ASSERT_WITH_CODE(0 == result,
*>* +   "Failed to setup dpm led config", return result);
*

will always lead to "result" being set to 0... Am I missing something?

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

Re: [PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards

2017-02-23 Thread Alex Deucher 
On Thu, Feb 23, 2017 at 5:50 PM, Alexandre Demers
 wrote:
> First, sorry for not replying directly as I should normally, but I'm not on
> my usual computer, so I can't. That being said...
>
> I may have my eyes in the same socket right now, but I think
> fiji_setup_dpm_led_config() always returns 0.
>
>> + if (mask)
>> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
>> +PPSMC_MSG_LedConfig,
>> +mask);
>> + return 0;
>> +}
>
> Even when "if (mask)" is true, whether smum_send_msg_to_smc_with_parameter()
> succeeds or not, fiji_setup_dpm_led_config() spits a 0 at the end.
>
> Thus,
>
>> + result = fiji_setup_dpm_led_config(hwmgr);
>> + PP_ASSERT_WITH_CODE(0 == result,
>> +"Failed to setup dpm led config", return result);
>
> will always lead to "result" being set to 0... Am I missing something?
>

Yes, that function can't fail.  I suppose we could just make it a void
function, but I was following the same pattern of all the other
functions in that file.

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

Re: [PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards

2017-02-23 Thread Edward O'Callaghan 
Hi guys,

Shouldn't this hook into the "led framework" of the kernel?

https://www.kernel.org/doc/Documentation/leds/leds-class.txt

Kind Regards,
Edward.

On 02/24/2017 10:03 AM, Alex Deucher wrote:
> On Thu, Feb 23, 2017 at 5:50 PM, Alexandre Demers
>  wrote:
>> First, sorry for not replying directly as I should normally, but I'm not on
>> my usual computer, so I can't. That being said...
>>
>> I may have my eyes in the same socket right now, but I think
>> fiji_setup_dpm_led_config() always returns 0.
>>
>>> + if (mask)
>>> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
>>> +PPSMC_MSG_LedConfig,
>>> +mask);
>>> + return 0;
>>> +}
>>
>> Even when "if (mask)" is true, whether smum_send_msg_to_smc_with_parameter()
>> succeeds or not, fiji_setup_dpm_led_config() spits a 0 at the end.
>>
>> Thus,
>>
>>> + result = fiji_setup_dpm_led_config(hwmgr);
>>> + PP_ASSERT_WITH_CODE(0 == result,
>>> +"Failed to setup dpm led config", return result);
>>
>> will always lead to "result" being set to 0... Am I missing something?
>>
> 
> Yes, that function can't fail.  I suppose we could just make it a void
> function, but I was following the same pattern of all the other
> functions in that file.
> 
> Alex
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 



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

RE: [PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards

2017-02-23 Thread Deucher, Alexander 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Edward O'Callaghan
> Sent: Thursday, February 23, 2017 7:51 PM
> To: Alex Deucher; Alexandre Demers
> Cc: Freedesktop - AMD-gfx
> Subject: Re: [PATCH] drm/amdgpu/powerplay: enable LEDs on Fiji boards
> 
> Hi guys,
> 
> Shouldn't this hook into the "led framework" of the kernel?
> 
> https://www.kernel.org/doc/Documentation/leds/leds-class.txt

The LEDs are not directly controllable by the driver.  The SMU microcontroller 
actually controls them (it lights them up in a pattern based on dpm states), we 
just tell the SMU to enable the functionality.

Alex

> 
> Kind Regards,
> Edward.
> 
> On 02/24/2017 10:03 AM, Alex Deucher wrote:
> > On Thu, Feb 23, 2017 at 5:50 PM, Alexandre Demers
> >  wrote:
> >> First, sorry for not replying directly as I should normally, but I'm not on
> >> my usual computer, so I can't. That being said...
> >>
> >> I may have my eyes in the same socket right now, but I think
> >> fiji_setup_dpm_led_config() always returns 0.
> >>
> >>> + if (mask)
> >>> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
> >>> +PPSMC_MSG_LedConfig,
> >>> +mask);
> >>> + return 0;
> >>> +}
> >>
> >> Even when "if (mask)" is true, whether
> smum_send_msg_to_smc_with_parameter()
> >> succeeds or not, fiji_setup_dpm_led_config() spits a 0 at the end.
> >>
> >> Thus,
> >>
> >>> + result = fiji_setup_dpm_led_config(hwmgr);
> >>> + PP_ASSERT_WITH_CODE(0 == result,
> >>> +"Failed to setup dpm led config", return result);
> >>
> >> will always lead to "result" being set to 0... Am I missing something?
> >>
> >
> > Yes, that function can't fail.  I suppose we could just make it a void
> > function, but I was following the same pattern of all the other
> > functions in that file.
> >
> > Alex
> > ___
> > 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/powerplay: enable LEDs on Fiji boards

2017-02-23 Thread Alexandre Demers 
On Thursday, February 23, 2017, Alex Deucher  wrote:

> On Thu, Feb 23, 2017 at 5:50 PM, Alexandre Demers
> > wrote:
> > First, sorry for not replying directly as I should normally, but I'm not
> on
> > my usual computer, so I can't. That being said...
> >
> > I may have my eyes in the same socket right now, but I think
> > fiji_setup_dpm_led_config() always returns 0.
> >
> >> + if (mask)
> >> + smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
> >> +PPSMC_MSG_LedConfig,
> >> +mask);
> >> + return 0;
> >> +}
> >
> > Even when "if (mask)" is true, whether smum_send_msg_to_smc_with_
> parameter()
> > succeeds or not, fiji_setup_dpm_led_config() spits a 0 at the end.
> >
> > Thus,
> >
> >> + result = fiji_setup_dpm_led_config(hwmgr);
> >> + PP_ASSERT_WITH_CODE(0 == result,
> >> +"Failed to setup dpm led config", return result);
> >
> > will always lead to "result" being set to 0... Am I missing something?
> >
>
> Yes, that function can't fail.  I suppose we could just make it a void
> function, but I was following the same pattern of all the other
> functions in that file.
>
> Alex
>

I see. Well, if there is no forseseeable change that would justify to
return a different value, I would be tempted to go with the void. But
either way, I'll live with it.

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