Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

[Sharma, Shashank]

Thanks for the patch,

Patch pushed for staging.


Regards

Shashank

On 25/03/2024 00:23, Alex Deucher wrote:

On Sat, Mar 23, 2024 at 4:47 PM Sharma, Shashank
 wrote:


On 23/03/2024 15:52, Johannes Weiner wrote:

On Thu, Mar 14, 2024 at 01:09:57PM -0400, Johannes Weiner wrote:

Hello,

On Fri, Mar 08, 2024 at 12:32:33PM +0100, Christian König wrote:

Am 07.03.24 um 23:07 schrieb Johannes Weiner:

Lastly I went with an open loop instead of a memcpy() as I wasn't
sure if that memory is safe to address a byte at at time.

Shashank pointed out to me in private that byte access would indeed be
safe. However, after actually trying it it won't work because memcpy()
doesn't play nice with mqd being volatile:

/home/hannes/src/linux/linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c: In 
function 'amdgpu_debugfs_mqd_read':
/home/hannes/src/linux/linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:550:22: 
warning: passing argument 1 of '__builtin_dynamic_object_size' discards 
'volatil' qualifier from pointer target type [-Wdiscarded-qualifiers]
550 | memcpy(kbuf, mqd, ring->mqd_size);

So I would propose leaving the patch as-is. Shashank, does that sound
good to you?

Friendly ping :)

Shashank, is your Reviewed-by still good for this patch, given the
above?

Ah, sorry I missed this due to some parallel work, and just realized the
memcpy/volatile limitation.

I also feel the need of protecting MQD read under a lock to avoid
parallel change in MQD while we do byte-by-byte copy, but I will add
that in my to-do list.

Please feel free to use my R-b.

Shashank, if the patch looks good, can you pick it up and apply it?

Alex



- Shashank


Thanks

Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

[Sharma, Shashank]

[AMD Official Use Only - General]

Hey Alex,
Sure, I will pick it up and push it to staging.

Regards
Shashank

From: Alex Deucher 
Sent: Monday, March 25, 2024 12:23 AM
To: Sharma, Shashank 
Cc: Johannes Weiner ; Christian König 
; Deucher, Alexander 
; Koenig, Christian ; 
amd-...@lists.freedesktop.org ; 
dri-devel@lists.freedesktop.org ; 
linux-ker...@vger.kernel.org 
Subject: Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

On Sat, Mar 23, 2024 at 4:47 PM Sharma, Shashank
 wrote:
>
>
> On 23/03/2024 15:52, Johannes Weiner wrote:
> > On Thu, Mar 14, 2024 at 01:09:57PM -0400, Johannes Weiner wrote:
> >> Hello,
> >>
> >> On Fri, Mar 08, 2024 at 12:32:33PM +0100, Christian König wrote:
> >>> Am 07.03.24 um 23:07 schrieb Johannes Weiner:
> >>>> Lastly I went with an open loop instead of a memcpy() as I wasn't
> >>>> sure if that memory is safe to address a byte at at time.
> >> Shashank pointed out to me in private that byte access would indeed be
> >> safe. However, after actually trying it it won't work because memcpy()
> >> doesn't play nice with mqd being volatile:
> >>
> >> /home/hannes/src/linux/linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c: In 
> >> function 'amdgpu_debugfs_mqd_read':
> >> /home/hannes/src/linux/linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:550:22:
> >>  warning: passing argument 1 of '__builtin_dynamic_object_size' discards 
> >> 'volatil' qualifier from pointer target type [-Wdiscarded-qualifiers]
> >>550 | memcpy(kbuf, mqd, ring->mqd_size);
> >>
> >> So I would propose leaving the patch as-is. Shashank, does that sound
> >> good to you?
> > Friendly ping :)
> >
> > Shashank, is your Reviewed-by still good for this patch, given the
> > above?
>
> Ah, sorry I missed this due to some parallel work, and just realized the
> memcpy/volatile limitation.
>
> I also feel the need of protecting MQD read under a lock to avoid
> parallel change in MQD while we do byte-by-byte copy, but I will add
> that in my to-do list.
>
> Please feel free to use my R-b.

Shashank, if the patch looks good, can you pick it up and apply it?

Alex


>
> - Shashank
>
> > Thanks

Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

[Sharma, Shashank]

On 23/03/2024 15:52, Johannes Weiner wrote:

On Thu, Mar 14, 2024 at 01:09:57PM -0400, Johannes Weiner wrote:

Hello,

On Fri, Mar 08, 2024 at 12:32:33PM +0100, Christian König wrote:

Am 07.03.24 um 23:07 schrieb Johannes Weiner:

Lastly I went with an open loop instead of a memcpy() as I wasn't
sure if that memory is safe to address a byte at at time.

Shashank pointed out to me in private that byte access would indeed be
safe. However, after actually trying it it won't work because memcpy()
doesn't play nice with mqd being volatile:

/home/hannes/src/linux/linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c: In 
function 'amdgpu_debugfs_mqd_read':
/home/hannes/src/linux/linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:550:22: 
warning: passing argument 1 of '__builtin_dynamic_object_size' discards 
'volatil' qualifier from pointer target type [-Wdiscarded-qualifiers]
   550 | memcpy(kbuf, mqd, ring->mqd_size);

So I would propose leaving the patch as-is. Shashank, does that sound
good to you?

Friendly ping :)

Shashank, is your Reviewed-by still good for this patch, given the
above?


Ah, sorry I missed this due to some parallel work, and just realized the 
memcpy/volatile limitation.


I also feel the need of protecting MQD read under a lock to avoid 
parallel change in MQD while we do byte-by-byte copy, but I will add 
that in my to-do list.


Please feel free to use my R-b.

- Shashank


Thanks

Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

[Sharma, Shashank]

+ Johannes

Regards
Shashank

On 13/03/2024 18:22, Sharma, Shashank wrote:

Hello Johannes,

On 07/03/2024 23:07, Johannes Weiner wrote:

An errant disk backup on my desktop got into debugfs and triggered the
following deadlock scenario in the amdgpu debugfs files. The machine
also hard-resets immediately after those lines are printed (although I
wasn't able to reproduce that part when reading by hand):

[ 1318.016074][ T1082] 
==
[ 1318.016607][ T1082] WARNING: possible circular locking dependency 
detected

[ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted
[ 1318.017598][ T1082] 
--

[ 1318.018096][ T1082] tar/1082 is trying to acquire lock:
[ 1318.018585][ T1082] 98c44175d6a0 (>mmap_lock){}-{3:3}, 
at: __might_fault+0x40/0x80

[ 1318.019084][ T1082]
[ 1318.019084][ T1082] but task is already holding lock:
[ 1318.020052][ T1082] 98c4c13f55f8 
(reservation_ww_class_mutex){+.+.}-{3:3}, at: 
amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]

[ 1318.020607][ T1082]
[ 1318.020607][ T1082] which lock already depends on the new lock.
[ 1318.020607][ T1082]
[ 1318.022081][ T1082]
[ 1318.022081][ T1082] the existing dependency chain (in reverse 
order) is:

[ 1318.023083][ T1082]
[ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}:
[ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0
[ 1318.024639][ T1082]    ww_mutex_lock+0x32/0x90
[ 1318.025161][ T1082]    dma_resv_lockdep+0x18a/0x330
[ 1318.025683][ T1082]    do_one_initcall+0x6a/0x350
[ 1318.026210][ T1082]    kernel_init_freeable+0x1a3/0x310
[ 1318.026728][ T1082]    kernel_init+0x15/0x1a0
[ 1318.027242][ T1082]    ret_from_fork+0x2c/0x40
[ 1318.027759][ T1082]    ret_from_fork_asm+0x11/0x20
[ 1318.028281][ T1082]
[ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}:
[ 1318.029297][ T1082]    dma_resv_lockdep+0x16c/0x330
[ 1318.029790][ T1082]    do_one_initcall+0x6a/0x350
[ 1318.030263][ T1082]    kernel_init_freeable+0x1a3/0x310
[ 1318.030722][ T1082]    kernel_init+0x15/0x1a0
[ 1318.031168][ T1082]    ret_from_fork+0x2c/0x40
[ 1318.031598][ T1082]    ret_from_fork_asm+0x11/0x20
[ 1318.032011][ T1082]
[ 1318.032011][ T1082] -> #0 (>mmap_lock){}-{3:3}:
[ 1318.032778][ T1082]    __lock_acquire+0x14bf/0x2680
[ 1318.033141][ T1082]    lock_acquire+0xcd/0x2c0
[ 1318.033487][ T1082]    __might_fault+0x58/0x80
[ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu]
[ 1318.034181][ T1082]    full_proxy_read+0x55/0x80
[ 1318.034487][ T1082]    vfs_read+0xa7/0x360
[ 1318.034788][ T1082]    ksys_read+0x70/0xf0
[ 1318.035085][ T1082]    do_syscall_64+0x94/0x180
[ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e
[ 1318.035664][ T1082]
[ 1318.035664][ T1082] other info that might help us debug this:
[ 1318.035664][ T1082]
[ 1318.036487][ T1082] Chain exists of:
[ 1318.036487][ T1082]   >mmap_lock --> 
reservation_ww_class_acquire --> reservation_ww_class_mutex

[ 1318.036487][ T1082]
[ 1318.037310][ T1082]  Possible unsafe locking scenario:
[ 1318.037310][ T1082]
[ 1318.037838][ T1082]    CPU0    CPU1
[ 1318.038101][ T1082]        
[ 1318.038350][ T1082]   lock(reservation_ww_class_mutex);
[ 1318.038590][ T1082] lock(reservation_ww_class_acquire);
[ 1318.038839][ T1082] lock(reservation_ww_class_mutex);
[ 1318.039083][ T1082]   rlock(>mmap_lock);
[ 1318.039328][ T1082]
[ 1318.039328][ T1082]  *** DEADLOCK ***
[ 1318.039328][ T1082]
[ 1318.040029][ T1082] 1 lock held by tar/1082:
[ 1318.040259][ T1082]  #0: 98c4c13f55f8 
(reservation_ww_class_mutex){+.+.}-{3:3}, at: 
amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]

[ 1318.040560][ T1082]
[ 1318.040560][ T1082] stack backtrace:
[ 1318.041053][ T1082] CPU: 22 PID: 1082 Comm: tar Not tainted 
6.8.0-rc7-00015-ge0c8221b72c0 #17 
3316c85d50e282c5643b075d1f01a4f6365e39c2
[ 1318.041329][ T1082] Hardware name: Gigabyte Technology Co., Ltd. 
B650 AORUS PRO AX/B650 AORUS PRO AX, BIOS F20 12/14/2023

[ 1318.041614][ T1082] Call Trace:
[ 1318.041895][ T1082]  
[ 1318.042175][ T1082]  dump_stack_lvl+0x4a/0x80
[ 1318.042460][ T1082]  check_noncircular+0x145/0x160
[ 1318.042743][ T1082]  __lock_acquire+0x14bf/0x2680
[ 1318.043022][ T1082]  lock_acquire+0xcd/0x2c0
[ 1318.043301][ T1082]  ? __might_fault+0x40/0x80
[ 1318.043580][ T1082]  ? __might_fault+0x40/0x80
[ 1318.043856][ T1082]  __might_fault+0x58/0x80
[ 1318.044131][ T1082]  ? __might_fault+0x40/0x80
[ 1318.044408][ T1082]  amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu 
8fe2afaa910cbd7654c8cab23563a94d6caebaab]

[ 1318.044749][ T1082]  full_proxy_read+0x55/0x80
[ 1318.045042][ T1082]  vfs_read+0xa7/0x360
[ 1318.045333][ T1082]  ksys_read+0x70/0xf0
[ 1318.045623][ T1082]  do_syscall_64+0x94/0x180
[ 1318.045913][ T1082] 

Re: [PATCH 2/2] drm:amdgpu: add firmware information of all IP's

[Sharma, Shashank]

On 14/03/2024 06:58, Khatri, Sunil wrote:


On 3/14/2024 2:06 AM, Alex Deucher wrote:
On Tue, Mar 12, 2024 at 8:42 AM Sunil Khatri  
wrote:

Add firmware version information of each
IP and each instance where applicable.


Is there a way we can share some common code with devcoredump,
debugfs, and the info IOCTL?  All three places need to query this
information and the same logic is repeated in each case.


Hello Alex,

Yes you re absolutely right the same information is being retrieved 
again as done in debugfs. I can reorganize the code so same function 
could be used by debugfs and devcoredump but this is exactly what i 
tried to avoid here. I did try to use minimum functionality in 
devcoredump without shuffling a lot of code here and there.


Also our devcoredump is implemented in amdgpu_reset.c and not all the 
information is available here and there we might have to include lot 
of header and cross functions in amdgpu_reset until we want a 
dedicated file for devcoredump.



I think Alex is suggesting to have one common backend to generate all 
the core debug info, and then different wrapper functions which can pack 
this raw info into the packets aligned with respective infra like 
devcore/debugfs/info IOCTL, which seems like a good idea to me.


If you think you need a new file for this backend it should be fine.


something like:

amdgpu_debug_core.c::

struct amdgpu_core_debug_info {

/* Superset of all the info you are collecting from HW */

};

- amdgpu_debug_generate_core_info

{

/* This function collects the core debug info from HW and saves in 
amdgpu_core_debug_info,


  we can update this periodically regardless of a request */

}

and then:

devcore_info *amdgpu_debug_pack_for_devcore(core_debug_info)

{

/* convert core debug info into devcore aligned format/data */

}

ioctl_info *amdgpu_debug_pack_for_info_ioctl(core_debug_info)

{

/* convert core debug info into info IOCTL aligned format/data */

}

debugfs_info *amdgpu_debug_pack_for_debugfs(core_debug_info)

{

/* convert core debug info into debugfs aligned format/data */

}

- Shashank





Info IOCTL does have a lot of information which also is in pipeline to 
be dumped but this if we want to reuse the functionality of IOCTL we 
need to reorganize a lot of code.


If that is the need of the hour i could work on that. Please let me know.

This is my suggestion if it makes sense:

1. If we want to reuse a lot of functionality then we need to 
modularize some of the functions further so they could be consumed 
directly by devcoredump.
2. We should also have a dedicated file for devcoredump.c/.h so its 
easy to include headers of needed functionality cleanly and easy to 
expand devcoredump.
3. based on the priority and importance of this task we can add 
information else some repetition is a real possibility.




Alex



Signed-off-by: Sunil Khatri 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 122 
++

  1 file changed, 122 insertions(+)

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

index 611fdb90a1fc..78ddc58aef67 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
@@ -168,6 +168,123 @@ void amdgpu_coredump(struct amdgpu_device 
*adev, bool vram_lost,

  {
  }
  #else
+static void amdgpu_devcoredump_fw_info(struct amdgpu_device *adev, 
struct drm_printer *p)

+{
+   uint32_t version;
+   uint32_t feature;
+   uint8_t smu_program, smu_major, smu_minor, smu_debug;
+
+   drm_printf(p, "VCE feature version: %u, fw version: 0x%08x\n",
+  adev->vce.fb_version, adev->vce.fw_version);
+   drm_printf(p, "UVD feature version: %u, fw version: 0x%08x\n",
+  0, adev->uvd.fw_version);
+   drm_printf(p, "GMC feature version: %u, fw version: 0x%08x\n",
+  0, adev->gmc.fw_version);
+   drm_printf(p, "ME feature version: %u, fw version: 0x%08x\n",
+  adev->gfx.me_feature_version, 
adev->gfx.me_fw_version);

+   drm_printf(p, "PFP feature version: %u, fw version: 0x%08x\n",
+  adev->gfx.pfp_feature_version, 
adev->gfx.pfp_fw_version);

+   drm_printf(p, "CE feature version: %u, fw version: 0x%08x\n",
+  adev->gfx.ce_feature_version, 
adev->gfx.ce_fw_version);

+   drm_printf(p, "RLC feature version: %u, fw version: 0x%08x\n",
+  adev->gfx.rlc_feature_version, 
adev->gfx.rlc_fw_version);

+
+   drm_printf(p, "RLC SRLC feature version: %u, fw version: 
0x%08x\n",

+  adev->gfx.rlc_srlc_feature_version,
+  adev->gfx.rlc_srlc_fw_version);
+   drm_printf(p, "RLC SRLG feature version: %u, fw version: 
0x%08x\n",

+  adev->gfx.rlc_srlg_feature_version,
+  adev->gfx.rlc_srlg_fw_version);
+   drm_printf(p, "RLC SRLS feature version: %u, fw version: 
0x%08x\n",

+  

Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

[Sharma, Shashank]

 ? do_syscall_64+0xa0/0x180
[ 1318.046201][ T1082]  ? lockdep_hardirqs_on+0x7d/0x100
[ 1318.046487][ T1082]  ? do_syscall_64+0xa0/0x180
[ 1318.046773][ T1082]  ? do_syscall_64+0xa0/0x180
[ 1318.047057][ T1082]  ? do_syscall_64+0xa0/0x180
[ 1318.047337][ T1082]  ? do_syscall_64+0xa0/0x180
[ 1318.047611][ T1082]  entry_SYSCALL_64_after_hwframe+0x46/0x4e
[ 1318.047887][ T1082] RIP: 0033:0x7f480b70a39d
[ 1318.048162][ T1082] Code: 91 ba 0d 00 f7 d8 64 89 02 b8 ff ff ff ff eb b2 e8 18 a3 
01 00 0f 1f 84 00 00 00 00 00 80 3d a9 3c 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 
f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 53 48 83
[ 1318.048769][ T1082] RSP: 002b:7ffde77f5c68 EFLAGS: 0246 ORIG_RAX: 

[ 1318.049083][ T1082] RAX: ffda RBX: 0800 RCX: 
7f480b70a39d
[ 1318.049392][ T1082] RDX: 0800 RSI: 55c9f2120c00 RDI: 
0008
[ 1318.049703][ T1082] RBP: 0800 R08: 55c9f2120a94 R09: 
0007
[ 1318.050011][ T1082] R10:  R11: 0246 R12: 
55c9f2120c00
[ 1318.050324][ T1082] R13: 0008 R14: 0008 R15: 
0800
[ 1318.050638][ T1082]  

amdgpu_debugfs_mqd_read() holds a reservation when it calls
put_user(), which may fault and acquire the mmap_sem. This violates
the established locking order.

Bounce the mqd data through a kernel buffer to get put_user() out of
the illegal section.

Fixes: 445d85e3c1df ("drm/amdgpu: add debugfs interface for reading MQDs")
Cc: sta...@vger.kernel.org  [v6.5+]
Signed-off-by: Johannes Weiner 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 46 +++-
  1 file changed, 29 insertions(+), 17 deletions(-)

This fixes the lockdep splat for me, and the hexdump of the output
looks sane after the patch. However, I'm not at all familiar with this
code to say for sure that this is the right solution. The mqd seems
small enough that the kmalloc won't get crazy.

Yeah, MQDs sizes are within range (so far :))

I'm also assuming that
ring->mqd_size is safe to access before the reserve & kmap. Lastly I
went with an open loop instead of a memcpy() as I wasn't sure if that
memory is safe to address a byte at at time.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index 5505d646f43a..06f0a6534a94 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -524,46 +524,58 @@ static ssize_t amdgpu_debugfs_mqd_read(struct file *f, 
char __user *buf,
  {
struct amdgpu_ring *ring = file_inode(f)->i_private;
volatile u32 *mqd;
-   int r;
+   u32 *kbuf;
+   int r, i;
uint32_t value, result;
  
  	if (*pos & 3 || size & 3)

return -EINVAL;
  
-	result = 0;

+   kbuf = kmalloc(ring->mqd_size, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
  
  	r = amdgpu_bo_reserve(ring->mqd_obj, false);

if (unlikely(r != 0))
-   return r;
+   goto err_free;
  
  	r = amdgpu_bo_kmap(ring->mqd_obj, (void **));

-   if (r) {
-   amdgpu_bo_unreserve(ring->mqd_obj);
-   return r;
-   }
+   if (r)
+   goto err_unreserve;
  
+	/*

+* Copy to local buffer to avoid put_user(), which might fault
+* and acquire mmap_sem, under reservation_ww_class_mutex.
+*/
+   for (i = 0; i < ring->mqd_size/sizeof(u32); i++)
+   kbuf[i] = mqd[i];


memcpy is safe to use here.

With that change, please feel free to use: Reviewed-by: Shashank Sharma 



- Shashank


+
+   amdgpu_bo_kunmap(ring->mqd_obj);
+   amdgpu_bo_unreserve(ring->mqd_obj);
+
+   result = 0;
while (size) {
if (*pos >= ring->mqd_size)
-   goto done;
+   break;
  
-		value = mqd[*pos/4];

+   value = kbuf[*pos/4];
r = put_user(value, (uint32_t *)buf);
if (r)
-   goto done;
+   goto err_free;
buf += 4;
result += 4;
size -= 4;
*pos += 4;
}
  
-done:

-   amdgpu_bo_kunmap(ring->mqd_obj);
-   mqd = NULL;
-   amdgpu_bo_unreserve(ring->mqd_obj);
-   if (r)
-   return r;
-
+   kfree(kbuf);
return result;
+
+err_unreserve:
+   amdgpu_bo_unreserve(ring->mqd_obj);
+err_free:
+   kfree(kbuf);
+   return r;
  }
  
  static const struct file_operations amdgpu_debugfs_mqd_fops = {

RE: [PATCH] drm/amdgpu: fix SI failure due to doorbells allocation

[Sharma, Shashank]

[AMD Official Use Only - General]

Reviewed-by: Shashank Sharma 

Regards
Shashank
-Original Message-
From: Icenowy Zheng 
Sent: Sunday, October 8, 2023 8:47 AM
To: Deucher, Alexander ; Koenig, Christian 
; Pan, Xinhui ; David Airlie 
; Daniel Vetter ; Sharma, Shashank 
; Yadav, Arvind 
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; Icenowy Zheng 
Subject: [PATCH] drm/amdgpu: fix SI failure due to doorbells allocation

SI hardware does not have doorbells at all, however currently the code will try 
to do the allocation and thus fail, makes SI AMDGPU not usable.

Fix this failure by skipping doorbells allocation when doorbells count is zero.

Fixes: 54c30d2a8def ("drm/amdgpu: create kernel doorbell pages")
Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
index d0249ada91d30..599aece42017a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
@@ -142,6 +142,10 @@ int amdgpu_doorbell_create_kernel_doorbells(struct 
amdgpu_device *adev)
int r;
int size;

+   /* SI HW does not have doorbells, skip allocation */
+   if (adev->doorbell.num_kernel_doorbells == 0)
+   return 0;
+
/* Reserve first num_kernel_doorbells (page-aligned) for kernel ops */
size = ALIGN(adev->doorbell.num_kernel_doorbells * sizeof(u32), 
PAGE_SIZE);

--
2.39.1

RE: [PATCH v6 1/5] drm/amdgpu: Allocate coredump memory in a nonblocking way

[Sharma, Shashank]

[AMD Official Use Only - General]

Pushed the rest of the patches in the series to amd-staging-drm-next.

Regards
Shashank
-Original Message-
From: Koenig, Christian 
Sent: Monday, September 11, 2023 1:15 PM
To: André Almeida ; dri-devel@lists.freedesktop.org; 
amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Sharma, Shashank 

Cc: kernel-...@igalia.com; Deucher, Alexander ; 
Pelloux-Prayer, Pierre-Eric 
Subject: Re: [PATCH v6 1/5] drm/amdgpu: Allocate coredump memory in a 
nonblocking way

Am 11.09.23 um 05:00 schrieb André Almeida:
> During a GPU reset, a normal memory reclaim could block to reclaim
> memory. Giving that coredump is a best effort mechanism, it shouldn't
> disturb the reset path. Change its memory allocation flag to a
> nonblocking one.

Since it is a bug fix I've already pushed this one into our internal branch 
quite a while ago.

Shashank can you take care of picking up the remaining patches and pushing them 
to amd-staging-drm-next?

Thanks,
Christian.

>
> Signed-off-by: André Almeida 
> Reviewed-by: Christian König 
> ---
> v5: no change
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index aa171db68639..bf4781551f88 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4847,7 +4847,7 @@ static void amdgpu_reset_capture_coredumpm(struct 
> amdgpu_device *adev)
>   struct drm_device *dev = adev_to_drm(adev);
>
>   ktime_get_ts64(>reset_time);
> - dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_KERNEL,
> + dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_NOWAIT,
> amdgpu_devcoredump_read, amdgpu_devcoredump_free);
>   }
>   #endif

RE: [PATCH v6 1/5] drm/amdgpu: Allocate coredump memory in a nonblocking way

[Sharma, Shashank]

[AMD Official Use Only - General]

Hey Christian,

Will do that.

Regards
Shashank

-Original Message-
From: Koenig, Christian 
Sent: Monday, September 11, 2023 1:15 PM
To: André Almeida ; dri-devel@lists.freedesktop.org; 
amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Sharma, Shashank 

Cc: kernel-...@igalia.com; Deucher, Alexander ; 
Pelloux-Prayer, Pierre-Eric 
Subject: Re: [PATCH v6 1/5] drm/amdgpu: Allocate coredump memory in a 
nonblocking way

Am 11.09.23 um 05:00 schrieb André Almeida:
> During a GPU reset, a normal memory reclaim could block to reclaim
> memory. Giving that coredump is a best effort mechanism, it shouldn't
> disturb the reset path. Change its memory allocation flag to a
> nonblocking one.

Since it is a bug fix I've already pushed this one into our internal branch 
quite a while ago.

Shashank can you take care of picking up the remaining patches and pushing them 
to amd-staging-drm-next?

Thanks,
Christian.

>
> Signed-off-by: André Almeida 
> Reviewed-by: Christian König 
> ---
> v5: no change
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index aa171db68639..bf4781551f88 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4847,7 +4847,7 @@ static void amdgpu_reset_capture_coredumpm(struct 
> amdgpu_device *adev)
>   struct drm_device *dev = adev_to_drm(adev);
>
>   ktime_get_ts64(>reset_time);
> - dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_KERNEL,
> + dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_NOWAIT,
> amdgpu_devcoredump_read, amdgpu_devcoredump_free);
>   }
>   #endif

RE: [PATCH 11/20] drm/amd/amdgpu/amdgpu_doorbell_mgr: Correct misdocumented param 'doorbell_index'

[Sharma, Shashank]

[AMD Official Use Only - General]

Reviewed-by: : Shashank Sharma 

Regards
Shashank
-Original Message-
From: Lee Jones 
Sent: Thursday, August 24, 2023 9:37 AM
To: l...@kernel.org
Cc: linux-ker...@vger.kernel.org; Deucher, Alexander 
; Koenig, Christian ; Pan, 
Xinhui ; David Airlie ; Daniel Vetter 
; Sharma, Shashank ; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 11/20] drm/amd/amdgpu/amdgpu_doorbell_mgr: Correct 
misdocumented param 'doorbell_index'

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c:123: warning: Function 
parameter or member 'doorbell_index' not described in 
'amdgpu_doorbell_index_on_bar'
 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c:123: warning: Excess function 
parameter 'db_index' description in 'amdgpu_doorbell_index_on_bar'

Signed-off-by: Lee Jones 
---
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "Pan, Xinhui" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Shashank Sharma 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
index da4be0bbb4466..d0249ada91d30 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
@@ -113,7 +113,7 @@ void amdgpu_mm_wdoorbell64(struct amdgpu_device *adev, u32 
index, u64 v)
  *
  * @adev: amdgpu_device pointer
  * @db_bo: doorbell object's bo
- * @db_index: doorbell relative index in this doorbell object
+ * @doorbell_index: doorbell relative index in this doorbell object
  *
  * returns doorbell's absolute index in BAR
  */
--
2.42.0.rc1.204.g551eb34607-goog

RE: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

[Sharma, Shashank]

[AMD Official Use Only - General]

+ Uday, for awareness. 

Regards
Shashank
-Original Message-
From: Pekka Paalanen 
Sent: 14 February 2023 10:28
To: Melissa Wen 
Cc: Ville Syrjälä ; 
dri-devel@lists.freedesktop.org; airl...@gmail.com; 
laurent.pinchart+rene...@ideasonboard.com; Sharma, Shashank 
; Siqueira, Rodrigo ; 
amd-...@lists.freedesktop.org; Hung, Alex ; Wentland, Harry 
; tzimmerm...@suse.de; Li, Sun peng (Leo) 
; maarten.lankho...@linux.intel.com; mrip...@kernel.org; 
seanp...@chromium.org; dan...@ffwll.ch; Lakha, Bhawanpreet 
; Kim, Sung joon ; 
cont...@emersion.fr; Pan, Xinhui ; Koenig, Christian 
; kernel-...@igalia.com; Deucher, Alexander 
; Kazlauskas, Nicholas 
; Joshua Ashton 
Subject: Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

On Mon, 13 Feb 2023 18:45:40 -0100
Melissa Wen  wrote:

> On 02/13, Ville Syrjälä wrote:
> > On Mon, Feb 13, 2023 at 11:01:31AM +0200, Pekka Paalanen wrote:  
> > > On Fri, 10 Feb 2023 14:47:50 -0500 Harry Wentland 
> > >  wrote:
> > >   
> > > > On 2/10/23 04:28, Pekka Paalanen wrote:  
> > > > > On Thu, 9 Feb 2023 13:27:02 -0100 Melissa Wen 
> > > > >  wrote:
> > > > > 
> > > > >> On 01/31, Pekka Paalanen wrote:
> > > > >>> On Mon, 9 Jan 2023 14:38:09 -0100 Melissa Wen 
> > > > >>>  wrote:
> > > > >>>   
> > > > >>>> On 01/09, Melissa Wen wrote:  
> > > > >>>>> Hi,
> > > > >>>>>
> > > > >>>>> After collecting comments in different places, here is a 
> > > > >>>>> second version of the work on adding DRM CRTC 3D LUT 
> > > > >>>>> support to the current DRM color mgmt interface. In 
> > > > >>>>> comparison to previous proposals [1][2][3], here we add 3D 
> > > > >>>>> LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT, 
> > > > >>>>> that means the following DRM CRTC color correction pipeline:
> > > > >>>>>
> > > > >>>>> Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> 
> > > > >>>>> Gamma 1D LUT  
> > > 
> > > ...
> > >   
> > > > >>> +/*
> > > > >>> + * struct drm_mode_lut3d_mode - 3D LUT mode information.
> > > > >>> + * @lut_size: number of valid points on every dimension of 3D LUT.
> > > > >>> + * @lut_stride: number of points on every dimension of 3D LUT.
> > > > >>> + * @bit_depth: number of bits of RGB. If color_mode defines 
> > > > >>> entries with higher
> > > > >>> + * bit_depth the least significant bits will be 
> > > > >>> truncated.
> > > > >>> + * @color_format: fourcc values, ex. DRM_FORMAT_XRGB16161616 or 
> > > > >>> DRM_FORMAT_XBGR16161616.
> > > > >>> + * @flags: flags for hardware-sepcific features  */ struct 
> > > > >>> +drm_mode_lut3d_mode {
> > > > >>> +   __u16 lut_size;
> > > > >>> +   __u16 lut_stride[3];
> > > > >>> +   __u16 bit_depth;
> > > > >>> +   __u32 color_format;
> > > > >>> +   __u32 flags;
> > > > >>> +};
> > > 
> > > ...
> > >   
> > > > >>> What is "number of bits of RGB"? Input precision? Output precision?
> > > > >>> Integer or floating point?  
> > > > >>
> > > > >> It's the bit depth of the 3D LUT values, the same for every 
> > > > >> channels. In
> > > > >> the AMD case, it's supports 10-bit and 12-bit, for example.
> > > > > 
> > > > > Ok. So e.g. r5g6b5 is not a possible 3D LUT element type on 
> > > > > any hardware ever?
> > > > > 
> > > > 
> > > > I haven't had a chance to go through all patches yet but if this 
> > > > is modeled after Alex Hung's work this should be covered by 
> > > > color_format.
> > > > The idea is that color_format takes a FOURCC value and defines 
> > > > the format of the entries in the 3DLUT blob.
> > > > 
> > > > The bit_depth describes the actual bit depth that the HW supports.
> > > > E.g., color_format could be DRM_FORMAT_XRGB16161616 but HW might 
> > > 

RE: Amdgpu module is references even after unbinding the vtcon

[Sharma, Shashank]

[AMD Official Use Only - General]

I would also highly recommend this to be tested with another compositor (Like 
Weston/Sway etc)

Regards
Shashank
-Original Message-
From: Christian König  
Sent: 26 January 2023 15:12
To: Slivka, Danijel ; Thomas Zimmermann 

Cc: Deucher, Alexander ; dri-devel 
; Sharma, Shashank 
Subject: Re: Amdgpu module is references even after unbinding the vtcon

Hi Danijel,

can you also double check that GDM/X is still capable of acquiring a DMA-buf 
file descriptor for the buffer (e.g. that we have a DMA-buf handle for it while 
they are started).

And that handover from fbdev to GDM/X is flicker free?

Thanks,
Christian.

Am 26.01.23 um 14:44 schrieb Slivka, Danijel:
> [AMD Official Use Only - General]
>
> Hi Christian,
>
> I have tested the proposed patch, the issue is not reproducible and 
> everything else seems to work fine.
>
> BR,
> Danijel
>
>> -Original Message-
>> From: Christian König 
>> Sent: Thursday, January 26, 2023 1:20 PM
>> To: Slivka, Danijel ; Thomas Zimmermann 
>> 
>> Cc: Deucher, Alexander ; dri-devel > de...@lists.freedesktop.org>; Sharma, Shashank 
>> 
>> Subject: Re: Amdgpu module is references even after unbinding the 
>> vtcon
>>
>> Am 26.01.23 um 10:49 schrieb Slivka, Danijel:
>>> [AMD Official Use Only - General]
>>>
>>> Hi Thomas,
>>>
>>> I have checked what you mentioned.
>>> When loading amdgpu we call  drm_client_init() during fbdev setup 
>>> [1], the
>> refcnt for drm_kms_helper increases from 3 -> 4.
>>> When we unbind vtcon, refcnt for drm_kms_helper drops 4 -> 3, but 
>>> the
>> drm_client_release() [2] is not called.
>>> The drm_client_release() is called only when unloading the amdgpu driver.
>>>
>>> Is this expected?
>> Yes, the client can't be released because it is possible that the 
>> vtcon is bound to this fbdev again.
>>
>> Please test the handle work around I've send around internally. At 
>> least for me that approach seems to work.
>>
>> Regards,
>> Christian.
>>
>>> There is a comment for drm_client_release with regards to fbdev :
>>> * This function should only be called from the unregister callback. An 
>>> exception
>>>* is fbdev which cannot free the buffer if userspace has open file 
>>> descriptors.
>>>
>>> Could this be relevant for our use case, although as 
>>> Application/X/GDM are
>> stopped at that point and no fd should be open.
>>> Thank you,
>>> BR,
>>> Danijel
>>>
>>>> -Original Message-
>>>> From: Thomas Zimmermann 
>>>> Sent: Wednesday, January 25, 2023 8:48 PM
>>>> To: Christian König 
>>>> Cc: Deucher, Alexander ; Slivka, Danijel 
>>>> ; dri-devel 
>>>> ; Sharma, Shashank 
>>>> 
>>>> Subject: Re: Amdgpu module is references even after unbinding the 
>>>> vtcon
>>>>
>>>> Hi Christian
>>>>
>>>> Am 24.01.23 um 15:12 schrieb Christian König:
>>>>> Hi Thomas,
>>>>>
>>>>> we ran into a problem with the general fbcon/fbdev implementation 
>>>>> and though that you might have some idea.
>>>>>
>>>>> What happens is the following:
>>>>> 1. We load amdgpu and get our normal fbcon.
>>>>> 2. fbcon allocates a dump BO as backing store for the console.
>>>>> 3. GDM/X/Applications start, new framebuffers are created BOs 
>>>>> imported, exported etc...
>>>>> 4. Somehow X or GDM iterated over all the framebuffer objects the 
>>>>> kernels knows about and export them as DMA-buf.
>>>>> 5. Application/X/GDM are stopped, handles closed, framebuffers 
>>>>> released etc...
>>>>> 6. We unbind vtcon.
>>>>>
>>>>> At this point the amdgpu module usually has a reference count of 0 
>>>>> and can be unloaded, but since GDM/X/Whoever iterated over all the 
>>>>> known framebuffers and exported them as DMA-buf (for whatever 
>>>>> reason
>>>>> idk) we now still have an exported DMA-buf and with it a reference 
>>>>> to the
>> module.
>>>>> Any idea how we could prevent that?
>>>> Here's another stab in the dark.
>>>>
>>>> The big difference between old-style fbdev and the new one is that 
>>>> the old fbdev setup (e.g., radeon) allocates a GEM object and puts 
>>>> together the fbdev data structures from the BO in a fairly hackish 
>>>> way. The new style uses an in-kernel client with a file to allocate 
>>>> the BO via dumb buffers; and holds a reference to the DRM module.
>>>>
>>>> Maybe the reference comes from the in-kernel DRM client itself. [1] 
>>>> Check if the client resources get released [2] when you unbind vtcon.
>>>>
>>>> Best regards
>>>> Thomas
>>>>
>>>> [1]
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_
>>>> cl
>>>> ient.c#L87
>>>> [2]
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_
>>>> cl
>>>> ient.c#L16
>>>> 0
>>>>
>>>>> Thanks,
>>>>> Christian.
>>>> --
>>>> Thomas Zimmermann
>>>> Graphics Driver Developer
>>>> SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, 
>>>> Germany (HRB 36809, AG Nürnberg)
>>>> Geschäftsführer: Ivo Totev

Re: [PATCH] amdgpu: add context creation flags in CS IOCTL

[Sharma, Shashank]

On 8/8/2022 12:59 PM, Christian König wrote:

Am 02.08.22 um 15:55 schrieb Shashank Sharma:

This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
   accomodate this new parameter.

The idea is to pass the workload hints while context creation,


Bad idea.

Please take AMDGPU_CTX_OP_SET_STABLE_PSTATE and 
AMDGPU_CTX_OP_GET_STABLE_PSTATE as blueprint for this and don't add 
extra flags to the context creation.


Regards,
Christian.


Hey Christian,
Noted, let me have a look at AMDGPU_CTX_OP_GET/SET_STABLE_PSTATE 
implementation.


- Shashank





  so
that kernel GPU scheduler can pass this information to GPU FW, which in
turn can adjust the GPU characterstics as per the workload type.

Signed-off-by: Shashank Sharma 
Cc: Alex Deucher 
Cc: Marek Olsak 
Cc: Christian Koenig 
Cc: Amarnath Somalapuram 
---
  amdgpu/amdgpu.h  |  2 ++
  amdgpu/amdgpu_cs.c   |  5 -
  include/drm/amdgpu_drm.h | 10 +-
  3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b118dd48..1ebb46e6 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -874,6 +874,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle 
handle,

   *
   * \param   dev  - \c [in] Device handle. See 
#amdgpu_device_initialize()
   * \param   priority - \c [in] Context creation flags. See 
AMDGPU_CTX_PRIORITY_*

+ * \param   flags    - \c [in] Context flags. See AMDGPU_CTX_FLAGS_*
   * \param   context  - \c [out] GPU Context handle
   *
   * \return   0 on success\n
@@ -884,6 +885,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle 
handle,

  */
  int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
   uint32_t priority,
+ uint32_t flags,
   amdgpu_context_handle *context);
  /**
   * Create GPU execution Context
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index fad484bf..d4723ea5 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -44,12 +44,14 @@ static int 
amdgpu_cs_reset_sem(amdgpu_semaphore_handle sem);

   *
   * \param   dev  - \c [in] Device handle. See 
#amdgpu_device_initialize()
   * \param   priority - \c [in] Context creation flags. See 
AMDGPU_CTX_PRIORITY_*

+ * \param   flags    - \c [in] Context flags. See AMDGPU_CTX_FLAGS_*
   * \param   context  - \c [out] GPU Context handle
   *
   * \return  0 on success otherwise POSIX Error code
  */
  drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
   uint32_t priority,
