On Fri, 2020-12-04 at 22:08 +0530, Anshuman Gupta wrote:
> On 2020-11-06 at 15:44:42 +0530, Gwan-gyeong Mun wrote:
> > It is a preliminary work for supporting multiple EDP PSR and
> > DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> > supportable PSR.
> > And this moves and rena
On Wed, 2020-11-18 at 13:11 +0200, Jani Nikula wrote:
> On Fri, 06 Nov 2020, Gwan-gyeong Mun
> wrote:
> > In order to support the PSR state of each transcoder, it adds
> > i915_psr_status to sub-directory of each transcoder.
> >
> > v2: Change using of Symbolic permissions 'S_IRUGO' to using of
>
On Fri, 2020-12-04 at 21:36 +0530, Anshuman Gupta wrote:
> On 2020-11-18 at 16:42:29 +0530, Jani Nikula wrote:
> > On Fri, 06 Nov 2020, Gwan-gyeong Mun
> > wrote:
> > > In order to support the PSR state of each transcoder, it adds
> > > i915_psr_status to sub-directory of each transcoder.
> > >
>
On Mon, 2020-12-14 at 08:55 +, Simon Ser wrote:
> > Userspace can set a damage clip with a negative coordinate,
> > negative
> > width or height or larger than the plane.
> > This invalid values could cause issues in some HW or even worst
> > enable
> > security flaws.
> >
> > v2:
> > - add de
On Sun, 2020-12-13 at 10:39 -0800, José Roberto de Souza wrote:
> Call the function that validates every damage clips of each plane.
> As in commit 093a3a39 ("drm/i915: Add plane damage clips
> property")
> this property was only enabled for gen12+ only checking it for gen12
> too.
>
> v2:
> -
On Sun, 2020-12-13 at 10:39 -0800, José Roberto de Souza wrote:
> Now using plane damage clips property to calcualte the damaged area.
> Selective fetch only supports one region to be fetched so software
> needs to calculate a bounding box around all damage clips.
>
> Now that we are not complete
On Mon, 2020-12-14 at 16:32 +0530, Anshuman Gupta wrote:
> On 2020-12-11 at 19:14:20 +0200, Gwan-gyeong Mun wrote:
> > It is a preliminary work for supporting multiple EDP PSR and
> > DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> > supportable PSR.
> > And this moves and rena
On Mon, 2020-12-14 at 16:32 +0530, Anshuman Gupta wrote:
> On 2020-12-11 at 19:14:20 +0200, Gwan-gyeong Mun wrote:
> > It is a preliminary work for supporting multiple EDP PSR and
> > DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> > supportable PSR.
> > And this moves and rena
On Mon, 2020-12-14 at 13:33 +0200, Jani Nikula wrote:
> On Fri, 11 Dec 2020, Gwan-gyeong Mun
> wrote:
> > It is a preliminary work for supporting multiple EDP PSR and
> > DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> > supportable PSR.
> > And this moves and renames the i915
On Mon, 2020-12-14 at 13:35 +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2020, Anshuman Gupta wrote:
> > On 2020-12-11 at 19:14:21 +0200, Gwan-gyeong Mun wrote:
> > > In order to support the PSR state of each transcoder, it adds
> > > i915_psr_status to sub-directory of each transcoder.
> > >
> > >
On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> Much more clear to read one function call than four lines doing this
> conversion.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Gwan-gyeong Mun
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_rect.c | 15 +
On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> Now using plane damage clips property to calcualte the damaged area.
> Selective fetch only supports one region to be fetched so software
> needs to calculate a bounding box around all damage clips.
>
> Now that we are not complete
On Tue, 2020-12-15 at 05:14 -0800, Souza, Jose wrote:
> On Tue, 2020-12-15 at 13:02 +0000, Mun, Gwan-gyeong wrote:
> > On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> > > Now using plane damage clips property to calcualte the damaged
> > > area.
On Wed, 2020-12-16 at 05:17 -0800, Souza, Jose wrote:
> On Wed, 2020-12-16 at 10:29 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-12-15 at 05:14 -0800, Souza, Jose wrote:
> > > On Tue, 2020-12-15 at 13:02 +, Mun, Gwan-gyeong wrote:
> > > > On Mon, 2020-12-14 a
On Wed, 2020-12-16 at 06:40 -0800, Souza, Jose wrote:
> On Wed, 2020-12-16 at 14:10 +0000, Mun, Gwan-gyeong wrote:
> > On Wed, 2020-12-16 at 05:17 -0800, Souza, Jose wrote:
> > > On Wed, 2020-12-16 at 10:29 +, Mun, Gwan-gyeong wrote:
> > > > On Tue, 2020-12-15 at
On Wed, 2020-12-16 at 09:48 -0800, José Roberto de Souza wrote:
> Now using plane damage clips property to calcualte the damaged area.
> Selective fetch only supports one region to be fetched so software
> needs to calculate a bounding box around all damage clips.
>
> Now that we are not complete
On Thu, 2020-12-17 at 05:34 -0800, Souza, Jose wrote:
> On Thu, 2020-12-17 at 11:51 +0000, Mun, Gwan-gyeong wrote:
> > On Wed, 2020-12-16 at 06:40 -0800, Souza, Jose wrote:
> > > On Wed, 2020-12-16 at 14:10 +, Mun, Gwan-gyeong wrote:
> > > > On Wed, 2020-12-16 at
On Thu, 2020-12-17 at 13:13 -0800, José Roberto de Souza wrote:
> Now using plane damage clips property to calcualte the damaged area.
> Selective fetch only supports one region to be fetched so software
> needs to calculate a bounding box around all damage clips.
>
> Now that we are not complete
On Wed, 2020-12-16 at 18:56 +0530, Anshuman Gupta wrote:
> On 2020-12-16 at 14:47:42 +0200, Gwan-gyeong Mun wrote:
> > It is a preliminary work for supporting multiple EDP PSR and
> > DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> > supportable PSR.
> > And this moves and rena
On Fri, 2020-12-18 at 10:46 -0800, José Roberto de Souza wrote:
> Much more clear to read one function call than four lines doing this
> conversion.
>
> v7:
> - function renamed
> - calculating width and height before truncate
> - inlined
>
> Cc: Ville Syrjälä
> Cc: dri-de...@lists.freedesktop.o
I've tested this patch with SelectiveFetch / PSR Selective Update IGT
test.
igt patch : Add FB_DAMAGE_CLIPS prop and new test for Selective fetch
: https://patchwork.freedesktop.org/series/84696/ (this igt patch is
under reviewing)
As per bspec, when I checked this patch by code level, it looked
On Fri, 2020-12-18 at 16:03 +0530, Swati Sharma wrote:
> DP does not support sending AVI info frame to panel. So we need to
> send AVI info frame to HDMI through some other DIP.
>
> When DP-to-HDMI protocol converter is present GMP DIP will be used
> to send AVI infoframe instead of static HDR inf
On Fri, 2020-12-18 at 16:03 +0530, Swati Sharma wrote:
> In this patch readout for AVI infoframes enclosed in GMP
> DIP is implemented.
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 74
> -
> 1 file chan
The v2 patch which addressed Jose's comments was floated to
https://patchwork.freedesktop.org/series/90819/
On Fri, 2021-05-21 at 14:52 -0700, Souza, Jose wrote:
> On Fri, 2021-05-21 at 11:58 +0100, Mun, Gwan-gyeong wrote:
> > On Tue, 2021-05-18 at 14:06 +0300, Ville Syrjälä wrote
Another patchset has been uploaded. Please ignore this patch.
On Tue, 2021-06-01 at 12:53 +0300, Gwan-gyeong Mun wrote:
> This introduces the following function that can exit and activate a
> psr
> source when intel_psr is already enabled.
>
> - intel_psr_pause(): Pause current PSR. It deactivate
Reviewed-by: Gwan-gyeong Mun
On Wed, 2021-05-05 at 14:38 -0700, José Roberto de Souza wrote:
> The implementation of two workarounds are missing causing failures
> in CI with pre-production HW.
>
> Cc: Gwan-gyeong Mun
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/
Hi Ville,
initially, intel_psr_pause() called intel_psr_disable_locked() instead
of intel_psr_exit().
In intel_psr_resume(), _intel_psr_enable_locked() was called instead of
intel_psr_activate().
Can you share what problem the initial code caused when calling
intel_psr_pause() / intel_psr_resume()
On Tue, 2021-05-18 at 14:06 +0300, Ville Syrjälä wrote:
> On Tue, May 18, 2021 at 09:33:09AM +0000, Mun, Gwan-gyeong wrote:
> > Hi Ville,
> > initially, intel_psr_pause() called intel_psr_disable_locked()
> > instead
> > of intel_psr_exit().
> > In intel_psr_r
On Fri, 2021-05-14 at 16:22 -0700, José Roberto de Souza wrote:
> This was only reduntant information has_hdmi_sink can do the same job.
> set_infoframes() hooks will call intel_write_infoframe() for the
> supported infoframes types and it will only be enabled if given type
> is set in crtc_state->
Reviewed-by: Gwan-gyeong Mun
Tested-by: Gwan-gyeong Mun
On Thu, 2021-04-08 at 13:49 -0700, José Roberto de Souza wrote:
> This WA fix some display glitches when the system is under high
> memory pressure.
>
> BSpec: 52890
> Cc: Gwan-gyeong Mun
> Signed-off-by: José Roberto de Souza
> ---
> dr
Reviewed-by: Gwan-gyeong Mun
Tested-by: Gwan-gyeong Mun
On Thu, 2021-04-08 at 13:49 -0700, José Roberto de Souza wrote:
> This reverts commit 71c1a4998320962f7b8362b2c5ee36610d49e8fb.
>
> The proper fix is Wa_14013723622, so now we can revert this WA and
> get back some power savings.
>
> Cc: G
The changed name looks more accurate to the edp 1.4b spec.
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2021-04-21 at 15:02 -0700, José Roberto de Souza wrote:
> DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Capture
> Indication" in eDP spec has a ambiguous name, so renami
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2021-04-21 at 15:02 -0700, José Roberto de Souza wrote:
> EDP_Y_COORDINATE_ENABLE became a reserved register in display 13.
> EDP_Y_COORDINATE_VALID have the same fate as EDP_Y_COORDINATE_ENABLE
> but as we don't need it, removing the macro
On Thu, 2021-04-22 at 07:39 -0700, Souza, Jose wrote:
> On Thu, 2021-04-22 at 12:54 +0300, Gwan-gyeong Mun wrote:
> > TGL PSR2 hardware tracking shows momentary flicker and screen shift
> > if
> > TGL Display stepping is B1 from A0.
> > It has been fixed from TGL Display stepping C0.
> >
> > HSDES
On Wed, 2019-05-08 at 20:32 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:53AM +0300, Gwan-gyeong Mun wrote:
> > SDP VSC Header and Data Block follow DP 1.4a spec, section
> > 2.2.5.7.5,
> > chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
> >
> > Signed-off-by: Gwan-
On Wed, 2019-05-08 at 20:56 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:54AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block in
On Wed, 2019-05-08 at 20:58 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:56AM +0300, Gwan-gyeong Mun wrote:
> > Data M/N calculations were assumed a bpp as RGB format. But when we
> > are
> > using YCbCr 4:2:0 output format on DP, we should change bpp
> > calculations
> > as YCbCr 4:
On Fri, 2019-05-17 at 15:36 +0200, Maarten Lankhorst wrote:
> Op 10-05-2019 om 03:53 schreef Gwan-gyeong Mun:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block in function
> >
On Tue, 2019-05-21 at 13:14 +0300, Laurent Pinchart wrote:
> Hello Jani,
>
> On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> > On Mon, 20 May 2019, Gwan-gyeong Mun
> > wrote:
> > > VSC SDP Payload for PSR is one of data block type of SDP
> > > (Secondaray Data
> > > Packet). In ord
On Mon, 2019-03-04 at 12:45 +0100, Maarten Lankhorst wrote:
> Op 01-03-2019 om 11:01 schreef Gwan-gyeong Mun:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can
> > detect
> > changing of status of connector, but it can not detect changing of
> > edid.
> >
> > Following scenario r
On Thu, 2019-04-11 at 17:00 +0100, Lisovskiy, Stanislav wrote:
> On Thu, 2019-04-11 at 17:36 +0300, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can
> > detect
> > changing of status of connector, but it can not detect changing of
> > edid.
> >
> > Followi
On Mon, 2019-04-15 at 18:32 +0200, Daniel Vetter wrote:
> On Thu, Apr 11, 2019 at 05:36:30PM +0300, Gwan-gyeong Mun wrote:
> > This patch series fix missed detection of changing of edid on
> > between
> > suspend and resume.
> > First patch fixes drm_helper_hdp_irq_event() in order to fix a
> > bel
On Thu, 2019-04-18 at 10:28 +0200, Daniel Vetter wrote:
> On Thu, Apr 18, 2019 at 11:09:29AM +0300, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can
> > detect
> > changing of status of connector, but it can not detect changing of
> > properties of the conn
On Thu, Apr 18, 2019 at 7:33 PM Jani Nikula wrote:
>
> On Thu, 18 Apr 2019, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can detect
> > changing of status of connector, but it can not detect changing of
> > properties of the connector.
> > e.g. changing o
On Mon, 2019-02-18 at 11:44 +0200, Jani Nikula wrote:
> FWIW these are all valid checkpatch complaints.
>
> BR,
> Jani.
>
> On Thu, 31 Jan 2019, Patchwork
> wrote:
> > == Series Details ==
> >
> > Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
> > URL : https://patchwork.f
On Fri, 2019-02-08 at 16:24 +0100, Maarten Lankhorst wrote:
> Op 31-01-2019 om 22:10 schreef Gwan-gyeong Mun:
> > Bspec describes that GEN10 only supports capability of YUV 4:2:0
> > output to
> > HDMI port and GEN11 supports capability of YUV 4:2:0 output to both
> > DP and
> > HDMI ports.
> >
>
On Fri, 2019-02-08 at 16:31 +0100, Maarten Lankhorst wrote:
> Op 31-01-2019 om 22:10 schreef Gwan-gyeong Mun:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block in function
> >
On Thu, 2019-02-21 at 21:37 +0200, Ville Syrjälä wrote:
> On Thu, Feb 21, 2019 at 09:27:26PM +0200, Gwan-gyeong Mun wrote:
> > This patch checks a support of YCBCR420 outputs on an encoder
> > level.
> > If the input mode is YCBCR420-only mode then it prepares DP as an
> > YCBCR420
> > output, else
On Mon, 2019-09-02 at 17:43 +0300, Ville Syrjälä wrote:
> On Fri, Aug 23, 2019 at 12:52:28PM +0300, Gwan-gyeong Mun wrote:
> > When BT.2020 Colorimetry output is used for DP, we should program
> > BT.2020
> > Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> > intel_crtc_state struct a
On Mon, 2019-09-02 at 17:44 +0300, Ville Syrjälä wrote:
> On Fri, Aug 23, 2019 at 12:52:29PM +0300, Gwan-gyeong Mun wrote:
> > In order to use colorspace property to Display Port connectors, it
> > extends
> > DRM_MODE_CONNECTOR_DisplayPort connector_type on
> > drm_mode_create_colorspace_property
On Tue, 2019-08-27 at 01:14 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: Mun, Gwan-gyeong
> > Sent: Friday, August 23, 2019 3:23 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Shankar, Uma <
>
; > > > Sent: Tuesday, September 3, 2019 6:12 PM
> > > > To: Mun, Gwan-gyeong
> > > > Cc: Intel Graphics Development > > > >; Shankar, Uma
> > > > ; dri-devel <
> > > > dri-de...@lists.freedesktop.org>
> > > > Sub
On Mon, 2019-09-09 at 13:25 +0300, Ville Syrjälä wrote:
> On Sat, Sep 07, 2019 at 11:19:55PM +0000, Mun, Gwan-gyeong wrote:
> > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > > wrote:
> > > > O
On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> wrote:
> > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > > wrote:
> > > > On Fri,
On Fri, 2019-09-13 at 22:13 +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2019 at 02:33:34PM +0300, Gwan-gyeong Mun wrote:
> > Because between HDMI and DP have different colorspaces, it renames
> > drm_mode_create_colorspace_property() function to
> > drm_mode_create_hdmi_colorspace_property() func
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add definitions for the MSA (Main Stream Attribute) MISC bits. On
> some hardware you can program these directly into a register.
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_dp_helper.h | 42
> ++
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Looks like we're currently setting the MSA to xvYCC BT.709 instead
> of the YCbCr BT.601 claimed by the comment. But even that comment
> is wrong since we configure the CSC matrix to BT.709.
>
> Let's remove the bo
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull the code for computing the limited color range
> setting into a small helper. We'll add a bit more to it
> later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +
On Thu, 2019-07-18 at 19:45 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> crtc_state->limited_color_range only applies to RGB output but
> we're currently setting it even for YCbCr output. That will
> lead to conflicting MSA and PIPECONF settings which can mess
> up the image. Let's make
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we have standard defines for the MSA MISC bits lets use
> them on HSW+ where we program these directly into the TRANS_MSA_MISC
> register.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/di
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since HSW the PIPECONF progressive vs. interlaced selection is done
> with just two bits instead of the earlier three. Let's not look at
> the
> extra bit on HSW+. Also gen2 doesn't support interlaced displays at
>
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make intel_get_crtc_ycbcr_config() simpler and rename it
> to bdw_get_pipemisc_output_format() to better reflect what
> it does.
>
> Also toss in some comments to document that the 4:2:0 PIPECONF
> bits are glk+ on
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On HSW the pipe colorspace is configured via PIPECONF
> (as opposed to PIPEMISC in BDW+). Let's configure+readout
> that stuff correctly.
>
> Enablling YCbCr 4:4:4 output will now be a simple matter of
Typo: Enabll
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On ILK-IVB the pipe colorspace is configured via PIPECONF
> (as opposed to PIPEMISC in BDW+). Let's configure+readout
> that stuff correctly.
>
> Enablling YCbCr 4:4:4 output will now be a simple matter of
Typo: En
On Wed, 2019-09-18 at 17:15 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:45AM +0300, Gwan-gyeong Mun wrote:
> > When BT.2020 Colorimetry output is used for DP, we should program
> > BT.2020
> > Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> > intel_crtc_state struct a
On Wed, 2019-09-18 at 17:08 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:46AM +0300, Gwan-gyeong Mun wrote:
> > Because between HDMI and DP have different colorspaces, it renames
> > drm_mode_create_colorspace_property() function to
> > drm_mode_create_hdmi_colorspace_property() func
On Wed, 2019-09-18 at 17:13 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:49AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_dp_setup_hdr_metadata_infoframe_sdp handles
> > Infoframe SDP
> > header and data block setup for HDR Static Metadata. It enables
> > writing of
> > HDR meta
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare the pipe csc for YCbCr output on ilk/snb. The main difference
> to IVB+ is the lack of explicit post offsets, and instead we must
> configure the CSC info RGB->YUV mode (which takes care of offsetting
> Cb/C
Except typo, the changes look good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2019-09-18 at 19:03 +, Mun, Gwan-gyeong wrote:
> On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On HSW the pipe colorspace is configured via PIPECO
Except typo, the changes look good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2019-09-18 at 19:05 +, Mun, Gwan-gyeong wrote:
> On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On ILK-IVB the pipe colorspace is configured via PIP
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're configuring the AVI infoframe quantization range bits as if
> we're always transmitting RGB pixels. Let's fix this so that we
> correctly indicate limited range YCC quantization range when
> transmitting YCbCr
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add comments to explain the ilk pipe csc operation a bit better.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 26 +---
> --
> 1 file changed, 21 insertions
On Wed, 2019-03-06 at 22:52 +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 09:30:57PM +0200, Gwan-gyeong Mun wrote:
> > This patch checks a support of YCBCR420 outputs on an encoder
> > level.
> > If the input mode is YCBCR420-only mode then it prepares DP as an
> > YCBCR420
> > output, else
On Wed, 2019-03-06 at 23:04 +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 09:31:01PM +0200, Gwan-gyeong Mun wrote:
> > All of the link bandwidth and Data M/N calculations were assumed a
> > bpp as
> > RGB format. But When we are using YCbCr 4:2:0 output format on DP,
> > we should change bp
On Wed, 2019-07-10 at 15:58 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> With 4:2:0 output the LS clock can be half of what it is with 4:4:4.
> Make that happen.
>
> Cc: Gwan-gyeong Mun
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
> 1 file
On Tue, 2019-10-15 at 22:05 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The MSA MISC computation now depends on the connector state, and
> we do it from the DDI .pre_enable() hook. All that is fine for
> DP SST but with MST we don't actually pass the connector state
> to the dig port's
On Sat, 2019-11-09 at 05:16 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Split a setting of MSA to MST and SST (rev3)
> URL : https://patchwork.freedesktop.org/series/69092/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_
On Mon, 2019-11-11 at 11:46 +, Saarinen, Jani wrote:
> Hi,
>
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of Souza,
> > Jose
> > Sent: torstai 7. marraskuuta 2019 23.16
> > To: Mun, Gwan-gyeong ; intel-
> > g...@lists.fre
On Mon, 2020-01-06 at 07:21 -0800, José Roberto de Souza wrote:
> Recent improvements in the state tracking in i915 caused PSR to not
> be
> enabled when reusing firmware/BIOS modeset, this is due to all
> initial
> commits returning ealier in intel_atomic_check() as needs_modeset()
> is always fal
Hi,
On Mon, 2019-11-25 at 15:38 -0800, José Roberto de Souza wrote:
> Recent improvements in the state tracking in i915 caused PSR to not
> be
> enabled when reusing firmware/BIOS modeset, this is due to all
> initial
> commits returning ealier in intel_atomic_check() as needs_modeset()
> is always
On Fri, 2020-03-20 at 13:57 +0200, Laurent Pinchart wrote:
> Hi Jani,
>
> On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> > On Fri, 20 Mar 2020, Jani Nikula
> > wrote:
> > > On Tue, 11 Feb 2020, Gwan-gyeong Mun
> > > wrote:
> > > > It adds an unpack only function for DRM infoframe
On Fri, 2020-03-27 at 14:56 +0200, Ville Syrjälä wrote:
> On Fri, Mar 27, 2020 at 07:27:56AM +0000, Mun, Gwan-gyeong wrote:
> > On Fri, 2020-03-20 at 13:57 +0200, Laurent Pinchart wrote:
> > > Hi Jani,
> > >
> > > On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani
On Sat, 2020-02-01 at 14:43 +0200, Jani Nikula wrote:
> On Fri, 31 Jan 2020, Gwan-gyeong Mun
> wrote:
> > When receiving video it is very useful to be able to log DP VSC
> > SDP.
> > This greatly simplifies debugging.
>
> Seems like a lot of the functions should really be in drm core.
>
> BR,
>
On Wed, 2020-02-05 at 20:12 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: dri-devel On Behalf
> > Of Gwan-
> > gyeong Mun
> > Sent: Tuesday, February 4, 2020 4:50 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org
>
On Wed, 2020-02-05 at 21:39 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: dri-devel On Behalf
> > Of Gwan-
> > gyeong Mun
> > Sent: Tuesday, February 4, 2020 4:50 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org
>
On Wed, 2020-02-05 at 21:59 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: dri-devel On Behalf
> > Of Gwan-
> > gyeong Mun
> > Sent: Tuesday, February 4, 2020 4:50 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org
>
On Wed, 2020-02-05 at 22:21 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of Gwan-
> > gyeong Mun
> > Sent: Tuesday, February 4, 2020 4:50 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org
>
On Fri, 2021-01-29 at 11:45 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v14,1/2] drm/i915/display: Support PSR
> Multiple Instances
> URL : https://patchwork.freedesktop.org/series/86445/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-t
Reviewed-by: Gwan-gyeong Mun
On Thu, 2021-02-04 at 07:33 -0800, José Roberto de Souza wrote:
> By mistake those 2 parameters were defined as read and write in the
> .h file while in the .c file it is read only.
> The intention here was to be read only to avoid the need of
> additional
> handling.
Reviewed-by: Gwan-gyeong Mun
Tested-by: Gwan-gyeong Mun
On Mon, 2020-11-02 at 11:18 -0800, Souza, Jose wrote:
> On Thu, 2020-10-29 at 21:37 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-10-27 at 16:45 -0700, José Roberto de Souza wrote:
> > > Add the calculations to set pla
Reviewed-by: Gwan-gyeong Mun
Tested-by: Gwan-gyeong Mun
On Tue, 2020-10-27 at 16:45 -0700, José Roberto de Souza wrote:
> The calculation the offsets of the main surface will be needed by
> PSR2
> selective fetch code so here splitting and exporting it.
> No functional changes were done here.
>
It works properly on a normal rgba plane.
In order to apply this patch, the commit messaged need to be polished.
Reviewed-by: Gwan-gyeong Mun
Tested-by: Gwan-gyeong Mun
On Tue, 2020-10-27 at 16:45 -0700, José Roberto de Souza wrote:
> Do the calculation of x and y offsets using
> skl_calc_main_
On Tue, 2020-10-27 at 13:12 -0700, Souza, Jose wrote:
> On Tue, 2020-10-27 at 01:04 +, Souza, Jose wrote:
> > On Mon, 2020-10-26 at 21:40 +0000, Mun, Gwan-gyeong wrote:
> > > On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote:
> > > > Now using
On Tue, 2020-10-27 at 10:25 -0700, Souza, Jose wrote:
> On Tue, 2020-10-27 at 13:34 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote:
> > > Planes can individually have transparent, move or have visibility
> > > chan
On Tue, 2020-12-01 at 09:39 -0800, Souza, Jose wrote:
> On Tue, 2020-12-01 at 17:26 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-10-27 at 13:12 -0700, Souza, Jose wrote:
> > > On Tue, 2020-10-27 at 01:04 +, Souza, Jose wrote:
> > > > On Mon, 2020-10-26 at 21:40
On Tue, 2020-12-01 at 09:44 -0800, Souza, Jose wrote:
> On Tue, 2020-12-01 at 17:33 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-10-27 at 10:25 -0700, Souza, Jose wrote:
> > > On Tue, 2020-10-27 at 13:34 +, Mun, Gwan-gyeong wrote:
> > > > On Tue, 2020-10-13 a
On Tue, 2020-12-01 at 13:15 -0800, Souza, Jose wrote:
> On Tue, 2020-12-01 at 19:40 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-12-01 at 09:39 -0800, Souza, Jose wrote:
> > > On Tue, 2020-12-01 at 17:26 +, Mun, Gwan-gyeong wrote:
> > > > On Tue, 2020-10-27 at
On Fri, 2020-10-23 at 21:06 +, Souza, Jose wrote:
> On Thu, 2020-10-22 at 13:56 +, Lee, Shawn C wrote:
> > On Thu, Oct. 22, 2020, 3:24 a.m, Lee Shawn C wrote:
> > > On Wed, Oct. 21, 2020, 5:13 p.m, Souza, Jose wrote:
> > > > On Wed, 2020-10-21 at 22:24 +0800, Lee Shawn C wrote:
> > > > > Dr
On Thu, 2020-12-03 at 15:53 -0800, Manasi Navare wrote:
> Even though our HW supports PSR + VRR, the available panels
> do not work reliably with PSR and VRR together. So if user
> requested VRR and is supported by HW enable that and do not
> enable PSR in that case.
>
> Cc: Ville Syrjälä
> Cc: G
On Tue, 2021-02-09 at 10:14 -0800, José Roberto de Souza wrote:
> for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion
> "with_psr" is better.
>
> Cc: Gwan-gyeong Mun
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 4 ++--
> dri
1 - 100 of 148 matches
Mail list logo
