From: Ander Conselvan De Oliveira <conselvan2@gmail.com>
To: "Konduru, Chandra" <chandra.konduru@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 16/19] drm/i915: Check lane sharing between pipes B & C using atomic state
Date: Mon, 23 Mar 2015 09:33:48 +0200 [thread overview]
Message-ID: <1427096028.3131.4.camel@gmail.com> (raw)
In-Reply-To: <76A9B330A4D78C4D99CB292C4CC06C0E36F7F671@fmsmsx101.amr.corp.intel.com>
On Sun, 2015-03-22 at 16:20 +0000, Konduru, Chandra wrote:
>
>
> > -----Original Message-----
> > From: Conselvan De Oliveira, Ander
> > Sent: Thursday, March 19, 2015 11:46 PM
> > To: Konduru, Chandra
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 16/19] drm/i915: Check lane sharing between pipes B & C
> > using atomic state
> >
> > On Thu, 2015-03-19 at 20:58 +0000, Konduru, Chandra wrote:
> > >
> > > > -----Original Message-----
> > > > From: Conselvan De Oliveira, Ander
> > > > Sent: Friday, March 13, 2015 2:49 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > > > Subject: [PATCH 16/19] drm/i915: Check lane sharing between pipes B
> > > > & C using atomic state
> > > >
> > > > Makes that code atomic ready.
> > > >
> > > > Signed-off-by: Ander Conselvan de Oliveira
> > > > <ander.conselvan.de.oliveira@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 49
> > > > ++++++++++++++++++++++++++++++-
> > > > -----
> > > > 1 file changed, 42 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index e720a48..8c97186 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -5537,13 +5537,20 @@ bool intel_connector_get_hw_state(struct
> > > > intel_connector *connector)
> > > > return encoder->get_hw_state(encoder, &pipe); }
> > > >
> > > > -static int pipe_required_fdi_lanes(struct drm_device *dev, enum
> > > > pipe pipe)
> > > > +static int pipe_required_fdi_lanes(struct drm_atomic_state *state,
> > > > + enum pipe pipe)
> > > > {
> > > > struct intel_crtc *crtc =
> > > > - to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
> > > > + to_intel_crtc(intel_get_crtc_for_pipe(state->dev, pipe));
> > > > + struct intel_crtc_state *crtc_state;
> > > > +
> > > > + crtc_state = intel_atomic_get_crtc_state(state, crtc);
> > > > + if (WARN_ON(IS_ERR(crtc_state))) {
> > > > + /* Cause modeset to fail due to excess lanes. */
> > > > + return 5;
> > > > + }
> > > >
> > > > - if (crtc->base.state->enable &&
> > > > - crtc->config->has_pch_encoder)
> > > > + if (crtc_state->base.enable && crtc_state->has_pch_encoder)
> > > > return crtc->config->fdi_lanes;
> > > >
> > > > return 0;
> > > > @@ -5552,6 +5559,8 @@ static int pipe_required_fdi_lanes(struct
> > > > drm_device *dev, enum pipe pipe) static bool
> > > > ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
> > > > struct intel_crtc_state *pipe_config) {
> > > > + struct drm_atomic_state *state = pipe_config->base.state;
> > > > +
> > > > DRM_DEBUG_KMS("checking fdi config on pipe %c, lanes %i\n",
> > > > pipe_name(pipe), pipe_config->fdi_lanes);
> > > > if (pipe_config->fdi_lanes > 4) {
> > > > @@ -5579,7 +5588,7 @@ static bool ironlake_check_fdi_lanes(struct
> > > > drm_device *dev, enum pipe pipe,
> > > > return true;
> > > > case PIPE_B:
> > > > if (pipe_config->fdi_lanes > 2 &&
> > > > - pipe_required_fdi_lanes(dev, PIPE_C) > 0) {
> > > > + pipe_required_fdi_lanes(state, PIPE_C) > 0) {
> > > > DRM_DEBUG_KMS("invalid shared fdi lane config on
> > pipe %c: %i
> > > > lanes\n",
> > > > pipe_name(pipe), pipe_config->fdi_lanes);
> > > > return false;
> > > > @@ -5591,7 +5600,7 @@ static bool ironlake_check_fdi_lanes(struct
> > > > drm_device *dev, enum pipe pipe,
> > > > pipe_name(pipe), pipe_config->fdi_lanes);
> > > > return false;
> > > > }
> > > > - if (pipe_required_fdi_lanes(dev, PIPE_B) > 2) {
> > > > + if (pipe_required_fdi_lanes(state, PIPE_B) > 2) {
> > > > DRM_DEBUG_KMS("fdi link B uses too many lanes to
> > enable link
> > > > C\n");
> > > > return false;
> > > > }
> > > > @@ -5601,15 +5610,41 @@ static bool ironlake_check_fdi_lanes(struct
> > > > drm_device *dev, enum pipe pipe,
> > > > }
> > > > }
> > > >
> > > > +static int add_pipe_b_c_to_state(struct drm_atomic_state *state) {
> > > > + struct intel_crtc *pipe_B =
> > > > + to_intel_crtc(intel_get_crtc_for_pipe(state->dev, PIPE_B));
> > > > + struct intel_crtc *pipe_C =
> > > > + to_intel_crtc(intel_get_crtc_for_pipe(state->dev, PIPE_C));
> > > > + struct intel_crtc_state *crtc_state;
> > > > +
> > > > + crtc_state = intel_atomic_get_crtc_state(state, pipe_B);
> > > > + if (IS_ERR(crtc_state))
> > > > + return PTR_ERR(crtc_state);
> > > > +
> > > > + crtc_state = intel_atomic_get_crtc_state(state, pipe_C);
> > > > + if (IS_ERR(crtc_state))
> > > > + return PTR_ERR(crtc_state);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > #define RETRY 1
> > > > static int ironlake_fdi_compute_config(struct intel_crtc *intel_crtc,
> > > > struct intel_crtc_state *pipe_config) {
> > > > struct drm_device *dev = intel_crtc->base.dev;
> > > > struct drm_display_mode *adjusted_mode = &pipe_config-
> > > > >base.adjusted_mode;
> > > > - int lane, link_bw, fdi_dotclock;
> > > > + int lane, link_bw, fdi_dotclock, ret;
> > > > bool setup_ok, needs_recompute = false;
> > > >
> > > > + if (IS_IVYBRIDGE(dev) &&
> > > > + (intel_crtc->pipe == PIPE_B || intel_crtc->pipe == PIPE_C)) {
> > > > + ret = add_pipe_b_c_to_state(pipe_config->base.state);
> > >
> > > In this scenario, crtc_states are created for both pipe B & C as an
> > > operation on one can affect the other. I may be missing something
> > > here, but where is the other crtc_state being used: compute/check flow
> > > and/or commit flow?
> >
> > The function pipe_required_fdi_lanes() above is changed in this patch to use the
> > crtc_state in the drm atomic state to determined FDI lane availability. At this
> > point we don't yet allow changes to multiple pipes, so the mode set is rejected if
> > the pipe that is not being mode set uses too many lanes.
>
> If request requires too many lanes then mode set is rejected, that is fine.
> But my query is when the request requires lanes that can be supported.
> In that case where the other crtc_state is being used?
Same place, pipe_required_fdi_lanes() called from
ironlake_check_fdi_lanes().
Ander
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-03-23 7:33 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 9:48 [PATCH v2 00/19] Remove depencies on staged config for atomic transition Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 01/19] drm/i915: Add intel_atomic_get_crtc_state() helper function Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 02/19] drm/i915: Pass acquire ctx also to intel_release_load_detect_pipe() Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 03/19] drm/i915: Allocate a drm_atomic_state for the legacy modeset code Ander Conselvan de Oliveira
2015-03-17 6:46 ` [PATCH v3] " Ander Conselvan de Oliveira
2015-03-18 7:57 ` [PATCH v4] " Ander Conselvan de Oliveira
2015-03-18 23:57 ` Konduru, Chandra
2015-03-19 7:50 ` Ander Conselvan De Oliveira
2015-03-19 21:08 ` [PATCH 03/19] " Konduru, Chandra
2015-03-20 7:00 ` Ander Conselvan De Oliveira
2015-03-22 16:28 ` Konduru, Chandra
2015-03-13 9:48 ` [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc is being disabled Ander Conselvan de Oliveira
[not found] ` <76A9B330A4D78C4D99CB292C4CC06C0E36F7B41B@fmsmsx101.amr.corp.intel.com>
2015-03-19 7:52 ` Ander Conselvan De Oliveira
2015-03-19 23:23 ` Konduru, Chandra
2015-03-20 8:40 ` Ander Conselvan De Oliveira
2015-03-20 9:51 ` Daniel Vetter
2015-03-20 10:06 ` Ander Conselvan De Oliveira
2015-03-20 10:39 ` Daniel Vetter
2015-03-22 16:46 ` Konduru, Chandra
2015-03-13 9:48 ` [PATCH 05/19] drm/i915: Update dummy connector atomic state with current config Ander Conselvan de Oliveira
2015-03-19 20:55 ` Konduru, Chandra
2015-03-20 6:41 ` Ander Conselvan De Oliveira
2015-03-13 9:48 ` [PATCH 06/19] drm/i915: Implement connector state duplication Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 07/19] drm/i915: Copy the staged connector config to the legacy atomic state Ander Conselvan de Oliveira
[not found] ` <76A9B330A4D78C4D99CB292C4CC06C0E36F7B6F0@fmsmsx101.amr.corp.intel.com>
2015-03-19 7:52 ` Ander Conselvan De Oliveira
2015-03-19 15:15 ` Daniel Vetter
2015-03-13 9:48 ` [PATCH 08/19] drm/i915: Don't use encoder->new_crtc in intel_modeset_pipe_config() Ander Conselvan de Oliveira
2015-03-19 0:44 ` Konduru, Chandra
2015-03-19 7:52 ` Ander Conselvan De Oliveira
2015-03-13 9:48 ` [PATCH 09/19] drm/i915: Don't use encoder->new_crtc in compute_baseline_pipe_bpp() Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 10/19] drm/i915: Don't depend on encoder->new_crtc in intel_dp_compute_config() Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 11/19] drm/i915: Don't depend on encoder->new_crtc in intel_hdmi_compute_config Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 12/19] drm/i915: Use atomic state in intel_ddi_crtc_get_new_encoder() Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 13/19] drm/i915: Don't use staged config in intel_dp_mst_compute_config() Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 14/19] drm/i915: Don't use encoder->new_crtc in intel_lvds_compute_config() Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 15/19] drm/i915: Pass an atomic state to modeset_global_resources() functions Ander Conselvan de Oliveira
2015-03-13 9:48 ` [PATCH 16/19] drm/i915: Check lane sharing between pipes B & C using atomic state Ander Conselvan de Oliveira
2015-03-19 20:58 ` Konduru, Chandra
2015-03-20 6:46 ` Conselvan De Oliveira, Ander
2015-03-22 16:20 ` Konduru, Chandra
2015-03-23 7:33 ` Ander Conselvan De Oliveira [this message]
2015-03-23 16:57 ` Konduru, Chandra
2015-03-13 9:49 ` [PATCH 17/19] drm/i915: Convert intel_pipe_will_have_type() to " Ander Conselvan de Oliveira
2015-03-19 19:24 ` Konduru, Chandra
2015-03-20 6:28 ` Ander Conselvan De Oliveira
2015-03-22 16:14 ` Konduru, Chandra
2015-03-13 9:49 ` [PATCH 18/19] drm/i915: Don't look at staged config crtc when changing DRRS state Ander Conselvan de Oliveira
2015-03-13 9:49 ` [PATCH 19/19] drm/i915: Remove usage of encoder->new_crtc from clock computations Ander Conselvan de Oliveira
2015-03-14 0:29 ` shuang.he
2015-03-19 20:39 ` Konduru, Chandra
2015-03-18 23:57 ` [PATCH v2 00/19] Remove depencies on staged config for atomic transition Konduru, Chandra
2015-03-19 15:20 ` Daniel Vetter
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=1427096028.3131.4.camel@gmail.com \
--to=conselvan2@gmail.com \
--cc=chandra.konduru@intel.com \
--cc=intel-gfx@lists.freedesktop.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