All of 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 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.