+ uint32_t flags,
   amdgpu_context_handle *context)
  {
  struct amdgpu_context *gpu_context;
@@ -74,6 +76,7 @@ drm_public int 
amdgpu_cs_ctx_create2(amdgpu_device_handle dev,

  memset(, 0, sizeof(args));
  args.in.op = AMDGPU_CTX_OP_ALLOC_CTX;
  args.in.priority = priority;
+    args.in.flags = flags;
  r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_CTX, , 
sizeof(args));

  if (r)
@@ -97,7 +100,7 @@ error:
  drm_public int amdgpu_cs_ctx_create(amdgpu_device_handle dev,
  amdgpu_context_handle *context)
  {
-    return amdgpu_cs_ctx_create2(dev, AMDGPU_CTX_PRIORITY_NORMAL, 
context);
+    return amdgpu_cs_ctx_create2(dev, AMDGPU_CTX_PRIORITY_NORMAL, 0, 
context);

  }
  /**
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 0cbd1540..d9fb1f20 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -238,10 +238,18 @@ union drm_amdgpu_bo_list {
  #define AMDGPU_CTX_PRIORITY_HIGH    512
  #define AMDGPU_CTX_PRIORITY_VERY_HIGH   1023
+/* GPU context workload hint bitmask */
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_MASK    0xFF
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_NONE    0
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_3D  (1 << 1)
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_VIDEO   (1 << 2)
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_VR  (1 << 3)
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_COMPUTE (1 << 4)
+
  struct drm_amdgpu_ctx_in {
  /** AMDGPU_CTX_OP_* */
  __u32    op;
-    /** For future use, no flags defined so far */
+    /** AMDGPU_CTX_FLAGS_* */
  __u32    flags;
  __u32    ctx_id;
  /** AMDGPU_CTX_PRIORITY_* */

Re: [PATCH] amdgpu: add context creation flags in CS IOCTL

[Sharma, Shashank]

On 8/2/2022 5:58 PM, Michel Dänzer wrote:

On 2022-08-02 15:55, Shashank Sharma wrote:

This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
   accomodate this new parameter.

The idea is to pass the workload hints while context creation, so
that kernel GPU scheduler can pass this information to GPU FW, which in
turn can adjust the GPU characterstics as per the workload type.

Signed-off-by: Shashank Sharma 
Cc: Alex Deucher 
Cc: Marek Olsak 
Cc: Christian Koenig 
Cc: Amarnath Somalapuram 
---
  amdgpu/amdgpu.h  |  2 ++
  amdgpu/amdgpu_cs.c   |  5 -
  include/drm/amdgpu_drm.h | 10 +-


See include/drm/README on how to handle changes to include/drm/*_drm.h .




Also, libdrm changes are now reviewed and merged as GitLab merge requests: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fdrm%2F-%2Fmerge_requestsdata=05%7C01%7Cshashank.sharma%40amd.com%7C50e342a42eac4d4d4fd408da749fd574%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637950527087917031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=qU41z3Hxo0jKMWgehDWLYi7r4x1QDsA%2F2KfOigj9iew%3Dreserved=0



Noted, Thanks.

Regards
Shashank

RE: [PATCH] futex: add missing rtmutex.h include

[Sharma, Shashank]

Acked-by: Shashank Sharma 

Regards
Shashank
-Original Message-
From: dri-devel  On Behalf Of 
Christian König
Sent: Thursday, April 7, 2022 1:46 PM
To: pet...@infradead.org; daniel.vet...@ffwll.ch; 
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: [PATCH] futex: add missing rtmutex.h include

Since this isn't included here any more since the removal of ww_mutex.h from 
seqlock.h which causes a build break.

Signed-off-by: Christian König 
Fixes: 63e8768b2ad9 ("seqlock: drop seqcount_ww_mutex_t")
---
 kernel/futex/futex.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h index 
c264cbeab71c..b5379c0e6d6d 100644
--- a/kernel/futex/futex.h
+++ b/kernel/futex/futex.h
@@ -3,6 +3,7 @@
 #define _FUTEX_H
 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_PREEMPT_RT
--
2.25.1

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/16/2022 10:50 PM, Rob Clark wrote:

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
 wrote:


From: Shashank Sharma 

This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.

V2: Addressed review comments from Christian and Amar
- move the reset information structure to DRM layer
- drop _ctx from struct name
- make pid 32 bit(than 64)
- set flag when VRAM invalid (than valid)
- add process name as well (Amar)

Cc: Alexandar Deucher 
Cc: Christian Koenig 
Cc: Amaranath Somalapuram 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_sysfs.c | 31 +++
  include/drm/drm_sysfs.h | 10 ++
  2 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 430e00b16eec..840994810910 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -409,6 +409,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_sysfs_hotplug_event);

+/**
+ * drm_sysfs_reset_event - generate a DRM uevent to indicate GPU reset
+ * @dev: DRM device
+ * @reset_info: The contextual information about the reset (like PID, flags)
+ *
+ * Send a uevent for the DRM device specified by @dev. This informs
+ * user that a GPU reset has occurred, so that an interested client
+ * can take any recovery or profiling measure.
+ */
+void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event 
*reset_info)
+{
+   unsigned char pid_str[13];
+   unsigned char flags_str[15];
+   unsigned char pname_str[TASK_COMM_LEN + 6];
+   unsigned char reset_str[] = "RESET=1";
+   char *envp[] = { reset_str, pid_str, pname_str, flags_str, NULL };
+
+   if (!reset_info) {
+   DRM_WARN("No reset info, not sending the event\n");
+   return;
+   }
+
+   DRM_DEBUG("generating reset event\n");
+
+   snprintf(pid_str, ARRAY_SIZE(pid_str), "PID=%u", reset_info->pid);
+   snprintf(pname_str, ARRAY_SIZE(pname_str), "NAME=%s", 
reset_info->pname);
+   snprintf(flags_str, ARRAY_SIZE(flags_str), "FLAGS=%u", 
reset_info->flags);
+   kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_reset_event);
+
  /**
   * drm_sysfs_connector_hotplug_event - generate a DRM uevent for any connector
   * change
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 6273cac44e47..5ba11c760619 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -1,16 +1,26 @@
  /* SPDX-License-Identifier: GPL-2.0 */
  #ifndef _DRM_SYSFS_H_
  #define _DRM_SYSFS_H_
+#include 
+
+#define DRM_GPU_RESET_FLAG_VRAM_INVALID (1 << 0)

  struct drm_device;
  struct device;
  struct drm_connector;
  struct drm_property;

+struct drm_reset_event {
+   uint32_t pid;


One side note, unrelated to devcoredump vs this..

AFAIU you probably want to be passing around a `struct pid *`, and
then somehow use pid_vnr() in the context of the process reading the
event to get the numeric pid.  Otherwise things will not do what you
expect if the process triggering the crash is in a different pid
namespace from the compositor.



I am not sure if it is a good idea to add the pid extraction complexity 
in here, it is left upto the driver to extract this information and pass 
it to the work queue. In case of AMDGPU, its extracted from GPU VM. It 
would be then more flexible for the drivers as well.


- Shashank


BR,
-R


+   uint32_t flags;
+   char pname[TASK_COMM_LEN];
+};
+
  int drm_class_device_register(struct device *dev);
  void drm_class_device_unregister(struct device *dev);

  void drm_sysfs_hotplug_event(struct drm_device *dev);
+void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event 
*reset_info);
  void drm_sysfs_connector_hotplug_event(struct drm_connector *connector);
  void drm_sysfs_connector_status_event(struct drm_connector *connector,
   struct drm_property *property);
--
2.32.0

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/10/2022 8:56 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 11:44 AM Sharma, Shashank
 wrote:




On 3/10/2022 8:35 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 11:14 AM Sharma, Shashank
 wrote:




On 3/10/2022 7:33 PM, Abhinav Kumar wrote:



On 3/10/2022 9:40 AM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank
 wrote:




On 3/10/2022 6:10 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank
 wrote:




On 3/10/2022 4:24 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 1:55 AM Christian König
 wrote:




Am 09.03.22 um 19:12 schrieb Rob Clark:

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
 wrote:

From: Shashank Sharma 

This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.

Why invent something new, rather than using the already existing
devcoredump?


Yeah, that's a really valid question.


I don't think we need (or should encourage/allow) something drm
specific when there is already an existing solution used by both
drm
and non-drm drivers.  Userspace should not have to learn to support
yet another mechanism to do the same thing.


Question is how is userspace notified about new available core
dumps?


I haven't looked into it too closely, as the CrOS userspace
crash-reporter already had support for devcoredump, so it "just
worked" out of the box[1].  I believe a udev event is what triggers
the crash-reporter to go read the devcore dump out of sysfs.


I had a quick look at the devcoredump code, and it doesn't look like
that is sending an event to the user, so we still need an event to
indicate a GPU reset.


There definitely is an event to userspace, I suspect somewhere down
the device_add() path?



Let me check that out as well, hope that is not due to a driver-private
event for GPU reset, coz I think I have seen some of those in a few DRM
drivers.



Definitely no driver private event for drm/msm .. I haven't dug
through it all but this is the collector for devcoredump, triggered
somehow via udev.  Most likely from event triggered by device_add()

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromiumos%2Fplatform2%2F%2B%2FHEAD%2Fcrash-reporter%2Fudev_collector.ccdata=04%7C01%7Cshashank.sharma%40amd.com%7C3b5c0e8744234962061d08da02d00248%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637825389694363926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mWI1Z%2B8eMJApePc5ajRipbGUG9Cw9wXf2FCw6NQxVaM%3Dreserved=0



Yes, that is correct. the uevent for devcoredump is from device_add()


Yes, I could confirm in the code that device_add() sends a uevent.

kobject_uevent(>kobj, KOBJ_ADD);

I was trying to map the ChromiumOs's udev event rules with the event
being sent from device_add(), what I could see is there is only one udev
rule for any DRM subsystem events in ChromiumOs's 99-crash-reporter.rules:

ACTION=="change", SUBSYSTEM=="drm", KERNEL=="card0", ENV{ERROR}=="1", \
 RUN+="/sbin/crash_reporter
--udev=KERNEL=card0:SUBSYSTEM=drm:ACTION=change"

Can someone confirm that this is the rule which gets triggered when a
devcoredump is generated ? I could not find an ERROR=1 string in the
env[] while sending this event from dev_add();


I think it is actually this rule:

ACTION=="add", SUBSYSTEM=="devcoredump", \
RUN+="/sbin/crash_reporter
--udev=SUBSYSTEM=devcoredump:ACTION=add:KERNEL_NUMBER=%n"

It is something non-drm specific because it supports devcore dumps
from non drm drivers.  I know at least some of the wifi and remoteproc
drivers use it.



Ah, this seems like a problem for me. I understand it will work for a
reset/recovery app well, but if a DRM client (like a compositor), who
wants to listen only to DRM events (like a GPU reset), wouldn't this
create a lot of noise for it ? Like every time any subsystem produces
this coredump, there will be a change in devcoresump subsystem, and the
client will have to parse the core file, and then will have to decide if
it wants to react to this, or ignore.

Wouldn't a GPU reset event, specific to DRM subsystem server better in
such case ?



So, I suppose there are two different use-cases.. for something like
distro which has generic crash telemetry (ie. when users opt in to
automated crash reporting), and in general for debugging gpu crashes,
you want devcoredump, preferably with plenty of information about gpu
state, etc, so you actually have a chance of debugging problems you
can't necessarily reproduce locally.  Note also that mesa CI has some
limited support for collecting devcore dumps if a 

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/10/2022 8:35 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 11:14 AM Sharma, Shashank
 wrote:




On 3/10/2022 7:33 PM, Abhinav Kumar wrote:



On 3/10/2022 9:40 AM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank
 wrote:




On 3/10/2022 6:10 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank
 wrote:




On 3/10/2022 4:24 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 1:55 AM Christian König
 wrote:




Am 09.03.22 um 19:12 schrieb Rob Clark:

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
 wrote:

From: Shashank Sharma 

This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.

Why invent something new, rather than using the already existing
devcoredump?


Yeah, that's a really valid question.


I don't think we need (or should encourage/allow) something drm
specific when there is already an existing solution used by both
drm
and non-drm drivers.  Userspace should not have to learn to support
yet another mechanism to do the same thing.


Question is how is userspace notified about new available core
dumps?


I haven't looked into it too closely, as the CrOS userspace
crash-reporter already had support for devcoredump, so it "just
worked" out of the box[1].  I believe a udev event is what triggers
the crash-reporter to go read the devcore dump out of sysfs.


I had a quick look at the devcoredump code, and it doesn't look like
that is sending an event to the user, so we still need an event to
indicate a GPU reset.


There definitely is an event to userspace, I suspect somewhere down
the device_add() path?



Let me check that out as well, hope that is not due to a driver-private
event for GPU reset, coz I think I have seen some of those in a few DRM
drivers.



Definitely no driver private event for drm/msm .. I haven't dug
through it all but this is the collector for devcoredump, triggered
somehow via udev.  Most likely from event triggered by device_add()

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromiumos%2Fplatform2%2F%2B%2FHEAD%2Fcrash-reporter%2Fudev_collector.ccdata=04%7C01%7Cshashank.sharma%40amd.com%7Cb4e920f125ae4d7de29708da02cd3112%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637825377562005233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=M4xHPErex4vn7l3lNPgniiMp%2BKb3SpOHQo2QLAndxDQ%3Dreserved=0



Yes, that is correct. the uevent for devcoredump is from device_add()


Yes, I could confirm in the code that device_add() sends a uevent.

kobject_uevent(>kobj, KOBJ_ADD);

I was trying to map the ChromiumOs's udev event rules with the event
being sent from device_add(), what I could see is there is only one udev
rule for any DRM subsystem events in ChromiumOs's 99-crash-reporter.rules:

ACTION=="change", SUBSYSTEM=="drm", KERNEL=="card0", ENV{ERROR}=="1", \
RUN+="/sbin/crash_reporter
--udev=KERNEL=card0:SUBSYSTEM=drm:ACTION=change"

Can someone confirm that this is the rule which gets triggered when a
devcoredump is generated ? I could not find an ERROR=1 string in the
env[] while sending this event from dev_add();


I think it is actually this rule:

ACTION=="add", SUBSYSTEM=="devcoredump", \
   RUN+="/sbin/crash_reporter
--udev=SUBSYSTEM=devcoredump:ACTION=add:KERNEL_NUMBER=%n"

It is something non-drm specific because it supports devcore dumps
from non drm drivers.  I know at least some of the wifi and remoteproc
drivers use it.



Ah, this seems like a problem for me. I understand it will work for a 
reset/recovery app well, but if a DRM client (like a compositor), who 
wants to listen only to DRM events (like a GPU reset), wouldn't this 
create a lot of noise for it ? Like every time any subsystem produces 
this coredump, there will be a change in devcoresump subsystem, and the 
client will have to parse the core file, and then will have to decide if 
it wants to react to this, or ignore.


Wouldn't a GPU reset event, specific to DRM subsystem server better in 
such case ?


- Shashank


BR,
-R

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/10/2022 7:33 PM, Abhinav Kumar wrote:



On 3/10/2022 9:40 AM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank
 wrote:




On 3/10/2022 6:10 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank
 wrote:




On 3/10/2022 4:24 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 1:55 AM Christian König
 wrote:




Am 09.03.22 um 19:12 schrieb Rob Clark:

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
 wrote:

