All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Nikula, Jani" <jani.nikula@intel.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"mairacanal@riseup.net" <mairacanal@riseup.net>
Subject: Re: [Intel-gfx] [PATCH v2 0/4] Fixes for damage clips handling
Date: Tue, 13 Sep 2022 15:16:34 +0300	[thread overview]
Message-ID: <YyB0omBHTmGphq58@intel.com> (raw)
In-Reply-To: <aae6e268-dff6-148d-b596-683add3220c2@suse.de>

On Tue, Sep 13, 2022 at 12:56:49PM +0200, Thomas Zimmermann wrote:
> 
> 
> Am 13.09.22 um 12:54 schrieb Thomas Zimmermann:
> > Hi
> > 
> > Am 13.09.22 um 12:47 schrieb Hogander, Jouni:
> >> On Tue, 2022-09-13 at 12:04 +0300, Ville Syrjälä wrote:
> >>> On Tue, Aug 23, 2022 at 02:29:16PM +0300, Jouni Högander wrote:
> >>>> Currently damage clips handling is broken for planes when using big
> >>>> framebuffer + offset in case kms driver adjusts drm_plane_state.src
> >>>> coords. This is because damage clips are using coords relative to
> >>>> original coords from user-space.
> >>>>
> >>>> This patchset is fixing this by using original
> >>>> coords from user-space instead of drm_plane_state.src when
> >>>> iterating
> >>>> damage_clips.
> >>>>
> >>>> v2: Modify drm unit tests accordingly
> >>>>
> >>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>> Cc: Jani Nikula <jani.nikula@intel.com>
> >>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>> Cc: José Roberto de Souza <jose.souza@intel.com>
> >>>> Cc: Mika Kahola <mika.kahola@intel.com>
> >>>> Cc: Maíra Canal <mairacanal@riseup.net>
> >>>>
> >>>> Jouni Högander (4):
> >>>>    drm: Use original src rect while initializing damage iterator
> >>>>    drm/i915/display: Use original src in psr2 sel fetch area
> >>>> calculation
> >>>>    drm/i915/display: Use drm helper instead of own loop for damage
> >>>> clips
> >>>>    drm/tests: Set also mock plane src_x, src_y, src_w and src_h
> >>>
> >>> Do these need to be applied into the same tree, or can
> >>> the drm vs. i915 stuff go in separately?
> >>
> >> Patch 1 and 2 are needed to fix that bigfb handling for i915. Patch 4
> >> is also needed to prevent breaking tests. Patch 3 is more like cleanup.
> >>
> >> I think i915 patches could go via i915 tree. This just means that i915
> >> bigfb handling isn't fixed by either of the sets alone.
> > 
> > I have a number of updates for damage handling that I want to get 
> > reviewed soon. Could you please merge your patchset via drm-misc-next?
> 
> Or at least patches 1 and 4.

Went with the 50/50 split. Everything pushed now. Thanks.

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Nikula, Jani" <jani.nikula@intel.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"mairacanal@riseup.net" <mairacanal@riseup.net>,
	"Souza, Jose" <jose.souza@intel.com>,
	"Kahola, Mika" <mika.kahola@intel.com>,
	"Hogander, Jouni" <jouni.hogander@intel.com>
Subject: Re: [PATCH v2 0/4] Fixes for damage clips handling
Date: Tue, 13 Sep 2022 15:16:34 +0300	[thread overview]
Message-ID: <YyB0omBHTmGphq58@intel.com> (raw)
In-Reply-To: <aae6e268-dff6-148d-b596-683add3220c2@suse.de>

