All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
Date: Fri, 21 Feb 2020 19:49:34 +0200	[thread overview]
Message-ID: <20200221174934.GT13686@intel.com> (raw)
In-Reply-To: <20200221171657.GE2363188@phenom.ffwll.local>

On Fri, Feb 21, 2020 at 06:16:57PM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > > > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
> > > > <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
> > > > > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > Looks like getting rid of private_flags is going to be pretty
> > > > > > > straightforward. I'll post patches for that once this first series
> > > > > > > lands.
> > > > > >
> > > > > > Going all in on crtc state? I suppose migrating away from private_flags
> > > > > > could easily start in i915 before that. Seems rather independent.
> > > > > >
> > > > > > I guess it's __intel_get_crtc_scanline() and:
> > > > > >
> > > > > >       vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)];
> > > > > >       mode = &vblank->hwmode;
> > > > > >
> > > > > >       if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP)
> > > > > >
> > > > > > that gives me the creeps in reviewing all that.
> > > > > >
> > > > > > There's also [1] adding new uses for private_flags; I think there were
> > > > > > issues in getting at the right crtc state on some of those paths, but I
> > > > > > forget the exact details. Ideas?
> > > > >
> > > > > I'm just going to move them to the crtc_state and put a copy into the
> > > > > crtc itself for the vblank code. Pretty much a 1:1 replacement.
> > > > > Saves me from having to think ;)
> > > > 
> > > > I've looked through the patches, and didn't spot any place where we
> > > > couldn't just get at the full crtc state. Might need some crtc->state
> > > > dereferencing and upcasting and making sure stuff is ordered correctly
> > > > with enable/disable paths of crtc, but nothing to jump over.
> > > 
> > > swap_state() could easily race with the irq handler. I guess
> > > practically unlikely the old crtc state would disappear before
> > > the irq handler is done, but still seems somewhat dubious.
> > 
> > And I guess the bigger problem is that swap_state() happens way too
> > early. So crtc->state would be pointing to bogus stuff while we're
> > disabling the crtc.
> 
> Uh, so we're essentially piggy-packing some random i915 state on top of
> the hw timing stuff the vblank handler does, and hope that this is
> race-free enough to not matter?
> 
> I think the right solution there would be to have a proper
> spinlock_irqsafe for this stuff that the dsi TE handler needs, and through
> that make sure that we're actually not going boom. At least it looked like
> there's also irq handling bits outside of the vblank code, so the vblank
> locking is not going to safe the day.

I haven't actually looked at the DSI TE stuff so far, so no
idea what's going on there.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
Date: Fri, 21 Feb 2020 19:49:34 +0200	[thread overview]
Message-ID: <20200221174934.GT13686@intel.com> (raw)
In-Reply-To: <20200221171657.GE2363188@phenom.ffwll.local>

On Fri, Feb 21, 2020 at 06:16:57PM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > > > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
> > > > <ville.syrjala@linux.intel.com> wrote:
> > > > >
> > > > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
> > > > > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > > > > Looks like getting rid of private_flags is going to be pretty
> > > > > > > straightforward. I'll post patches for that once this first series
> > > > > > > lands.
> > > > > >
> > > > > > Going all in on crtc state? I suppose migrating away from private_flags
> > > > > > could easily start in i915 before that. Seems rather independent.
> > > > > >
> > > > > > I guess it's __intel_get_crtc_scanline() and:
> > > > > >
> > > > > >       vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)];
> > > > > >       mode = &vblank->hwmode;
> > > > > >
> > > > > >       if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP)
> > > > > >
> > > > > > that gives me the creeps in reviewing all that.
> > > > > >
> > > > > > There's also [1] adding new uses for private_flags; I think there were
> > > > > > issues in getting at the right crtc state on some of those paths, but I
> > > > > > forget the exact details. Ideas?
> > > > >
> > > > > I'm just going to move them to the crtc_state and put a copy into the
> > > > > crtc itself for the vblank code. Pretty much a 1:1 replacement.
> > > > > Saves me from having to think ;)
> > > > 
> > > > I've looked through the patches, and didn't spot any place where we
> > > > couldn't just get at the full crtc state. Might need some crtc->state
> > > > dereferencing and upcasting and making sure stuff is ordered correctly
> > > > with enable/disable paths of crtc, but nothing to jump over.
> > > 
> > > swap_state() could easily race with the irq handler. I guess
> > > practically unlikely the old crtc state would disappear before
> > > the irq handler is done, but still seems somewhat dubious.
> > 
> > And I guess the bigger problem is that swap_state() happens way too
> > early. So crtc->state would be pointing to bogus stuff while we're
> > disabling the crtc.
> 
> Uh, so we're essentially piggy-packing some random i915 state on top of
> the hw timing stuff the vblank handler does, and hope that this is
> race-free enough to not matter?
> 
> I think the right solution there would be to have a proper
> spinlock_irqsafe for this stuff that the dsi TE handler needs, and through
> that make sure that we're actually not going boom. At least it looked like
> there's also irq handling bits outside of the vblank code, so the vblank
> locking is not going to safe the day.