From: Shashank Sharma 

This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.
Why invent something new, rather than using the already existing 
devcoredump?


Yeah, that's a really valid question.


I don't think we need (or should encourage/allow) something drm
specific when there is already an existing solution used by both 
drm

and non-drm drivers.  Userspace should not have to learn to support
yet another mechanism to do the same thing.


Question is how is userspace notified about new available core 
dumps?


I haven't looked into it too closely, as the CrOS userspace
crash-reporter already had support for devcoredump, so it "just
worked" out of the box[1].  I believe a udev event is what triggers
the crash-reporter to go read the devcore dump out of sysfs.


I had a quick look at the devcoredump code, and it doesn't look like
that is sending an event to the user, so we still need an event to
indicate a GPU reset.


There definitely is an event to userspace, I suspect somewhere down
the device_add() path?



Let me check that out as well, hope that is not due to a driver-private
event for GPU reset, coz I think I have seen some of those in a few DRM
drivers.



Definitely no driver private event for drm/msm .. I haven't dug
through it all but this is the collector for devcoredump, triggered
somehow via udev.  Most likely from event triggered by device_add()

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromiumos%2Fplatform2%2F%2B%2FHEAD%2Fcrash-reporter%2Fudev_collector.ccdata=04%7C01%7Cshashank.sharma%40amd.com%7C86146416b717420501fc08da02c4785b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637825340130157925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LncI%2F5mIpeG1Avj2YXLmbZ5f1ONUfpf6TzJZH3%2Fs8%2Fw%3Dreserved=0 



Yes, that is correct. the uevent for devcoredump is from device_add()


Yes, I could confirm in the code that device_add() sends a uevent.

kobject_uevent(>kobj, KOBJ_ADD);

I was trying to map the ChromiumOs's udev event rules with the event 
being sent from device_add(), what I could see is there is only one udev 
rule for any DRM subsystem events in ChromiumOs's 99-crash-reporter.rules:


ACTION=="change", SUBSYSTEM=="drm", KERNEL=="card0", ENV{ERROR}=="1", \
  RUN+="/sbin/crash_reporter 
--udev=KERNEL=card0:SUBSYSTEM=drm:ACTION=change"


Can someone confirm that this is the rule which gets triggered when a 
devcoredump is generated ? I could not find an ERROR=1 string in the 
env[] while sending this event from dev_add();


- Shashank

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fbase%2Fcore.c%23L3340data=04%7C01%7Cshashank.sharma%40amd.com%7C86146416b717420501fc08da02c4785b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637825340130157925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5HyWYZ5ZWYz4mUPWeTW51QFdoY0NlA50Nbj1dAC6os4%3Dreserved=0 





BR,
-R

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/10/2022 6:10 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank
 wrote:




On 3/10/2022 4:24 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 1:55 AM Christian König
 wrote:




Am 09.03.22 um 19:12 schrieb Rob Clark:

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
 wrote:

From: Shashank Sharma 

This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.

Why invent something new, rather than using the already existing devcoredump?


Yeah, that's a really valid question.


I don't think we need (or should encourage/allow) something drm
specific when there is already an existing solution used by both drm
and non-drm drivers.  Userspace should not have to learn to support
yet another mechanism to do the same thing.


Question is how is userspace notified about new available core dumps?


I haven't looked into it too closely, as the CrOS userspace
crash-reporter already had support for devcoredump, so it "just
worked" out of the box[1].  I believe a udev event is what triggers
the crash-reporter to go read the devcore dump out of sysfs.


I had a quick look at the devcoredump code, and it doesn't look like
that is sending an event to the user, so we still need an event to
indicate a GPU reset.


There definitely is an event to userspace, I suspect somewhere down
the device_add() path?



Let me check that out as well, hope that is not due to a driver-private 
event for GPU reset, coz I think I have seen some of those in a few DRM 
drivers.


- Shashank


BR,
-R

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/10/2022 4:24 PM, Rob Clark wrote:

On Thu, Mar 10, 2022 at 1:55 AM Christian König
 wrote:




Am 09.03.22 um 19:12 schrieb Rob Clark:

On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
 wrote:

From: Shashank Sharma 

This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.

Why invent something new, rather than using the already existing devcoredump?


Yeah, that's a really valid question.


I don't think we need (or should encourage/allow) something drm
specific when there is already an existing solution used by both drm
and non-drm drivers.  Userspace should not have to learn to support
yet another mechanism to do the same thing.


Question is how is userspace notified about new available core dumps?


I haven't looked into it too closely, as the CrOS userspace
crash-reporter already had support for devcoredump, so it "just
worked" out of the box[1].  I believe a udev event is what triggers
the crash-reporter to go read the devcore dump out of sysfs.


I had a quick look at the devcoredump code, and it doesn't look like 
that is sending an event to the user, so we still need an event to 
indicate a GPU reset.


- Shashank



BR,
-R

[1] One small change to allow-list the drm/msm devcore dumps was
needed after a privacy review/audit of what is contained in the GPU
devcored to ensure it does not contain any PII .. for CrOS on amd
devices I'd be happy to walk whoever deals with amd CrOS devices
through the process offline.


Regards,
Christian.



BR,
-R

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

[Sharma, Shashank]

On 3/9/2022 8:47 AM, Simon Ser wrote:

Hi,

Maybe it would be a good idea to state the intended use-case in the
commit message? 


It was added in the second patch, but yeah, it makes more sense to add a 
cover-letter probably.


And explain why the current (driver-specific IIRC) APIs

aren't enough?

As you mentioned, we also started with a driver specific API, and then 
realized that most of the drivers can benefit from this infrastructure, 
as most of them would be more or less interested in the similar 
information.



Since this introduces new uAPI, can you point to a user-space patch
which uses the new uAPI? See this link for more info on DRM user-space
requirements:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdri.freedesktop.org%2Fdocs%2Fdrm%2Fgpu%2Fdrm-uapi.html%23open-source-userspace-requirementsdata=04%7C01%7Cshashank.sharma%40amd.com%7C85e8e40c84524f3272e908da01a11b1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637824088716047386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BMTzBIfl3FGHdAv%2BSx%2F83a86x8eksbOhdQVqdrJ2Rq0%3Dreserved=0

The userspace work is in progress, this was to get a general feedback 
from the community and the interest.



Please use drm_dbg_* and drm_warn_* helpers instead of DRM_DEBUG and
DRM_WARN. This allows identifying on which device the uevent happens.


Well, I don't want to break the consistency across the file, as other
functions seems to be using DRM_DEBUG family of prints.

On Tuesday, March 8th, 2022 at 19:04, Shashank Sharma 
 wrote:


+void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event 
*reset_info)


reset_info can be const.

Sure.

- Shashank

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

[Sharma, Shashank]

Hello Brian,
(+Uma in cc)

Thanks for your comments, Let me try to fill-in for Harry to keep the 
design discussion going. Please find my comments inline.


On 8/2/2021 10:00 PM, Brian Starkey wrote:

Hi,

Thanks for having a stab at this, it's a massive complex topic to
solve.

Do you have the the HTML rendered somewhere for convenience?

On Fri, Jul 30, 2021 at 04:41:29PM -0400, Harry Wentland wrote:

Use the new DRM RFC doc section to capture the RFC previously only
described in the cover letter at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F89506%2Fdata=04%7C01%7CShashank.Sharma%40amd.com%7C42a8172c947b41c17a5c08d955d2e859%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637635186605487756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DAoEKo7fl83YPgqFvEGCHF2vyYfILfoLBCCu5Q2Lg88%3Dreserved=0

v3:
  * Add sections on single-plane and multi-plane HDR
  * Describe approach to define HW details vs approach to define SW intentions
  * Link Jeremy Cline's excellent HDR summaries
  * Outline intention behind overly verbose doc
  * Describe FP16 use-case
  * Clean up links

v2: create this doc

v1: n/a

Signed-off-by: Harry Wentland 
---
  Documentation/gpu/rfc/color_intentions.drawio |   1 +
  Documentation/gpu/rfc/color_intentions.svg|   3 +
  Documentation/gpu/rfc/colorpipe   |   1 +
  Documentation/gpu/rfc/colorpipe.svg   |   3 +
  Documentation/gpu/rfc/hdr-wide-gamut.rst  | 580 ++
  Documentation/gpu/rfc/index.rst   |   1 +
  6 files changed, 589 insertions(+)
  create mode 100644 Documentation/gpu/rfc/color_intentions.drawio
  create mode 100644 Documentation/gpu/rfc/color_intentions.svg
  create mode 100644 Documentation/gpu/rfc/colorpipe
  create mode 100644 Documentation/gpu/rfc/colorpipe.svg
  create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst



-- snip --


+
+Mastering Luminances
+
+
+Even though we are able to describe the absolute luminance of a pixel
+using the PQ 2084 EOTF we are presented with physical limitations of the
+display technologies on the market today. Here are a few examples of
+luminance ranges of displays.
+
+.. flat-table::
+   :header-rows: 1
+
+   * - Display
+ - Luminance range in nits
+
+   *  - Typical PC display
+  - 0.3 - 200
+
+   *  - Excellent LCD HDTV
+  - 0.3 - 400
+
+   *  - HDR LCD w/ local dimming
+  - 0.05 - 1,500
+
+Since no display can currently show the full 0.0005 to 10,000 nits
+luminance range of PQ the display will need to tone-map the HDR content,
+i.e to fit the content within a display's capabilities. To assist
+with tone-mapping HDR content is usually accompanied by a metadata
+that describes (among other things) the minimum and maximum mastering
+luminance, i.e. the maximum and minimum luminance of the display that
+was used to master the HDR content.
+
+The HDR metadata is currently defined on the drm_connector via the
+hdr_output_metadata blob property.
+
+It might be useful to define per-plane hdr metadata, as different planes
+might have been mastered differently.


I think this only applies to the approach where all the processing is
decided in the kernel right?

If we directly expose each pipeline stage, and userspace controls
everything, there's no need for the kernel to know the mastering
luminance of any of the input content. The kernel would only need to
know the eventual *output* luminance range, which might not even match
any of the input content!


Yes, you are right. In an approach where a compositor controls 
everything, we might not need this property, as the compositor can 
directly prepare the color correction pipeline with the required 
matrices and kernel can just follow it.


The reason why we introduced this property here is that there may be a 
hardware which implements a fixed function degamma HW unit or tone 
mapping unit, and this property might make it easier for their drivers 
to implement.


So the whole idea was to plan a seed for thoughts for those drivers, and 
see if it makes sense to have such a property.



...


+
+How are we solving the problem?
+===
+
+Single-plane
+
+
+If a single drm_plane is used no further work is required. The compositor
+will provide one HDR plane alongside a drm_connector's hdr_output_metadata
+and the display HW will output this plane without further processing if
+no CRTC LUTs are provided.
+
+If desired a compositor can use the CRTC LUTs for HDR content but without
+support for PWL or multi-segmented LUTs the quality of the operation is
+expected to be subpar for HDR content.
+
+
+Multi-plane
+---
+
+In multi-plane configurations we need to solve the problem of blending
+HDR and SDR content. This blending should be done in linear space and
+therefore requires framebuffer data that is presented in linear space
+or a way to convert 

Re: [PATCH 1/3] drm: Introduce scaling filter mode property

[Sharma, Shashank]

Hello Harry,

Thanks for your comments, please find mine inline.

On 10/22/2019 7:36 PM, Harry Wentland wrote:


On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:

On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:

This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.

This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.

There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 
  include/drm/drm_crtc.h| 26 ++
  include/drm/drm_mode_config.h |  6 ++
  3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+   } else if (property == config->scaling_filter_property) {
+   state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+   else if (property == config->scaling_filter_property)
+   *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
  struct dma_fence;
  struct edid;
  
+enum drm_scaling_filters {

+   DRM_SCALING_FILTER_DEFAULT,
+   DRM_SCALING_FILTER_MEDIUM,
+   DRM_SCALING_FILTER_BILINEAR,
+   DRM_SCALING_FILTER_NN,

Please use real words.


+   DRM_SCALING_FILTER_NN_IS_ONLY,

Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.


+   DRM_SCALING_FILTER_EDGE_ENHANCE,
+   DRM_SCALING_FILTER_INVALID,

That invalid enum value seems entirely pointless.

This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.


FWIW, AMD HW allows us to specify a number of horizontal and vertical
taps for scaling. Number of taps are limited by our linebuffer size. The
default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
if your're running a large horizontal resolution on some ASICs.

I'm not sure it makes sense to define filters here that aren't used. It
sounds like default and nearest neighbour would suffice for now in order
to support integer scaling.


Agree, this seems to be a consistent feedback from the community, I will 
probably start with a smaller set of most popular/used ones.


- Shashank



Harry


+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+   { DRM_SCALING_FILTER_DEFAULT, "Default" },
+   { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+   { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+   { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+   { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+   { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
  static inline int64_t U642I64(uint64_t val)
  {
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
 */
u32 target_vblank;
  
+	/**

+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+   u32 scaling_filter;

We have an enum so should use it. The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.


+
/**
 * @async_flip:
 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
 

Re: [PATCH 1/3] drm: Introduce scaling filter mode property

[Sharma, Shashank]

Hello Mihail,

Thanks for your review, my comments inline.

On 10/22/2019 6:56 PM, Mihail Atanassov wrote:

Hi Shashank,

On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:

This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.

This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.

There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 
  include/drm/drm_crtc.h| 26 ++
  include/drm/drm_mode_config.h |  6 ++
  3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
   return ret;
   } else if (property == config->prop_vrr_enabled) {
   state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
   } else if (property == config->degamma_lut_property) {
   ret = drm_atomic_replace_property_blob_from_id(dev,
   >degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
   else if (property == config->prop_out_fence_ptr)
   *val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
   else if (crtc->funcs->atomic_get_property)
   return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
   else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
  struct dma_fence;
  struct edid;

+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
+ DRM_SCALING_FILTER_NN_IS_ONLY,
+ DRM_SCALING_FILTER_EDGE_ENHANCE,

This one looks to be missing a stringified version below.

Oh yes, it did. Thanks for pointing this out.

  Just wanted
to jump in early and suggest dropping it from the scaling filter enum.
Edge enhancement is orthogonal to the mode used for scaling, at least
on komeda HW, so we wouldn't be able to make the best use of the
property in its current form.
Yes, Ville also suggested similar, I guess we can start with the smaller 
set.



+ DRM_SCALING_FILTER_INVALID,
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
  static inline int64_t U642I64(uint64_t val)
  {
   return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
   u32 target_vblank;

+ /**
+  * @scaling_filter:
+  *
+  * Scaling filter mode to be applied
+  */
+ u32 scaling_filter;
+
   /**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
*/
   struct drm_property *modifiers_property;

+ /**
+  * @scaling_filter_property: CRTC property to apply a particular filter

A scaling filter option can also be useful for scaling individual
planes, do you have any plans to extend the property's applications
in that direction?


Yes, the second stage of development should contain the plane level 
filtering too, but as you know, that would be a complex thing to handle, 
as planes apply filter pre-blending. We need to discus that (in a 
parallel thread :)) how should that look like.


- Shashank




+  * while scaling in panel fitter mode.
+  */
+ struct drm_property *scaling_filter_property;
+
   /* cursor size */
   uint32_t cursor_width, cursor_height;




--
Mihail



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 

Re: [PATCH 1/3] drm: Introduce scaling filter mode property

[Sharma, Shashank]

On 10/22/2019 5:56 PM, Ville Syrjälä wrote:

On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:

This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.

This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.

There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 
  include/drm/drm_crtc.h| 26 ++
  include/drm/drm_mode_config.h |  6 ++
  3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+   } else if (property == config->scaling_filter_property) {
+   state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+   else if (property == config->scaling_filter_property)
+   *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
  struct dma_fence;
  struct edid;
  
+enum drm_scaling_filters {

+   DRM_SCALING_FILTER_DEFAULT,
+   DRM_SCALING_FILTER_MEDIUM,
+   DRM_SCALING_FILTER_BILINEAR,
+   DRM_SCALING_FILTER_NN,
+   DRM_SCALING_FILTER_NN_IS_ONLY,
+   DRM_SCALING_FILTER_EDGE_ENHANCE,
+   DRM_SCALING_FILTER_INVALID,
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+   { DRM_SCALING_FILTER_DEFAULT, "Default" },
+   { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+   { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+   { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+   { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+   { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
  static inline int64_t U642I64(uint64_t val)
  {
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
 */
u32 target_vblank;
  
+	/**

+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+   u32 scaling_filter;
+
/**
 * @async_flip:
 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
 */
struct drm_property *modifiers_property;
  
+	/**

+* @scaling_filter_property: CRTC property to apply a particular filter
+* while scaling in panel fitter mode.
+*/
+   struct drm_property *scaling_filter_property;

This needs to per-crtc/plane.


I am not getting this, why ? It's not different than any other CRTC 
property like gamma/CSC etc, where we just attach them to corresponding 
CRTC, isn't it ?


- Shashank


+
/* cursor size */
uint32_t cursor_width, cursor_height;
  
--

2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: Introduce scaling filter mode property

[Sharma, Shashank]

Hello Ville,

Thanks for the comments, mine inline.


On 10/22/2019 5:50 PM, Ville Syrjälä wrote:

On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:

This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.

This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.

There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 
  include/drm/drm_crtc.h| 26 ++
  include/drm/drm_mode_config.h |  6 ++
  3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+   } else if (property == config->scaling_filter_property) {
+   state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+   else if (property == config->scaling_filter_property)
+   *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
  struct dma_fence;
  struct edid;
  
+enum drm_scaling_filters {

+   DRM_SCALING_FILTER_DEFAULT,
+   DRM_SCALING_FILTER_MEDIUM,
+   DRM_SCALING_FILTER_BILINEAR,
+   DRM_SCALING_FILTER_NN,

Please use real words.
Yes, I saw that coming. It was getting difficult with the 80 char stuff, 
it was even more difficult while using it :). But let me see how better 
can I do here.

+   DRM_SCALING_FILTER_NN_IS_ONLY,

Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.
Agree, that's also one option. I was thinking to make it convenient for 
userspace,  For example if a compositor just want to checkout NN only 
when its beneficial (like old gaming scenarios) but doesn't have enough 
information (or intent), it can leave it to kernel too. But I agree, 
this can cause corner cases. Let's discuss and see if we need it at all, 
as you mentioned.

+   DRM_SCALING_FILTER_EDGE_ENHANCE,
+   DRM_SCALING_FILTER_INVALID,

That invalid enum value seems entirely pointless.

I was thinking about loops and all, but yeah, we can remove it.


This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.

Sure, lets start with smaller set.



+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+   { DRM_SCALING_FILTER_DEFAULT, "Default" },
+   { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+   { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+   { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+   { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+   { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
  static inline int64_t U642I64(uint64_t val)
  {
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
 */
u32 target_vblank;
  
+	/**

+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+   u32 scaling_filter;

We have an enum so should use it.

Got it.

The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.
The comment is actually with the property, Here I think its clear that 
it's for CRTC scaling, as its a part of CRTC state.



+
/**
 * @async_flip:
 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- 

RE: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property

[Sharma, Shashank]

Hey Daniel, 

> -Original Message-
> From: Daniel Vetter  On Behalf Of Daniel Vetter
> Sent: Tuesday, October 22, 2019 3:39 PM
> To: Sharma, Shashank 
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode 
> property
> 
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> > This patch adds a scaling filter mode porperty to allow:
> > - A driver/HW to showcase it's scaling filter capabilities.
> > - A userspace to pick a desired effect while scaling.
> >
> > This option will be particularly useful in the scenarios where Integer
> > mode scaling is possible, and a UI client wants to pick filters like
> > Nearest-neighbor applied for non-blurry outputs.
> >
> > There was a RFC patch series published, to discus the request to
> > enable Integer mode scaling by some of the gaming communities, which
> > can be found here:
> > https://patchwork.freedesktop.org/series/66175/
> >
> > Signed-off-by: Shashank Sharma 
> 
> Two things:
> 
> - needs real property docs for this in the kms property chapter
Got it, 
> - would be good if we could somehow subsume the panel fitter prop into
>   this? Or at least document possible interactions with that.
> 
Sure, let me see what can I do here. 
> Plus userspace ofc, recommended best practices is to add a Link: tag pointing 
> at the
> userspace patch series/merge request directly to the patch that adds the new 
> uapi.
> 

Yep, WIP, will soon drop a link here. 

- Shashank
> Cheers, Daniel
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 
> >  include/drm/drm_crtc.h| 26 ++
> >  include/drm/drm_mode_config.h |  6 ++
> >  3 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 0d466d3b0809..883329453a86 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> > return ret;
> > } else if (property == config->prop_vrr_enabled) {
> > state->vrr_enabled = val;
> > +   } else if (property == config->scaling_filter_property) {
> > +   state->scaling_filter = val;
> > } else if (property == config->degamma_lut_property) {
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >degamma_lut,
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > +   else if (property == config->scaling_filter_property)
> > +   *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property, 
> > val);
> > else
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 5e9b15a0e8c5..94c5509474a8 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -58,6 +58,25 @@ struct device_node;  struct dma_fence;  struct
> > edid;
> >
> > +enum drm_scaling_filters {
> > +   DRM_SCALING_FILTER_DEFAULT,
> > +   DRM_SCALING_FILTER_MEDIUM,
> > +   DRM_SCALING_FILTER_BILINEAR,
> > +   DRM_SCALING_FILTER_NN,
> > +   DRM_SCALING_FILTER_NN_IS_ONLY,
> > +   DRM_SCALING_FILTER_EDGE_ENHANCE,
> > +   DRM_SCALING_FILTER_INVALID,
> > +};
> > +
> > +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> > +   { DRM_SCALING_FILTER_DEFAULT, "Default" },
> > +   { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> > +   { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> > +   { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> > +   { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> > +   { DRM_SCALING_FILTER_INVALID, "Invalid" }, };
> > +
> >  static inline int64_t U642I64(uint64_t val)  {
> > return (int64_t)*((int64_t *));
> > @@ -283,6 +302,13 @@ struct drm_crtc_state {
> >  */
> > u32 target_vblank;
> >
> > +   /**
> > +* @scaling_filter:
> > +*
> > +* Scaling filter mode to be applied
> > +*/
> > +   u32 scaling_filter;
> > +
>

Re: [PATCH v3 3/4] drm/edid: Throw away the dummy VIC 0 cea mode

[Sharma, Shashank]

On 9/25/2019 7:25 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Now that the cea mode handling is not 100% tied to the single
array the dummy VIC 0 mode is pretty much pointles. Throw it
out.

Cc: Hans Verkuil 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 14 +-
  1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9f6996323efa..0007004d3221 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -709,11 +709,9 @@ static const struct minimode extra_modes[] = {
  /*
   * From CEA/CTA-861 spec.
   *
- * Index with VIC.
+ * Index with VIC-1.


Do we want to really do this ? Till now, due to dummy VIC, indexing was 
pretty direct as per VIC, which was making the code easy to read and 
understand. I would still think that keeping the dummy VIC and adjusting 
the size of cea_modes_0[] in the size function, would be something 
neater to do, do you think so ?


- Shashank


   */
-static const struct drm_display_mode edid_cea_modes_0[] = {
-   /* 0 - dummy, VICs start at 1 */
-   { },
+static const struct drm_display_mode edid_cea_modes_1[] = {
/* 1 - 640x480@60Hz 4:3 */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
   752, 800, 0, 480, 490, 492, 525, 0,
@@ -3211,10 +3209,8 @@ static u8 *drm_find_cea_extension(const struct edid 
*edid)
  
  static const struct drm_display_mode *cea_mode_for_vic(u8 vic)

  {
-   if (!vic)
-   return NULL;
-   if (vic < ARRAY_SIZE(edid_cea_modes_0))
-   return _cea_modes_0[vic];
+   if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
+   return _cea_modes_1[vic - 1];
if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
return _cea_modes_193[vic - 193];
return NULL;
@@ -3227,7 +3223,7 @@ static u8 cea_num_vics(void)
  
  static u8 cea_next_vic(u8 vic)

  {
-   if (++vic == ARRAY_SIZE(edid_cea_modes_0))
+   if (++vic == 1 + ARRAY_SIZE(edid_cea_modes_1))
vic = 193;
return vic;
  }

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] drm/edid: Add CTA-861-G modes with VIC >= 193

[Sharma, Shashank]

On 9/25/2019 7:25 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Add a second table to the cea modes with VIC >= 193.

Cc: Hans Verkuil 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 151 -
  1 file changed, 149 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b700fc075257..9f6996323efa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1376,6 +1376,149 @@ static const struct drm_display_mode edid_cea_modes_0[] 
= {
  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
  };
  
+/*

+ * From CEA/CTA-861 spec.
+ *
+ * Index with VIC-193.
+ */
+static const struct drm_display_mode edid_cea_modes_193[] = {

just like previous patch, should we call it edid_cea_861_g_modes ?

+   /* 193 - 5120x2160@120Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 1485000, 5120, 5284,
+  5372, 5500, 0, 2160, 2168, 2178, 2250, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 194 - 7680x4320@24Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
+  10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 195 - 7680x4320@25Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
+  10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 196 - 7680x4320@30Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
+  8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 197 - 7680x4320@48Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
+  10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 198 - 7680x4320@50Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10032,
+  10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 199 - 7680x4320@60Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 8232,
+  8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 200 - 7680x4320@100Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 9792,
+  9968, 10560, 0, 4320, 4336, 4356, 4500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 201 - 7680x4320@120Hz 16:9 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 8032,
+  8208, 8800, 0, 4320, 4336, 4356, 4500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 202 - 7680x4320@24Hz 64:27 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
+  10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 203 - 7680x4320@25Hz 64:27 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
+  10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 204 - 7680x4320@30Hz 64:27 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
+  8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 205 - 7680x4320@48Hz 64:27 */
+   { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
+  10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ 

Re: [PATCH v3 1/4] drm/edid: Abstract away cea_edid_modes[]

[Sharma, Shashank]

Hello Ville,

On 9/25/2019 7:24 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

We're going to need two cea mode tables (on for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to indicathe how it's to be
Should we call it something which indicates the spec version, instead of 
a random '0', like edid_cea_861_F_modes[] and the next one as _G_modes 
or CTA_3 modes ?

indexed.

Cc: Hans Verkuil 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 80 +++---
  1 file changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3c9703b08491..b700fc075257 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -707,12 +707,11 @@ static const struct minimode extra_modes[] = {
  };
  
  /*

- * Probably taken from CEA-861 spec.
- * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
+ * From CEA/CTA-861 spec.
   *
- * Index using the VIC.
+ * Index with VIC.
   */
-static const struct drm_display_mode edid_cea_modes[] = {
+static const struct drm_display_mode edid_cea_modes_0[] = {
/* 0 - dummy, VICs start at 1 */
{ },
/* 1 - 640x480@60Hz 4:3 */
@@ -3067,6 +3066,25 @@ static u8 *drm_find_cea_extension(const struct edid 
*edid)
return cea;
  }
  
+static const struct drm_display_mode *cea_mode_for_vic(u8 vic)

+{
+   if (!vic)
+   return NULL;
+   if (vic < ARRAY_SIZE(edid_cea_modes_0))
+   return _cea_modes_0[vic];
+   return NULL;
+}
+
+static u8 cea_num_vics(void)
+{
+   return ARRAY_SIZE(edid_cea_modes_0);
+}
+
+static u8 cea_next_vic(u8 vic)
+{
+   return vic + 1;
Is there any specific reason for adding a new helper function, just to 
return vic + 1 ?

+}
+
  /*
   * Calculate the alternate clock for the CEA mode
   * (60Hz vs. 59.94Hz etc.)
@@ -3104,14 +3122,14 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 * get the other variants by simply increasing the
 * vertical front porch length.
 */
-   BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
-edid_cea_modes[9].vtotal != 262 ||
-edid_cea_modes[12].vtotal != 262 ||
-edid_cea_modes[13].vtotal != 262 ||
-edid_cea_modes[23].vtotal != 312 ||
-edid_cea_modes[24].vtotal != 312 ||
-edid_cea_modes[27].vtotal != 312 ||
-edid_cea_modes[28].vtotal != 312);
+   BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262 ||
+cea_mode_for_vic(9)->vtotal != 262 ||
+cea_mode_for_vic(12)->vtotal != 262 ||
+cea_mode_for_vic(13)->vtotal != 262 ||
+cea_mode_for_vic(23)->vtotal != 312 ||
+cea_mode_for_vic(24)->vtotal != 312 ||
+cea_mode_for_vic(27)->vtotal != 312 ||
+cea_mode_for_vic(28)->vtotal != 312);
  
  	if (((vic == 8 || vic == 9 ||

  vic == 12 || vic == 13) && mode->vtotal < 263) ||
@@ -3139,10 +3157,16 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
  
-	for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {

-   struct drm_display_mode cea_mode = edid_cea_modes[vic];
+   for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+   const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+   struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
  
+		if (!mode)

+   continue;
+
+   cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3178,10 +3202,16 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
  
-	for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {

-   struct drm_display_mode cea_mode = edid_cea_modes[vic];
+   for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {

Again, why not just vic+=1 :) ?

+   const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+   struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
  
+		if (!mode)

+   continue;
+
+   cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3202,7 +3232,7 @@ EXPORT_SYMBOL(drm_match_cea_mode);
  
  static 

RE: [PATCH v11 3/6] drm: Extend I915 mei interface for transcoder info

[Sharma, Shashank]

Looks good to me,
From display side, Please feel free to use Reviewed-by: Shashank Sharma 


Regards
Shashank
> -Original Message-
> From: Winkler, Tomas
> Sent: Wednesday, August 28, 2019 1:49 PM
> To: C, Ramalingam 
> Cc: intel-gfx ; dri-devel  de...@lists.freedesktop.org>; Sharma, Shashank ;
> Daniel Vetter ; Nikula, Jani 
> Subject: RE: [PATCH v11 3/6] drm: Extend I915 mei interface for transcoder 
> info
> 
> 
> 
> >
> > On 2019-08-28 at 13:28:06 +0530, Winkler, Tomas wrote:
> > > > I915 needs to send the index of the transcoder as per ME FW.
> > > >
> > > > To support this, define enum mei_fw_tc and add as a member into
> > > > the struct hdcp_port_data.
> > > >
> > > > v2:
> > > >   Typo in commit msg is fixed [Shashank]
> > > > v3:
> > > >   kdoc is added for mei_fw_tc [Tomas]
> > > >   s/MEI_TC_x/MEI_TRANSCODER_x
> > > >
> > > > Signed-off-by: Ramalingam C 
> > > > Acked-by: Jani Nikula 
> > >
> > > LGTM, just need to updated the copyright year.
> > Tomas,
> >
> > Copyright year for this i915_mei_hdcp_interface.h is updated in the
> > 1st patch itself.
> 
> Okay.
> >
> > -Ram
> > >
> > > > ---
> > > >  include/drm/i915_mei_hdcp_interface.h | 24
> > 
> > > >  1 file changed, 24 insertions(+)
> > > >
> > > > diff --git a/include/drm/i915_mei_hdcp_interface.h
> > > > b/include/drm/i915_mei_hdcp_interface.h
> > > > index 08670aa650d4..4d48de8890ca 100644
> > > > --- a/include/drm/i915_mei_hdcp_interface.h
> > > > +++ b/include/drm/i915_mei_hdcp_interface.h
> > > > @@ -54,9 +54,32 @@ enum mei_fw_ddi {
> > > > MEI_DDI_RANGE_END = MEI_DDI_A,
> > > >  };
> > > >
> > > > +/**
> > > > + * enum mei_fw_tc - ME Firmware defined index for transcoders
> > > > + * @MEI_INVALID_TRANSCODER: Index for Invalid transcoder
> > > > + * @MEI_TRANSCODER_EDP: Index for EDP Transcoder
> > > > + * @MEI_TRANSCODER_DSI0: Index for DSI0 Transcoder
> > > > + * @MEI_TRANSCODER_DSI1: Index for DSI1 Transcoder
> > > > + * @MEI_TRANSCODER_A: Index for Transcoder A
> > > > + * @MEI_TRANSCODER_B: Index for Transcoder B
> > > > + * @MEI_TRANSCODER_C: Index for Transcoder C
> > > > + * @MEI_TRANSCODER_D: Index for Transcoder D  */ enum mei_fw_tc {
> > > > +   MEI_INVALID_TRANSCODER = 0x00,
> > > > +   MEI_TRANSCODER_EDP,
> > > > +   MEI_TRANSCODER_DSI0,
> > > > +   MEI_TRANSCODER_DSI1,
> > > > +   MEI_TRANSCODER_A = 0x10,
> > > > +   MEI_TRANSCODER_B,
> > > > +   MEI_TRANSCODER_C,
> > > > +   MEI_TRANSCODER_D
> > > > +};
> > > > +
> > > >  /**
> > > >   * struct hdcp_port_data - intel specific HDCP port data
> > > >   * @fw_ddi: ddi index as per ME FW
> > > > + * @fw_tc: transcoder index as per ME FW
> > > >   * @port_type: HDCP port type as per ME FW classification
> > > >   * @protocol: HDCP adaptation as per ME FW
> > > >   * @k: No of streams transmitted on a port. Only on DP MST this
> > > > is != 1 @@ -
> > > > 69,6 +92,7 @@ enum mei_fw_ddi {
> > > >   */
> > > >  struct hdcp_port_data {
> > > > enum mei_fw_ddi fw_ddi;
> > > > +   enum mei_fw_tc fw_tc;
> > > > u8 port_type;
> > > > u8 protocol;
> > > > u16 k;
> > > > --
> > > > 2.20.1
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp

[Sharma, Shashank]

Looks good to me,
From display side, Please feel free to use Reviewed-by: Shashank Sharma 


> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, August 28, 2019 2:28 PM
> To: Winkler, Tomas 
> Cc: intel-gfx ; dri-devel  de...@lists.freedesktop.org>; Sharma, Shashank ;
> Daniel Vetter ; Nikula, Jani 
> Subject: Re: [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into
> intel_hdcp
> 
> On 2019-08-28 at 14:09:01 +0530, Winkler, Tomas wrote:
> > >
> > > On 2019-08-28 at 13:56:06 +0530, Winkler, Tomas wrote:
> > > >
> > > > > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > > > > Hence on every modeset update associated transcoder into the
> > > > > intel_hdcp of the port.
> > > > >
> > > > > v2:
> > > > >   s/trans/cpu_transcoder [Jani]
> > > > > v3:
> > > > >   comment is added for fw_ddi init for gen12+ [Shashank]
> > > > >   only hdcp capable transcoder is translated into fw_tc
> > > > > [Shashank]
> > > > > v4:
> > > > >   fw_tc initialization is kept for modeset. [Tomas]
> > > > >   few extra doc is added at port_data init [Tomas]
> > > > >
> > > > > Signed-off-by: Ramalingam C 
> > > > > Acked-by: Jani Nikula 
> > > > > ---
> > > > >  .../drm/i915/display/intel_display_types.h|  7 +++
> > > > >  drivers/gpu/drm/i915/display/intel_dp.c   |  3 ++
> > > > >  drivers/gpu/drm/i915/display/intel_hdcp.c | 48 
> > > > > ++-
> > > > >  drivers/gpu/drm/i915/display/intel_hdcp.h |  3 ++
> > > > >  drivers/gpu/drm/i915/display/intel_hdmi.c |  3 ++
> > > > >  5 files changed, 63 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index 96514dcc7812..61277a87dbe7 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -388,6 +388,13 @@ struct intel_hdcp {
> > > > >   wait_queue_head_t cp_irq_queue;
> > > > >   atomic_t cp_irq_count;
> > > > >   int cp_irq_count_cached;
> > > > > +
> > > > > + /*
> > > > > +  * HDCP register access for gen12+ need the transcoder 
> > > > > associated.
> > > > > +  * Transcoder attached to the connector could be changed at 
> > > > > modeset.
> > > > > +  * Hence caching the transcoder here.
> > > > > +  */
> > > > > + enum transcoder cpu_transcoder;
> > > > >  };
> > > > >
> > > > >  struct intel_connector {
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 23908da1cd5d..e8471689f785 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct
> > > > > intel_encoder *encoder,
> > > > >
> > > > >   intel_psr_compute_config(intel_dp, pipe_config);
> > > > >
> > > > > + intel_hdcp_transcoder_config(intel_connector,
> > > > > +  pipe_config->cpu_transcoder);
> > > > > +
> > > > >   return 0;
> > > > >  }
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > index e8b04cc8fcb1..988d675f9f69 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > @@ -1764,13 +1764,59 @@ enum mei_fw_ddi
> > > > > intel_get_mei_fw_ddi_index(enum port port)
> > > > >   }
> > > > >  }
> > > > >
> > > > > +static inline
> > > > > +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder) {
> > > > > + switch (cpu_transcoder) {
> > > > > + cas

Re: [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp

[Sharma, Shashank]

Regards

Shashank

On 8/27/2019 10:57 AM, Ramalingam C wrote:

On 2019-08-27 at 10:49:25 +0530, Sharma, Shashank wrote:

Regards

Shashank

On 8/22/2019 8:49 PM, Ramalingam C wrote:

On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.

v2:
s/trans/cpu_transcoder [Jani]

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
   .../drm/i915/display/intel_display_types.h|  7 +++
   drivers/gpu/drm/i915/display/intel_dp.c   |  3 ++
   drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
   drivers/gpu/drm/i915/display/intel_hdcp.h |  3 ++
   drivers/gpu/drm/i915/display/intel_hdmi.c |  3 ++
   5 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+   /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+   enum transcoder cpu_transcoder;

attached_transcoder to be inline with MEI counterpart of the code ?

This is needed so that we can use this to get the offset of register.
Need not be inline with MEI.
:) I meant in the MEI side we are using name "attached_transcoder" so 
using the same in I915 also would be easy to understand. But this is not 
important, I will leave it to you.

   };
   struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_psr_compute_config(intel_dp, pipe_config);
+   intel_hdcp_transcoder_config(intel_connector,
+pipe_config->cpu_transcoder);
+
return 0;
   }
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port 
port)
}
   }
+static inline
+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+   switch (cpu_transcoder) {
+   case TRANSCODER_A ... TRANSCODER_D:
+   return (enum mei_fw_tc)(cpu_transcoder | 0x10);

Again, as this is in context of HDCP, we should not entertain transcoders
below. Or we should move this function in a more generic file like
intel_display.c or intel_ddi.c

This is specific to hdcp. So let it be here. We will fill invalid
TRANSCODER for all non HDCO capable transcoders. Hope that works for
you.

Sure.

+   case TRANSCODER_EDP:
+   return MEI_TC_EDP;
+   case TRANSCODER_DSI_0:
+   return MEI_TC_DSI0;
+   case TRANSCODER_DSI_1:
+   return MEI_TC_DSI1;
+   default:
+   return MEI_INVALID_TRANSCODER;
+   }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   if (!hdcp->shim)
+   return;
+
+   if (INTEL_GEN(dev_priv) >= 12) {

Ah, so this is the gen_check which I was talking about in previous patch :-)

+   mutex_lock(>mutex);
+   hdcp->cpu_transcoder = cpu_transcoder;
+   hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+   mutex_unlock(>mutex);
+   }
+}
+
   static inline int initialize_hdcp_port_data(struct intel_connector 
*connector,
const struct intel_hdcp_shim *shim)
   {
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
+   struct intel_crtc *crtc;
+
+   if (INTEL_GEN(dev_priv) < 12) {
+   data->fw_ddi =
+   intel_get_mei_fw_ddi_index(connector->encoder->port);
+   } else {
+   crtc = to_intel_crtc(connector->base.state->crtc);
+   if (crtc) {
+   hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+   data->fw_tc = intel_get_mei

Re: [PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info

[Sharma, Shashank]

On 8/27/2019 10:47 AM, Ramalingam C wrote:

On 2019-08-27 at 10:42:33 +0530, Sharma, Shashank wrote:

Regards

Shashank

On 8/22/2019 8:49 PM, Ramalingam C wrote:

For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.

This change fills the payload for ME FW from hdcp_port_data.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
   drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
   drivers/misc/mei/hdcp/mei_hdcp.h |  4 +++-
   2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3638c77eba26..93027fd96c71 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
session_init_in.port.integrated_port_type = data->port_type;
session_init_in.port.physical_port = (u8)data->fw_ddi;

As this entry is only valid till GEN11.5, don't we need GEN_CHECK here, say
(INTEL_GEN() < 12). Is that possible in MEI_FW ?

Shashank,

Not needed, as I915 checks the GEN# while loading the transcoder detail
into hdcp_port_data. So here we can assign whatever passed as part of
hdcp_port_data.

-Ram


Yep, just saw this in the next patch,

Please feel free to use: Reviewed-by: Shashank Sharma 




If not, probably we have to add this gen_check while filling the fw_tc part
in I915.

Applies for all the changes below too.

- Shashank


+   session_init_in.port.attached_transcoder = (u8)data->fw_tc;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
verify_rxcert_in.port.integrated_port_type = data->port_type;
verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
+   verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
send_hprime_in.port.integrated_port_type = data->port_type;
send_hprime_in.port.physical_port = (u8)data->fw_ddi;
+   send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
   HDCP_2_2_H_PRIME_LEN);
@@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
pairing_info_in.port.integrated_port_type = data->port_type;
pairing_info_in.port.physical_port = (u8)data->fw_ddi;
+   pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
   HDCP_2_2_E_KH_KM_LEN);
@@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.port.integrated_port_type = data->port_type;
lc_init_in.port.physical_port = (u8)data->fw_ddi;
+   lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct 
hdcp_port_data *data,
verify_lprime_in.port.integrated_port_type = data->port_type;
verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
+   verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
   HDCP_2_2_L_PRIME_LEN);
@@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
get_skey_in.port.integrated_port_type = data->port_type;
get_skey_in.port.physical_port = (u8)data->fw_ddi;
+   get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
if (byte < 0) {
@@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
verify_repeater_in.port.integrated_port_type = data->port_type;
verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
+   verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
   HDCP_2_2_RXINFO_LEN);
@@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
verify_mprime_in.port.integrated_port_type = data->port_type;
verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
+   verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
   HDCP_2_2_MPRIME_LEN);
@@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device 
*dev,
enable

Re: [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp

[Sharma, Shashank]

Regards

Shashank

On 8/22/2019 8:49 PM, Ramalingam C wrote:

On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.

v2:
   s/trans/cpu_transcoder [Jani]

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
  .../drm/i915/display/intel_display_types.h|  7 +++
  drivers/gpu/drm/i915/display/intel_dp.c   |  3 ++
  drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
  drivers/gpu/drm/i915/display/intel_hdcp.h |  3 ++
  drivers/gpu/drm/i915/display/intel_hdmi.c |  3 ++
  5 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+   /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+   enum transcoder cpu_transcoder;

attached_transcoder to be inline with MEI counterpart of the code ?

  };
  
  struct intel_connector {

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
  
  	intel_psr_compute_config(intel_dp, pipe_config);
  
+	intel_hdcp_transcoder_config(intel_connector,

+pipe_config->cpu_transcoder);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c

index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port 
port)
}
  }
  
+static inline

+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+   switch (cpu_transcoder) {
+   case TRANSCODER_A ... TRANSCODER_D:
+   return (enum mei_fw_tc)(cpu_transcoder | 0x10);
Again, as this is in context of HDCP, we should not entertain 
transcoders below. Or we should move this function in a more generic 
file like intel_display.c or intel_ddi.c

+   case TRANSCODER_EDP:
+   return MEI_TC_EDP;
+   case TRANSCODER_DSI_0:
+   return MEI_TC_DSI0;
+   case TRANSCODER_DSI_1:
+   return MEI_TC_DSI1;
+   default:
+   return MEI_INVALID_TRANSCODER;
+   }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+
+   if (!hdcp->shim)
+   return;
+
+   if (INTEL_GEN(dev_priv) >= 12) {

Ah, so this is the gen_check which I was talking about in previous patch :-)

+   mutex_lock(>mutex);
+   hdcp->cpu_transcoder = cpu_transcoder;
+   hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+   mutex_unlock(>mutex);
+   }
+}
+
  static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
  {
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
+   struct intel_crtc *crtc;
+
+   if (INTEL_GEN(dev_priv) < 12) {
+   data->fw_ddi =
+   intel_get_mei_fw_ddi_index(connector->encoder->port);
+   } else {
+   crtc = to_intel_crtc(connector->base.state->crtc);
+   if (crtc) {
+   hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+   data->fw_tc = intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+   }
+   data->fw_ddi = intel_get_mei_fw_ddi_index(PORT_NONE);


I dint understand this, why PORT_NONE ?

- Shashank


+   }
  
-	data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);

data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
  
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h b/drivers/gpu/drm/i915/display/intel_hdcp.h

index 59a2b40405cc..41c1053d9e38 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -16,10 +16,13 @@ struct 

Re: [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info

[Sharma, Shashank]

On 8/22/2019 8:49 PM, Ramalingam C wrote:

I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
  include/drm/i915_mei_hdcp_interface.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/include/drm/i915_mei_hdcp_interface.h 
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
  };
  
+enum mei_fw_tc {

+   MEI_INVALID_TRANSCODER = 0x00,  /* Invalid transcoder type */
+   MEI_TC_EDP, /* Transcoder for eDP */
+   MEI_TC_DSI0,/* Transcoder for DSI0 */
+   MEI_TC_DSI1,/* Transcoder for DSI1 */
Also, this is a bit odd, coz ports above can't do HDCP, so it doesn't 
make sense to have them here. But seems like we want to be in sync with 
MEI FW definitions, so we should change the function


intel_get_mei_fw_ddi_index to accept only from ports A to D, not above 
or below.


- Shashank


+   MEI_TC_A = 0x10,/* Transcoder TCA */
+   MEI_TC_B,   /* Transcoder TCB */
+   MEI_TC_C,   /* Transcoder TCC */
+   MEI_TC_D/* Transcoder TCD */
+};
+
  /**
   * struct hdcp_port_data - intel specific HDCP port data
   * @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
   * @port_type: HDCP port type as per ME FW classification
   * @protocol: HDCP adaptation as per ME FW
   * @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
   */
  struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+   enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info

[Sharma, Shashank]

On 8/22/2019 8:49 PM, Ramalingam C wrote:

I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.


The commit message says you are defining enum mei_fw_ddi, but you are 
actually defining enum mei_fw_tc;


- Shashank


Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
  include/drm/i915_mei_hdcp_interface.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/include/drm/i915_mei_hdcp_interface.h 
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
  };
  
+enum mei_fw_tc {

+   MEI_INVALID_TRANSCODER = 0x00,  /* Invalid transcoder type */
+   MEI_TC_EDP, /* Transcoder for eDP */
+   MEI_TC_DSI0,/* Transcoder for DSI0 */
+   MEI_TC_DSI1,/* Transcoder for DSI1 */
+   MEI_TC_A = 0x10,/* Transcoder TCA */
+   MEI_TC_B,   /* Transcoder TCB */
+   MEI_TC_C,   /* Transcoder TCC */
+   MEI_TC_D/* Transcoder TCD */
+};
+
  /**
   * struct hdcp_port_data - intel specific HDCP port data
   * @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
   * @port_type: HDCP port type as per ME FW classification
   * @protocol: HDCP adaptation as per ME FW
   * @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
   */
  struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+   enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW

[Sharma, Shashank]

Regards

Shashank

On 8/27/2019 10:03 AM, Ramalingam C wrote:

On 2019-08-27 at 09:54:18 +0530, Sharma, Shashank wrote:

Hello Ram,

On 8/22/2019 8:48 PM, Ramalingam C wrote:

I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.

Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
   drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
   drivers/misc/mei/hdcp/mei_hdcp.c  | 34 ---
   drivers/misc/mei/hdcp/mei_hdcp.h  | 12 
   include/drm/i915_mei_hdcp_interface.h | 16 +--
   4 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops 
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
   };
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+   switch (port) {
+   case PORT_A:
+   return MEI_DDI_A;
+   case PORT_B ... PORT_F:
+   return (enum mei_fw_ddi)port;
+   default:
+   return MEI_DDI_INVALID_PORT;
+   }
+}
+
   static inline int initialize_hdcp_port_data(struct intel_connector 
*connector,
const struct intel_hdcp_shim *shim)
   {
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
-   data->port = connector->encoder->port;
+   data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
   #include "mei_hdcp.h"
-static inline u8 mei_get_ddi_index(enum port port)
-{
-   switch (port) {
-   case PORT_A:
-   return MEI_DDI_A;
-   case PORT_B ... PORT_F:
-   return (u8)port;
-   default:
-   return MEI_DDI_INVALID_PORT;
-   }
-}
-
   /**
* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
session_init_in.port.integrated_port_type = data->port_type;
-   session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
verify_rxcert_in.port.integrated_port_type = data->port_type;
-   verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+   verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
-   send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+   send_hprime_in.port.physical_port = (u8)data->fw_ddi;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
   HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
pairing_info_in.port.integrated_port_type = data->port_type;
-   pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+   pairing_info_in.port.physical_port = (u8)data->fw_ddi;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
   HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
lc_init_in.port.integrated_port_type = data->port_type;
-   lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   lc_init_in.port.physical_port = (u8)data->fw_ddi;
byte = mei_cldev_send(cldev, (u8 *)_

Re: [PATCH v9 2/6] drm: Move port definition back to i915 header

[Sharma, Shashank]

tern struct resource intel_graphics_stolen_res;
  #define INTEL_GEN11_BSM_DW1   0xc4
  #define   INTEL_BSM_MASK  (-(1u << 20))
  
-enum port {

-   PORT_NONE = -1,
-
-   PORT_A = 0,
-   PORT_B,
-   PORT_C,
-   PORT_D,
-   PORT_E,
-   PORT_F,
-   PORT_G,
-   PORT_H,
-   PORT_I,
-
-   I915_MAX_PORTS
-};
-
-#define port_name(p) ((p) + 'A')
-
  #endif/* _I915_DRM_H_ */


Otherwise patch looks good to me.

With(or without) above mentioned suggestion, Feel free to use: 
Reviewed-by: Shashank Sharma 


- Shashank

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW

[Sharma, Shashank]

Hello Ram,

On 8/22/2019 8:48 PM, Ramalingam C wrote:

I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.

Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.

Signed-off-by: Ramalingam C 
Acked-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
  drivers/misc/mei/hdcp/mei_hdcp.c  | 34 ---
  drivers/misc/mei/hdcp/mei_hdcp.h  | 12 
  include/drm/i915_mei_hdcp_interface.h | 16 +--
  4 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops 
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
  };
  
+static inline

+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+   switch (port) {
+   case PORT_A:
+   return MEI_DDI_A;
+   case PORT_B ... PORT_F:
+   return (enum mei_fw_ddi)port;
+   default:
+   return MEI_DDI_INVALID_PORT;
+   }
+}
+
  static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
  {
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
  
-	data->port = connector->encoder->port;

+   data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
  
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c

index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
  
  #include "mei_hdcp.h"
  
-static inline u8 mei_get_ddi_index(enum port port)

-{
-   switch (port) {
-   case PORT_A:
-   return MEI_DDI_A;
-   case PORT_B ... PORT_F:
-   return (u8)port;
-   default:
-   return MEI_DDI_INVALID_PORT;
-   }
-}
-
  /**
   * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
   * @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
  
  	session_init_in.port.integrated_port_type = data->port_type;

-   session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
  
  	byte = mei_cldev_send(cldev, (u8 *)_init_in,

@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
  
  	verify_rxcert_in.port.integrated_port_type = data->port_type;

-   verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+   verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
  
  	verify_rxcert_in.cert_rx = rx_cert->cert_rx;

memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
  
  	send_hprime_in.port.integrated_port_type = data->port_type;

-   send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+   send_hprime_in.port.physical_port = (u8)data->fw_ddi;
  
  	memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,

   HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
  
  	pairing_info_in.port.integrated_port_type = data->port_type;

-   pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+   pairing_info_in.port.physical_port = (u8)data->fw_ddi;
  
  	memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,

   HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
  
  	lc_init_in.port.integrated_port_type = data->port_type;

-   lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   lc_init_in.port.physical_port = (u8)data->fw_ddi;
  
  	byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));

if (byte < 0) {
@@ -378,7 +366,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct 
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
  
  	

RE: [PATCH v10 6/6] drm/hdcp: reference for srm file format

[Sharma, Shashank]

Hi Ram, 
Just a minor nitpick. 

Regards
Shashank
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> Ramalingam C
> Sent: Friday, July 12, 2019 12:30 PM
> To: intel-gfx ; dri-devel  de...@lists.freedesktop.org>; Pekka Paalanen ; Daniel
> Vetter 
> Subject: [PATCH v10 6/6] drm/hdcp: reference for srm file format
> 
> In the kernel documentation, HDCP specifications links are shared as a 
> reference for
> SRM table format.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_hdcp.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c index
> 77433ee3d652..803bf8283b83 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -271,6 +271,13 @@ static void drm_hdcp_request_srm(struct drm_device
> *drm_dev)
>   *
>   * SRM should be presented in the name of "display_hdcp_srm.bin".
>   *
> + * Format of the SRM table that userspace needs to write into the
> + binary file
> + * is defined at
I would just prefer addition of 2 ',' and a ':', something like:
Format of the SRM table, that the userspace needs to write into the binary 
file, is defined at:

With this change, please feel free to use:
Reviewed-by: Shashank Sharma 

> + * 1. Renewability chapter on 55th page of HDCP 1.4 specification
> + *
> + https://www.digital-cp.com/sites/default/files/specifications/HDCP%20S
> + pecification%20Rev1_4_Secure.pdf
> + * 2. Renewability chapter on 63rd page of HDCP 2.2 specification
> + *
> + https://www.digital-cp.com/sites/default/files/specifications/HDCP%20o
> + n%20HDMI%20Specification%20Rev2_2_Final1.pdf
> + *
>   * Returns:
>   * TRUE on any of the KSV is revoked, else FALSE.
>   */
> --
> 2.19.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/5] drm/edid: Abstract away cea_edid_modes[]

[Sharma, Shashank]

Hi Ville,

On 7/11/2019 4:02 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

We're going to need two cea mode tables (on for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to indicathe how it's to be
indexed.


I am not very sure if its a good idea to split into two different 
tables, or adding multiple dummy placeholder modes (like VIC 0) for the 
modes not available. It could give us continuity and we can keep on 
using almost the same functions. We can just add some checks for range 
between VIC 128 - 193. Just a thought.


- Shashank


Cc: Hans Verkuil 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 80 +++---
  1 file changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcd9ed569d64..703d2bc26fd9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -707,12 +707,11 @@ static const struct minimode extra_modes[] = {
  };
  
  /*

- * Probably taken from CEA-861 spec.
- * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
+ * From CEA/CTA-861 spec.
   *
- * Index using the VIC.
+ * Index with VIC.
   */
-static const struct drm_display_mode edid_cea_modes[] = {
+static const struct drm_display_mode edid_cea_modes_0[] = {
/* 0 - dummy, VICs start at 1 */
{ },
/* 1 - 640x480@60Hz 4:3 */
@@ -3067,6 +3066,25 @@ static u8 *drm_find_cea_extension(const struct edid 
*edid)
return cea;
  }
  
+static const struct drm_display_mode *cea_mode_for_vic(u8 vic)

+{
+   if (!vic)
+   return NULL;
+   if (vic < ARRAY_SIZE(edid_cea_modes_0))
+   return _cea_modes_0[vic];
+   return NULL;
+}
+
+static u8 cea_num_vics(void)
+{
+   return ARRAY_SIZE(edid_cea_modes_0);
+}
+
+static u8 cea_next_vic(u8 vic)
+{
+   return vic + 1;
+}
+
  /*
   * Calculate the alternate clock for the CEA mode
   * (60Hz vs. 59.94Hz etc.)
@@ -3104,14 +3122,14 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 * get the other variants by simply increasing the
 * vertical front porch length.
 */
-   BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
-edid_cea_modes[9].vtotal != 262 ||
-edid_cea_modes[12].vtotal != 262 ||
-edid_cea_modes[13].vtotal != 262 ||
-edid_cea_modes[23].vtotal != 312 ||
-edid_cea_modes[24].vtotal != 312 ||
-edid_cea_modes[27].vtotal != 312 ||
-edid_cea_modes[28].vtotal != 312);
+   BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262 ||
+cea_mode_for_vic(9)->vtotal != 262 ||
+cea_mode_for_vic(12)->vtotal != 262 ||
+cea_mode_for_vic(13)->vtotal != 262 ||
+cea_mode_for_vic(23)->vtotal != 312 ||
+cea_mode_for_vic(24)->vtotal != 312 ||
+cea_mode_for_vic(27)->vtotal != 312 ||
+cea_mode_for_vic(28)->vtotal != 312);
  
  	if (((vic == 8 || vic == 9 ||

  vic == 12 || vic == 13) && mode->vtotal < 263) ||
@@ -3139,10 +3157,16 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
  
-	for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {

-   struct drm_display_mode cea_mode = edid_cea_modes[vic];
+   for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+   const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+   struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
  
+		if (!mode)

+   continue;
+
+   cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3178,10 +3202,16 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
  
-	for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {

-   struct drm_display_mode cea_mode = edid_cea_modes[vic];
+   for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+   const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+   struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
  
+		if (!mode)

+   continue;
+
+   cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3202,7 +3232,7 @@ 

Re: [PATCH v2 1/5] drm/edid: Add CTA-861-G modes with VIC < 128

[Sharma, Shashank]

40, 4016,
+  4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 121 - 5120x2160@24Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 396000, 5120, 7116,
+  7204, 7500, 0, 2160, 2168, 2178, 2200, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 122 - 5120x2160@25Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 396000, 5120, 6816,
+  6904, 7200, 0, 2160, 2168, 2178, 2200, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 123 - 5120x2160@30Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 396000, 5120, 5784,
+  5872, 6000, 0, 2160, 2168, 2178, 2200, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 124 - 5120x2160@48Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 742500, 5120, 5866,
+  5954, 6250, 0, 2160, 2168, 2178, 2475, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 125 - 5120x2160@50Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 742500, 5120, 6216,
+  6304, 6600, 0, 2160, 2168, 2178, 2250, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 126 - 5120x2160@60Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 742500, 5120, 5284,
+  5372, 5500, 0, 2160, 2168, 2178, 2250, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 127 - 5120x2160@100Hz 64:27 */
+   { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 1485000, 5120, 6216,
+  6304, 6600, 0, 2160, 2168, 2178, 2250, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
  };


Cross checked all timings with CEA-861-G spec. Feel free to use:

Reviewed-by: Shashank Sharma 

- Shashank

  
  /*

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v3 6/7] drm: Add Client Cap for advance gamma mode

[Sharma, Shashank]

On 4/15/2019 7:42 PM, Lankhorst, Maarten wrote:

mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank:

-Original Message-
From: Lankhorst, Maarten
Sent: Monday, April 15, 2019 4:28 PM
To: Shankar, Uma ; intel-gfx@lists.freedeskt
op.org; dri-
de...@lists.freedesktop.org
Cc: Syrjala, Ville ; emil.l.velikov@gmail.
com;
s...@ravnborg.org; Roper, Matthew D ;
seanp...@chromium.org; brian.star...@arm.com; dcasta...@chromium.or
g;
Sharma, Shashank 
Subject: Re: [v3 6/7] drm: Add Client Cap for advance gamma mode

fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar:

Introduced a client cap for advance cap mode
capability. Userspace should set this to get
to be able to use the new gamma_mode property.

If this is not set, driver will work in legacy
mode.

Suggested-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 

Nack, this doesn't seem like a sensible idea. We already guard it
behind the gamma mode property. Userspace shouldn't set the gamma
mode
to a value it doesn't understand.

~Maarten

Hey Maarten,
In that case, what do you suggest should be the right way to do this
?

@Ville, any comments here ?


I would say drop this patch, and just enable segmented gamma
unconditionally, it's not the first property that can cause trouble
when not understood.


Honestly, I kindof like this simple approach suggestion, which makes the 
property focused, and easy to use. But one of the benefits I see for 
this new gamma mode property was, that we can handle other advanced 
gamma modes like 10/12/split and multi-segmented gamma modes too, using 
this. So even though the single property is easy to use, but if we try 
to cover each of the gamma modes per single property, it might get 
confusing to see 4 different gamma mode properties, and how to set one 
of this.


Another problem I see is, the precision and no of entries in the LUT, 
for multi-segment gamma is different than traditional gamma, and we 
might break some (most ?) of the old userspaces. Do you think is there 
any way in which we can avoid this ?


- Shashank


~Maarten

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v3 6/7] drm: Add Client Cap for advance gamma mode

[Sharma, Shashank]

> -Original Message-
> From: Lankhorst, Maarten
> Sent: Monday, April 15, 2019 4:28 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
> dri-
> de...@lists.freedesktop.org
> Cc: Syrjala, Ville ; emil.l.veli...@gmail.com;
> s...@ravnborg.org; Roper, Matthew D ;
> seanp...@chromium.org; brian.star...@arm.com; dcasta...@chromium.org;
> Sharma, Shashank 
> Subject: Re: [v3 6/7] drm: Add Client Cap for advance gamma mode
> 
> fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar:
> > Introduced a client cap for advance cap mode
> > capability. Userspace should set this to get
> > to be able to use the new gamma_mode property.
> >
> > If this is not set, driver will work in legacy
> > mode.
> >
> > Suggested-by: Ville Syrjälä 
> > Signed-off-by: Uma Shankar 
> 
> Nack, this doesn't seem like a sensible idea. We already guard it
> behind the gamma mode property. Userspace shouldn't set the gamma mode
> to a value it doesn't understand.
> 
> ~Maarten

Hey Maarten, 
In that case, what do you suggest should be the right way to do this ? 

@Ville, any comments here ? 

Regards
Shashank
> 
> >  drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> >  drivers/gpu/drm/drm_ioctl.c   | 5 +
> >  include/drm/drm_atomic.h  | 1 +
> >  include/drm/drm_crtc.h| 7 +++
> >  include/drm/drm_file.h| 8 
> >  include/uapi/drm/drm.h| 2 ++
> >  6 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index d85e0c9..590c87a 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -974,6 +974,8 @@ int drm_atomic_set_property(struct
> > drm_atomic_state *state,
> > break;
> > }
> >
> > +   crtc_state->advance_gamma_mode_active =
> > +   state-
> > >advance_gamma_mode_active;
> > ret = drm_atomic_crtc_set_property(crtc,
> > crtc_state, prop, prop_value);
> > break;
> > @@ -1297,6 +1299,7 @@ int drm_mode_atomic_ioctl(struct drm_device
> > *dev,
> > drm_modeset_acquire_init(,
> > DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > state->acquire_ctx = 
> > state->allow_modeset = !!(arg->flags &
> > DRM_MODE_ATOMIC_ALLOW_MODESET);
> > +   state->advance_gamma_mode_active = file_priv-
> > >advance_gamma_mode_active;
> >
> >  retry:
> > copied_objs = 0;
> > diff --git a/drivers/gpu/drm/drm_ioctl.c
> > b/drivers/gpu/drm/drm_ioctl.c
> > index d337f16..e593a4c 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -348,6 +348,11 @@ static int drm_getcap(struct drm_device *dev,
> > void *data, struct drm_file *file_
> > return -EINVAL;
> > file_priv->writeback_connectors = req->value;
> > break;
> > +   case DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES:
> > +   if (req->value > 1)
> > +   return -EINVAL;
> > +   file_priv->advance_gamma_mode_active = req->value;
> > +   break;
> > default:
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index 824a5ed..02c1a68 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -338,6 +338,7 @@ struct drm_atomic_state {
> >  * states.
> >  */
> > bool duplicated : 1;
> > +   bool advance_gamma_mode_active : 1;
> > struct __drm_planes_state *planes;
> > struct __drm_crtcs_state *crtcs;
> > int num_connector;
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index f789359..f11dc25 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -170,6 +170,11 @@ struct drm_crtc_state {
> > bool color_mgmt_changed : 1;
> >
> > /**
> > +* This is to indicate advance gamma mode support
> > +*/
> > +   bool advance_gamma_mode_active : 1;
> > +
> > +   /**
> >  * @no_vblank:
> >  *
> >  * Reflects the ability of a CRTC to send VBLANK events.
> > This state
> > @@ -952,6 +957,8 @@ struct drm_crtc {
> >  */
> > bool enabled;
> >
> > +   bool advance_gamma_mode_active : 1;
> > +
> > /**
> >  * @mode:
> > 

Re: [v7 0/9] Add HDR Metadata Parsing and handling in DRM layer

[Sharma, Shashank]

Hello Uma,

V7 looks good to me, please feel free to use for the whole series:

Reviewed-by: Shashank Sharma 

Regards

Shashank

On 4/3/2019 1:50 AM, Uma Shankar wrote:

This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after blending)
metadata from user space compositors to driver.

Dynamic Range and Mastering infoframe creation and sending.

ToDo:
1. We need to get the color framework in place for all planes
which support HDR content in hardware. This is already in progres
and patches are out for review in mailing list.
2. UserSpace/Compositors: Blending policies and metadata blob
creation and passing to driver. Work is already in progress
by Intel's middleware teams on wayland and the patches for
the same are in review.

Please review and share your feedbacks/suggestions.

Note: The intention for these patches is to get a design feedback on
the uapi changes, generic property design and infoframe handling.
This cannot get merged as of now without the userspace support in place.

A POC has already been developed by Ville based on wayland. Please refer
below link to see the component interactions and usage:
https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html

v2: Updated Ville's POC changes to the patch series.Incorporated cleanups
and fixes from Ville. Rebase on latest drm-tip.

v3: Fixed a warning causing builds to break on CI. No major change.

v4: Addressed Shashank's review comments.

v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset
case for HDR metadata update. Dropped a redundant patch.

v6: Addressed Shashank's review comments and added RB's received.

v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and
Shashank's review comments.

Note: Media driver and VAAPI changes for HDR are already out, with compositors
changes also expected to land soon. Weston changes already floated and reviews
started in community and is in active development along with GL efforts.

Uma Shankar (7):
   drm: Add HDR source metadata property
   drm: Parse HDR metadata info from EDID
   drm: Enable HDR infoframe support
   drm/i915: Attach HDR metadata property to connector
   drm/i915: Write HDR infoframe and send to panel
   drm/i915:Enabled Modeset when HDR Infoframe changes
   drm/i915: Set Infoframe for non modeset case for HDR

Ville Syrjälä (2):
   drm/i915: Add HLG EOTF
   drm/i915: Enable infoframes on GLK+ for HDR

  drivers/gpu/drm/drm_atomic.c|   2 +
  drivers/gpu/drm/drm_atomic_uapi.c   |  13 +++
  drivers/gpu/drm/drm_connector.c |   6 ++
  drivers/gpu/drm/drm_edid.c  | 102 
  drivers/gpu/drm/i915/i915_reg.h |   4 +
  drivers/gpu/drm/i915/intel_atomic.c |  14 ++-
  drivers/gpu/drm/i915/intel_ddi.c|  13 +++
  drivers/gpu/drm/i915/intel_drv.h|   1 +
  drivers/gpu/drm/i915/intel_hdmi.c   |  79 ++-
  drivers/video/hdmi.c| 186 
  include/drm/drm_connector.h |  10 ++
  include/drm/drm_edid.h  |   5 +
  include/drm/drm_mode_config.h   |   6 ++
  include/linux/hdmi.h|  38 
  include/uapi/drm/drm_mode.h |  22 +
  15 files changed, 496 insertions(+), 5 deletions(-)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v6 11/13] drm/i915:Enabled Modeset when HDR Infoframe changes

[Sharma, Shashank]

On 3/20/2019 4:18 PM, Uma Shankar wrote:

This patch enables modeset whenever HDR metadata
needs to be updated to sink.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_atomic.c | 15 ++-
  drivers/gpu/drm/i915/intel_hdmi.c   |  4 
  2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index b844e88..4ff6042 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -102,6 +102,16 @@ int intel_digital_connector_atomic_set_property(struct 
drm_connector *connector,
return -EINVAL;
  }
  
+static bool blob_equal(const struct drm_property_blob *a,

+  const struct drm_property_blob *b)
+{
+   if (a && b)
+   return a->length == b->length &&
+   !memcmp(a->data, b->data, a->length);
+
+   return !a == !b;
+}
+
  int intel_digital_connector_atomic_check(struct drm_connector *conn,
 struct drm_connector_state *new_state)
  {
@@ -129,7 +139,10 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
new_conn_state->base.colorspace != old_conn_state->base.colorspace 
||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
-   new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
+   new_conn_state->base.scaling_mode !=
+   old_conn_state->base.scaling_mode ||
+   !blob_equal(new_conn_state->base.hdr_output_metadata_blob_ptr,
If you are keeping this line ahead of the upper one due to 80 char 
limit, please pull that one also two tabs back, right now this is not 
even looking good.

+   old_conn_state->base.hdr_output_metadata_blob_ptr))
crtc_state->mode_changed = true;
  
  	return 0;

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 8decafd..4d06734 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -792,6 +792,10 @@ void intel_read_infoframe(struct intel_encoder *encoder,
struct hdr_static_metadata *hdr_metadata;
int ret;
  
+	if (!conn_state->hdr_output_metadata_blob_ptr ||

+   conn_state->hdr_output_metadata_blob_ptr->length == 0)
+   return true;
+


This patch needs a rebase on the latest code, as this is definitely not 
where we want this code :-)


- Shashank


hdr_metadata = (struct hdr_static_metadata *)
conn_state->hdr_output_metadata_blob_ptr->data;
  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v6 10/13] drm/i915: Enable infoframes on GLK+ for HDR

[Sharma, Shashank]

On 3/20/2019 4:18 PM, Uma Shankar wrote:

From: Ville Syrjälä 

This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.

v2: Addressed Shashank's review comment.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/i915_reg.h   |  4 
  drivers/gpu/drm/i915/intel_hdmi.c | 18 +-
  2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 31a3020..fe931e7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4718,6 +4718,7 @@ enum {
  #define   VIDEO_DIP_FREQ_MASK (3 << 16)
  /* HSW and later: */
  #define   DRM_DIP_ENABLE  (1 << 28)
+#define   VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
  #define   PSR_VSC_BIT_7_SET   (1 << 27)
  #define   VSC_SELECT_MASK (0x3 << 25)
  #define   VSC_SELECT_SHIFT25
@@ -8156,6 +8157,7 @@ enum {
  #define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
  #define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
  #define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A  0x60440
  #define _HSW_VIDEO_DIP_AVI_ECC_A  0x60240
  #define _HSW_VIDEO_DIP_VS_ECC_A   0x60280
  #define _HSW_VIDEO_DIP_SPD_ECC_A  0x602C0
@@ -8169,6 +8171,7 @@ enum {
  #define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
  #define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
  #define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B  0x61440
  #define _HSW_VIDEO_DIP_BVI_ECC_B  0x61240
  #define _HSW_VIDEO_DIP_VS_ECC_B   0x61280
  #define _HSW_VIDEO_DIP_SPD_ECC_B  0x612C0
@@ -8194,6 +8197,7 @@ enum {
  #define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
  #define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
  #define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i)  _MMIO_TRANS2(trans, 
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
  #define ICL_VIDEO_DIP_PPS_DATA(trans, i)  _MMIO_TRANS2(trans, 
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
  #define ICL_VIDEO_DIP_PPS_ECC(trans, i)   _MMIO_TRANS2(trans, 
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
  
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c

index e4bc7fc..8decafd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -134,6 +134,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+   case HDMI_INFOFRAME_TYPE_DRM:
+   return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -159,6 +161,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+   case HDMI_INFOFRAME_TYPE_DRM:
+   return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -545,7 +549,8 @@ static u32 hsw_infoframes_enabled(struct intel_encoder 
*encoder,
  
  	return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |

  VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+ VIDEO_DIP_ENABLE_DRM_GLK);
I think this should also be GEN check protected, as 
hsw_infoframes_enabled will be called by many platforms, and before GLK 
they cant support DRM_IF.

  }
  
  static const u8 infoframe_type_to_idx[] = {

@@ -1177,7 +1182,8 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
  
  	val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |

 VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);


Same here.

- Shashank

  
  	if (!enable) {

I915_WRITE(reg, val);
@@ -1200,9 +1206,11 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
intel_write_infoframe(encoder, crtc_state,
  HDMI_INFOFRAME_TYPE_VENDOR,
  _state->infoframes.hdmi);
-   intel_write_infoframe(encoder, crtc_state,
- HDMI_INFOFRAME_TYPE_DRM,
- _state->infoframes.drm);
+   if ((INTEL_GEN(dev_priv) >= 10 || 

Re: [v6 13/13] video/hdmi: Add const variants for drm infoframe

[Sharma, Shashank]

On 3/20/2019 4:18 PM, Uma Shankar wrote:

Added the const version of infoframe for DRM metadata
for HDR.

Signed-off-by: Uma Shankar 
---
  drivers/video/hdmi.c | 63 ++--
  include/linux/hdmi.h |  5 +
  2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 80bb0ee..f9ca555 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -668,6 +668,30 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe 
*frame)
  }
  EXPORT_SYMBOL(hdmi_drm_infoframe_init);
  
+static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe *frame)

+{
+   if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
+   frame->version != 1)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
+ * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
This comment doesn't match what's being done in this function, as, 
hdmi_drm_infoframe_check_only() doesn't validate length.

+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame)
+{
+   return hdmi_drm_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_check);
+
  /**
   * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
   * @frame: HDMI DRM infoframe
@@ -682,8 +706,8 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe 
*frame)
   * Returns the number of bytes packed into the binary buffer or a negative
   * error code on failure.
   */
-ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
-   size_t size)
+ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe *frame,
+void *buffer, size_t size)
  {
u8 *ptr = buffer;
size_t length;
@@ -736,6 +760,37 @@ ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe 
*frame, void *buffer,
  
  	return length;

  }
+EXPORT_SYMBOL(hdmi_drm_infoframe_pack_only);
+
+/**
+ * hdmi_drm_infoframe_pack() - check a HDMI DRM infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which it packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame,
+   void *buffer, size_t size)
+{
+   int ret;
+
+   ret = hdmi_drm_infoframe_check(frame);
+   if (ret)
+   return ret;
+
+   return hdmi_drm_infoframe_pack_only(frame, buffer, size);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_pack);
  
  /*

   * hdmi_vendor_any_infoframe_check() - check a vendor infoframe
@@ -845,6 +900,10 @@ ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe 
*frame, void *buffer,
length = hdmi_avi_infoframe_pack_only(>avi,
  buffer, size);
break;
+   case HDMI_INFOFRAME_TYPE_DRM:
+   length = hdmi_drm_infoframe_pack_only(>drm,
+ buffer, size);
+   break;
case HDMI_INFOFRAME_TYPE_SPD:
length = hdmi_spd_infoframe_pack_only(>spd,
  buffer, size);
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 202ed4a..fd8e534 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -213,6 +213,11 @@ ssize_t hdmi_avi_infoframe_pack_only(const struct 
hdmi_avi_infoframe *frame,
 void *buffer, size_t size);
  int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame);
  int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame);
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
+   size_t size);
+ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe *frame,
+void *buffer, size_t size);
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame);
  
  enum hdmi_spd_sdi {

HDMI_SPD_SDI_UNKNOWN,


With that minor comment related to description fixed, this patch looks 
good to me. Please feel free to use:


Reviewed-by: Shashank Sharma 

- Shashank

Re: [v6 12/13] drm/i915: Set Infoframe for non modeset case for HDR

[Sharma, Shashank]

On 3/20/2019 4:18 PM, Uma Shankar wrote:

HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_ddi.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 69aa0d1..a27aab9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3566,6 +3566,10 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
  const struct intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state)
  {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(>base);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
  
@@ -3575,6 +3579,15 @@ static void intel_ddi_update_pipe(struct intel_encoder *encoder,

else if (conn_state->content_protection ==
 DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
+
+   /* Set the infoframe for NON modeset cases as well */
+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+   if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
+   conn_state->hdr_metadata_changed)
+   intel_dig_port->set_infoframes(encoder,
+  
crtc_state->has_infoframe,
+  crtc_state, conn_state);
+   }
  }
  

Looks good to me,  Please feel free to use:

Reviewed-by: Shashank Sharma 



  static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v6 07/13] drm/i915: Write HDR infoframe and send to panel

[Sharma, Shashank]

On 3/20/2019 4:18 PM, Uma Shankar wrote:

Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.

v2: Rebase

v3: Fixed a warning message

v4: Addressed Shashank's review comments

v5: Rebase. Added infoframe calculation in compute config.

v6: Addressed Shashank's review comment. Added HDR metadata
support from GEN10 onwards as per Shashank's recommendation.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_drv.h  |  1 +
  drivers/gpu/drm/i915/intel_hdmi.c | 41 +++
  2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d9f188e..c6c3cc7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1043,6 +1043,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+   union hdmi_infoframe drm;
} infoframes;
  
  	/* HDMI scrambling status */

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5f06237..e4bc7fc 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -555,6 +555,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder 
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+   HDMI_INFOFRAME_TYPE_DRM,
  };
  
  u32 intel_hdmi_infoframe_enable(unsigned int type)

@@ -777,6 +778,30 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
  }
  
+static bool

+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+   struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+   struct hdr_static_metadata *hdr_metadata;
+   int ret;
+
+   hdr_metadata = (struct hdr_static_metadata *)
+   conn_state->hdr_output_metadata_blob_ptr->data;
+
+   ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+   if (ret < 0) {
+   DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+   return false;
+   }
+
+   crtc_state->infoframes.enable |=
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+   return true;
+}
+
  static void g4x_set_infoframes(struct intel_encoder *encoder,
   bool enable,
   const struct intel_crtc_state *crtc_state,
@@ -1175,6 +1200,9 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
intel_write_infoframe(encoder, crtc_state,
  HDMI_INFOFRAME_TYPE_VENDOR,
  _state->infoframes.hdmi);
+   intel_write_infoframe(encoder, crtc_state,


We should have a GEN check here also, else, there could be case where we 
dint compute infoframes <=10 but wrote it, which will write garbage.


- Shashank


+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
  }
  
  void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)

@@ -2381,6 +2409,19 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
return -EINVAL;
}
  
+	/*

+* Support HDR Metadata from Gen10 onwards
+* ToDo: Gen9 also can support HDR with LSPCON.
+* Support for the same to be enabled later.
+*/
+   if (INTEL_GEN(dev_priv) >= 10) {
+   if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config,
+ conn_state)) {
+   DRM_DEBUG_KMS("bad DRM infoframe\n");
+   return -EINVAL;
+   }
+   }
+
return 0;
  }
  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v6 02/13] drm: Parse HDR metadata info from EDID

[Sharma, Shashank]

On 3/20/2019 4:18 PM, Uma Shankar wrote:

HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.

v2: Rebase and added Ville's POC changes to the patch.

v3: No Change

v4: Addressed Shashank's review comments

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c | 49 ++
  1 file changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fa39592..fd8a621a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2840,6 +2840,7 @@ static int drm_cvt_modes(struct drm_connector *connector,
  #define VIDEO_BLOCK 0x02
  #define VENDOR_BLOCK0x03
  #define SPEAKER_BLOCK 0x04
+#define HDR_STATIC_METADATA_BLOCK  0x6
  #define USE_EXTENDED_TAG 0x07
  #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
  #define EXT_VIDEO_DATA_BLOCK_420  0x0E
@@ -3587,6 +3588,12 @@ static int add_3d_struct_modes(struct drm_connector 
*connector, u16 structure,
  }
  
  static int

+cea_db_payload_len_ext(const u8 *db)
+{
+   return (db[0] & 0x1f) - 1;
+}
+
+static int
  cea_db_extended_tag(const u8 *db)
  {
return db[1];
@@ -3822,6 +3829,46 @@ static void fixup_detailed_cea_mode_clock(struct 
drm_display_mode *mode)
mode->clock = clock;
  }
  
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)

+{
+   if (cea_db_tag(db) != USE_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != HDR_STATIC_METADATA_BLOCK)
+   return false;
+
+   return true;
+}
+
+static uint8_t eotf_supported(const u8 *edid_ext)
+{
+   return edid_ext[2] &
+   (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+}
+
+static uint8_t hdr_metadata_type(const u8 *edid_ext)
+{
+   return edid_ext[3] &
+   BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+   u16 len;
+
+   len = cea_db_payload_len_ext(db);
+   connector->hdr_metadata.eotf = eotf_supported(db);
+   connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+   if (len >= 5)
+   connector->hdr_metadata.max_fall = db[5];
+   if (len >= 4)


Little bike shed, If we pass >=5 we need not to compare >= 4, or we 
should check >=4 first and then >=5 in sequence.


With that change ( and assuming you fixed the checkpatch stuff already), 
please feel free to use:


Reviewed-by: Shashank Sharma 


+   connector->hdr_metadata.max_cll = db[4];
+}
+
  static void
  drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
  {
@@ -4449,6 +4496,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
drm_parse_vcdb(connector, db);
+   if (cea_db_is_hdmi_hdr_metadata_block(db))
+   drm_parse_hdr_metadata_block(connector, db);
}
  }
  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v5 03/13] drm: Parse Colorimetry data block from EDID

[Sharma, Shashank]

On 3/20/2019 12:47 PM, Shankar, Uma wrote:



-Original Message-
From: Sharma, Shashank
Sent: Friday, March 15, 2019 1:01 PM
To: Shankar, Uma ; intel-...@lists.freedesktop.org; dri-
de...@lists.freedesktop.org
Cc: Lankhorst, Maarten ; Syrjala, Ville
; emil.l.veli...@gmail.com; brian.star...@arm.com;
liviu.du...@arm.com
Subject: RE: [v5 03/13] drm: Parse Colorimetry data block from EDID




-Original Message-
From: Shankar, Uma
Sent: Monday, March 11, 2019 9:28 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Lankhorst, Maarten ; Syrjala, Ville
; Sharma, Shashank
; emil.l.veli...@gmail.com;
brian.star...@arm.com; liviu.du...@arm.com; Shankar, Uma

Subject: [v5 03/13] drm: Parse Colorimetry data block from EDID

CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.

v2: Rebase

v3: No Change

v4: Addressed Shashank's review comments. Updated colorimetry field to
16 bit as
DCI-P3 got added in CEA 861-G spec, as pointed out by Shashank.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c  | 26 ++
include/drm/drm_connector.h |  3 +++
  2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
c5a81b8..0470845 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
*connector,
  #define VIDEO_BLOCK 0x02
  #define VENDOR_BLOCK0x03
  #define SPEAKER_BLOCK 0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
  #define HDR_STATIC_METADATA_BLOCK 0x6
  #define USE_EXTENDED_TAG 0x07
  #define EXT_VIDEO_CAPABILITY_BLOCK 0x00 @@ -3823,6 +3824,29 @@ static
void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
mode->clock = clock;
  }

+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {

Same comment for the opening brace above ?

Again this looks like  mail client issue.


+   if (cea_db_tag(db) != USE_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != COLORIMETRY_DATA_BLOCK)

Space before '!' ?

Same here.


+   return false;
+
+   return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const
+u8 *db) {
+   struct drm_hdmi_info *info = >display_info.hdmi;
+   uint16_t len;
+
+   len = cea_db_payload_len_ext(db);
+   /* As per CEA 861-G spec */
+   info->colorimetry = ((db[3] & (0x1 << 7)) << 1) | db[2]; }

This means we are setting the 15th bit for DCI-P3 then there is a gap of 7 
bits, and
then there are other bits. Do we want to make DCI-P3 as bit 8 ? Anyways this 
can be
differed for a discussion later.

This is at 8th position only.  We are shifting the db[3] which is 8 bit by 1 
and keeping the 7th bit (DCI-P3)
at the 8th position (if we count from 0).

Regards,
Uma Shankar


My bad,  its 8th bit only.

If those above alignment problems are checked already, feel free to use

Reviewed-by: Shashank Sharma 

- Shashank


+
+
  static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)  {
if (cea_db_tag(db) != USE_EXTENDED_TAG) @@ -4495,6 +4519,8 @@ static
void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+   if (cea_db_is_hdmi_colorimetry_data_block(db))
+   drm_parse_colorimetry_data_block(connector, db);
}
  }

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 29388bd..94f926e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,9 @@ struct drm_hdmi_info {

/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+   /* @colorimetry: bitmap of supported colorimetry modes */
+   u16 colorimetry;

- Shashank

  };

  /**
--
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v5 09/13] drm/i915: Add HLG EOTF

[Sharma, Shashank]

On 3/11/2019 9:28 AM, Uma Shankar wrote:

From: Ville Syrjälä 

ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.

v2: Rebase

v3: Fixed a warning message

v4: Addressed Shashank's review comments

Signed-off-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c | 4 ++--
  include/linux/hdmi.h   | 1 +
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 49f8340..4cd22e8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3864,8 +3864,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
return edid_ext[2] &
(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
 BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
-BIT(HDMI_EOTF_SMPTE_ST2084));
-
+BIT(HDMI_EOTF_SMPTE_ST2084) |
+BIT(HDMI_EOTF_BT_2100_HLG));
  }
  
  static uint8_t hdr_metadata_type(const u8 *edid_ext)

diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 33243b2..ad652e6 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -161,6 +161,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+   HDMI_EOTF_BT_2100_HLG,
  };
  


Looks good to me,

Feel free to use: Reviewed-by: Shashank Sharma 


  struct hdmi_avi_infoframe {

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v5 07/13] drm/i915: Write HDR infoframe and send to panel

[Sharma, Shashank]

On 3/11/2019 9:27 AM, Uma Shankar wrote:

Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.

v2: Rebase

v3: Fixed a warning message

v4: Addressed Shashank's review comments

v5: Rebase. Added infoframe calculation in compute config.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_drv.h  |  1 +
  drivers/gpu/drm/i915/intel_hdmi.c | 33 +
  2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 58483f8..a5ee124 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1037,6 +1037,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+   union hdmi_infoframe drm;
} infoframes;
  
  	/* HDMI scrambling status */

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0952475..ea7afa0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -555,6 +555,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder 
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+   HDMI_INFOFRAME_TYPE_DRM,
  };
  
  u32 intel_hdmi_infoframe_enable(unsigned int type)

