Hi Chris,
Thanks for the comments.
I will try out the changes you have mentioned for counting vblanks.
For other comments please find the responses inline.
On 9/23/2016 6:48 PM, Chris Wilson wrote:
On Fri, Sep 23, 2016 at 06:10:29PM +0530, Nautiyal Ankit wrote:
From: Ramalingam C
As per discussion with Chris, on IRC following were the suggestions :
- Chris has suggested an event based approach to avoid using pthreads.
- Avoid using kernel-specific info like transitional delays and instead
use either polling or wait-for-event approach. Need to focus on
user-observable
On 5/5/2018 1:49 AM, Ville Syrjälä wrote:
On Thu, May 03, 2018 at 08:26:26AM +0200, Daniel Vetter wrote:
On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
We parse the EDID and add all the modes in the connector's mo
On 5/7/2018 5:58 PM, Ville Syrjälä wrote:
On Mon, May 07, 2018 at 10:34:53AM +0530, Nautiyal, Ankit K wrote:
On 5/5/2018 1:49 AM, Ville Syrjälä wrote:
On Thu, May 03, 2018 at 08:26:26AM +0200, Daniel Vetter wrote:
On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote:
From
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: 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
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ä
Reviewed-by: Shashank Sharma
---
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
From: Ankit Nautiyal
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
whether user space requested this information or not.
This patch prunes the modes with aspect-ratio
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the
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: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
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ä
Reviewed-by: Shashank Sharma
---
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a
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
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch:
-prunes the modes with aspect-ratio
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise
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
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a
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ä
Reviewed-by: Shashank Sharma
---
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: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch:
-prunes the modes with aspect-ratio
On 4/27/2018 7:24 PM, Ville Syrjälä wrote:
On Fri, Apr 27, 2018 at 05:44:53PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the
On 4/27/2018 7:35 PM, Ville Syrjälä wrote:
On Fri, Apr 27, 2018 at 05:44:54PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, reg
Hi Mika,
Thanks for the review.
Please find my comments inline:
On 2/12/2018 8:04 PM, Kahola, Mika wrote:
On Wed, 2018-01-24 at 18:20 +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
This patch adds the support to print the aspect ratio of the
From: Ankit Nautiyal
This patch adds the support to test the modes with aspect ratios.
If the kernel supports the aspect ratio capabilities, the modes
with aspect ratios are set one by one.
This test is a means to verify the drm patch series :Aspect ratio
support in
From: Ankit Nautiyal
This patch series provides a means to test the aspect ratio support
in DRM layer.
https://patchwork.freedesktop.org/series/33984/
Patch 1: adds support to print aspect ratio information for a mode.
Patch 2: modifies the testdisplay to test modes
From: Ankit Nautiyal
This patch adds the support to print the aspect ratio of the modes
(if provided) along with other mode information.
Signed-off-by: Ankit Nautiyal
---
lib/igt_kms.c | 31 +--
1 file
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the
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
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ä
Reviewed-by: Shashank Sharma
---
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, then getblob called
with the blob id of a user-mode, should clear the aspect-ratio
information in the blob data.
Currently for a given blob id, there is no way to determine if the
blob stores
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
From: Ankit Nautiyal
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
whether user space requested this information or not.
This patch prunes the modes with aspect-ratio
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.
To avoid this, a new drm
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due
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: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise
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ä
Reviewed-by: Shashank Sharma
---
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series
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: Ankit Nautiyal
This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.
Signed-off-by: Ankit Nautiyal
---
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
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.
To avoid this, a new drm
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
From: Ankit Nautiyal
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
whether user space requested this information or not.
This patch prunes the modes with aspect-ratio
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due
of
modes in the connector modelist is increased by 2, resulting in failure
of assertion 'mode_count==13'.
Perhaps this need to be handled in the test.
-Regards,
Ankit
On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:
From: "Sharma, Shashank" <shashank.sha...@intel.com>
Current DRM layer fu
On 4/6/2018 11:14 PM, Ville Syrjälä wrote:
On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
This patch is causing failure of IGT test kms_3d. The kms_3d test
expects the no. of 3d modes to be 13.
(The test has hard-coded value for expected no. of 3d modes as 13)
But due
On 4/17/2018 11:17 PM, Ville Syrjälä wrote:
On Tue, Apr 17, 2018 at 10:45:07AM +0530, Nautiyal, Ankit K wrote:
On 4/6/2018 11:14 PM, Ville Syrjälä wrote:
On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
This patch is causing failure of IGT test kms_3d. The kms_3d test
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not
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
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch prunes the modes with aspect-ratio
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.
To avoid this, a new drm
From: Ankit Nautiyal
This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.
Signed-off-by: Ankit Nautiyal
---
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due
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: 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ä
Reviewed-by: Shashank Sharma
---
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series
On 4/20/2018 7:52 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio informati
On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in ex
On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the
On 4/23/2018 3:52 PM, Jani Nikula wrote:
On Mon, 23 Apr 2018, "Nautiyal, Ankit K" <ankit.k.nauti...@intel.com> wrote:
On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti.
On 4/23/2018 3:43 PM, Ville Syrjälä wrote:
On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:
On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal <ankit.k.nauti...@intel.com>
This patc
From: Ankit Nautiyal
Currently, the transcoder port sync feature is not available, due to
which the 5K-tiled dual DP monitors experience corruption when
2560x2880 mode is applied for both of the tiled DP connectors.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97244
There is a patch
tile_is_single_monitor = 1
tile_group_id = 1
num_h_tile = 2
num_v_tile = 1
tile_h_loc = 1
tile_v_loc = 0
tile_h_size = 2560
tile_v_size = 2880
Regards,
Ankit
On 8/27/2019 1:09 PM, Sharma, Shashank wrote:
Hello Ankit,
On 8/27/2019 11:59 AM, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal
Cu
wrote:
On Tue, 27 Aug 2019, Manasi Navare wrote:
On Tue, Aug 27, 2019 at 01:34:15PM +0300, Jani Nikula wrote:
On Tue, 27 Aug 2019, "Nautiyal, Ankit K" wrote:
From: Ankit Nautiyal
Currently, the transcoder port sync feature is not available, due to
which the 5K-tiled dual DP monitors
On 8/30/2019 12:06 AM, Navare, Manasi D wrote:
On Thu, Aug 29, 2019 at 02:36:18PM +0300, Jani Nikula wrote:
On Thu, 29 Aug 2019, "Nautiyal, Ankit K" wrote:
Hi Jani, Manasi,
Thanks for the comments and suggestions. Please find my response inline.
On 8/29/2019 12:14 PM, Jani Ni
, Ankit K wrote:
On 8/30/2019 12:06 AM, Navare, Manasi D wrote:
On Thu, Aug 29, 2019 at 02:36:18PM +0300, Jani Nikula wrote:
On Thu, 29 Aug 2019, "Nautiyal, Ankit K"
wrote:
Hi Jani, Manasi,
Thanks for the comments and suggestions. Please find my response
inline.
On 8/29/2019 12:1
From: Ankit Nautiyal
Currently the offset for PIPE D cursor control register is missing in
i915_reg.h due to which the cursor plane cannot be enabled for Pipe D.
This also causes kernel Warning, when a user requests to enable cursor
plane for PIPE D for Gen 12 platforms.
This patch adds the
From: Ankit Nautiyal
Currently the offset for PIPE D cursor control register is missing in
i915_reg.h due to which the cursor plane cannot be enabled for Pipe D.
This also causes kernel Warning, when a user requests to enable cursor
plane for PIPE D for Gen 12 platforms.
This patch adds the
Hi Jani,
Thanks for the comments and suggestions. Please find my response inline.
On 5/27/2020 7:44 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the
On 5/27/2020 7:48 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The vesion
requested via debugfs needs to be stored in hdcp structure. This can
then be
Hi Anshuman,
Thanks for the review comments and suggestions.
Please find my response inline:
On 6/15/2020 10:15 AM, Anshuman Gupta wrote:
On 2020-06-08 at 15:31:03 +0530, Ankit Nautiyal wrote:
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to
Hi Anshuman,
Thanks for the comments. Please find my response inline:
On 6/15/2020 9:59 AM, Anshuman Gupta wrote:
On 2020-06-08 at 15:31:02 +0530, Ankit Nautiyal wrote:
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The
On 11/25/2020 12:56 PM, Manasi Navare wrote:
The Bspec does not mention polling the FEC Enable
Live status bit. That is only there for debug purposes.
So remove the polling from driver.
Cc: Ankit Nautiyal
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 --
On 12/5/2020 2:28 AM, Manasi Navare wrote:
This patch fixes the slice count computation algorithm
for calculating the slice count based on Peak pixel rate
and the max slice width allowed on the DSC engines.
We need to ensure slice count > min slice count req
as per DP spec based on peak pixel
1 - 100 of 517 matches
Mail list logo