On Tue, Sep 13, 2022 at 12:56:49PM +0200, Thomas Zimmermann wrote:
> 
> 
> Am 13.09.22 um 12:54 schrieb Thomas Zimmermann:
> > Hi
> > 
> > Am 13.09.22 um 12:47 schrieb Hogander, Jouni:
> >> On Tue, 2022-09-13 at 12:04 +0300, Ville Syrjälä wrote:
> >>> On Tue, Aug 23, 2022 at 02:29:16PM +0300, Jouni Högander wrote:
> >>>> Currently damage clips handling is broken for planes when using big
> >>>> framebuffer + offset in case kms driver adjusts drm_plane_state.src
> >>>> coords. This is because damage clips are using coords relative to
> >>>> original coords from user-space.
> >>>>
> >>>> This patchset is fixing this by using original
> >>>> coords from user-space instead of drm_plane_state.src when
> >>>> iterating
> >>>> damage_clips.
> >>>>
> >>>> v2: Modify drm unit tests accordingly
> >>>>
> >>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>> Cc: Jani Nikula <jani.nikula@intel.com>
> >>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>> Cc: José Roberto de Souza <jose.souza@intel.com>
> >>>> Cc: Mika Kahola <mika.kahola@intel.com>
> >>>> Cc: Maíra Canal <mairacanal@riseup.net>
> >>>>
> >>>> Jouni Högander (4):
> >>>>    drm: Use original src rect while initializing damage iterator
> >>>>    drm/i915/display: Use original src in psr2 sel fetch area
> >>>> calculation
> >>>>    drm/i915/display: Use drm helper instead of own loop for damage
> >>>> clips
> >>>>    drm/tests: Set also mock plane src_x, src_y, src_w and src_h
> >>>
> >>> Do these need to be applied into the same tree, or can
> >>> the drm vs. i915 stuff go in separately?
> >>
> >> Patch 1 and 2 are needed to fix that bigfb handling for i915. Patch 4
> >> is also needed to prevent breaking tests. Patch 3 is more like cleanup.
> >>
> >> I think i915 patches could go via i915 tree. This just means that i915
> >> bigfb handling isn't fixed by either of the sets alone.
> > 
> > I have a number of updates for damage handling that I want to get 
> > reviewed soon. Could you please merge your patchset via drm-misc-next?
> 
> Or at least patches 1 and 4.

Went with the 50/50 split. Everything pushed now. Thanks.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-09-13 12:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23 11:29 [Intel-gfx] [PATCH v2 0/4] Fixes for damage clips handling Jouni Högander
2022-08-23 11:29 ` Jouni Högander
2022-08-23 11:29 ` [Intel-gfx] [PATCH v2 1/4] drm: Use original src rect while initializing damage iterator Jouni Högander
2022-08-23 11:29   ` Jouni Högander
2022-09-02 10:58   ` [Intel-gfx] " Kahola, Mika
2022-09-02 10:58     ` Kahola, Mika
2022-08-23 11:29 ` [Intel-gfx] [PATCH v2 2/4] drm/i915/display: Use original src in psr2 sel fetch area calculation Jouni Högander
2022-08-23 11:29   ` Jouni Högander
2022-09-02 10:59   ` [Intel-gfx] " Kahola, Mika
2022-09-02 10:59     ` Kahola, Mika
2022-08-23 11:29 ` [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Use drm helper instead of own loop for damage clips Jouni Högander
2022-08-23 11:29   ` Jouni Högander
2022-09-02 11:03   ` [Intel-gfx] " Kahola, Mika
2022-09-02 11:03     ` Kahola, Mika
2022-08-23 11:29 ` [Intel-gfx] [PATCH v2 4/4] drm/tests: Set also mock plane src_x, src_y, src_w and src_h Jouni Högander
2022-08-23 11:29   ` Jouni Högander
2022-09-02 11:06   ` [Intel-gfx] " Kahola, Mika
2022-09-02 11:06     ` Kahola, Mika
2022-09-03 14:04   ` Maíra Canal
2022-09-03 14:04     ` Maíra Canal
2022-08-23 12:44 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fixes for damage clips handling (rev2) Patchwork
2022-08-23 13:03 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-08-24  7:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-09-02 16:28 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fixes for damage clips handling (rev3) Patchwork
2022-09-02 16:53 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-02 23:08 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-09-06 18:11 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
2022-09-13  9:04 ` [Intel-gfx] [PATCH v2 0/4] Fixes for damage clips handling Ville Syrjälä
2022-09-13  9:04   ` Ville Syrjälä
2022-09-13 10:47   ` [Intel-gfx] " Hogander, Jouni
2022-09-13 10:47     ` Hogander, Jouni
2022-09-13 10:54     ` [Intel-gfx] " Thomas Zimmermann
2022-09-13 10:54       ` Thomas Zimmermann
2022-09-13 10:56       ` [Intel-gfx] " Thomas Zimmermann
2022-09-13 10:56         ` Thomas Zimmermann
2022-09-13 12:16         ` Ville Syrjälä [this message]
2022-09-13 12:16           ` Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YyB0omBHTmGphq58@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=mairacanal@riseup.net \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.