@@ -777,6 +778,30 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
  }
  
+static bool

+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+   struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+   struct hdr_static_metadata *hdr_metadata;
+   int ret;
+


Don't we need a GEN/monitor check before going ahead with HDR metadata ?

- Shashank


+   hdr_metadata = (struct hdr_static_metadata *)
+   conn_state->hdr_output_metadata_blob_ptr->data;
+
+   ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+   if (ret < 0) {
+   DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+   return false;
+   }
+
+   crtc_state->infoframes.enable |=
+   intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+   return true;
+}
+
  static void g4x_set_infoframes(struct intel_encoder *encoder,
   bool enable,
   const struct intel_crtc_state *crtc_state,
@@ -1175,6 +1200,9 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
intel_write_infoframe(encoder, crtc_state,
  HDMI_INFOFRAME_TYPE_VENDOR,
  _state->infoframes.hdmi);
+   intel_write_infoframe(encoder, crtc_state,
+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
  }
  
  void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)

@@ -2381,6 +2409,11 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
return -EINVAL;
}
  
+	if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config, conn_state)) {

+   DRM_DEBUG_KMS("bad DRM infoframe\n");
+   return -EINVAL;
+   }
+
return 0;
  }
  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v5 06/13] drm: Enable HDR infoframe support

[Sharma, Shashank]

ct drm_connector *connector,
   const struct drm_display_mode *mode,
   enum hdmi_quantization_range 
rgb_quant_range);
  
+int

+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+   void *hdr_source_metadata);
+
  /**
   * drm_eld_mnl - Get ELD monitor name length in bytes.
   * @eld: pointer to an eld memory structure with mnl set
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index a065194..33243b2 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -47,6 +47,7 @@ enum hdmi_infoframe_type {
HDMI_INFOFRAME_TYPE_AVI = 0x82,
HDMI_INFOFRAME_TYPE_SPD = 0x83,
HDMI_INFOFRAME_TYPE_AUDIO = 0x84,
+   HDMI_INFOFRAME_TYPE_DRM = 0x87,
  };
  
  #define HDMI_IEEE_OUI 0x000c03

@@ -185,12 +186,32 @@ struct hdmi_avi_infoframe {
unsigned short right_bar;
  };
  
+struct hdmi_drm_infoframe {

+   enum hdmi_infoframe_type type;
+   unsigned char version;
+   unsigned char length;
+   enum hdmi_eotf eotf;
+   enum hdmi_metadata_type metadata_type;
+   struct {
+   uint16_t x, y;
+   } display_primaries[3];
+   struct {
+   uint16_t x, y;
+   } white_point;
+   uint16_t max_mastering_display_luminance;
+   uint16_t min_mastering_display_luminance;
+   uint16_t max_fall;
+   uint16_t max_cll;
+   uint16_t min_cll;
+};
+
  int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame);
  ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void 
*buffer,
size_t size);
  ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
 void *buffer, size_t size);
  int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame);
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame);
  
  enum hdmi_spd_sdi {

HDMI_SPD_SDI_UNKNOWN,
@@ -365,6 +386,7 @@ ssize_t hdmi_vendor_infoframe_pack_only(const struct 
hdmi_vendor_infoframe *fram
struct hdmi_spd_infoframe spd;
union hdmi_vendor_any_infoframe vendor;
struct hdmi_audio_infoframe audio;
+   struct hdmi_drm_infoframe drm;
  };


With the minor issues pointed above fixed, feel free to use:

Reviewed-by: Shashank Sharma 

- Shashank

  
  ssize_t hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer,

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v5 04/13] drm/i915: Attach HDR metadata property to connector

[Sharma, Shashank]

> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma 
> Subject: [v5 04/13] drm/i915: Attach HDR metadata property to connector
> 
> Attach HDR metadata property to connector object.
> 
> v2: Rebase
> 
> v3: Updated the property name as per updated name while creating hdr metadata
> property
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index cd422a7..0952475 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2719,6 +2719,8 @@ static void intel_hdmi_destroy(struct drm_connector
> *connector)
> 
>   drm_connector_attach_content_type_property(connector);
>   connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + drm_object_attach_property(>base,
> + connector->dev->mode_config.hdr_output_metadata_property, 0);
'connector->dev' should be aligned to the line above, but seems like you have 
done this to meet the 80 char limit. 
May be a local ptr variable will help with 80 char. 

Apart from that, looks good to me, and feel free to use:
Reviewed-by: Shashank Sharma 
> 
>   if (!HAS_GMCH(dev_priv))
>   drm_connector_attach_max_bpc_property(connector, 8, 12);
> --
> 1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v5 03/13] drm: Parse Colorimetry data block from EDID

[Sharma, Shashank]

> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma 
> Subject: [v5 03/13] drm: Parse Colorimetry data block from EDID
> 
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from panel.
> 
> v2: Rebase
> 
> v3: No Change
> 
> v4: Addressed Shashank's review comments. Updated colorimetry field to 16 bit 
> as
> DCI-P3 got added in CEA 861-G spec, as pointed out by Shashank.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_edid.c  | 26 ++
> include/drm/drm_connector.h |  3 +++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> c5a81b8..0470845 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
>  #define VIDEO_BLOCK 0x02
>  #define VENDOR_BLOCK0x03
>  #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK   0x5
>  #define HDR_STATIC_METADATA_BLOCK0x6
>  #define USE_EXTENDED_TAG 0x07
>  #define EXT_VIDEO_CAPABILITY_BLOCK 0x00 @@ -3823,6 +3824,29 @@ static
> void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
>   mode->clock = clock;
>  }
> 
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
Same comment for the opening brace above ? 
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
Space before '!' ? 
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const
> +u8 *db) {
> + struct drm_hdmi_info *info = >display_info.hdmi;
> + uint16_t len;
> +
> + len = cea_db_payload_len_ext(db);
> + /* As per CEA 861-G spec */
> + info->colorimetry = ((db[3] & (0x1 << 7)) << 1) | db[2]; }
This means we are setting the 15th bit for DCI-P3 then there is a gap of 7 
bits, and then there are other bits. Do we want to make DCI-P3 as bit 8 ? 
Anyways this can be differed for a discussion later. 
> +
> +
>  static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)  {
>   if (cea_db_tag(db) != USE_EXTENDED_TAG) @@ -4495,6 +4519,8 @@ static
> void drm_parse_cea_ext(struct drm_connector *connector,
>   drm_parse_vcdb(connector, db);
>   if (cea_db_is_hdmi_hdr_metadata_block(db))
>   drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
>   }
>  }
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> 29388bd..94f926e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -206,6 +206,9 @@ struct drm_hdmi_info {
> 
>   /** @y420_dc_modes: bitmap of deep color support index */
>   u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
- Shashank
>  };
> 
>  /**
> --
> 1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v5 02/13] drm: Parse HDR metadata info from EDID

[Sharma, Shashank]

> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma 
> Subject: [v5 02/13] drm: Parse HDR metadata info from EDID
> 
> HDR metadata block is introduced in CEA-861.3 spec.
> Parsing the same to get the panel's HDR metadata.
> 
> v2: Rebase and added Ville's POC changes to the patch.
> 
> v3: No Change
> 
> v4: Addressed Shashank's review comments
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_edid.c | 52
> ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 5f14253..c5a81b8 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
>  #define VIDEO_BLOCK 0x02
>  #define VENDOR_BLOCK0x03
>  #define SPEAKER_BLOCK0x04
> +#define HDR_STATIC_METADATA_BLOCK0x6
>  #define USE_EXTENDED_TAG 0x07
>  #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>  #define EXT_VIDEO_DATA_BLOCK_420 0x0E
> @@ -3581,6 +3582,12 @@ static int add_3d_struct_modes(struct drm_connector
> *connector, u16 structure,  }
> 
>  static int
> +cea_db_payload_len_ext(const u8 *db)
> +{
> + return (db[0] & 0x1f) - 1;
You might have already checked with checkpatch, but can we cross check the 
space before '-' ? 
> +}
> +
> +static int
>  cea_db_extended_tag(const u8 *db)
>  {
>   return db[1];
> @@ -3816,6 +3823,49 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
>   mode->clock = clock;
>  }
> 
> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != HDR_STATIC_METADATA_BLOCK)
same here,  looks like we need spaces around !=, or may be this is due to my 
mail client  ? 
> + return false;
> +
> + return true;
> +}
> +
> +static uint8_t eotf_supported(const u8 *edid_ext) {
> +
> + return edid_ext[2] &
> + (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
> +  BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
Again, space before the '|' sign, please excuse me if this is false alarm ... 
> +  BIT(HDMI_EOTF_SMPTE_ST2084));
> +
> +}
> +
> +static uint8_t hdr_metadata_type(const u8 *edid_ext) {
> +
> + return edid_ext[3] &
> + BIT(HDMI_STATIC_METADATA_TYPE1);
> +}
> +
> +static void
> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8
> +*db) {
Shouldn't this variable go to line above ? 
> + uint16_t len;
> +
> + len = cea_db_payload_len_ext(db);
> + connector->hdr_metadata.eotf = eotf_supported(db);
> + connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
> +
> + if (len >= 5)
> + connector->hdr_metadata.max_fall = db[5];
> + if (len >= 4)
> + connector->hdr_metadata.max_cll = db[4]; }
This '}' certainly should not be here.  
> +
>  static void
>  drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)  { 
> @@
> -4443,6 +4493,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
>   drm_parse_y420cmdb_bitmap(connector, db);
>   if (cea_db_is_vcdb(db))
>   drm_parse_vcdb(connector, db);
> + if (cea_db_is_hdmi_hdr_metadata_block(db))
> + drm_parse_hdr_metadata_block(connector, db);
- Shashank
>   }
>  }
> 
> --
> 1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [v5 01/13] drm: Add HDR source metadata property

[Sharma, Shashank]

Hello Uma, 

> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma 
> Subject: [v5 01/13] drm: Add HDR source metadata property
> 
> This patch adds a blob property to get HDR metadata information from 
> userspace.
> This will be send as part of AVI Infoframe to panel.
> 
> v2: Rebase and modified the metadata structure elements as per Ville's POC 
> changes.
> 
> v3: No Change
> 
> v4: Addressed Shashank's review comments
> 
> v5: Rebase.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_connector.c |  6 ++
>  include/drm/drm_connector.h | 10 ++
>  include/drm/drm_mode_config.h   |  6 ++
>  include/linux/hdmi.h| 10 ++
>  include/uapi/drm/drm_mode.h | 16 
>  5 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 07d65a1..b031079 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1054,6 +1054,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.non_desktop_property = prop;
> 
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
Needs alignment with the line above. 
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_output_metadata_property = prop;
> +
>   return 0;
>  }
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> c806199..29388bd 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -561,6 +561,13 @@ struct drm_connector_state {
>* and the connector bpc limitations obtained from edid.
>*/
>   u8 max_bpc;
> +
> + /**
> +  * @metadata_blob_ptr:
> +  * DRM blob property for HDR output metadata
> +  */
> + struct drm_property_blob *hdr_output_metadata_blob_ptr;
> + u8 hdr_metadata_changed : 1;
>  };
> 
>  /**
> @@ -1201,6 +1208,9 @@ struct drm_connector {
>* _mode_config.connector_free_work.
>*/
>   struct llist_node free_node;
> +
> + /* HDR metdata */
> + struct hdr_static_metadata hdr_metadata;
I was under the assumption that we are not parsing the hdr_metadata from the 
EDID, and the userspace needs to parse it from the EDID. If that's the case, we 
might not even need this pointer. Are we even using this or am I missing 
something here ? 
>  };
> 
>  #define obj_to_connector(x) container_of(x, struct drm_connector, base) diff 
> --git
> a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index
> 7f60e8e..ef2656b 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -836,6 +836,12 @@ struct drm_mode_config {
>*/
>   struct drm_property *writeback_out_fence_ptr_property;
> 
> + /*
> +  * hdr_metadata_property: Connector property containing hdr metatda
> +  * This will be provided by userspace compositors based on HDR content
> +  */
> + struct drm_property *hdr_output_metadata_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
> 
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index 
> 927ad64..a065194
> 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -152,6 +152,16 @@ enum hdmi_content_type {
>   HDMI_CONTENT_TYPE_GAME,
>  };
> 
> +enum hdmi_metadata_type {
> + HDMI_STATIC_METADATA_TYPE1 = 1,
> +};
> +
> +enum hdmi_eotf {
> + HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
> + HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
> + HDMI_EOTF_SMPTE_ST2084,
> +};
> +
>  struct hdmi_avi_infoframe {
>   enum hdmi_infoframe_type type;
>   unsigned char version;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index
> a439c2e..5012af2 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -630,6 +630,22 @@ struct drm_color_lut {
>   __u16 reserved;
>  };
> 
> +/* HDR Metadata */
> +struct hdr_static_metadata {
> + uint8_t eotf;
> + uint8_t metadata_type;
> + struct {
> + uint16_t x, y;
> + } display_primaries[3];
> + struct {
> + uint16_t x, y;
> + } white_point;
>

Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property

[Sharma, Shashank]

Regards

Shashank

On 2/8/2019 7:00 PM, Ville Syrjälä wrote:

On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:

Regards

Shashank

On 2/8/2019 6:22 PM, Ville Syrjälä wrote:

On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:

Regards
Shashank


-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Shankar, Uma
Sent: Friday, February 8, 2019 5:45 PM
To: Ville Syrjälä 
Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ; 
dri-
de...@lists.freedesktop.org; Lankhorst, Maarten 
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property


-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, February 5, 2019 10:02 PM
To: Shankar, Uma 
Cc: intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten

Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
property

On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:

Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like
601, 709, BT2020 etc. This helps to switch based on content
type which is to be displayed. The decision lies with
compositors as to in which scenarios, a particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut
colorspaces like
BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to
the one supported. Sink supported colorspaces should be
retrieved by userspace from EDID and driver will not explicitly
expose

them.

Basically the expectation from userspace is:
   - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
 colorspace
   - Set this new property to let the sink know what it
 converted the CRTC output to.

v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported

colorspaces.

Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the
colorspace is not chosen by user, suggested by Ville and
Maarten. Addressed other misc review comments from Maarten.
Split the changes to have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol standard.

v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated
HDMI and DP property creation in the common helper.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian
Starkey's suggestion in order to go with string matching at userspace.
Updated the commit message to add more details as well kernel docs.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and
Daniel Stone's comments and moved to drm include file. Moved
back to older design with exposing all HDMI colorspaces to
userspace since infoframe capability is there even on legacy
platforms, as per Ville's review comments.

v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.

v11: Addressed Ville's review comments. Updated the Macro
naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.

Signed-off-by: Uma Shankar 
Acked-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Reviewed-by: Maarten Lankhorst

---
   drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
   drivers/gpu/drm/drm_connector.c   | 78

+++

   include/drm/drm_connector.h   | 50 +
   3 files changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int
drm_atomic_connector_set_property(struct

drm_connector *connector,

return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb =

drm_framebuffer_lookup(dev,

NULL, val);

int ret =

drm_atomic_set_writeback_fb_for_connector(state,

fb); @@

-814,6 +816,8 @@ static int
drm_atomic_connector_set_property(struct

drm_connector *connector,

*val = state->picture_aspect_ratio;
} else if (property == config->con

Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property

[Sharma, Shashank]

Regards

Shashank

On 2/8/2019 6:22 PM, Ville Syrjälä wrote:

On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:

Regards
Shashank


-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Shankar, Uma
Sent: Friday, February 8, 2019 5:45 PM
To: Ville Syrjälä 
Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ; 
dri-
de...@lists.freedesktop.org; Lankhorst, Maarten 
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property


-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, February 5, 2019 10:02 PM
To: Shankar, Uma 
Cc: intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten

Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
property

On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:

Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like
601, 709, BT2020 etc. This helps to switch based on content
type which is to be displayed. The decision lies with
compositors as to in which scenarios, a particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut
colorspaces like
BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to
the one supported. Sink supported colorspaces should be
retrieved by userspace from EDID and driver will not explicitly
expose

them.

Basically the expectation from userspace is:
  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
  - Set this new property to let the sink know what it
converted the CRTC output to.

v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported

colorspaces.

Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the
colorspace is not chosen by user, suggested by Ville and
Maarten. Addressed other misc review comments from Maarten.
Split the changes to have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol standard.

v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated
HDMI and DP property creation in the common helper.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian
Starkey's suggestion in order to go with string matching at userspace.
Updated the commit message to add more details as well kernel docs.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and
Daniel Stone's comments and moved to drm include file. Moved
back to older design with exposing all HDMI colorspaces to
userspace since infoframe capability is there even on legacy
platforms, as per Ville's review comments.

v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.

v11: Addressed Ville's review comments. Updated the Macro
naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.

Signed-off-by: Uma Shankar 
Acked-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Reviewed-by: Maarten Lankhorst

---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
  drivers/gpu/drm/drm_connector.c   | 78

+++

  include/drm/drm_connector.h   | 50 +
  3 files changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int
drm_atomic_connector_set_property(struct

drm_connector *connector,

return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb =

drm_framebuffer_lookup(dev,

NULL, val);

int ret =

drm_atomic_set_writeback_fb_for_connector(state,

fb); @@

-814,6 +816,8 @@ static int
drm_atomic_connector_set_property(struct

drm_connector *connector,

*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == connector->colorspace_property) {
+   

RE: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property

[Sharma, Shashank]

Regards
Shashank

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Shankar, Uma
> Sent: Friday, February 8, 2019 5:45 PM
> To: Ville Syrjälä 
> Cc: intel-...@lists.freedesktop.org; Syrjala, Ville 
> ; dri-
> de...@lists.freedesktop.org; Lankhorst, Maarten 
> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
> 
> >> >> >-Original Message-
> >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >> >> >Sent: Tuesday, February 5, 2019 10:02 PM
> >> >> >To: Shankar, Uma 
> >> >> >Cc: intel-...@lists.freedesktop.org;
> >> >> >dri-devel@lists.freedesktop.org; Syrjala, Ville
> >> >> >; Lankhorst, Maarten
> >> >> >
> >> >> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
> >> >> >property
> >> >> >
> >> >> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
> >> >> >> Create a new connector property to program colorspace to sink 
> >> >> >> devices.
> >> >> >> Modern sink devices support more than 1 type of colorspace like
> >> >> >> 601, 709, BT2020 etc. This helps to switch based on content
> >> >> >> type which is to be displayed. The decision lies with
> >> >> >> compositors as to in which scenarios, a particular colorspace will 
> >> >> >> be picked.
> >> >> >>
> >> >> >> This will be helpful mostly to switch to higher gamut
> >> >> >> colorspaces like
> >> >> >> BT2020 when the media content is encoded as BT2020. Thereby
> >> >> >> giving a good visual experience to users.
> >> >> >>
> >> >> >> The expectation from userspace is that it should parse the EDID
> >> >> >> and get supported colorspaces. Use this property and switch to
> >> >> >> the one supported. Sink supported colorspaces should be
> >> >> >> retrieved by userspace from EDID and driver will not explicitly
> >> >> >> expose
> >them.
> >> >> >>
> >> >> >> Basically the expectation from userspace is:
> >> >> >>  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >> >> >>colorspace
> >> >> >>  - Set this new property to let the sink know what it
> >> >> >>converted the CRTC output to.
> >> >> >>
> >> >> >> v2: Addressed Maarten and Ville's review comments. Enhanced the
> >> >> >> colorspace enum to incorporate both HDMI and DP supported
> >colorspaces.
> >> >> >> Also, added a default option for colorspace.
> >> >> >>
> >> >> >> v3: Removed Adobe references from enum definitions as per
> >> >> >> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> >> >> >> Default to an unset state where driver will assign the
> >> >> >> colorspace is not chosen by user, suggested by Ville and
> >> >> >> Maarten. Addressed other misc review comments from Maarten.
> >> >> >> Split the changes to have separate colorspace property for DP and 
> >> >> >> HDMI.
> >> >> >>
> >> >> >> v4: Addressed Chris and Ville's review comments, and created a
> >> >> >> common colorspace property for DP and HDMI, filtered the list
> >> >> >> based on the colorspaces supported by the respective protocol 
> >> >> >> standard.
> >> >> >>
> >> >> >> v5: Made the property creation helper accept enum list based on
> >> >> >> platform capabilties as suggested by Shashank. Consolidated
> >> >> >> HDMI and DP property creation in the common helper.
> >> >> >>
> >> >> >> v6: Addressed Shashank's review comments.
> >> >> >>
> >> >> >> v7: Added defines instead of enum in uapi as per Brian
> >> >> >> Starkey's suggestion in order to go with string matching at 
> >> >> >> userspace.
> >> >> >> Updated the commit message to add more details as well kernel docs.
> >> >> >>
> >> >> >> v8: Addressed Maarten's review comments.
> >> >> >>
> >> >> >> v9: Removed macro defines from uapi as per Brian Starkey and
> >> >> >> Daniel Stone's comments and moved to drm include file. Moved
> >> >> >> back to older design with exposing all HDMI colorspaces to
> >> >> >> userspace since infoframe capability is there even on legacy
> >> >> >> platforms, as per Ville's review comments.
> >> >> >>
> >> >> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's 
> >> >> >> ack.
> >> >> >>
> >> >> >> v11: Addressed Ville's review comments. Updated the Macro
> >> >> >> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
> >> >> >>
> >> >> >> Signed-off-by: Uma Shankar 
> >> >> >> Acked-by: Jani Nikula 
> >> >> >> Reviewed-by: Shashank Sharma 
> >> >> >> Reviewed-by: Maarten Lankhorst
> >> >> >> 
> >> >> >> ---
> >> >> >>  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
> >> >> >>  drivers/gpu/drm/drm_connector.c   | 78
> >> >> >+++
> >> >> >>  include/drm/drm_connector.h   | 50 +
> >> >> >>  3 files changed, 132 insertions(+)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> >> index 9a1f41a..9b5d44f 100644
> >> >> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> >> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> 

Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset

[Sharma, Shashank]

  Hello Ville,

On 1/29/2019 9:33 PM, Ville Syrjälä wrote:

On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ville Syrjälä
Sent: Tuesday, January 29, 2019 9:14 PM
To: Shankar, Uma 
Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten ;
dri-devel@lists.freedesktop.org
Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset

On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:

This patch attaches the colorspace connector property to the hdmi
connector. Based on colorspace change, modeset will be triggered to
switch to new colorspace.

Based on colorspace property value create an infoframe with
appropriate colorspace. This can be used to send an infoframe packet
with proper colorspace value set which will help to enable wider color
gamut like BT2020 on sink.

This patch attaches and enables HDMI colorspace, DP will be taken care
separately.

v2: Merged the changes of creating infoframe as well to this patch as
per Maarten's suggestion.

v3: Addressed review comments from Shashank. Separated HDMI and DP
colorspaces as suggested by Ville and Maarten.

v4: Addressed Chris and Ville's review comments, and created a common
colorspace property for DP and HDMI, filtered the list based on the
colorspaces supported by the respective protocol standard. Handle the
default case properly.

v5: Added Platform specific colorspace enums and called the property
creation helper using the same.

v6: Addressed Shashank's review comments.

v7: Rebase

v8: Addressed Maarten's review comments.

Signed-off-by: Uma Shankar 
Reviewed-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/intel_atomic.c|  1 +
  drivers/gpu/drm/i915/intel_connector.c | 63

++

  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_hdmi.c  | 24 +
  4 files changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..76b7114 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct

drm_connector *conn,

 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
||
+   new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio != old_conn_state-
base.picture_aspect_ratio ||
new_conn_state->base.content_type != old_conn_state-
base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..9a12d5e 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -30,6 +30,48 @@
  #include "intel_drv.h"
  #include "i915_drv.h"

+static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+   { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
+
+static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+   { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry 

Re: [v2 04/14] drm: Parse Colorimetry data block from EDID

[Sharma, Shashank]

On 1/8/2019 12:10 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Sharma, Shashank
Sent: Thursday, December 20, 2018 11:54 PM
To: Shankar, Uma ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Syrjala, Ville ; Lankhorst, Maarten

Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.

v2: Rebase

Signed-off-by: Uma Shankar 
---
   drivers/gpu/drm/drm_edid.c  | 24 
   include/drm/drm_connector.h |  2 ++
   2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d12b74e..344d8c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,28 @@ static void fixup_detailed_cea_mode_clock(struct

drm_display_mode *mode)

mode->clock = clock;
   }

+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
+   if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != COLORIMETRY_DATA_BLOCK)
+

Again, the COLORIMETRY_DATA_BLOCK definition should be added into this
patch.

Ok, will do that.


return false;
+
+   return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const u8 *db) {
+   struct drm_hdmi_info *info = >display_info.hdmi;
+   uint16_t len;
+
+   len = cea_db_payload_len(db);

Again, the return value of this function doesn't account for extended db tag 
byte,
so what we are looking for is len -1

Will update this.


+   info->colorimetry = db[2];

colorimetry block is actually db[2] and db[3].bit7 (which represents
DCI-P3 space), so we probably want to make info->colorimetryuint16_t

3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601 xvYCC709 xvYCC601
4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0

This is how db[2] and db[3] is described in spec. There is not much clarity on 
F47. Not sure if they
are for DCI-P3, can you clarify once.
Ah, check CEA-861-G table 70, there there is no F47, but I could see 
DCI-P3 in that place, which spec is that you are following right now ?

- Shashank

Regards,
Uma Shankar


+}
+
+
   static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
   {
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6

+4535,8

@@ static void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+   if (cea_db_is_hdmi_colorimetry_data_block(db))
+   drm_parse_colorimetry_data_block(connector, db);
}
   }

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 2ee45dc..90ce364 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,8 @@ struct drm_hdmi_info {

/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+

Please add a one line description about this variable.

Sure will update this.


+   u8 colorimetry;
   };

   /**

Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 03/14] drm: Parse HDR metadata info from EDID

[Sharma, Shashank]

Regards

Shashank


On 1/8/2019 11:10 AM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Sharma, Shashank
Sent: Thursday, December 20, 2018 11:47 PM
To: Shankar, Uma ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Syrjala, Ville ; Lankhorst, Maarten

Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.

v2: Rebase and added Ville's POC changes to the patch.

Signed-off-by: Uma Shankar 
---
   drivers/gpu/drm/drm_edid.c | 45

+

   1 file changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 106fd38..d12b74e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,49 @@ static void fixup_detailed_cea_mode_clock(struct

drm_display_mode *mode)

mode->clock = clock;
   }

I guess the previous patch (or a art of previous patch) should be merged in this
patch.

Sure, will update this.


+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
+   if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != HDR_STATIC_METADATA_BLOCK)
+   return false;
+
+   return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)

Why uint16 ? why not uint8_t ? this is clearly one byte.

Ok, will change this.


+{
+
+   return edid_ext[2] &
+   (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |

Should we bother about SDR bit at all ? Why not just check HDR bits ?

As per spec, all of these are EOTF types. So lets update whatever is supported.
User should put correct EOTF for HDR from this list.


+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext) {

Same uint8_t stuff

Ok. Will update.


+
+   return edid_ext[3] &
+   BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const
+u8 *db) {
+   uint16_t len;
+
+   len = cea_db_payload_len(db);

Length is  incorrect here for extended tag blocks, as this function doesn't 
account
the extended tag byte's size. So the payload length is looking for is len - 1. 
May be
a good time to add
cea_extended_db_payload_len() ?

As per spec, the definition says length after this byte so it factors the 
extended tag byte
well, IIUC. Please correct me if my understanding is wrong.

This is how the data is arranged in a normal CEA DB and Extended CEA DB
++   +-+
|Tag|Length= 3 |   |Tag|Length=3 |
++   +-+
| Data   |   |Extended tag |
++   +-+
| Data   |   |Data |
++   +-+
| Data   |   |Data |
++   +-+

This function cea_db_payload_len() was written before the CEA extended 
blocks were introduced, so it is unaware of Extended tag code, and 
assumes its a part of data. But in case of extended tag block the actual 
data length is 3 -1 = 2. You can have a look at how we are parsing the 
YCBCR 4:2:0 blocks. That's why I made this comment "may be a good time 
to add cea_extended_db_payload_len() function" or enhance the existing 
function to reflect the extended tag.

- Shashank


Regards,
Uma Shankar


+   connector->hdr_metadata.eotf = eotf_supported(db);
+   connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+   if (len >= 5)
+   connector->hdr_metadata.max_fall = db[5];
+   if (len >= 4)
+   connector->hdr_metadata.max_cll = db[4]; }
+
   static void
   drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
   {
@@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct drm_connector

*connector,

drm_parse_hdmi_forum_vsdb(connector, db);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
+   if (cea_db_is_hdmi_hdr_metadata_block(db))
+   drm_parse_hdr_metadata_block(connector, db);
}
   }


- Shashank

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 14/14] drivers/video: Constantify function argument for HDMI infoframe log

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

From: Ville Syrjälä 

Function argument for hdmi_drm_infoframe_log is made constant.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
  drivers/video/hdmi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 0937c8c..7ab8086 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1383,8 +1383,8 @@ static void hdmi_audio_infoframe_log(const char *level,
   * @frame: HDMI DRM infoframe
   */
  static void hdmi_drm_infoframe_log(const char *level,
-  struct device *dev,
-  struct hdmi_drm_infoframe *frame)
+  struct device *dev,
+  const struct hdmi_drm_infoframe *frame)

Why not merge this patch with 8/14 drm: Enable HDR infoframe support ?
- Shashank

  {
int i;
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 12/14] drm/i915: Enable infoframes on GLK+ for HDR

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

From: Ville Syrjälä 

This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/i915_reg.h   |  4 
  drivers/gpu/drm/i915/intel_hdmi.c | 12 +---
  2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a7d605..6f44d02 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4591,6 +4591,7 @@ enum {
  #define   VIDEO_DIP_FREQ_MASK (3 << 16)
  /* HSW and later: */
  #define   DRM_DIP_ENABLE  (1 << 28)
+#define   VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
  #define   PSR_VSC_BIT_7_SET   (1 << 27)
  #define   VSC_SELECT_MASK (0x3 << 25)
  #define   VSC_SELECT_SHIFT25
@@ -8015,6 +8016,7 @@ enum {
  #define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
  #define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
  #define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A  0x60440
  #define _HSW_VIDEO_DIP_AVI_ECC_A  0x60240
  #define _HSW_VIDEO_DIP_VS_ECC_A   0x60280
  #define _HSW_VIDEO_DIP_SPD_ECC_A  0x602C0
@@ -8028,6 +8030,7 @@ enum {
  #define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
  #define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
  #define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B  0x61440
  #define _HSW_VIDEO_DIP_BVI_ECC_B  0x61240
  #define _HSW_VIDEO_DIP_VS_ECC_B   0x61280
  #define _HSW_VIDEO_DIP_SPD_ECC_B  0x612C0
@@ -8052,6 +8055,7 @@ enum {
  #define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
  #define HSW_TVIDEO_DIP_GCP(trans) _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_GCP_A)
  #define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans, 
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i)  _MMIO_TRANS2(trans, 
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
  #define ICL_VIDEO_DIP_PPS_DATA(trans, i)  _MMIO_TRANS2(trans, 
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
  #define ICL_VIDEO_DIP_PPS_ECC(trans, i)   _MMIO_TRANS2(trans, 
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
  
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c

index 6286c4a..5c2e3c9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -123,6 +123,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+   case HDMI_INFOFRAME_TYPE_DRM:
+   return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -146,6 +148,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+   case HDMI_INFOFRAME_TYPE_DRM:
+   return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -432,7 +436,8 @@ static bool hsw_infoframe_enabled(struct intel_encoder 
*encoder,
  
  	return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |

  VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+ VIDEO_DIP_ENABLE_DRM_GLK);
  }
  
  /*

@@ -889,7 +894,8 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
  
  	val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |

 VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);
  
  	if (!enable) {

I915_WRITE(reg, val);
@@ -908,7 +914,7 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state, conn_state);
  
  	/* Set Dynamic Range and Mastering Infoframe if supported and changed */

-   if (conn_state->hdr_metadata_changed)
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))

Shouldn't this be

if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) && 
conn_state->hdr_metadata_changed) ?


intel_hdmi_set_drm_infoframe(encoder, crtc_state, conn_state);
  }
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 11/14] drm/i915: Add HLG EOTF

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

From: Ville Syrjälä 

ADD HLG EOTF to the list of EOTF transfer functions
supported.

Would it be possible to add some details about HLG ?


Signed-off-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c | 4 ++--
  include/linux/hdmi.h   | 1 +
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a7fc9b..fa86494 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3857,8 +3857,8 @@ static uint16_t eotf_supported(const u8 *edid_ext)
return edid_ext[2] &
(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
 BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
-BIT(HDMI_EOTF_SMPTE_ST2084));
-
+BIT(HDMI_EOTF_SMPTE_ST2084) |
+BIT(HDMI_EOTF_BT_2100_HLG));
  }
  
  static uint16_t hdr_metadata_type(const u8 *edid_ext)

diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index ce00e1e..b5346c3 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -146,6 +146,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+   HDMI_EOTF_BT_2100_HLG,
  };
  
  struct hdmi_avi_infoframe {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 09/14] drm/i915: Write HDR infoframe and send to panel

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.

v2: Rebase

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
  1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 8a1e5cb..6286c4a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -475,6 +475,29 @@ static void intel_write_infoframe(struct intel_encoder 
*encoder,
frame->any.type, buffer, len);
  }
  
+/* Set Dynamic Range and Mastering Infoframe */

+static void intel_hdmi_set_drm_infoframe(struct drm_encoder *encoder,
+const struct intel_crtc_state
+*crtc_state,
+const struct drm_connector_state
+
We will need this function for lspcon too, if you want to add in a 
different series, please add a TODO: here.

 *conn_state)
+{
+   union hdmi_infoframe frame;
+   struct hdr_static_metadata *hdr_metadata;
+   int ret;
+
+   hdr_metadata = (struct hdr_static_metadata *)
+   conn_state->hdr_source_metadata_blob_ptr->data;
+
+   ret = drm_hdmi_infoframe_set_hdr_metadata(, hdr_metadata);
+   if (ret < 0) {
+   DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+   return;
+   }
+
+   intel_write_infoframe(encoder, crtc_state, );
+}
+
  static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
 const struct intel_crtc_state 
*crtc_state,
 const struct drm_connector_state 
*conn_state)
@@ -883,6 +906,10 @@ static void hsw_set_infoframes(struct intel_encoder 
*encoder,
intel_hdmi_set_avi_infoframe(encoder, crtc_state, conn_state);
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state, conn_state);
+
+   /* Set Dynamic Range and Mastering Infoframe if supported and changed */
+   if (conn_state->hdr_metadata_changed)
+   intel_hdmi_set_drm_infoframe(encoder, crtc_state, conn_state);
  }
  
  void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)

- Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 08/14] drm: Enable HDR infoframe support

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.

The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.

v2: Rebase and added Ville's POC changes.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c |  58 
  drivers/video/hdmi.c   | 129 +
  include/drm/drm_edid.h |   4 ++
  include/linux/hdmi.h   |  22 
  4 files changed, 213 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 344d8c1..5a7fc9b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4916,6 +4916,64 @@ void drm_set_preferred_mode(struct drm_connector 
*connector,
  EXPORT_SYMBOL(drm_set_preferred_mode);
  
  /**

+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
+ * HDR metadata from userspace
+ * @frame: HDMI AVI infoframe
+ * @hdr_source_metadata: hdr_source_metadata info from userspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+   void *hdr_metadata)
+{
+   struct hdr_static_metadata *hdr_source_metadata;
+   int err, i;
+
+   if (!frame || !hdr_metadata)
+   return -EINVAL;
+
+   err = hdmi_drm_infoframe_init(frame);
+   if (err < 0)
+   return err;
+
+   DRM_DEBUG_KMS("type = %x\n", frame->type);
+
+   hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
+
+   frame->length = sizeof(struct hdr_static_metadata);
+
+
+   frame->eotf = hdr_source_metadata->eotf;
+   frame->metadata_type = hdr_source_metadata->metadata_type;
+
+   for (i = 0; i < 3; i++) {
+   frame->display_primaries[i].x =
+   hdr_source_metadata->display_primaries[i].x;
+   frame->display_primaries[i].y =
+   hdr_source_metadata->display_primaries[i].y;
+   }
+
+   frame->white_point.x = hdr_source_metadata->white_point.x;
+   frame->white_point.y = hdr_source_metadata->white_point.y;
+
+   frame->max_mastering_display_luminance =
+   hdr_source_metadata->max_mastering_display_luminance;
+   frame->min_mastering_display_luminance =
+   hdr_source_metadata->min_mastering_display_luminance;
+
+   frame->max_cll = hdr_source_metadata->max_cll;
+   frame->max_fall = hdr_source_metadata->max_fall;
+
+   hdmi_infoframe_log(KERN_CRIT, NULL,
+  (union hdmi_infoframe *)frame);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
+
+
+/**
   * drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe 
with
   *  data from a DRM display mode
   * @frame: HDMI AVI infoframe
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 799ae49..0937c8c 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -650,6 +650,93 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
return 0;
  }
  
+/**

+ * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
+ * mastering infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
+{
+   memset(frame, 0, sizeof(*frame));
+
+   frame->type = HDMI_INFOFRAME_TYPE_DRM;
+   frame->version = 1;
+
+   return 0;
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+
+/**
+ * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
+   size_t size)
+{
+   u8 *ptr = buffer;
+   size_t length;
+   int i;
+
+   length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+   if (size < length)
+   return -ENOSPC;
+
+   memset(buffer, 0, size);
+
+   ptr[0] = frame->type;
+   ptr[1] = frame->version;
+   ptr[2] = frame->length;
+   ptr[3] = 0; /* checksum */
+
+   /* start infoframe payload */
+   ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+   *ptr++ = 

Re: [v2 07/14] drm: Implement HDR source metadata set and get property handling

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

HDR source metadata set and get property implemented in this
patch.
Again, HDR output metadata ? How about re-arranging the line like "This 
patch implements get() and set() functions for HDR output metadata 
property" just to make it more clear ?

The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.

v2: Rebase and added Ville's POC changes

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_atomic.c  |  2 ++
  drivers/gpu/drm/drm_atomic_uapi.c | 13 +
  2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5eb4013..4e71c6b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -881,6 +881,8 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
  
  	drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name);

drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
+   drm_printf(p, "\thdr_metadata_changed=%d\n",
+   state->hdr_metadata_changed);

Alignment
  
  	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)

if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c408898..b721b12 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -686,6 +686,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
  {
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = >mode_config;
+   bool replaced = false;
+   int ret;
  
  	if (property == config->prop_crtc_id) {

struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
@@ -734,6 +736,14 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+   } else if (property == config->hdr_source_metadata_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >hdr_source_metadata_blob_ptr,
+   val,
+   -1, sizeof(struct hdr_static_metadata),
+   );
Alignment, but I know it might be difficult to contain the params within 
80 chars.

+   state->hdr_metadata_changed |= replaced;
+   return ret;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
@@ -816,6 +826,9 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->content_type;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == config->hdr_source_metadata_property) {
+   *val = (state->hdr_source_metadata_blob_ptr) ?
+   state->hdr_source_metadata_blob_ptr->base.id : 0;
} else if (property == connector->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {

- Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 05/14] drm/i915: Attach HDR metadata property to connector

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

Attach HDR metadata property to connector object.

v2: Rebase

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 07e803a..8a1e5cb 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2154,6 +2154,8 @@ static void intel_hdmi_destroy(struct drm_connector 
*connector)
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.hdr_source_metadata_property, 0);

Alignment with line above missing.
- Shashank
  
  	if (!HAS_GMCH_DISPLAY(dev_priv))

drm_connector_attach_max_bpc_property(connector, 8, 12);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 04/14] drm: Parse Colorimetry data block from EDID

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.

v2: Rebase

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c  | 24 
  include/drm/drm_connector.h |  2 ++
  2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d12b74e..344d8c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,28 @@ static void fixup_detailed_cea_mode_clock(struct 
drm_display_mode *mode)
mode->clock = clock;
  }
  
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)

+{
+   if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != COLORIMETRY_DATA_BLOCK)
+   
Again, the COLORIMETRY_DATA_BLOCK definition should be added into this 
patch.

return false;
+
+   return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+   struct drm_hdmi_info *info = >display_info.hdmi;
+   uint16_t len;
+
+   len = cea_db_payload_len(db);
Again, the return value of this function doesn't account for extended db 
tag byte, so what we are looking for is len -1

+   info->colorimetry = db[2];
colorimetry block is actually db[2] and db[3].bit7 (which represents 
DCI-P3 space), so we probably want to make info->colorimetryuint16_t

+}
+
+
  static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
  {
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
@@ -4513,6 +4535,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+   if (cea_db_is_hdmi_colorimetry_data_block(db))
+   drm_parse_colorimetry_data_block(connector, db);
}
  }
  
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h

index 2ee45dc..90ce364 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,8 @@ struct drm_hdmi_info {
  
  	/** @y420_dc_modes: bitmap of deep color support index */

u8 y420_dc_modes;
+

Please add a one line description about this variable.

+   u8 colorimetry;
  };
  
  /**

Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 03/14] drm: Parse HDR metadata info from EDID

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.

v2: Rebase and added Ville's POC changes to the patch.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c | 45 +
  1 file changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 106fd38..d12b74e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,49 @@ static void fixup_detailed_cea_mode_clock(struct 
drm_display_mode *mode)
mode->clock = clock;
  }
I guess the previous patch (or a art of previous patch) should be merged 
in this patch.
  
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)

+{
+   if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+   return false;
+
+   if (db[1] != HDR_STATIC_METADATA_BLOCK)
+   return false;
+
+   return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)

Why uint16 ? why not uint8_t ? this is clearly one byte.

+{
+
+   return edid_ext[2] &
+   (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |

Should we bother about SDR bit at all ? Why not just check HDR bits ?

+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext)
+{

Same uint8_t stuff

+
+   return edid_ext[3] &
+   BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+   uint16_t len;
+
+   len = cea_db_payload_len(db);
Length is  incorrect here for extended tag blocks, as this function 
doesn't account the extended tag byte's size. So the payload length is 
looking for is len - 1. May be a good time to add 
cea_extended_db_payload_len() ?

+   connector->hdr_metadata.eotf = eotf_supported(db);
+   connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+   if (len >= 5)
+   connector->hdr_metadata.max_fall = db[5];
+   if (len >= 4)
+   connector->hdr_metadata.max_cll = db[4];
+}
+
  static void
  drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
  {
@@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
drm_parse_hdmi_forum_vsdb(connector, db);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
+   if (cea_db_is_hdmi_hdr_metadata_block(db))
+   drm_parse_hdr_metadata_block(connector, db);
}
  }
  

- Shashank

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 02/14] drm: Add CEA extended tag blocks and HDR bitfield macros

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

Add bit field and macro for extended tag in CEA block. Also,
declare macros for HDR metadata block.
This should have been a part of patch, where these macros are being 
used, so that we can see it being used properly. While re-basing can you 
please merge ?

v2: Rebase

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_edid.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b506e36..106fd38 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2843,6 +2843,22 @@ static int drm_cvt_modes(struct drm_connector *connector,
  #define EDID_CEA_YCRCB422 (1 << 4)
  #define EDID_CEA_VCDB_QS  (1 << 6)
  
+#define DATA_BLOCK_EXTENDED_TAG		0x07
Alignment should be one tab back, also I think we already have added 
extended tag macro (for parsing YCBCR420 blocks)

+#define VIDEO_CAPABILITY_DATA_BLOCK0x0
+#define VSVD_DATA_BLOCK0x1

Alignment one tab back

+#define COLORIMETRY_DATA_BLOCK 0x5
+#define HDR_STATIC_METADATA_BLOCK  0x6
+
+/* HDR Metadata Block: Bit fields */
+#define SUPPORTED_EOTF_MASK0x3f
+#define TRADITIONAL_GAMMA_SDR  (0x1 << 0)
+#define TRADITIONAL_GAMMA_HDR  (0x1 << 1)
+#define SMPTE_ST2084   (0x1 << 2)
+#define FUTURE_EOTF(0x1 << 3)

why not properly call it HLG if we are adding a bit for it already ?

+#define RESERVED_EOTF  (0x3 << 4)
+
+#define STATIC_METADATA_TYPE1  (0x1 << 0)
+
  /*
   * Search EDID for CEA extension block.
   */

- Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 01/14] drm: Add HDR source metadata property

[Sharma, Shashank]

Regards

Shashank


On 12/12/2018 2:08 AM, Uma Shankar wrote:

This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.

v2: Rebase and modified the metadata structure elements
as per Ville's POC changes.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_connector.c |  6 ++
  include/drm/drm_connector.h | 10 ++
  include/drm/drm_mode_config.h   |  6 ++
  include/linux/hdmi.h| 10 ++
  include/uapi/drm/drm_mode.h | 16 
  5 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da8ae80..361fcda 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1027,6 +1027,12 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
  
+	prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,

+  "HDR_SOURCE_METADATA", 0);
I see that the compositor would be using this blob to setup the output 
HDR curve post blending, which would be in most of cases, sink HDR. So 
we should ideally call it HDR_OUTPUT_METADATA or output_hdr_metadata.

+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.hdr_source_metadata_property = prop;
+
return 0;
  }
  
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h

index 9be2181..2ee45dc 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -520,6 +520,13 @@ struct drm_connector_state {
 * and the connector bpc limitations obtained from edid.
 */
u8 max_bpc;
+
+   /**
+* @metadata_blob_ptr:
+* DRM blob property for HDR metadata
+*/
+   struct drm_property_blob *hdr_source_metadata_blob_ptr;

Same goes again here, output_hdr_metadata_blob ?

+   u8 hdr_metadata_changed : 1;
  };
  
  /**

@@ -1154,6 +1161,9 @@ struct drm_connector {
 * _mode_config.connector_free_work.
 */
struct llist_node free_node;
+
+   /* HDR metdata */
+   struct hdr_static_metadata hdr_metadata;
I think while designing this framework, we should leave the scope for 
dynamic metadata, which would be following up soon. So we should have a 
union inside struct hdr_metedata, which will have option for both static 
and dynamic type of metadata. I will add details to the place where you 
are adding definition of hdr_static_metadata().

  };
  
  #define obj_to_connector(x) container_of(x, struct drm_connector, base)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 69ccd27..4b3211b 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -836,6 +836,12 @@ struct drm_mode_config {
 */
struct drm_property *writeback_out_fence_ptr_property;
  
+	/*

+* hdr_metadata_property: Connector property containing hdr metatda
+* This will be provided by userspace compositors based on HDR content
+*/
+   struct drm_property *hdr_source_metadata_property;

Again, source->output

+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
  
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h

index d2bacf5..bed3e08 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -137,6 +137,16 @@ enum hdmi_content_type {
HDMI_CONTENT_TYPE_GAME,
  };
  
