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 [thread overview] 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
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com> To: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie>, Maxime Ripard <maxime.ripard@bootlin.com>, Nouveau Dev <nouveau@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "open list:DRM DRIVERS FOR RENESAS" <linux-renesas-soc@vger.kernel.org>, Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Sean Paul <seanpaul@chromium.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Sean Paul <sean@poorly.run>, intel-gfx <intel-gfx@lists.freedesktop.org>, Ben Skeggs <bskeggs@redhat.com> 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 [thread overview] 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-05-16 13:28 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-02 19:49 [PATCH v3 00/10] drm: Add self refresh helpers Sean Paul 2019-05-02 19:49 ` [PATCH v3 01/10] drm: Add atomic variants of enable/disable to encoder helper funcs Sean Paul 2019-05-03 7:51 ` Daniel Vetter 2019-05-03 12:34 ` Sean Paul 2019-05-03 14:08 ` Daniel Vetter 2019-05-03 14:08 ` Daniel Vetter 2019-05-02 19:49 ` [PATCH v3 02/10] drm: Add drm_atomic_crtc_state_for_encoder helper Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-03 8:18 ` Daniel Vetter 2019-05-03 12:47 ` Sean Paul 2019-05-03 14:06 ` Daniel Vetter 2019-05-05 21:15 ` Daniel Vetter 2019-05-05 22:01 ` Laurent Pinchart 2019-05-05 22:01 ` Laurent Pinchart 2019-05-02 19:49 ` [PATCH v3 03/10] drm: Add atomic variants for bridge enable/disable Sean Paul 2019-05-03 7:45 ` Daniel Vetter 2019-05-02 19:49 ` [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-03 8:19 ` Daniel Vetter 2019-05-11 19:12 ` Laurent Pinchart 2019-05-11 19:12 ` Laurent Pinchart 2019-05-13 14:38 ` Sean Paul 2019-05-13 14:38 ` Sean Paul 2019-05-16 12:00 ` Laurent Pinchart 2019-05-16 12:00 ` Laurent Pinchart 2019-05-16 14:21 ` Sean Paul 2019-05-16 14:21 ` Sean Paul 2019-05-13 14:47 ` Daniel Vetter 2019-05-13 14:47 ` Daniel Vetter 2019-05-16 12:02 ` Laurent Pinchart 2019-05-16 12:02 ` Laurent Pinchart 2019-05-16 12:07 ` Daniel Vetter 2019-05-16 12:07 ` Daniel Vetter 2019-05-16 13:28 ` Ville Syrjälä [this message] 2019-05-16 13:28 ` Ville Syrjälä 2019-05-02 19:49 ` [PATCH v3 05/10] drm: Add helpers to kick off self refresh mode in drivers Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-03 7:36 ` Daniel Vetter 2019-05-02 19:49 ` [PATCH v3 06/10] drm/rockchip: Use dirtyfb helper Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` [PATCH v3 07/10] drm/rockchip: Check for fast link training before enabling psr Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` [PATCH v3 08/10] drm/rockchip: Use the helpers for PSR Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` [PATCH v3 09/10] drm/rockchip: Don't fully disable vop on self refresh Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` [PATCH v3 10/10] drm/rockchip: Use drm_atomic_helper_commit_tail_rpm Sean Paul 2019-05-02 19:49 ` Sean Paul 2019-05-02 19:49 ` Sean Paul
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=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: linkBe 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.