All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Sean Paul" <sean@poorly.run>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Sean Paul" <seanpaul@chromium.org>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"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>
Subject: Re: [PATCH v3 02/10] drm: Add drm_atomic_crtc_state_for_encoder helper
Date: Mon, 6 May 2019 01:01:09 +0300	[thread overview]
Message-ID: <20190505220109.GD4922@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190505211536.GA17751@phenom.ffwll.local>

Hello,

On Sun, May 05, 2019 at 11:15:36PM +0200, Daniel Vetter wrote:
> On Fri, May 03, 2019 at 04:06:28PM +0200, Daniel Vetter wrote:
> > On Fri, May 3, 2019 at 2:47 PM Sean Paul <sean@poorly.run> wrote:
> >> On Fri, May 03, 2019 at 10:18:51AM +0200, Daniel Vetter wrote:
> >>> On Thu, May 02, 2019 at 03:49:44PM -0400, Sean Paul wrote:
> >>>> From: Sean Paul <seanpaul@chromium.org>
> >>>>
> >>>> This patch adds a helper to tease out the currently connected crtc for
> >>>> an encoder, along with its state. This follows the same pattern as the
> >>>> drm_atomic_crtc_*_for_* macros in the atomic helpers. Since the
> >>>> relationship of crtc:encoder is 1:n, we don't need a loop since there is
> >>>> only one crtc per encoder.
> >>>
> >>> No idea which macros you mean, couldn't find them.
> >>
> >> No longer relevant with the changes below, but for completeness, I was trying to
> >> refer to drm_atomic_crtc_state_for_each_plane and friends. I see now that I
> >> wasn't terribly clear :)
> >>
> >>>> Instead of splitting this into 3 functions which all do the same thing,
> >>>> this is presented as one function. Perhaps that's too ugly and it should
> >>>> be split to:
> >>>> struct drm_crtc *drm_atomic_crtc_for_encoder(state, encoder);
> >>>> struct drm_crtc_state *drm_atomic_new_crtc_state_for_encoder(state, encoder);
> >>>> struct drm_crtc_state *drm_atomic_old_crtc_state_for_encoder(state, encoder);
> >>>>
> >>>> Suggestions welcome.
> >>>>
> >>>> Changes in v3:
> >>>> - Added to the set
> >>>>
> >>>> Cc: Daniel Vetter <daniel@ffwll.ch>
> >>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> >>>> ---
> >>>>  drivers/gpu/drm/drm_atomic_helper.c | 48 +++++++++++++++++++++++++++++
> >>>>  include/drm/drm_atomic_helper.h     |  6 ++++
> >>>>  2 files changed, 54 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >>>> index 71cc7d6b0644..1f81ca8daad7 100644
> >>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>>> @@ -3591,3 +3591,51 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >>>>     return ret;
> >>>>  }
> >>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
> >>>> +
> >>>> +/**
> >>>> + * drm_atomic_crtc_state_for_encoder - Get crtc and new/old state for an encoder
> >>>> + * @state: Atomic state
> >>>> + * @encoder: The encoder to fetch the crtc information for
> >>>> + * @crtc: If not NULL, receives the currently connected crtc
> >>>> + * @old_crtc_state: If not NULL, receives the crtc's old state
> >>>> + * @new_crtc_state: If not NULL, receives the crtc's new state
> >>>> + *
> >>>> + * This function finds the crtc which is currently connected to @encoder and
> >>>> + * returns it as well as its old and new state. If there is no crtc currently
> >>>> + * connected, the function will clear @crtc, @old_crtc_state, @new_crtc_state.
> >>>> + *
> >>>> + * All of @crtc, @old_crtc_state, and @new_crtc_state are optional.
> >>>> + */
> >>>> +void drm_atomic_crtc_state_for_encoder(struct drm_atomic_state *state,
> >>>> +                                  struct drm_encoder *encoder,
> >>>> +                                  struct drm_crtc **crtc,
> >>>> +                                  struct drm_crtc_state **old_crtc_state,
> >>>> +                                  struct drm_crtc_state **new_crtc_state)
> >>>> +{
> >>>> +   struct drm_crtc *tmp_crtc;
> >>>> +   struct drm_crtc_state *tmp_new_crtc_state, *tmp_old_crtc_state;
> >>>> +   u32 enc_mask = drm_encoder_mask(encoder);
> >>>> +   int i;
> >>>> +
> >>>> +   for_each_oldnew_crtc_in_state(state, tmp_crtc, tmp_old_crtc_state,
> >>>> +                                 tmp_new_crtc_state, i) {
> >>>
> >>> So there's two ways to do this:
> >>>
> >>> - Using encoder_mask, which is a helper thing. In that case I'd rename
> >>>   this to drm_atomic_helper_crtc_for_encoder.
> >>>
> >>> - By looping over the connectors, and looking at ->best_encoder and
> >>>   ->crtc, see drm_encoder_get_crtc in drm_encoder.c. That's the core way
> >>>   of doing things. In that case call it drm_atomic_crtc_for_encoder, and
> >>>   put it into drm_atomic.c.
> >>>
> >>> There's two ways of doing the 2nd one: looping over connectors in a
> >>> drm_atomic_state, or the connector list overall. First requires that the
> >>> encoder is already in drm_atomic_state (which I think makes sense).
> >>
> >> Yeah, I wasn't particularly interested in encoders not in state. I had
> >> considered going the connector route, but since you can have multiple connectors
> >> per encoder, going through crtc seemed a bit more direct.
> > 
> > You can have multiple possible connectors for a given encoder, and
> > multiple possible encoders for a given connector. In both cases the
> > driver picks for you. But for active encoders and connectors the
> > relationship is 1:1. That's what the helpers exploit by looping over
> > connectors to get at encoders.
> > 
> >>> Even more complications on old/new_crtc_state: Is that the old state for
> >>> the old crtc, or the old state for the new crtc (that can switch too).
> >>> Same for the new crtc state ...
> >>>
> >>> tldr; I'd create 2 functions:
> >>>
> >>> drm_crtc *drm_atomic_encoder_get_new_crtc(drm_atomic_state *state, encoder)
> >>> drm_crtc *drm_atomic_encoder_get_old_crtc(drm_atomic_state *state, encoder)
> >>>
> >>> With the requirement that they'll return NULL if the encder isn't in in
> >>> @state, and implemented using looping over connectors in @state.
> >>
> >> It seems like we could just tweak this function a bit to get the new or old crtc
> >> for an encoder. Any particular reason for going through connector instead? Is it
> >> to avoid the encoder_mask which is a helper thing? In that case, perhaps this
> >> should use connector links and live in drm_atomic.c?
> > 
> > Well as explained, there's 3 ways you can achieve the same really. I
> > do think the "loop over connectors in drm_atomic_state, WARN() if we
> > haven't found the encoder you want the crtc for" is probably the most
> > solid aproach since it picks up a core atomic concept. But the others
> > (looping the connector list, or looping encoder_mask) all work too.
> > 
> > Aside: plane/encoder_mask was added to go from crtc to
> > planes/encoders, not really to go the other way round.
> > 
> > Another solution would be to pass the connector_state to all atomic
> > encoder hooks, then you could just look at connector_state->crtc. Plus
> > you can get at all the other interesting bits and pieces of
> > information. In a way this is fallout from us keeping encoders as a
> > meaningful concept for easier transition of legacy drivers, while
> > still keeping them entirely irrelevant for the actual userspace api
> > semantics.
> > 
> > So maybe we want drm_atomic_encoder_get_old/new_connector here. Or
> > maybe we even want the full set of functions, i.e.
> > drm_atomic_encoder_get_old/new_connector/crtc.
> 
> Laurent just asked me on irc how to get from a bridge to connector
> information. Bridge knows its encoder (it's static), so a encode2connector
> function would already have a 2nd user with this.
> 
> I.e. I'd say +1 on that approach, and then you can get at the connector
> state and whatever else you feel like from there?
> 
> Adding Laurent.

Thank you. I'll experiment with this, but please don't wait for me to
post a v4.

> > In all cases I think only returning the object, not it's state is
> > simplest, since then you avoid the confusion of old/new state for
> > old/new obj.
> >
> >>> tldr; this is a lot more tricky than it looks like ...
> >>>
> >>>> +           if (!(tmp_new_crtc_state->encoder_mask & enc_mask))
> >>>> +                   continue;
> >>>> +
> >>>> +           if (new_crtc_state)
> >>>> +                   *new_crtc_state = tmp_new_crtc_state;
> >>>> +           if (old_crtc_state)
> >>>> +                   *old_crtc_state = tmp_old_crtc_state;
> >>>> +           if (crtc)
> >>>> +                   *crtc = tmp_crtc;
> >>>> +           return;
> >>>> +   }
> >>>> +
> >>>> +   if (new_crtc_state)
> >>>> +           *new_crtc_state = NULL;
> >>>> +   if (old_crtc_state)
> >>>> +           *old_crtc_state = NULL;
> >>>> +   if (crtc)
> >>>> +           *crtc = NULL;
> >>>> +}
> >>>> +EXPORT_SYMBOL(drm_atomic_crtc_state_for_encoder);
> >>>> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> >>>> index 58214be3bf3d..2383550a0cc8 100644
> >>>> --- a/include/drm/drm_atomic_helper.h
> >>>> +++ b/include/drm/drm_atomic_helper.h
> >>>> @@ -153,6 +153,12 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >>>>                                    uint32_t size,
> >>>>                                    struct drm_modeset_acquire_ctx *ctx);
> >>>>
> >>>> +void drm_atomic_crtc_state_for_encoder(struct drm_atomic_state *state,
> >>>> +                                  struct drm_encoder *encoder,
> >>>> +                                  struct drm_crtc **crtc,
> >>>> +                                  struct drm_crtc_state **old_crtc_state,
> >>>> +                                  struct drm_crtc_state **new_crtc_state);
> >>>> +
> >>>>  /**
> >>>>   * drm_atomic_crtc_for_each_plane - iterate over planes currently attached to CRTC
> >>>>   * @plane: the loop cursor

-- 
Regards,

Laurent Pinchart
_______________________________________________
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Sean Paul" <sean@poorly.run>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Sean Paul" <seanpaul@chromium.org>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"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>
Subject: Re: [PATCH v3 02/10] drm: Add drm_atomic_crtc_state_for_encoder helper
Date: Mon, 6 May 2019 01:01:09 +0300	[thread overview]
Message-ID: <20190505220109.GD4922@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190505211536.GA17751@phenom.ffwll.local>

Hello,

On Sun, May 05, 2019 at 11:15:36PM +0200, Daniel Vetter wrote:
> On Fri, May 03, 2019 at 04:06:28PM +0200, Daniel Vetter wrote:
> > On Fri, May 3, 2019 at 2:47 PM Sean Paul <sean@poorly.run> wrote:
> >> On Fri, May 03, 2019 at 10:18:51AM +0200, Daniel Vetter wrote:
> >>> On Thu, May 02, 2019 at 03:49:44PM -0400, Sean Paul wrote:
> >>>> From: Sean Paul <seanpaul@chromium.org>
> >>>>
> >>>> This patch adds a helper to tease out the currently connected crtc for
> >>>> an encoder, along with its state. This follows the same pattern as the
> >>>> drm_atomic_crtc_*_for_* macros in the atomic helpers. Since the
> >>>> relationship of crtc:encoder is 1:n, we don't need a loop since there is
> >>>> only one crtc per encoder.
> >>>
> >>> No idea which macros you mean, couldn't find them.
> >>
> >> No longer relevant with the changes below, but for completeness, I was trying to
> >> refer to drm_atomic_crtc_state_for_each_plane and friends. I see now that I
> >> wasn't terribly clear :)
> >>
> >>>> Instead of splitting this into 3 functions which all do the same thing,
> >>>> this is presented as one function. Perhaps that's too ugly and it should
> >>>> be split to:
> >>>> struct drm_crtc *drm_atomic_crtc_for_encoder(state, encoder);
> >>>> struct drm_crtc_state *drm_atomic_new_crtc_state_for_encoder(state, encoder);
> >>>> struct drm_crtc_state *drm_atomic_old_crtc_state_for_encoder(state, encoder);
> >>>>
> >>>> Suggestions welcome.
> >>>>
> >>>> Changes in v3:
> >>>> - Added to the set
> >>>>
> >>>> Cc: Daniel Vetter <daniel@ffwll.ch>
> >>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> >>>> ---
> >>>>  drivers/gpu/drm/drm_atomic_helper.c | 48 +++++++++++++++++++++++++++++
> >>>>  include/drm/drm_atomic_helper.h     |  6 ++++
> >>>>  2 files changed, 54 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >>>> index 71cc7d6b0644..1f81ca8daad7 100644
> >>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>>> @@ -3591,3 +3591,51 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >>>>     return ret;
> >>>>  }
> >>>>  EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
> >>>> +
> >>>> +/**
> >>>> + * drm_atomic_crtc_state_for_encoder - Get crtc and new/old state for an encoder
> >>>> + * @state: Atomic state
> >>>> + * @encoder: The encoder to fetch the crtc information for
> >>>> + * @crtc: If not NULL, receives the currently connected crtc
> >>>> + * @old_crtc_state: If not NULL, receives the crtc's old state
> >>>> + * @new_crtc_state: If not NULL, receives the crtc's new state
> >>>> + *
> >>>> + * This function finds the crtc which is currently connected to @encoder and
> >>>> + * returns it as well as its old and new state. If there is no crtc currently
> >>>> + * connected, the function will clear @crtc, @old_crtc_state, @new_crtc_state.
> >>>> + *
> >>>> + * All of @crtc, @old_crtc_state, and @new_crtc_state are optional.
> >>>> + */
> >>>> +void drm_atomic_crtc_state_for_encoder(struct drm_atomic_state *state,
> >>>> +                                  struct drm_encoder *encoder,
> >>>> +                                  struct drm_crtc **crtc,
> >>>> +                                  struct drm_crtc_state **old_crtc_state,
> >>>> +                                  struct drm_crtc_state **new_crtc_state)
> >>>> +{
> >>>> +   struct drm_crtc *tmp_crtc;
> >>>> +   struct drm_crtc_state *tmp_new_crtc_state, *tmp_old_crtc_state;
> >>>> +   u32 enc_mask = drm_encoder_mask(encoder);
> >>>> +   int i;
> >>>> +
> >>>> +   for_each_oldnew_crtc_in_state(state, tmp_crtc, tmp_old_crtc_state,
> >>>> +                                 tmp_new_crtc_state, i) {
> >>>
> >>> So there's two ways to do this:
> >>>
> >>> - Using encoder_mask, which is a helper thing. In that case I'd rename
> >>>   this to drm_atomic_helper_crtc_for_encoder.
> >>>
> >>> - By looping over the connectors, and looking at ->best_encoder and
> >>>   ->crtc, see drm_encoder_get_crtc in drm_encoder.c. That's the core way
> >>>   of doing things. In that case call it drm_atomic_crtc_for_encoder, and
> >>>   put it into drm_atomic.c.
> >>>
> >>> There's two ways of doing the 2nd one: looping over connectors in a
> >>> drm_atomic_state, or the connector list overall. First requires that the
> >>> encoder is already in drm_atomic_state (which I think makes sense).
> >>
> >> Yeah, I wasn't particularly interested in encoders not in state. I had
> >> considered going the connector route, but since you can have multiple connectors
> >> per encoder, going through crtc seemed a bit more direct.
> > 
> > You can have multiple possible connectors for a given encoder, and
> > multiple possible encoders for a given connector. In both cases the
> > driver picks for you. But for active encoders and connectors the
> > relationship is 1:1. That's what the helpers exploit by looping over
> > connectors to get at encoders.
> > 
> >>> Even more complications on old/new_crtc_state: Is that the old state for
> >>> the old crtc, or the old state for the new crtc (that can switch too).
> >>> Same for the new crtc state ...
> >>>
> >>> tldr; I'd create 2 functions:
> >>>
> >>> drm_crtc *drm_atomic_encoder_get_new_crtc(drm_atomic_state *state, encoder)
> >>> drm_crtc *drm_atomic_encoder_get_old_crtc(drm_atomic_state *state, encoder)
> >>>
> >>> With the requirement that they'll return NULL if the encder isn't in in
> >>> @state, and implemented using looping over connectors in @state.
> >>
> >> It seems like we could just tweak this function a bit to get the new or old crtc
> >> for an encoder. Any particular reason for going through connector instead? Is it
> >> to avoid the encoder_mask which is a helper thing? In that case, perhaps this
> >> should use connector links and live in drm_atomic.c?
> > 
> > Well as explained, there's 3 ways you can achieve the same really. I
> > do think the "loop over connectors in drm_atomic_state, WARN() if we
> > haven't found the encoder you want the crtc for" is probably the most
> > solid aproach since it picks up a core atomic concept. But the others
> > (looping the connector list, or looping encoder_mask) all work too.
> > 
> > Aside: plane/encoder_mask was added to go from crtc to
> > planes/encoders, not really to go the other way round.
> > 
> > Another solution would be to pass the connector_state to all atomic
> > encoder hooks, then you could just look at connector_state->crtc. Plus
> > you can get at all the other interesting bits and pieces of
> > information. In a way this is fallout from us keeping encoders as a
> > meaningful concept for easier transition of legacy drivers, while
> > still keeping them entirely irrelevant for the actual userspace api
> > semantics.
> > 
> > So maybe we want drm_atomic_encoder_get_old/new_connector here. Or
> > maybe we even want the full set of functions, i.e.
> > drm_atomic_encoder_get_old/new_connector/crtc.
> 
> Laurent just asked me on irc how to get from a bridge to connector
> information. Bridge knows its encoder (it's static), so a encode2connector
> function would already have a 2nd user with this.
> 
> I.e. I'd say +1 on that approach, and then you can get at the connector
> state and whatever else you feel like from there?
> 
> Adding Laurent.

Thank you. I'll experiment with this, but please don't wait for me to
post a v4.

> > In all cases I think only returning the object, not it's state is
> > simplest, since then you avoid the confusion of old/new state for
> > old/new obj.
> >
> >>> tldr; this is a lot more tricky than it looks like ...
> >>>
> >>>> +           if (!(tmp_new_crtc_state->encoder_mask & enc_mask))
> >>>> +                   continue;
> >>>> +
> >>>> +           if (new_crtc_state)
> >>>> +                   *new_crtc_state = tmp_new_crtc_state;
> >>>> +           if (old_crtc_state)
> >>>> +                   *old_crtc_state = tmp_old_crtc_state;
> >>>> +           if (crtc)
> >>>> +                   *crtc = tmp_crtc;
> >>>> +           return;
> >>>> +   }
> >>>> +
> >>>> +   if (new_crtc_state)
> >>>> +           *new_crtc_state = NULL;
> >>>> +   if (old_crtc_state)
> >>>> +           *old_crtc_state = NULL;
> >>>> +   if (crtc)
> >>>> +           *crtc = NULL;
> >>>> +}
> >>>> +EXPORT_SYMBOL(drm_atomic_crtc_state_for_encoder);
> >>>> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> >>>> index 58214be3bf3d..2383550a0cc8 100644
> >>>> --- a/include/drm/drm_atomic_helper.h
> >>>> +++ b/include/drm/drm_atomic_helper.h
> >>>> @@ -153,6 +153,12 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >>>>                                    uint32_t size,
> >>>>                                    struct drm_modeset_acquire_ctx *ctx);
> >>>>
> >>>> +void drm_atomic_crtc_state_for_encoder(struct drm_atomic_state *state,
> >>>> +                                  struct drm_encoder *encoder,
> >>>> +                                  struct drm_crtc **crtc,
> >>>> +                                  struct drm_crtc_state **old_crtc_state,
> >>>> +                                  struct drm_crtc_state **new_crtc_state);
> >>>> +
> >>>>  /**
> >>>>   * drm_atomic_crtc_for_each_plane - iterate over planes currently attached to CRTC
> >>>>   * @plane: the loop cursor

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2019-05-05 22:01 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 [this message]
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ä
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=20190505220109.GD4922@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=sean@poorly.run \
    --cc=seanpaul@chromium.org \
    --cc=ville.syrjala@linux.intel.com \
    /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.