Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sean Paul <sean@poorly.run>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Sean Paul <seanpaul@chromium.org>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Ben Skeggs <bskeggs@redhat.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Eric Anholt <eric@anholt.net>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	David Airlie <airlied@linux.ie>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Nouveau Dev <nouveau@lists.freedesktop.org>,
	"open list:DRM DRIVERS FOR RENESAS" 
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Date: Thu, 16 May 2019 16:28:03 +0300
Message-ID: <20190516132803.GM24299@intel.com> (raw)
In-Reply-To: <CAKMK7uG_TmzZBgVkJ+j9C53KRp1OgswYuxpFV77+eU6BPWwGgw@mail.gmail.com>

On Thu, May 16, 2019 at 02:07:34PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 2:02 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Hi Daniel,
> >
> > On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote:
> > > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote:
> > > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> > > >> From: Sean Paul <seanpaul@chromium.org>
> > > >>
> > > >> Everyone who implements connector_helper_funcs->atomic_check reaches
> > > >> into the connector state to get the atomic state. Instead of continuing
> > > >> this pattern, change the callback signature to just give atomic state
> > > >> and let the driver determine what it does and does not need from it.
> > > >>
> > > >> Eventually all atomic functions should do this, but that's just too much
> > > >> busy work for me.
> > > >
> > > > Given that drivers also access the connector state, isn't this slightly
> > > > more inefficient ?
> > >
> > > It's atomic code, we're trying to optimize for clean code at the expense
> > > of a bit of runtime overhead due to more pointer chasing. And I agree with
> > > the general push, the pile of old/new_state pointers of various objects
> > > we're passing around is confusing. Passing the overall drm_atomic_state
> > > seems much more reasonable, and with that we can get everything else. Plus
> > > it's much more obvious whether you have the old/new state (since that's
> > > explicit when you look it up from the drm_atomic_state).
> >
> > Yes, I agree it's cleaner. I just hope the atomic state tracking cost
> > can be kept under control :-)
> >
> > By the way, this is likely not going to happen as it would be way too
> > intrusive, but it would be nice to rename drm_atomic_state to
> > drm_atomic_transaction (or something similar). It doesn't model a state,
> > but a change between an old state to a new state. This confused me in
> > the past, and I'm sure it can still be confusing to newcomers.
> 
> Why are you the first to suggest this, this is awesome!

Can't quite tell if that's irony or not. Anyways, this has been
suggested before but no volunteers stepped forward.

> drm_atomic_state is indeed not a state, but a transaction representing
> how we go from the old to the new state.

On a semi-related topic, I've occasionally pondered about moving
mode_changed & co. from the obj states to the top level
state/transaction (maybe stored as a bitmask). But that would
definitely not be a trivial sed job.

-- 
Ville Syrjälä
Intel

      reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190502194956.218441-1-sean@poorly.run>
2019-05-02 19:49 ` Sean Paul
2019-05-03  8:19   ` Daniel Vetter
2019-05-11 19:12   ` Laurent Pinchart
2019-05-13 14:38     ` Sean Paul
2019-05-16 12:00       ` Laurent Pinchart
2019-05-16 14:21         ` Sean Paul
2019-05-13 14:47     ` Daniel Vetter
2019-05-16 12:02       ` Laurent Pinchart
2019-05-16 12:07         ` Daniel Vetter
2019-05-16 13:28           ` Ville Syrjälä [this message]

Reply instructions:

You may reply publically 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=20190516132803.GM24299@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=bskeggs@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sean@poorly.run \
    --cc=seanpaul@chromium.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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org linux-renesas-soc@archiver.kernel.org
	public-inbox-index linux-renesas-soc


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/ public-inbox