I haven't actually looked at the DSI TE stuff so far, so no
idea what's going on there.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-02-21 17:49 UTC|newest]

Thread overview: 133+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 20:35 [PATCH 00/12] drm: Put drm_display_mode on diet Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 01/12] drm: Nuke mode->hsync Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 10:55   ` Emil Velikov
2020-02-20 10:55     ` Emil Velikov
2020-02-21 16:04     ` Ville Syrjälä
2020-02-21 16:04       ` Ville Syrjälä
2020-02-21 16:55       ` Emil Velikov
2020-02-21 16:55         ` Emil Velikov
2020-02-19 20:35 ` [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 10:56   ` Emil Velikov
2020-02-20 10:56     ` [Intel-gfx] " Emil Velikov
2020-02-25  0:49     ` Inki Dae
2020-02-19 20:35 ` [PATCH 03/12] drm/i915: Introduce some local intel_dp variables Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 11:13   ` Emil Velikov
2020-02-20 11:13     ` Emil Velikov
2020-02-19 20:35 ` [PATCH 04/12] drm: Nuke mode->vrefresh Ville Syrjala
2020-02-19 20:35   ` Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35   ` Ville Syrjala
2020-02-20 12:00   ` Emil Velikov
2020-02-20 12:00     ` Emil Velikov
2020-02-20 12:00     ` [Intel-gfx] " Emil Velikov
2020-02-20 12:00     ` Emil Velikov
2020-02-22 12:32   ` Sam Ravnborg
2020-02-22 12:32     ` Sam Ravnborg
2020-02-22 12:32     ` [Intel-gfx] " Sam Ravnborg
2020-02-22 12:32     ` Sam Ravnborg
2020-02-24 13:14     ` Ville Syrjälä
2020-02-24 13:14       ` Ville Syrjälä
2020-02-24 13:14       ` [Intel-gfx] " Ville Syrjälä
2020-02-24 13:14       ` Ville Syrjälä
2020-02-24 14:14   ` Andrzej Hajda
2020-02-24 14:14     ` Andrzej Hajda
2020-02-24 14:14     ` [Intel-gfx] " Andrzej Hajda
2020-02-24 14:14     ` Andrzej Hajda
2020-02-25 11:21     ` Ville Syrjälä
2020-02-25 11:21       ` Ville Syrjälä
2020-02-25 11:21       ` [Intel-gfx] " Ville Syrjälä
2020-02-25 11:21       ` Ville Syrjälä
2020-02-25 15:19       ` Andrzej Hajda
2020-02-25 15:19         ` Andrzej Hajda
2020-02-25 15:19         ` [Intel-gfx] " Andrzej Hajda
2020-02-25 15:19         ` Andrzej Hajda
2020-02-25 15:45         ` Ville Syrjälä
2020-02-25 15:45           ` Ville Syrjälä
2020-02-25 15:45           ` [Intel-gfx] " Ville Syrjälä
2020-02-25 15:45           ` Ville Syrjälä
2020-02-25 19:27           ` Ville Syrjälä
2020-02-25 19:27             ` [Intel-gfx] " Ville Syrjälä
2020-02-25 19:27             ` Ville Syrjälä
2020-02-25 21:52             ` Linus Walleij
2020-02-25 21:52               ` Linus Walleij
2020-02-25 21:52               ` [Intel-gfx] " Linus Walleij
2020-02-25 21:52               ` Linus Walleij
2020-02-19 20:35 ` [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35   ` Ville Syrjala
2020-02-20 11:24   ` Emil Velikov
2020-02-20 11:24     ` [Intel-gfx] " Emil Velikov
2020-02-20 11:24     ` Emil Velikov
2020-02-20 15:33     ` Ville Syrjälä
2020-02-20 15:33       ` [Intel-gfx] " Ville Syrjälä
2020-02-20 15:33       ` Ville Syrjälä
2020-02-20 18:14       ` Daniel Vetter
2020-02-20 18:14         ` [Intel-gfx] " Daniel Vetter
2020-02-20 18:14         ` Daniel Vetter
2020-02-19 20:35 ` [PATCH 06/12] drm: Shrink {width,height}_mm to u16 Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 12:48   ` Emil Velikov
2020-02-20 12:48     ` Emil Velikov
2020-02-19 20:35 ` [PATCH 07/12] drm: Shrink mode->type to u8 Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 18:17   ` Daniel Vetter
2020-02-20 18:17     ` Daniel Vetter
2020-02-19 20:35 ` [PATCH 08/12] drm: Make mode->flags u32 Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 09/12] drm: Shrink drm_display_mode timings Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 18:19   ` Daniel Vetter
2020-02-20 18:19     ` Daniel Vetter
2020-02-20 18:47     ` Ville Syrjälä
2020-02-20 18:47       ` Ville Syrjälä
2020-02-21 16:13   ` Sam Ravnborg
2020-02-21 16:13     ` [Intel-gfx] " Sam Ravnborg
2020-02-21 17:27   ` Sam Ravnborg
2020-02-21 17:27     ` [Intel-gfx] " Sam Ravnborg
2020-02-24 13:06     ` Ville Syrjälä
2020-02-24 13:06       ` [Intel-gfx] " Ville Syrjälä
2020-02-19 20:35 ` [PATCH 10/12] drm: Flatten drm_mode_vrefresh() Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 11/12] drm: Shrink mode->private_flags Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-21 16:15   ` Sam Ravnborg
2020-02-21 16:15     ` [Intel-gfx] " Sam Ravnborg
2020-02-24 13:23     ` Ville Syrjälä
2020-02-24 13:23       ` [Intel-gfx] " Ville Syrjälä
2020-02-19 20:35 ` [PATCH 12/12] drm: pahole struct drm_display_mode Ville Syrjala
2020-02-19 20:35   ` [Intel-gfx] " Ville Syrjala
2020-02-20 12:53   ` Emil Velikov
2020-02-20 12:53     ` [Intel-gfx] " Emil Velikov
2020-02-19 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Put drm_display_mode on diet Patchwork
2020-02-19 21:18 ` [PATCH 00/12] " Ville Syrjälä
2020-02-19 21:18   ` [Intel-gfx] " Ville Syrjälä
2020-02-19 21:21 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-02-20 13:21 ` [PATCH 00/12] " Emil Velikov
2020-02-20 13:21   ` [Intel-gfx] " Emil Velikov
2020-02-20 14:27   ` Ville Syrjälä
2020-02-20 14:27     ` [Intel-gfx] " Ville Syrjälä
2020-02-20 15:34     ` Ville Syrjälä
2020-02-20 15:34       ` Ville Syrjälä
2020-02-21 11:32       ` Jani Nikula
2020-02-21 11:32         ` Jani Nikula
2020-02-21 11:43         ` Ville Syrjälä
2020-02-21 11:43           ` Ville Syrjälä
2020-02-21 14:42           ` Daniel Vetter
2020-02-21 14:42             ` Daniel Vetter
2020-02-21 15:40             ` Ville Syrjälä
2020-02-21 15:40               ` Ville Syrjälä
2020-02-21 16:09               ` Ville Syrjälä
2020-02-21 16:09                 ` Ville Syrjälä
2020-02-21 17:16                 ` Daniel Vetter
2020-02-21 17:16                   ` Daniel Vetter
2020-02-21 17:49                   ` Ville Syrjälä [this message]
2020-02-21 17:49                     ` Ville Syrjälä
2020-02-20 17:01     ` Emil Velikov
2020-02-20 17:01       ` [Intel-gfx] " Emil Velikov
2020-02-21 15:09 ` Linus Walleij
2020-02-21 15:09   ` [Intel-gfx] " Linus Walleij
2020-02-21 18:26 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork

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=20200221174934.GT13686@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.