Created attachment 143404 [details] HDCP Log plus kernel log -- system architecture: x86-64 -- kernel version: 5.0.0-rc6 from http://cgit.freedesktop.org/drm-tip -- Linux distribution: Ubuntu 18.04.1 LTS -- Machine or mother board model: Intel Kaby Lake -- Display connector: HDMI -- Test Device: SL-8800 HDCP Compliance Instrument Two HDCP Compliance test cases failed when hdp_time is set to 100ms in SL-8800 Test Suite. However, these two test cases passed when hpd_time is set to 3s. On Leaf Hill Yocto, all hdcp compliance test cases are able to pass with hpd_time 100ms. Yocto is still with kernel 4.14. Attached is the compliance log with kernel log after enabling 0xe > /sys/module/drm/parameters/debug.
Issue is also reproducible on APL.
Hi, For compliance of HDCP1.4, we need to pass the tests mentioned at https://www.digital-cp.com/sites/default/files/specifications/HDCPSpecificationComplianceTestSpecification1_2.pdf I don't see any mentioning of hpd_time restriction in the compliance test specification shared above. Am I missing something? Could you please cross verify and come back on this?
HI, I’m from IOTG ASPE software validation. All the observation of logs and bugs was provided to Khairul by us. Just to make it clear that there is no restriction for validating 1A-02 & 03 for the HDP timer which is 100ms and that is just a default setting value. As we debug further, we've discovered the tolerance HDP timer is 2200ms. Having said that, it means the test will pass if HPD is set above or equal to 2200ms. There is no acceptance criteria written in our test case for this HPD timer. As per our understanding, this is due to either Intel KMD driver or Hardware performance limitation or both. So we’re depending on Khairul to debug further on Intel KMD as for now.
Hi, We also need help from Ram to debug on the intel_hdcp KMD because if we use hdcp legacy that do not go through intel hdcp kmd, all the tests able to pass even with 100ms test configuration.
(In reply to Edward Tan from comment #3) > Just to make it clear that there is no > restriction for validating 1A-02 & 03 for the HDP timer which is 100ms and > that is just a default setting value. So can we infer that this issue doesn't block the compliance clearance? BTW, what does this HPD_Timer setting stand for? Duration for which monitor is off(plugged out)? From the log attached, we can see that after the hot-unplug and hot-plug HDCP src is not starting the authentication. Two reasons possible: 1. During hotplug out, EDID is still available on DDC. But since with larger HPD_Timer, this is working. so this is ruled out. 2. I915 is not processing the Hotplug event within 100mSec!? regression in 5.0? as it is ok with the older kernel. Few more basic questions to understand the compliance setup: 1. How do you initiate the HDCP authentication from userspace? 2. For each hot-plug event, we need to start the rendering of FB and then HDCP authentication. How are we doing it?
> On Leaf Hill Yocto, all hdcp compliance test cases are able to pass with > hpd_time 100ms. Yocto is still with kernel 4.14. Whether do you have any additional non-upstreamed patches in this kernel?
(In reply to Ramalingam C from comment #6) > > On Leaf Hill Yocto, all hdcp compliance test cases are able to pass with > > hpd_time 100ms. Yocto is still with kernel 4.14. > > Whether do you have any additional non-upstreamed patches in this kernel? Ram, Yocto 4.14 is not using intel_hdcp kmd but using hdcp legacy call to enable hdcp directly from User Space. Even using later kernel + hdcp legacy implementation the failure test cases are able to pass with default test setup (100ms).
(In reply to Ramalingam C from comment #6) > > On Leaf Hill Yocto, all hdcp compliance test cases are able to pass with > > hpd_time 100ms. Yocto is still with kernel 4.14. > > Whether do you have any additional non-upstreamed patches in this kernel? Hi Ram, I tested the legacy hdcp 1.4 soluction on kernel drm-tip 5.0 without any non-upstreamed patches, the 1a-02 and 1a-03 compliance cases passed with 100ms hpd time configuration, however the uapi + hdcp_kmd solution failed.
(In reply to Ramalingam C from comment #5) > (In reply to Edward Tan from comment #3) > > Just to make it clear that there is no > > restriction for validating 1A-02 & 03 for the HDP timer which is 100ms and > > that is just a default setting value. > > So can we infer that this issue doesn't block the compliance clearance? > > BTW, what does this HPD_Timer setting stand for? Duration for which monitor > is off(plugged out)? > > From the log attached, we can see that after the hot-unplug and hot-plug > HDCP src is not starting the authentication. > > Two reasons possible: > 1. During hotplug out, EDID is still available on DDC. But since with larger > HPD_Timer, this is working. so this is ruled out. > 2. I915 is not processing the Hotplug event within 100mSec!? regression in > 5.0? as it is ok with the older kernel. > > Few more basic questions to understand the compliance setup: > 1. How do you initiate the HDCP authentication from userspace? > 2. For each hot-plug event, we need to start the rendering of FB and then > HDCP authentication. How are we doing it? Userspace will retrigger enablement after detecting hotplug-in event. For each hot plut in event, the hdcp daemon resets the Content Protection drm property to desired via drmIoctl call, and what's does the "start the rendering of FB" mean here?
From the discussion with compliance execution team here, HPD_Timer is the delay allowed by the analyzer, to start the HDCP authentication after an HPD detection. So we need to check the turnaround time in our whole stack KMD & UMD. So Khairul and Shiqiang, Could you please measure the time required for below activities on compliance setup. 1. Time taken to broadcast the hotplug uevent from kernel after the HPD detection. 2. Time taken to receive the HDCP request from userspace after the hotplug uevent broadcast from the kernel. 3. Time taken to start the HDCP auth after atomic request. Basically, at the kernel, capture the time of 1. hpd detection 2. hotplug uevent broadcast 3. atomic request arrival at kernel for HDCP 4. HDCP authentication start at intel_hdcp.c
Khairul/Shiqiang , can you address Comment 10?
Khairul/Shiqiang, any progress with this bug?
No feedback from more than 2 months, closing this bug WORKSFORME.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.