[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: Sharma, Shashank
Sent: Tuesday, January 21, 2020 11:44 AM
To: Lee Shawn C ; intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: RE: [Intel-gfx] [PATCH v2] drm/i915: Check require
[AMD Official Use Only - Internal Distribution Only]
Hello Shawn,
-Original Message-
From: Intel-gfx On Behalf Of Lee
Shawn C
Sent: Tuesday, January 21, 2020 6:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: [Intel-gfx] [PATCH v2] drm/i915: Check
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
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
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
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
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-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Introd
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
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
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[]
On 9/19/2019 10:08 PM, Jani Nikula wrote:
On Wed, 18 Sep 2019, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1:
On 9/18/2019 1:27 PM, Animesh Manna wrote:
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
On 9/18/2019 1:27 PM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated
] = TRANSCODER_DSI0_OFFSET, \
[TRANSCODER_DSI_1] = TRANSCODER_DSI1_OFFSET, \
}, \
- .has_global_mocs = 1
+ .has_global_mocs = 1, \
+ .display.has_dsb = 1
Looks good to me, feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
static const
On 9/12/2019 7:09 PM, Jani Nikula wrote:
On Thu, 12 Sep 2019, "Sharma, Shashank" wrote:
On 9/12/2019 12:41 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commi
On 9/12/2019 12:41 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated
ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
With or without suggested change above: Feel free to use
Reviewed-by: Shashank Sharma
- Shashank
#endif /* _I915_REG_H_ */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ipe) * 0x1000 + (id) * 100)
+#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_STATUS (1 << 0)
+
#endif /* _I915_REG_H_ */
Looks good to me,
Please feel free to use Reviewed-by: Shash
On 9/12/2019 6:37 PM, Animesh Manna wrote:
On 9/12/2019 6:30 PM, Sharma, Shashank wrote:
On 9/12/2019 6:21 PM, Jani Nikula wrote:
On Thu, 12 Sep 2019, "Sharma, Shashank"
wrote:
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. G
d intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val);
#endif
Looks good to me,
Please feel free to use Reviewed-by: Shashank Sharma
- Shashank
On 9/12/2019 6:21 PM, Jani Nikula wrote:
On Thu, 12 Sep 2019, "Sharma, Shashank" wrote:
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused
uot;display/intel_display.h"
#include "display/intel_display_power.h"
#include "display/intel_dpll_mgr.h"
+#include "display/intel_dsb.h"
#include "display/intel_frontbuffer.h"
#include "dis
info.h
@@ -135,6 +135,7 @@ enum intel_ppgtt_type {
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
+ func(has_dsb); \
func(has_fbc); \
func(has_gmch); \
func(has_hotplug); \
Looks good to me,
Feel free to use: Reviewed-by: Shashank Sharma
- Sh
> -Original Message-
> From: Manna, Animesh
> Sent: Monday, September 9, 2019 10:27 PM
> To: Sharma, Shashank ; intel-
> g...@lists.freedesktop.org
> Cc: Thierry, Michel ; Nikula, Jani
> ;
> Vivi, Rodrigo
> Subject: Re: [PATCH v5 05/11] drm/i915/d
On 9/7/2019 4:37 PM, Animesh Manna wrote:
The lifetime of command buffer can be controlled by the dsb user
throuh refcount. Added refcount mechanism is dsb get/put call
which create/destroy dsb context.
Cc: Jani Nikula
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
On 9/7/2019 4:37 PM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro
On 9/7/2019 4:37 PM, Animesh Manna wrote:
This patch adds a function, which will internally get the gem buffer
for DSB engine. The GEM buffer is from global GTT, and is mapped into
CPU domain, contains the data + opcode to be feed to DSB engine.
v1: Initial version.
v2:
- removed some
On 9/4/2019 5:56 PM, Ville Syrjälä wrote:
On Wed, Sep 04, 2019 at 08:32:09AM +0530, Sharma, Shashank wrote:
Hello Ville,
On 9/3/2019 10:50 PM, Ville Syrjälä wrote:
On Tue, Sep 03, 2019 at 10:22:25PM +0530, Shashank Sharma wrote:
Blurry outputs during upscaling the buffer, is a generic
On 9/4/2019 1:08 PM, Ramalingam C wrote:
On 2019-09-03 at 22:22:26 +0530, Shashank Sharma wrote:
If the upscaling ratio is a complete integer, Intel display HW can
pickup special scaling mode, which can produce better non-blurry
outputs. This patch adds a check to indicate if this is such an
On 9/4/2019 12:58 PM, Jani Nikula wrote:
On Tue, 03 Sep 2019, Shashank Sharma wrote:
If the upscaling ratio is a complete integer, Intel display HW can
pickup special scaling mode, which can produce better non-blurry
outputs. This patch adds a check to indicate if this is such an upscaling
Hello Ville,
On 9/3/2019 10:50 PM, Ville Syrjälä wrote:
On Tue, Sep 03, 2019 at 10:22:25PM +0530, Shashank Sharma wrote:
Blurry outputs during upscaling the buffer, is a generic problem of gfx
industry. One of the major reason behind this blurriness is the
interpolation of pixel values used by
On 9/3/2019 1:29 PM, Jani Nikula wrote:
On Tue, 03 Sep 2019, "Sharma, Shashank" wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Jani
Nikula
Sent: Friday, August 30, 2019 7:02 PM
To: Manna, Animesh ;
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani
> Nikula
> Sent: Friday, August 30, 2019 7:02 PM
> To: Manna, Animesh ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani
> Nikula
> Sent: Friday, August 30, 2019 7:06 PM
> To: Manna, Animesh ; intel-gfx@lists.freedesktop.org
> Cc: Thierry, Michel
> Subject: Re: [Intel-gfx] [PATCH v4 02/10]
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Gamma lut programming can be programmed using DSB
where bulk register programming can be done using indexed
register write which takes number of data and the mmio offset
to be written.
v1: Initial version.
v2: Directly call dsb-api at callsites.
So here is the documentation, this resolves atleast one review comment
from me :)
- Shashank
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
Cc: Michel Thierry
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Added key register definitions of DSB.
dsb-ctrl register is required to enable dsb-engine.
head-ptr register hold the head of buffer address from where the
execution will start.
Programming tail-ptr register is a trigger point to start execution.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. Will be using for bulk register programming
Reshuffle-> This feature can be used for bulk register programming e.g.
e.g. gamma lut programming, HDR meta data
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
Cc: Jani Nikula
Cc: Rodrigo Vivi
On 8/28/2019 12:40 AM, Animesh Manna wrote:
The function will internally get the gem buffer from global GTT
This patch adds a function, which will internally get the gem buffer for
DSB engine.
which is mapped in cpu domain to feed the data + opcode for DSB engine.
This GEM buffer is from
Hello Animesh
On 8/28/2019 12:40 AM, Animesh Manna wrote:
From gen12 onwards Display State Buffer(DSB) is hardware capability
added which allows driver to batch submit display HW programming.
Let's rephrase this line a bit, how about:
DSB is a new hardware capability, introduced in GEN12
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.freedeskt
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, S
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
Hello Ankit,
On 8/27/2019 11:59 AM, 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 experience corruption when
2560x2880 mode is applied for both of the tiled DP connectors.
Bugzilla:
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
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
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
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
---
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 |
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
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
(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
___
Intel-gfx mailing list
Intel-gfx@l
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
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
>
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
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_PICT
Regards
Shashank
On 7/9/2019 7:39 AM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check
Hello Ram,
On 7/2/2019 11:24 AM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check is
sequence gives a proper white output.
Regards
Shashank
On 5/8/2019 6:35 PM, Sharma, Shashank wrote:
On 5/7/2019 7:57 PM, Ville Syrjälä wrote:
On Tue, May 07, 2019 at 07:26:44PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma
On 5/7/2019 7:57 PM, Ville Syrjälä wrote:
On Tue, May 07, 2019 at 07:26:44PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine
Regards
Shashank
On 5/6/2019 6:41 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 06:25:19PM +0530, Sharma, Shashank wrote:
On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä
On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve
On 5/3/2019 8:35 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:06PM +0530, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, May 2, 2019 3:45 PM
> To: Sharma, Shashank
> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> ; Lankhorst,
> Maarten
> Subject: Re: [Intel-gfx] [PATCH
On 4/30/2019 4:09 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 10:22:40AM +0530, Sharma, Shashank wrote:
On 4/26/2019 8:07 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 06:40:11PM +0530, Sharma, Shashank wrote:
On 4/13/2019 12:00 AM, Ville Syrjala wrote:
From: Ville Syrjälä
On 4/29/2019 7:42 PM, Jani Nikula wrote:
On Fri, 26 Apr 2019, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 17 +
1
On 4/26/2019 8:07 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 06:40:11PM +0530, Sharma, Shashank wrote:
On 4/13/2019 12:00 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The pipe has a special HDR mode with higher precision when only
HDR planes are active. Let's use it.
Curiously
On 4/29/2019 5:19 PM, Ville Syrjälä wrote:
On Mon, Apr 29, 2019 at 05:00:21PM +0530, Sharma, Shashank wrote:
On 4/26/2019 11:59 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 11:31:51PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi
On 4/26/2019 11:59 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 11:31:51PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine
On 4/26/2019 11:46 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 11:31:50PM +0530, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h |
On 4/13/2019 12:00 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The pipe has a special HDR mode with higher precision when only
HDR planes are active. Let's use it.
Curiously this fixes the kms_color gamma/degamma tests when
using a HDR plane, which is always the case unless one hacks
the
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
per, 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
>
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
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
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
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman
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
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
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
---
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-gfx@lists.freedesktop.org; dri-
de...@lists.freedesktop.org
Cc: Lankhorst, Maarten ; Syrjala, Ville
; emil.l.veli...@gmail.com; brian.star
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
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
mi_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_SP
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com
Hello Uma,
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star
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
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
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-gfx@lists.freedesktop.org; Syrjala, Ville
> ; dri-
> de...@lists.freedesktop.org;
1 - 100 of 619 matches
Mail list logo
