Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: intel-gfx@lists.freedesktop.org,
	David Lechner <david@lechnology.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
Date: Fri, 23 Mar 2018 17:36:43 +0200	[thread overview]
Message-ID: <20180323153643.GC5453@intel.com> (raw)
In-Reply-To: <20180323135806.GT5453@intel.com>

On Fri, Mar 23, 2018 at 03:58:06PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 23, 2018 at 02:37:23PM +0100, Noralf Trønnes wrote:
> > 
> > Den 23.03.2018 12.31, skrev Ville Syrjälä:
> > > On Fri, Mar 23, 2018 at 12:43:58AM +0100, Noralf Trønnes wrote:
> > >>
> > >> Den 22.03.2018 21.27, skrev Ville Syrjala:
> > >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >>>
> > >>> mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > >>> bowels of the .atomic_enable() hook. That prevents us from taking the
> > >>> plane mutex in fb->dirty() unless we also plumb down the acquire
> > >>> context.
> > >>>
> > >>> Instead it seems simpler to split the fb->dirty() into a tinydrm
> > >>> specific lower level hook that can be called from
> > >>> mipi_dbi_enable_flush() and from a generic higher level
> > >>> tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
> > >>> vfuncs table we'll just stick it into tinydrm_device directly
> > >>> for now.
> > >> The long term goal is to try and get rid of tinydrm.ko by moving stuff
> > >> elsewhere as it's kind of a middle layer. So I'd really like to avoid
> > >> adding a callback like this.
> > >> Hopefully we can work out a solution based on my suggestion in the
> > >> 'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
> > > I don't want to start redesigning the entire architecture at
> > > this point. That would also cause a bigger risk of regression and
> > > then we'd potentially have to try and revert the entire plane->fb
> > > thing, which would not be fun if any significant changes have
> > > occurred in the meantime.
> > >
> > >> If we do need a hook, I prefer that we add it to
> > >> drm_simple_display_pipe_funcs.
> > > If you have plans to redesign tinydrm anyway it seems to me that
> > > a temporary hook in tinydrm is may be a bit less intrusive than
> > > inflicting it on the simple_kms_helper.
> > 
> > Yes you're right of course, what was I thinking.
> > 
> > You missed out on one call site:
> > 
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > index 11ae950b0fc9..7924eb59c2e1 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > @@ -124,11 +124,8 @@ void tinydrm_display_pipe_update(struct 
> > drm_simple_display_pipe *pipe,
> >          struct drm_framebuffer *fb = pipe->plane.state->fb;
> >          struct drm_crtc *crtc = &tdev->pipe.crtc;
> > 
> > -       if (fb && (fb != old_state->fb)) {
> > -               pipe->plane.fb = fb;
> > -               if (fb->funcs->dirty)
> > -                       fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> > -       }
> > +       if (fb && (fb != old_state->fb))
> > +               tdev->fb_dirty(fb, NULL, 0, 0, NULL, 0);
> > 
> >          if (crtc->state->event) {
> >                  spin_lock_irq(&crtc->dev->event_lock);
> > 
> > With that fixed, series is:
> > 
> > Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
> 
> Awesome. Thanks. And thanks for catching that extra dirty() call. I'll
> go and fix it up.

OK, I posted the fixed version.

Would you be interested in running some kind of smoke test on this
before I push it? I'd hate to break things for you, and unfortunately
(or maybe fortunately :) I don't have any hardware to test this.

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

  reply	other threads:[~2018-03-23 15:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-22 20:27 [PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook Ville Syrjala
2018-03-22 20:27 ` [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook Ville Syrjala
2018-03-22 23:43   ` Noralf Trønnes
2018-03-23 11:31     ` Ville Syrjälä
2018-03-23 13:37       ` Noralf Trønnes
2018-03-23 13:58         ` Ville Syrjälä
2018-03-23 15:36           ` Ville Syrjälä [this message]
2018-03-23 15:35   ` [PATCH v2 " Ville Syrjala
2018-03-23 16:28     ` Noralf Trønnes
2018-03-28 16:23       ` Ville Syrjälä
2018-03-24 17:22     ` David Lechner
2018-03-22 21:11 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook Patchwork
2018-03-22 21:26 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-23  0:26 ` ✓ Fi.CI.IGT: " Patchwork
2018-03-23 17:47 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook (rev3) Patchwork
2018-03-23 18:01 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-23 21:24 ` ✓ Fi.CI.IGT: " Patchwork
2018-03-24 17:26 ` [PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook David Lechner
2018-03-27 10:07   ` Ville Syrjälä
2018-03-27 16:40     ` David Lechner

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=20180323153643.GC5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=david@lechnology.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=noralf@tronnes.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox