On Fri, 2018-08-03 at 20:12 +0100, Chris Wilson wrote:
> Quoting Gwan-gyeong Mun (2018-08-03 17:41:50)
>
> Even for trivial patches, always include a changelog. In this case, I
> added "Trivial typo, s/loose/lose/, in i915_drm_resume."
>
> > Signed-off-by: Gwan-gyeong Mun
>
> Reviewed-by:
On Thu, 2018-10-11 at 15:57 -0700, Paulo Zanoni wrote:
> From: Mahesh Kumar
>
> Enable SAGV for ICL platform.
>
> Cc: Gwan-gyeong Mun
> Reviewed-by: James Ausmus
> Reviewed-by: Paulo Zanoni
> Signed-off-by: Mahesh Kumar
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c
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 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 :
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,
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,
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
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
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.
> >
> >
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
> >
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
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 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
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
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:
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
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
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 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
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 <
>
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
; > > > 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 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ä
> ---
>
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 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ä
>
> 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:
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
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 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:
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 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()
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 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
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
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()
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
>
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
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 PIP
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 ->
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
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
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 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
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
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 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 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 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 Thu, 2020-02-20 at 15:15 -0800, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to the end of
On Fri, 2020-02-21 at 12:11 -0800, Souza, Jose wrote:
> On Fri, 2020-02-21 at 20:04 +0000, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-02-20 at 15:15 -0800, José Roberto de Souza wrote:
> > > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > >
On Fri, 2020-02-21 at 10:15 -0800, Souza, Jose wrote:
> On Fri, 2020-02-21 at 15:46 +0000, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-02-20 at 12:55 -0800, Souza, Jose wrote:
> > > On Thu, 2020-02-20 at 12:39 +, Mun, Gwan-gyeong wrote:
> > > > On Tue, 2020-02-18 a
On Thu, 2020-02-20 at 12:55 -0800, Souza, Jose wrote:
> On Thu, 2020-02-20 at 12:39 +0000, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> > > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > >
On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to
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
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
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
Hi Ville,
Thank you for notifying me that. I definitely missed the crash.
Sorry for that.
Danial and Jani, I' under debugging the crash case.
If you are availabe please do not merge current version.
Br,
G.G.
>
On Fri, 2020-05-15 at 16:14 +0200, Daniel Vetter wrote:
> On Fri, May 15, 2020 at
Hi Bartlomiej and Laurent Pinchart, can I have your ack for merging
this via drm-intel along
with the rest of the series, please?
BR,
G.G.
On Thu, 2020-05-14 at 09:07 +0300, Gwan-gyeong Mun wrote:
> It adds an unpack only function for DRM infoframe for dynamic range
> and
> mastering infoframe
t; > selective fetch registers and MAN_TRK_CTL enabling selective
> > > fetch but
> > > for now it is fetching the whole area of the planes.
> > > The damaged area calculation will come as next and final step.
> > >
> > > BSpec: 55229
>
On Thu, 2020-10-01 at 10:14 -0700, Souza, Jose wrote:
> On Thu, 2020-10-01 at 12:24 +0100, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-09-24 at 10:42 -0700, José Roberto de Souza wrote:
> > > Another step towards PSR2 selective fetch, here programming plane
> > >
On Mon, 2020-10-12 at 11:15 -0700, Souza, Jose wrote:
> On Mon, 2020-10-12 at 19:12 +0100, Mun, Gwan-gyeong wrote:
> > After applying this patch, the psr screen glitch issue is still
> > seen.
>
> Same IOMMU errors too? In my end it is fixed.
> Can you also give a try
After applying this patch, the psr screen glitch issue is still seen.
On Fri, 2020-10-02 at 16:16 -0700, José Roberto de Souza wrote:
> Writes to CURSURFLIVE in TGL are causing IOMMU errors and visual
> glitches that are often reproduced when executing CPU intensive
> workloads while a eDP 4K
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2020-10-07 at 12:52 -0700, José Roberto de Souza wrote:
> Another step towards PSR2 selective fetch, here programming plane
> selective fetch registers and MAN_TRK_CTL enabling selective fetch
> but
> for now it is fetching the whole area
On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> Another step towards PSR2 selective fetch, here programming plane
> selective fetch registers and MAN_TRK_CTL enabling selective fetch
> but
> for now it is fetching the whole area of the planes.
> The damaged area calculation will
On Wed, 2020-09-23 at 10:09 -0700, Souza, Jose wrote:
> On Wed, 2020-09-23 at 10:10 -0700, José Roberto de Souza wrote:
> > On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> > > On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> > > > Anoth
On Thu, 2020-09-24 at 10:42 -0700, José Roberto de Souza wrote:
> Another step towards PSR2 selective fetch, here programming plane
> selective fetch registers and MAN_TRK_CTL enabling selective fetch
> but
> for now it is fetching the whole area of the planes.
> The damaged area calculation will
On Tue, 2020-09-15 at 12:57 -0700, Souza, Jose wrote:
> On Tue, 2020-09-15 at 20:28 +0100, Mun, Gwan-gyeong wrote:
> > On Mon, 2020-09-14 at 13:15 -0700, Souza, Jose wrote:
> > > On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 31, 2020 at
1. While testing the problematic scenario, it has not always shown the
IOMMU DAMR related below errors on the drm-tip.
(sometimes the error messages raised, but some times it has not
happened on the same kernel and scenario.
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read] Request
On Thu, 2020-10-22 at 12:43 +, Mun, Gwan-gyeong wrote:
> 1. While testing the problematic scenario, it has not always shown
> the
> IOMMU DAMR related below errors on the drm-tip.
>(sometimes the error messages raised, but some times it has not
> happened on the same kern
On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote:
> Add the calculations to set plane selective fetch registers depending
> in the value of the area damaged.
> It is still using the whole plane area as damaged but that will
> change
> in next patches.
>
> BSpec: 55229
> Cc:
On Tue, 2020-10-13 at 16:01 -0700, 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.
>
> Cc: Ville Syrjälä
> Cc:
On Tue, 2020-10-13 at 16:01 -0700, José Roberto de Souza wrote:
> Planes can individually have transparent, move or have visibility
> changed if any of those happens, planes bellow it will be visible or
> have more pixels of it visible than before.
>
> This patch is taking care of this case for
On Mon, 2020-07-06 at 16:43 -0700, José Roberto de Souza wrote:
> From the 3 WAs for PSR2 man track/selective fetch this is only one
> needed when doing single full frames at every flip.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 19
On Mon, 2020-07-06 at 16:43 -0700, José Roberto de Souza wrote:
> All GEN12 platforms supports PSR2 selective fetch but not all GEN12
> platforms supports PSR2 hardware tracking(aka RKL).
>
> This feature consists in software programming registers with the
> damaged area of each plane this way
On Fri, 2020-06-12 at 21:49 +, Mun, Gwan-gyeong wrote:
> On Fri, 2020-06-12 at 14:18 -0700, Souza, Jose wrote:
> > On Fri, 2020-06-12 at 21:57 +0100, Mun, Gwan-gyeong wrote:
> > > On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> > > > This regis
On Mon, 2020-06-15 at 19:40 +0300, Ville Syrjälä wrote:
> On Fri, Jun 12, 2020 at 08:33:31PM +, Souza, Jose wrote:
> > On Fri, 2020-06-12 at 19:30 +0300, Ville Syrjälä wrote:
> > > On Tue, May 26, 2020 at 03:14:46PM -0700, José Roberto de Souza
> > > wrote:
> > > > All GEN12 platforms supports
On Thu, 2020-06-25 at 18:01 -0700, José Roberto de Souza wrote:
> This registers will be used to implement PSR2 manual
> tracking/selective
> fetch.
>
> v2:
> - Fixed typo in _PLANE_SEL_FETCH_BASE
> - Renamed PSR2_MAN_TRK_CTL bits to better match spec names
> - Renamed _PLANE_SEL_FETCH_* to
On Tue, 2020-06-16 at 10:29 -0700, Souza, Jose wrote:
> On Tue, 2020-06-16 at 16:16 +0100, Mun, Gwan-gyeong wrote:
> > On Mon, 2020-06-15 at 19:40 +0300, Ville Syrjälä wrote:
> > > On Fri, Jun 12, 2020 at 08:33:31PM +, Souza, Jose wrote:
> > > > On Fri, 2020-06-12
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2020-05-20 at 14:27 -0700, José Roberto de Souza wrote:
> This parameter is meant to be used when PSR issues are found as some
> issues in the past was due wrong values set in VBT so this would be
> a quick and easy way to ask users or for
On Thu, 2020-06-04 at 18:51 -0700, Souza, Jose wrote:
> On Fri, 2020-06-05 at 03:23 +0300, Gwan-gyeong Mun wrote:
> > The IO buffer Wake and Fast Wake bit size and value have been
> > changed from
> > Gen12+.
> > It programs default value of IO buffer Wake and Fast Wake on
> > Gen12+.
> >
> > -
This feature is supported from GEN9+, but this time it focuses on
supporting of PSR2 software tracking for GEN12+.
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> This property will be used by PSR2 software tracking, adding it to
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> Future patches will bring PSR2 selective fetch configuration
> validation but most of the configuration checks will be used for HW
> tracking and selective fetch so the reoder was
On Fri, 2020-06-12 at 14:18 -0700, Souza, Jose wrote:
> On Fri, 2020-06-12 at 21:57 +0100, Mun, Gwan-gyeong wrote:
> > On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> > > This registers will be used to implement PSR2 software tracking.
> > >
> >
On Tue, 2020-05-26 at 15:14 -0700, José Roberto de Souza wrote:
> This registers will be used to implement PSR2 software tracking.
>
> BSpec: 55229
> BSpec: 50424
> BSpec: 50420
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 68 ++-
>
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
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
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
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
>
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.
>
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-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 usi
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 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:
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:
> > > > >
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
1 - 100 of 148 matches
Mail list logo