+enum hdmi_metadata_type {

+   HDMI_STATIC_METADATA_TYPE1 = 1,
+};
+
+enum hdmi_eotf {
+   HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
+   HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
+   HDMI_EOTF_SMPTE_ST2084,
I guess we are not bothering about HLG now, which is fine actually, less 
complicated for now.

+};
+
  struct hdmi_avi_infoframe {
enum hdmi_infoframe_type type;
unsigned char version;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index a439c2e..5012af2 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -630,6 +630,22 @@ struct drm_color_lut {
__u16 reserved;
  };
  
+/* HDR Metadata */

+struct hdr_static_metadata {
+   uint8_t eotf;
+   uint8_t metadata_type;
+   struct {
+   uint16_t x, y;
+   } display_primaries[3];
+   struct {
+   uint16_t x, y;
+   } white_point;
+   uint16_t max_mastering_display_luminance;
+   uint16_t min_mastering_display_luminance;
+   uint16_t max_fall;
+   uint16_t max_cll;
+};

How about defining struct hdr_metadata {
uint8_t size;
union {
struct hdr_static_metadata *static;
struct hdr_metadata_dynamic *dynamic;
} metadata;
};
So that its easier when we are extending support for dynamic HDR ?

- Shashank

+
  #define DRM_MODE_PAGE_FLIP_EVENT 0x01
  #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
  #define 

Re: [v5 2/2] drm/i915: Attach colorspace property and enable modeset

[Sharma, Shashank]

Regards

Shashank


On 12/11/2018 11:44 PM, Uma Shankar wrote:

This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.

Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.

This patch attaches and enables HDMI colorspace, DP will be
taken care separately.

v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.

v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.

v5: Added Platform specific colorspace enums and called the
property creation helper using the same.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_atomic.c|  1 +
  drivers/gpu/drm/i915/intel_connector.c | 63 ++
  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_hdmi.c  | 18 ++
  4 files changed, 83 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index a5a2c8f..35ef70a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+   new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index 18e370f..59fa420 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -31,6 +31,48 @@
  #include "intel_drv.h"
  #include "i915_drv.h"
  
+static const struct drm_prop_enum_list gen10_hdmi_colorspace[] = {

+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
+static const struct drm_prop_enum_list legacy_hdmi_colorspace[] = {
+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+};
+
  int intel_connector_init(struct intel_connector *connector)
  {
struct intel_digital_connector_state *conn_state;
@@ -262,3 +304,24 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
  }
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_i915_private 

Re: [v5 1/2] drm: Add colorspace connector property

[Sharma, Shashank]

Regards

Shashank


On 12/11/2018 11:44 PM, Uma Shankar wrote:

This patch adds a colorspace connector property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.

v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.

v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
  drivers/gpu/drm/drm_connector.c   | 82 +++
  include/drm/drm_connector.h   | 17 
  include/uapi/drm/drm_mode.h   | 33 
  4 files changed, 136 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 86ac339..9df7520 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -729,6 +729,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -797,6 +799,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == connector->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index fa9baac..46928f7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
  };
  DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
  
+/* List of HDMI Colorspaces supported */

+static const struct drm_prop_enum_list hdmi_colorspace[] = {

Should we call this list hdmi_colorspaces :) ?

+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
+/* List of DP Colorspaces supported */

Same here for dp_colorspaces ?

+static const struct drm_prop_enum_list dp_colorspace[] = {
+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry 

Re: [v4 2/3] drm: Add DP colorspace property

[Sharma, Shashank]

Regards

Shashank


On 11/27/2018 10:10 PM, Uma Shankar wrote:

This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.

v2: Addressed Maarten and Ville's review comments. Enhanced
 the colorspace enum to incorporate both HDMI and DP supported
 colorspaces. Also, added a default option for colorspace.

v3: Split the changes to have separate colorspace property for
DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_connector.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 57d36e4..30e2e6f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
  };
  
+static const struct drm_prop_enum_list dp_colorspace[] = {

+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* DP MSA Colorimetry */
+   { DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+   { DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+   { DP_COLORIMETRY_SRGB, "sRGB" },
+   { DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+   { DP_COLORIMETRY_SCRGB, "scRGB" },
+   { DP_COLORIMETRY_DCI_P3, "DCI-P3" },
+   { DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Profile" },
+};
+
+
The same comments as previous patch, possibility of the platform specfic 
enum values being passed from the core driver. and DRM layer blindly 
registers it.

- Shashank

  /**
   * DOC: standard connector properties
   *
@@ -1454,6 +1477,14 @@ int drm_mode_create_colorspace_property(struct 
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspace));
if (!prop)
return -ENOMEM;
+   } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+   "Colorspace", dp_colorspace,
+   ARRAY_SIZE(dp_colorspace));
+   if (!prop)
+   return -ENOMEM;
}
  
  	connector->colorspace_property = prop;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v4 1/3] drm: Add HDMI colorspace property

[Sharma, Shashank]

Regards

Shashank


On 11/27/2018 10:10 PM, Uma Shankar wrote:

This patch adds a HDMI colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.

v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 +++
  drivers/gpu/drm/drm_connector.c   | 61 +++
  include/drm/drm_connector.h   | 14 +
  include/uapi/drm/drm_mode.h   | 33 +
  4 files changed, 112 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 86ac339..9df7520 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -729,6 +729,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -797,6 +799,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == connector->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index fa9baac..57d36e4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
  };
  DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
  
+static const struct drm_prop_enum_list hdmi_colorspace[] = {

+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
This still doesn't help us with the platform specific colorspace 
support, like:
Even for HDMI, Until GEN10, we don't want to add BT2020 colorspace enum 
values for Intel driver, which would be difficult to know for a user.


How about we modify the design a drm helper bit like this:
1. Keep the absolute_colorimetry_list as the full range of colorimetry 
enum values supported by DRM for HDMI display
2. Make the DRM helper accept a series/subset of these enum values, 
which will be passed from the core driver (like I915), and the DRM 
functions creates property with these passed values.
3. Call the DRM helper function from functions core driver function 
(like intel_ddi_init()) from where we already know:

- Which display to select enum values from (HDMI/DP)
- Which enum values to pick based on current platform (Like if GEN 
< GEN9, add dont add REC_2020 etc)


- Shashank

+};
+
  /**
   * DOC: 

Re: [v2 2/2] drm/i915: Attach colorspace property and enable modeset

[Sharma, Shashank]

Regards

Shashank


On 10/31/2018 5:35 PM, Uma Shankar wrote:

This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.

Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.

v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_atomic.c | 1 +
  drivers/gpu/drm/i915/intel_hdmi.c   | 5 +
  2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index a5a2c8f..35ef70a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+   new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 129b880..8a41fb3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -486,6 +486,8 @@ static void intel_hdmi_set_avi_infoframe(struct 
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
  
+	frame.avi.extended_colorimetry = conn_state->colorspace;

+
We must also set the date byte 2 bits C1-C0 (colorimetry part) to 
indicate the use of extended colorimetry bits, so that monitor will 
refer to extended colorimetry data, else it wont even bother looking at it:


Extended Colorimetry Information Valid (colorimetry indicated in bits 
EC0, EC1, and EC2)



Its right now set to dafault 0-0 I guess, indicating No data We should 
also set it to a default value now, when we have started bothering about 
gamut.


Regards
Shashank

drm_hdmi_avi_infoframe_quant_range(, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
@@ -2125,6 +2127,9 @@ static void intel_hdmi_destroy(struct drm_connector 
*connector)
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.colorspace_property,
+   COLORIMETRY_ITU_709);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
  }
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2 1/2] drm: Add colorspace property

[Sharma, Shashank]

Regards

Shashank


On 10/31/2018 5:35 PM, Uma Shankar wrote:

This patch adds a colorspace property enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.

v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.

Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/drm_atomic_uapi.c |  4 
  drivers/gpu/drm/drm_connector.c   | 44 +++
  include/drm/drm_connector.h   |  7 +++
  include/drm/drm_mode_config.h |  6 ++
  include/uapi/drm/drm_mode.h   | 24 +
  5 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f31..9e1d46b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -721,6 +721,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+   } else if (property == config->colorspace_property) {
+   state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -795,6 +797,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == config->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index aa18b1d..5ad52a0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,38 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
  };
  DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
  
+static const struct drm_prop_enum_list colorspace[] = {

+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "601" },
+   { COLORIMETRY_ITU_709, "709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "s601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_ADOBE_YCC_601, "adobe601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_ADOBE_RGB, "adobe_rgb" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_RGB, "BT2020_rgb" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_YCC, "BT2020_ycc" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_CYCC, "BT2020_cycc" },
+   /* DP MSA Colorimetry */
+   { COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+   { COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+   { COLORIMETRY_SRGB, "SRGB" },
+   { COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+   { COLORIMETRY_SCRGB, "SCRGB" },
+   { COLORIMETRY_DCI_P3, "DCIP3" },
+   { COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Proflie" },
+   /* FOR HD 720p+, Default Colorimetry is based on ITU-R BT.709 */
+   { COLORIMETRY_DEFAULT, "Default: ITU_709" },
+};
+
  /**
   * DOC: standard connector properties
   *
@@ -972,6 +1004,12 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
   *can also expose this property to external outputs, in which case they
   *must support "None", which should be the default (since external screens
   *have a built-in scaler).
+ *
+ * colorspace:
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace.
As commented on the previous patch, we might have to consider the HW 
capability while doing this.

   */
  
  int drm_connector_create_standard_properties(struct drm_device *dev)

@@ -1020,6 +1058,12 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
  
+	prop = drm_property_create_enum(dev, 

Re: [v2 0/2] Add Colorspace connector property interface

[Sharma, Shashank]

Hello Uma,

My comments inline.


On 10/31/2018 5:35 PM, Uma Shankar wrote:

This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Kernel will not give the supported colorspaces since
this is panel dependent and our curremt property infrastructure is
not supporting it.
I am not very sure about this part, consider a situation where, I have 
connected a HDMI 2.0 monitor which supports BT2020 gamut, to a GEN9 
device, running an user-space which can also support BT2020 playback / 
HDR playback. Now, both monitor and user-space supports BT2020 playback, 
but the HW doesn't, and this will create a problem during playback. So I 
gess we need to expose a kernel Cap or property to showcase if the HW 
can support BT2020/DCI-P3 gamut space or not.


- Shashank

Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"

v2: Addressed Ville and Maarten's review comments. Merged the 2nd
and 3rd patch into one common logical patch.

Uma Shankar (2):
   drm: Add colorspace property
   drm/i915: Attach colorspace property and enable modeset

  drivers/gpu/drm/drm_atomic_uapi.c   |  4 
  drivers/gpu/drm/drm_connector.c | 44 +
  drivers/gpu/drm/i915/intel_atomic.c |  1 +
  drivers/gpu/drm/i915/intel_hdmi.c   |  5 +
  include/drm/drm_connector.h |  7 ++
  include/drm/drm_mode_config.h   |  6 +
  include/uapi/drm/drm_mode.h | 24 
  7 files changed, 91 insertions(+)



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

[Sharma, Shashank]

Regards

Shashank


On 10/15/2018 4:39 PM, Jani Nikula wrote:

On Mon, 15 Oct 2018, Jani Nikula  wrote:

On Fri, 05 Oct 2018, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct
definitions in the header for the mask to work correctly.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
Signed-off-by: Clint Taylor 

When posting fixes like this, please do git blame on the stuff you're
fixing, and add Fixes: tag and a bunch of Cc's. It'll help us propagate
the fix to stable kernels and get feedback from the authors and
reviewers. 'dim fixes' will help you with this:

$ dim fixes e6a9a2c3dc437
Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information")
Cc: Ville Syrjälä 
Cc: Jose Abreu 
Cc: Shashank Sharma 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.14+

Anyway this looks sane to me,

Reviewed-by: Jani Nikula 

but I'm wondering if there was some deeper meaning to the original |= in
there.
Honestly, I was considering new blocks in HDMI 2.1 spec for dc, and 
parsing of those before this block, keeping |= required.
But we can always do other way around, or will take care of it when we 
add code for it.

Just cross checked with the spec too,

Reviewed-by: Shashank Sharma 

- Shashank


PS. It'll be useful to repost this Cc: intel-gfx just to get the CI as
we seem to be the only consumer of the stuff being fixed.



BR,
Jani.



---
  drivers/gpu/drm/drm_edid.c | 2 +-
  include/drm/drm_edid.h | 6 +++---
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1e2b940..ff0bfc6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4282,7 +4282,7 @@ static void drm_parse_ycbcr420_deep_color_info(struct 
drm_connector *connector,
struct drm_hdmi_info *hdmi = >display_info.hdmi;
  
  	dc_mask = db[7] & DRM_EDID_YCBCR420_DC_MASK;

-   hdmi->y420_dc_modes |= dc_mask;
+   hdmi->y420_dc_modes = dc_mask;
  }
  
  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b25d12e..e3c4048 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -214,9 +214,9 @@ struct detailed_timing {
  #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
  
  /* YCBCR 420 deep color modes */

-#define DRM_EDID_YCBCR420_DC_48  (1 << 6)
-#define DRM_EDID_YCBCR420_DC_36  (1 << 5)
-#define DRM_EDID_YCBCR420_DC_30  (1 << 4)
+#define DRM_EDID_YCBCR420_DC_48  (1 << 2)
+#define DRM_EDID_YCBCR420_DC_36  (1 << 1)
+#define DRM_EDID_YCBCR420_DC_30  (1 << 0)
  #define DRM_EDID_YCBCR420_DC_MASK (DRM_EDID_YCBCR420_DC_48 | \
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/scdc-helper: Convert errors into debug messages

[Sharma, Shashank]

Reviewed-by: Shashank Sharma 

Regards
Shashank
On 3/23/2018 11:55 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Since we may attempt to reconfigure SCDC when the sink has already been
disconnected we probably shouldn't scare the user with errors in dmesg
that are 100% expected in that case. Just leave it up to the caller
whether to print an error message or not, and just output debug
messages from the helper itself.

Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_scdc_helper.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index 657ea5ab6c3f..870e25f1f788 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -141,7 +141,7 @@ bool drm_scdc_get_scrambling_status(struct i2c_adapter 
*adapter)
  
  	ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );

if (ret < 0) {
-   DRM_ERROR("Failed to read scrambling status: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read scrambling status: %d\n", ret);
return false;
}
  
@@ -168,7 +168,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
  
  	ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );

if (ret < 0) {
-   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
return false;
}
  
@@ -179,7 +179,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
  
  	ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);

if (ret < 0) {
-   DRM_ERROR("Failed to enable scrambling: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to enable scrambling: %d\n", ret);
return false;
}
  
@@ -223,7 +223,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter *adapter, bool set)
  
  	ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );

if (ret < 0) {
-   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
return false;
}
  
@@ -234,7 +234,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter *adapter, bool set)
  
  	ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);

if (ret < 0) {
-   DRM_ERROR("Failed to set TMDS clock ratio: %d\n", ret);
+   DRM_DEBUG_KMS("Failed to set TMDS clock ratio: %d\n", ret);
return false;
}
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Sharma, Shashank]

Regards

Shashank


On 3/1/2018 6:54 PM, Ville Syrjälä wrote:

On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 2/24/2018 12:55 AM, Ville Syrjala wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

While we want to potentially support multiple different gamma/degamma
LUT sizes we can (and should) at least check that the blob length
is a multiple of the LUT entry size.

I dint understand the exact idea behind doing this, how is this going to
benefit ? May be a bit more description ?

The benefit is rejecting garbage fed in from userspace.


Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
   drivers/gpu/drm/drm_atomic.c | 15 +++
   1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8945357212ba..933edec0299d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
 struct drm_property_blob **blob,
 uint64_t blob_id,
 ssize_t expected_size,
+ssize_t expected_size_mod,
 bool *replaced)
   {
struct drm_property_blob *new_blob = NULL;
@@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
if (new_blob == NULL)
return -EINVAL;
   
-		if (expected_size > 0 && expected_size != new_blob->length) {

+   if (expected_size > 0 &&
+   new_blob->length != expected_size) {
+   drm_property_blob_put(new_blob);
+   return -EINVAL;
+   }

One line needed here, matching the previous if() pattern

What line? Don't understand.
I mean, I can see a blank line before previous if() condition, so lets 
keep the same pattern for this if() too


- Shashank

+   if (expected_size_mod > 0 &&
+   new_blob->length % expected_size_mod != 0) {
drm_property_blob_put(new_blob);
return -EINVAL;
}
@@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>ctm,
val,
-   sizeof(struct drm_color_ctm),
+   sizeof(struct drm_color_ctm), -1,
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>gamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Sharma, Shashank]

Regards

Shashank


On 2/24/2018 12:55 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

While we want to potentially support multiple different gamma/degamma
LUT sizes we can (and should) at least check that the blob length
is a multiple of the LUT entry size.
I dint understand the exact idea behind doing this, how is this going to 
benefit ? May be a bit more description ?


Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_atomic.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8945357212ba..933edec0299d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
 struct drm_property_blob **blob,
 uint64_t blob_id,
 ssize_t expected_size,
+ssize_t expected_size_mod,
 bool *replaced)
  {
struct drm_property_blob *new_blob = NULL;
@@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
if (new_blob == NULL)
return -EINVAL;
  
-		if (expected_size > 0 && expected_size != new_blob->length) {

+   if (expected_size > 0 &&
+   new_blob->length != expected_size) {
+   drm_property_blob_put(new_blob);
+   return -EINVAL;
+   }

One line needed here, matching the previous if() pattern

+   if (expected_size_mod > 0 &&
+   new_blob->length % expected_size_mod != 0) {
drm_property_blob_put(new_blob);
return -EINVAL;
}
@@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>ctm,
val,
-   sizeof(struct drm_color_ctm),
+   sizeof(struct drm_color_ctm), -1,
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>gamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] drm: Remove now pointelss blob->data casts

[Sharma, Shashank]

Regards

Shashank


On 2/24/2018 12:55 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

Now that blob->data is void* again we don't need the casts anymore.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_atomic.c| 3 +--
  drivers/gpu/drm/drm_atomic_helper.c | 2 +-
  drivers/gpu/drm/drm_edid.c  | 3 +--
  drivers/gpu/drm/drm_fb_helper.c | 2 +-
  drivers/gpu/drm/drm_plane.c | 2 +-
  5 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d534587..8945357212ba 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -391,8 +391,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state 
*state,
if (blob) {
if (blob->length != sizeof(struct drm_mode_modeinfo) ||
drm_mode_convert_umode(state->crtc->dev, >mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+  blob->data))
return -EINVAL;
  
  		state->mode_blob = drm_property_blob_get(blob);

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe9e01c..6211a1b20405 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3816,7 +3816,7 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
}
  
  	/* Prepare GAMMA_LUT with the legacy values. */

-   blob_data = (struct drm_color_lut *) blob->data;
+   blob_data = blob->data;
for (i = 0; i < size; i++) {
blob_data[i].red = red[i];
blob_data[i].green = green[i];
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 788fee4b4bf9..134069f36482 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1575,8 +1575,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
struct edid *override = NULL;
  
  	if (connector->override_edid)

-   override = drm_edid_duplicate((const struct edid *)
- connector->edid_blob_ptr->data);
+   override = drm_edid_duplicate(connector->edid_blob_ptr->data);
  
  	if (!override)

override = drm_load_edid_firmware(connector);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd133..0646b108030b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1351,7 +1351,7 @@ static struct drm_property_blob 
*setcmap_new_gamma_lut(struct drm_crtc *crtc,
if (IS_ERR(gamma_lut))
return gamma_lut;
  
-	lut = (struct drm_color_lut *)gamma_lut->data;

+   lut = gamma_lut->data;
if (cmap->start || cmap->len != size) {
u16 *r = crtc->gamma_store;
u16 *g = r + crtc->gamma_size;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 09de6ecb3968..9851616cf0f3 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -104,7 +104,7 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
if (IS_ERR(blob))
return -1;
  
-	blob_data = (struct drm_format_modifier_blob *)blob->data;

+   blob_data = blob->data;

Reviewed-by: Shashank Sharma 

blob_data->version = FORMAT_BLOB_CURRENT;
blob_data->count_formats = plane->format_count;
blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] Revert "drm: Use a flexible array member for blob property data"

[Sharma, Shashank]

Regards

Shashank


On 2/24/2018 12:55 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

Using a flexible array for the blob data was a mistake by me. It
forces all users of the blob data to cast blob->data to something
else. void* is clearly superior so let's go back to the original
scheme.

Not a clean revert as the code has moved.

This reverts commit d63f5e6bf6f2a1573ea39c9937cdf5ab0b3a4b77.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_property.c | 1 +
  include/drm/drm_property.h | 2 +-
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6b819d..0f6620fea3de 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -550,6 +550,7 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
/* This must be explicitly initialised, so we can safely call list_del
 * on it in the removal handler, even if it isn't in a file list. */
INIT_LIST_HEAD(>head_file);
+   blob->data = (void *)blob + sizeof(*blob);
blob->length = length;
blob->dev = dev;
  
diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h

index 8a522b4bed40..265fd1f2e112 100644
--- a/include/drm/drm_property.h
+++ b/include/drm/drm_property.h
@@ -209,7 +209,7 @@ struct drm_property_blob {
struct list_head head_global;
struct list_head head_file;
size_t length;
-   unsigned char data[];
+   void *data;
  };
  
  struct drm_prop_enum_list {

Reviewed-by: Shashank Sharma 

Regards
Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 05/11] drm/edid: Clear display info fully

[Sharma, Shashank]

Regards

Shashank


On 2/27/2018 6:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Now that we have split the display info into static and dynamic parts,
we can just zero out the entire dynamic part with memset(). Previously
we were just clearing parts of it, leaving stale data in other parts
(eg. HDMI SCDC capabilities).

Also when the edid is NULL drm_add_edid_modes() bails out early skipping
the call to drm_add_display_info(). Thus we would again leave stale
data behind. To avoid that let's clear out the display info at the
very start of drm_add_edid_modes().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_connector.c |  3 +--
  drivers/gpu/drm/drm_edid.c  | 23 +++
  2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d73e97ed7dff..ddd7d978f462 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1389,10 +1389,9 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 * duplicate it rather than attempt to ensure some arbitrary
 * ordering of calls.
 */
+   drm_reset_display_info(connector);
if (edid)
drm_add_display_info(connector, edid);
-   else
-   drm_reset_display_info(connector);
  
  	drm_object_property_set_value(>base,

  dev->mode_config.non_desktop_property,
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 788fee4b4bf9..78c1f37be3db 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4443,37 +4443,18 @@ drm_reset_display_info(struct drm_connector *connector)
  {
struct drm_display_info *info = >display_info;
  
-	info->width_mm = 0;

-   info->height_mm = 0;
-
-   info->bpc = 0;
-   info->color_formats = 0;
-   info->cea_rev = 0;
-   info->max_tmds_clock = 0;
-   info->dvi_dual = false;
-   info->has_hdmi_infoframe = false;
-
-   info->non_desktop = 0;
+   memset(info, 0, sizeof(*info));
  }
  EXPORT_SYMBOL_GPL(drm_reset_display_info);
  
  u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid)

  {
struct drm_display_info *info = >display_info;
-
u32 quirks = edid_get_quirks(edid);
  
  	info->width_mm = edid->width_cm * 10;

info->height_mm = edid->height_cm * 10;
  
-	/* driver figures it out in this case */

-   info->bpc = 0;
-   info->color_formats = 0;
-   info->cea_rev = 0;
-   info->max_tmds_clock = 0;
-   info->dvi_dual = false;
-   info->has_hdmi_infoframe = false;
-
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
  
  	DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);

@@ -4684,6 +4665,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
int num_modes = 0;
u32 quirks;
  
+	drm_reset_display_info(connector);
How about if we move the call to drm_reset_display_info() within 
drm_add_display_info() ?

something like:
drm_add_display_info()
{
struct drm_display_info *info = >display_info;
u32 quirks = edid_get_quirks(edid);

drm_reset_display_info();

info->width_mm = edid->width_cm * 10;
info->height_mm = edid->height_cm * 10;
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);

..
}

- Shashank

+
if (edid == NULL) {
clear_eld(connector);
return 0;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Sharma, Shashank]

for I915: Acked-by: Shashank Sharma 

Regards
Shashank
On 2/27/2018 6:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Hans de Goede 
Cc: Shashank Sharma 
Cc: Stefan Agner 
Cc: Thierry Reding 
Cc: Boris Brezillon 
Cc: Philipp Zabel 
Cc: Laurent Pinchart 
Cc: Manfred Schlaegl 
Cc: Marek Vasut 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Alison Wang 
Cc: Eric Anholt 
Cc: Linus Walleij 
Cc: linux-renesas-...@vger.kernel.org
Cc: Maxime Ripard 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   2 +-
  drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |   2 +-
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   2 +-
  drivers/gpu/drm/bridge/sii902x.c   |   2 +-
  drivers/gpu/drm/bridge/tc358767.c  |   2 +-
  drivers/gpu/drm/drm_connector.c|  12 +-
  drivers/gpu/drm/drm_fb_helper.c|   2 +-
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-
  drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
  drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 +-
  drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
  drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
  drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
  drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
  drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
  drivers/gpu/drm/i915/intel_dsi.c   |   4 +-
  drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
  drivers/gpu/drm/i915/intel_lvds.c  |   2 +-
  drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
  drivers/gpu/drm/imx/parallel-display.c |   2 +-
  drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
  drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
  drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
  drivers/gpu/drm/panel/panel-lvds.c |   4 +-
  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
  drivers/gpu/drm/panel/panel-simple.c   |   4 +-
  drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
  drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
  drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
  drivers/gpu/drm/tve200/tve200_display.c|   2 +-
  drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
  include/drm/drm_connector.h| 123 -
  36 files changed, 125 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 74d2efaec52f..1ba72dc2a85b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1927,7 +1927,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
  
-	connector->display_info.subpixel_order = subpixel_order;

+   connector->static_display_info.subpixel_order = subpixel_order;
drm_connector_register(connector);
  
  	if (has_aux)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c 
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 120dd3b26fc2..7e9f7f1ab1b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -639,7 +639,7 @@ static int 

Re: [PATCH v3 3/8] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 1/17/2018 8:59 PM, Ville Syrjälä wrote:

On Wed, Jan 17, 2018 at 02:35:40PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma <shashank.sha...@intel.com>
Cc: "Lin, Jia" <lin.a@intel.com>
Cc: Akashdeep Sharma <akashdeep.sha...@intel.com>
Cc: Jim Bride <jim.br...@linux.intel.com>
Cc: Jose Abreu <jose.ab...@synopsys.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Emil Velikov <emil.l.veli...@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
   drivers/gpu/drm/drm_edid.c | 18 ++
   1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1818a71..3d57c41 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2908,11 +2908,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
   static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

return 0;
   
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2926,7 +2930,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
   
   		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2943,11 +2947,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
*/
   u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

return 0;
   
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+

How about stereo flags ? CEA modes can be 3d and in that case we might
want to add DRM_MODE_MATCH_3D_FLAGS here

There are no separate VICs for stereo vs. no stereo. So ignoring the
stereo flags here seems like the correct thing to do.

Agree,
Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>

- Shashank

for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2961,7 +2969,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
   
   		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3008,6 +3016,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
   static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

@@ -3025,7 +3034,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
   
-		if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)

Re: [PATCH v3 1/8] drm/modes: Introduce drm_mode_match()

[Sharma, Shashank]

Regards

Shashank


On 1/17/2018 8:51 PM, Ville Syrjälä wrote:

On Wed, Jan 17, 2018 at 02:11:55PM +0530, Sharma, Shashank wrote:


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
   drivers/gpu/drm/drm_modes.c | 134 
++--
   include/drm/drm_modes.h |   9 +++
   2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a..8128dbb 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
   }
   EXPORT_SYMBOL(drm_mode_duplicate);
   
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,

+  const struct drm_display_mode *mode2)

Shouldn't the second parameter be aligned to next char after the opening
bracket in above line (instead of being align to the bracket) ?

It is. The extra junk at the start of the line is causing the alignment
to look wrong when it's not because the tab stops are still aligned to
the start of the line. This is one reason why I think that using tabs
for alignment isn't a particularly great idea.


I have this same comment for most of the functions in this patch.

+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,

Should we call it drm_mode_match_flag_no_stereo ?

It's not really "no stereo", rather it's "check all the flags not being
checked by something more specific".

Yeah, anyways no big deal. With or without, feel free to use my r-b
- Shashank

+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
   /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
* @mode1: first mode
* @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
*
* Check to see if @mode1 and @mode2 are equivalent.
*
* Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
*/
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
   {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
   
-	/* do clock check convert to PICOS so fb modes get matched

-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   

Re: [PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[Sharma, Shashank]

Regards

Shashank


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
---
  drivers/gpu/drm/drm_ioctl.c | 5 +
  include/drm/drm_file.h  | 7 +++
  include/uapi/drm/drm.h  | 7 +++
  3 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe48..e092550 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..6e0e435 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,13 @@ struct drm_file {
unsigned atomic:1;
  
  	/**

+* @aspect_ratio_allowed:
+*
+* True if client has asked to expose the aspect-ratio flags with mode.
Minor reword, may be "True if client can handle picture aspect ratios, 
and has requested to pass this information along with the mode"

+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..fe5f531 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
   */
  #define DRM_CLIENT_CAP_ATOMIC 3
  
+/**

+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will expose aspect ratio flags to userspace.
+ */
Again "If set to 1, the DRM core will provide aspect ratio information 
in modes"

+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
  struct drm_set_client_cap {
__u64 capability;

With these optional review comments, please feel free to use
Reviewed-by: Shashank Sharma 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/8] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1818a71..3d57c41 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2908,11 +2908,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
  static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2926,7 +2930,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2943,11 +2947,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
   */
  u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
How about stereo flags ? CEA modes can be 3d and in that case we might 
want to add DRM_MODE_MATCH_3D_FLAGS here


- Shashank

for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2961,7 +2969,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3008,6 +3016,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
  static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

@@ -3025,7 +3034,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
  
-		if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))

+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
  
@@ -3042,6 +3051,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_

   */
  static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

@@ -3057,7 +3067,7 @@ static 

Re: [PATCH v3 2/8] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Sharma, Shashank]

Regards
Shashank

On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd5379..1818a71 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3025,7 +3025,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
  
-		if (drm_mode_equal_no_clocks(to_match, hdmi_mode))

+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}

Reviewed-by: Shashank Sharma 
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/8] drm/modes: Introduce drm_mode_match()

[Sharma, Shashank]

On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_modes.c | 134 ++--
  include/drm/drm_modes.h |   9 +++
  2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a..8128dbb 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
  }
  EXPORT_SYMBOL(drm_mode_duplicate);
  
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,

+  const struct drm_display_mode *mode2)
Shouldn't the second parameter be aligned to next char after the opening 
bracket in above line (instead of being align to the bracket) ?

I have this same comment for most of the functions in this patch.

+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,

Should we call it drm_mode_match_flag_no_stereo ?

+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
  /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
   * @mode1: first mode
   * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
   *
   * Check to see if @mode1 and @mode2 are equivalent.
   *
   * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
   */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
  {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
  
-	/* do clock check convert to PICOS so fb modes get matched

-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
return false;
  
-	return drm_mode_equal_no_clocks(mode1, mode2);

+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ 

Re: [REBASE 3/5] drm: Expose modes with aspect ratio, only if requested

[Sharma, Shashank]

Regards

Shashank


On 11/21/2017 10:41 PM, Ville Syrjälä wrote:

On Fri, Nov 17, 2017 at 03:00:30PM +0530, Shashank Sharma wrote:

From: aknautiy 

We parse the EDID and add all the modes in the connector's
modelist. This adds CEA modes with aspect ratio information
too, regadless of if user space requested this information or
not.

This patch prunes the modes with aspect-ratio information, from
a connector's modelist, if the user-space has not set the aspect
ratio DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: aknautiy 
---
  drivers/gpu/drm/drm_connector.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc89..a246bb5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE)
+   return false;

I don't think we can just blindly drop the modes. We would have to
expose them with the aspect ratio cleared. That could lead to
duplicates, but I'm thinking that shouldn't be a real problem for
userspace. Having to filteri out the duplicates would certainly
complicate things a bit.

Yes, Agree. Even I was thinking that the right way should be to:
- add a drm_mode_equal_no_aspect function (like 
drm_mode_equal_no_clock_no_stereo).

- clear the aspect ratio information from the mode, when not asked for.
- check the sorted connector->modes list for duplicates for this mode, 
using above function.

- if mode exists, remove it from the list
- if not, keep it in the list

Sounds like a plan ?

- Shashank
  
  	return true;

  }
--
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel