Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thursday, August 17, 2017 1:44:14 PM PDT Rodrigo Vivi wrote: > On Thu, Aug 17, 2017 at 1:11 PM, Pandiyan, Dhinakaran > > wrote: > > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote: > >> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: > >> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare > >> > > >> ><[1]manasi.d.nav...@intel.com> wrote: > >> > In case of eDP because the panel has a fixed mode we cannot > >> > link train fallback and prune modes since this results in > >> > no modes available for eDP connector. > >> > > >> >What about downclock modes?! > >> > >> What are the downclock modes? We have seen an issue with pruning modes > >> in case of eDP panel where we end up pruning the mode due to link train > >> fallback and then we get an error saying "No modes available for the > >> connector" > > > > fwiw I've got two laptops with eDP's having more than ten modes. > > those ten are probably a list of modes with scaler right?! Yeah, Clint very graciously explained that to me after I sent the email. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix the channel equalization failure condition during Link Training
== Series Details == Series: drm/i915/dp: Fix the channel equalization failure condition during Link Training URL : https://patchwork.freedesktop.org/series/28960/ State : success == Summary == Series 28960v1 drm/i915/dp: Fix the channel equalization failure condition during Link Training https://patchwork.freedesktop.org/api/1.0/series/28960/revisions/1/mbox/ fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:453s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:435s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:361s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:557s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:520s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:519s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:611s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:421s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:424s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:503s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:602s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:599s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:523s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:477s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:485s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:477s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:405s cdafe36f7b6f8fa0ae1a90babce68cbd8ccc98cb drm-tip: 2017y-08m-17d-21h-02m-32s UTC integration manifest 48c01fe55f07 drm/i915/dp: Fix the channel equalization failure condition during Link Training == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5432/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Fix the channel equalization failure condition during Link Training
In the channel EQ retry loop, we break from the loop in case of failure to get link status or failure in clock recovery or failure to update link training. In these cases channel_eq_status is still false even though the retry loop has not reached max retries. So we need to consider this as a failure condition. Signed-off-by: Manasi Navare Cc: Jim Bride Cc: Jani Nikula Cc: Ville Syrjala --- drivers/gpu/drm/i915/intel_dp_link_training.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c index 05907fa..3fef219 100644 --- a/drivers/gpu/drm/i915/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c @@ -294,9 +294,9 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp) } /* Try 5 times, else fail and try at lower BW */ - if (tries == 5) { + if (tries == 5 || !intel_dp->channel_eq_status) { intel_dp_dump_link_status(link_status); - DRM_DEBUG_KMS("Channel equalization failed 5 times\n"); + DRM_DEBUG_KMS("Channel equalization failed\n"); } intel_dp_set_idle_link_train(intel_dp); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence
On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula wrote: > > On Thu, 15 Jun 2017, Imre Deak wrote: > > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote: > >> I believe it is worth allowing RPM to work without requiring DMC, no?! > > > > Not if there is no good reason for not using DMC. It was decided early > > on that we won't support that configuration since if you care about the > > power saving provided by partially disabling things you probably also > > care about the bigger power saving provided by DMC. So that is the > > current state of the driver, enabling runtime PM without having DMC > > loaded is not supported. Proper support for that would need to be added > > after a justification why not to use the firmware. > > Agreed. We already have too many configurations to support, and we > already struggle with our testing coverage as-is. Adding new > configurations to be tested is not to be taken lightly. > For context, we are seeing GPU hangs at suspend/resume with DMC enabled (feel free to email me if you want to be added to the internal bug) which is the reason for this patch. If those GPU hangs can be fixed instead, then that would be an even better solution, IMO. Is there someone on your side who could help with these hangs? Stéphane > > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 8/8] drm/i915: Constify states passed to enable/disable/etc. encoder hooks
On Fri, May 19, 2017 at 04:17:25PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The enable/disable/etc. encoder hooks aren't supposed to alter the > state(s), so pass them as const. Unfortunately C lacks any kind of deep > const thingy, so this can't catch all abuses. But at least it acts as a > hint to the reader telling them not to mess about with the state(s). That makes total sense. I didn't check all functions to see if no one is ofending them though. Acked-by: Rodrigo Vivi > > v2: Update intel_tv_mode_find() and ironlake_edp_pll_on() as well > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_crt.c| 22 ++-- > drivers/gpu/drm/i915/intel_ddi.c| 30 > drivers/gpu/drm/i915/intel_dp.c | 64 - > drivers/gpu/drm/i915/intel_dp_mst.c | 16 - > drivers/gpu/drm/i915/intel_drv.h| 32 - > drivers/gpu/drm/i915/intel_dsi.c| 22 ++-- > drivers/gpu/drm/i915/intel_dvo.c| 12 +++ > drivers/gpu/drm/i915/intel_hdmi.c | 70 > ++--- > drivers/gpu/drm/i915/intel_lvds.c | 24 ++--- > drivers/gpu/drm/i915/intel_sdvo.c | 24 ++--- > drivers/gpu/drm/i915/intel_tv.c | 14 > 11 files changed, 165 insertions(+), 165 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_crt.c > b/drivers/gpu/drm/i915/intel_crt.c > index 84a1f5e85153..94b9a2eeb0b2 100644 > --- a/drivers/gpu/drm/i915/intel_crt.c > +++ b/drivers/gpu/drm/i915/intel_crt.c > @@ -143,7 +143,7 @@ static void hsw_crt_get_config(struct intel_encoder > *encoder, > /* Note: The caller is required to filter out dpms modes not supported by the > * platform. */ > static void intel_crt_set_dpms(struct intel_encoder *encoder, > -struct intel_crtc_state *crtc_state, > +const struct intel_crtc_state *crtc_state, > int mode) > { > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > @@ -194,28 +194,28 @@ static void intel_crt_set_dpms(struct intel_encoder > *encoder, > } > > static void intel_disable_crt(struct intel_encoder *encoder, > - struct intel_crtc_state *old_crtc_state, > - struct drm_connector_state *old_conn_state) > + const struct intel_crtc_state *old_crtc_state, > + const struct drm_connector_state *old_conn_state) > { > intel_crt_set_dpms(encoder, old_crtc_state, DRM_MODE_DPMS_OFF); > } > > static void pch_disable_crt(struct intel_encoder *encoder, > - struct intel_crtc_state *old_crtc_state, > - struct drm_connector_state *old_conn_state) > + const struct intel_crtc_state *old_crtc_state, > + const struct drm_connector_state *old_conn_state) > { > } > > static void pch_post_disable_crt(struct intel_encoder *encoder, > - struct intel_crtc_state *old_crtc_state, > - struct drm_connector_state *old_conn_state) > + const struct intel_crtc_state *old_crtc_state, > + const struct drm_connector_state > *old_conn_state) > { > intel_disable_crt(encoder, old_crtc_state, old_conn_state); > } > > static void hsw_post_disable_crt(struct intel_encoder *encoder, > - struct intel_crtc_state *old_crtc_state, > - struct drm_connector_state *old_conn_state) > + const struct intel_crtc_state *old_crtc_state, > + const struct drm_connector_state > *old_conn_state) > { > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > > @@ -228,8 +228,8 @@ static void hsw_post_disable_crt(struct intel_encoder > *encoder, > } > > static void intel_enable_crt(struct intel_encoder *encoder, > - struct intel_crtc_state *pipe_config, > - struct drm_connector_state *conn_state) > + const struct intel_crtc_state *pipe_config, > + const struct drm_connector_state *conn_state) > { > intel_crt_set_dpms(encoder, pipe_config, DRM_MODE_DPMS_ON); > } > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 6203c2da3daf..21aa5eab292c 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -644,7 +644,7 @@ static void intel_wait_ddi_buf_idle(struct > drm_i915_private *dev_priv, > DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n", port_name(port)); > } > > -static uint32_t hsw_pll_to_ddi_pll_sel(struct intel_shared_dpll *pll) > +static uint32_t hsw_pll_to_ddi_pll_sel(const struct intel_shared_
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Remove mostly duplicated video DIP handling from PSR code
On Fri, May 19, 2017 at 04:17:24PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that the infoframe hooks are part of the intel_dig_port, we can use > the normal .write_infoframe() hook to update the VSC SDP. We do need to > deal with the size difference between the VSC DIP and the others though. > > Another minor snag is that the compiler will complain to use if we keep > using enum hdmi_infoframe_type type and passing in the DP define instead, > so et's just change to unsigned int all over for the inforframe type. > > Signed-off-by: Ville Syrjälä how didn't we have this before?! :) Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_drv.h | 2 +- > drivers/gpu/drm/i915/intel_hdmi.c | 26 -- > drivers/gpu/drm/i915/intel_psr.c | 39 > ++- > 3 files changed, 23 insertions(+), 44 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index a3d66ccafa5e..534a5bfb273e 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1067,7 +1067,7 @@ struct intel_digital_port { > > void (*write_infoframe)(struct drm_encoder *encoder, > const struct intel_crtc_state *crtc_state, > - enum hdmi_infoframe_type type, > + unsigned int type, > const void *frame, ssize_t len); > void (*set_infoframes)(struct drm_encoder *encoder, > bool enable, > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 6b1c3f998a63..47a9f7f98a62 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -70,7 +70,7 @@ static struct intel_hdmi *intel_attached_hdmi(struct > drm_connector *connector) > return enc_to_intel_hdmi(&intel_attached_encoder(connector)->base); > } > > -static u32 g4x_infoframe_index(enum hdmi_infoframe_type type) > +static u32 g4x_infoframe_index(unsigned int type) > { > switch (type) { > case HDMI_INFOFRAME_TYPE_AVI: > @@ -85,7 +85,7 @@ static u32 g4x_infoframe_index(enum hdmi_infoframe_type > type) > } > } > > -static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type) > +static u32 g4x_infoframe_enable(unsigned int type) > { > switch (type) { > case HDMI_INFOFRAME_TYPE_AVI: > @@ -100,9 +100,11 @@ static u32 g4x_infoframe_enable(enum hdmi_infoframe_type > type) > } > } > > -static u32 hsw_infoframe_enable(enum hdmi_infoframe_type type) > +static u32 hsw_infoframe_enable(unsigned int type) > { > switch (type) { > + case DP_SDP_VSC: > + return VIDEO_DIP_ENABLE_VSC_HSW; > case HDMI_INFOFRAME_TYPE_AVI: > return VIDEO_DIP_ENABLE_AVI_HSW; > case HDMI_INFOFRAME_TYPE_SPD: > @@ -118,10 +120,12 @@ static u32 hsw_infoframe_enable(enum > hdmi_infoframe_type type) > static i915_reg_t > hsw_dip_data_reg(struct drm_i915_private *dev_priv, >enum transcoder cpu_transcoder, > - enum hdmi_infoframe_type type, > + unsigned int type, >int i) > { > switch (type) { > + case DP_SDP_VSC: > + return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i); > case HDMI_INFOFRAME_TYPE_AVI: > return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i); > case HDMI_INFOFRAME_TYPE_SPD: > @@ -136,7 +140,7 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv, > > static void g4x_write_infoframe(struct drm_encoder *encoder, > const struct intel_crtc_state *crtc_state, > - enum hdmi_infoframe_type type, > + unsigned int type, > const void *frame, ssize_t len) > { > const uint32_t *data = frame; > @@ -191,7 +195,7 @@ static bool g4x_infoframe_enabled(struct drm_encoder > *encoder, > > static void ibx_write_infoframe(struct drm_encoder *encoder, > const struct intel_crtc_state *crtc_state, > - enum hdmi_infoframe_type type, > + unsigned int type, > const void *frame, ssize_t len) > { > const uint32_t *data = frame; > @@ -251,7 +255,7 @@ static bool ibx_infoframe_enabled(struct drm_encoder > *encoder, > > static void cpt_write_infoframe(struct drm_encoder *encoder, > const struct intel_crtc_state *crtc_state, > - enum hdmi_infoframe_type type, > + unsigned int type, > const void *frame, ssize_t len) > { > const uint32_t *data = frame; > @@ -309,7 +313,7 @@ static bool cpt_infoframe_enabled(struct drm_encoder > *encoder, > > static void vlv_write_infoframe(struct dr
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Plumb crtc_state to PSR enable/disable
On Fri, May 19, 2017 at 04:17:23PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The PSR enable/disable need to know things about the crtc state, so > plumb it through. This will become even more important when we start > to reuse the generic infoframe code for the VSC DIP programming as the > infoframe code wants the crtc state as well. > > Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_ddi.c | 4 +-- > drivers/gpu/drm/i915/intel_dp.c | 4 +-- > drivers/gpu/drm/i915/intel_drv.h | 6 ++-- > drivers/gpu/drm/i915/intel_psr.c | 77 > +--- > 4 files changed, 48 insertions(+), 43 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 5dbbfedfbb06..6203c2da3daf 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -1847,7 +1847,7 @@ static void intel_enable_ddi(struct intel_encoder > *intel_encoder, > intel_dp_stop_link_train(intel_dp); > > intel_edp_backlight_on(intel_dp); > - intel_psr_enable(intel_dp); > + intel_psr_enable(intel_dp, pipe_config); > intel_edp_drrs_enable(intel_dp, pipe_config); > } > > @@ -1875,7 +1875,7 @@ static void intel_disable_ddi(struct intel_encoder > *intel_encoder, > struct intel_dp *intel_dp = enc_to_intel_dp(encoder); > > intel_edp_drrs_disable(intel_dp, old_crtc_state); > - intel_psr_disable(intel_dp); > + intel_psr_disable(intel_dp, old_crtc_state); > intel_edp_backlight_off(intel_dp); > } > } > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 62084e350f58..1784989ca478 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -2669,7 +2669,7 @@ static void intel_disable_dp(struct intel_encoder > *encoder, > intel_audio_codec_disable(encoder); > > if (HAS_PSR(dev_priv) && !HAS_DDI(dev_priv)) > - intel_psr_disable(intel_dp); > + intel_psr_disable(intel_dp, old_crtc_state); > > /* Make sure the panel is off before trying to change the mode. But also >* ensure that we have vdd while we switch off the panel. */ > @@ -2901,7 +2901,7 @@ static void vlv_enable_dp(struct intel_encoder *encoder, > struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); > > intel_edp_backlight_on(intel_dp); > - intel_psr_enable(intel_dp); > + intel_psr_enable(intel_dp, pipe_config); > } > > static void g4x_pre_enable_dp(struct intel_encoder *encoder, > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index de2288f78961..a3d66ccafa5e 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1740,8 +1740,10 @@ static inline void > intel_backlight_device_unregister(struct intel_connector *con > > > /* intel_psr.c */ > -void intel_psr_enable(struct intel_dp *intel_dp); > -void intel_psr_disable(struct intel_dp *intel_dp); > +void intel_psr_enable(struct intel_dp *intel_dp, > + const struct intel_crtc_state *crtc_state); > +void intel_psr_disable(struct intel_dp *intel_dp, > + const struct intel_crtc_state *old_crtc_state); > void intel_psr_invalidate(struct drm_i915_private *dev_priv, > unsigned frontbuffer_bits); > void intel_psr_flush(struct drm_i915_private *dev_priv, > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index c3780d0d2baf..f976aa865ef9 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -103,28 +103,26 @@ static void intel_psr_write_vsc(struct intel_dp > *intel_dp, > POSTING_READ(ctl_reg); > } > > -static void vlv_psr_setup_vsc(struct intel_dp *intel_dp) > +static void vlv_psr_setup_vsc(struct intel_dp *intel_dp, > + const struct intel_crtc_state *crtc_state) > { > - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > - struct drm_device *dev = intel_dig_port->base.base.dev; > - struct drm_i915_private *dev_priv = to_i915(dev); > - struct drm_crtc *crtc = intel_dig_port->base.base.crtc; > - enum pipe pipe = to_intel_crtc(crtc)->pipe; > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); > uint32_t val; > > /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */ > - val = I915_READ(VLV_VSCSDP(pipe)); > + val = I915_READ(VLV_VSCSDP(crtc->pipe)); > val &= ~VLV_EDP_PSR_SDP_FREQ_MASK; > val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME; > - I915_WRITE(VLV_VSCSDP(pipe), val); > + I915_WRITE(VLV_VSCSDP(crtc->pipe), val); > } > > -static void skl_p
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Check has_infoframes when enabling infoframes
On Fri, May 19, 2017 at 04:17:19PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > has_infoframe is what tells us whether infoframes should be enabled, so > let's pass that instead of has_hdmi_sink to .set_infoframes(). makes sense Reviewed-by: Rodrigo Vivi > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_ddi.c | 6 +++--- > drivers/gpu/drm/i915/intel_hdmi.c | 6 +++--- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 0914ad96a71b..8ab0f34d8de9 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -1673,7 +1673,7 @@ static void intel_ddi_pre_enable_dp(struct > intel_encoder *encoder, > } > > static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder, > - bool has_hdmi_sink, > + bool has_infoframe, > const struct intel_crtc_state *crtc_state, > const struct drm_connector_state > *conn_state, > struct intel_shared_dpll *pll) > @@ -1698,7 +1698,7 @@ static void intel_ddi_pre_enable_hdmi(struct > intel_encoder *encoder, > INTEL_OUTPUT_HDMI); > > intel_hdmi->set_infoframes(drm_encoder, > -has_hdmi_sink, > +has_infoframe, > crtc_state, conn_state); > } > > @@ -1718,7 +1718,7 @@ static void intel_ddi_pre_enable(struct intel_encoder > *encoder, > } > if (type == INTEL_OUTPUT_HDMI) { > intel_ddi_pre_enable_hdmi(encoder, > - pipe_config->has_hdmi_sink, > + pipe_config->has_infoframe, > pipe_config, conn_state, > pipe_config->shared_dpll); > } > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 58d690393b29..b586d9782109 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1676,7 +1676,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder > *encoder, > intel_hdmi_prepare(encoder, pipe_config); > > intel_hdmi->set_infoframes(&encoder->base, > -pipe_config->has_hdmi_sink, > +pipe_config->has_infoframe, > pipe_config, conn_state); > } > > @@ -1696,7 +1696,7 @@ static void vlv_hdmi_pre_enable(struct intel_encoder > *encoder, >0x2b247878); > > intel_hdmi->set_infoframes(&encoder->base, > -pipe_config->has_hdmi_sink, > +pipe_config->has_infoframe, > pipe_config, conn_state); > > g4x_enable_hdmi(encoder, pipe_config, conn_state); > @@ -1768,7 +1768,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder > *encoder, > chv_set_phy_signal_level(encoder, 128, 102, false); > > intel_hdmi->set_infoframes(&encoder->base, > -pipe_config->has_hdmi_sink, > +pipe_config->has_infoframe, > pipe_config, conn_state); > > g4x_enable_hdmi(encoder, pipe_config, conn_state); > -- > 2.10.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915/pmu: serve global events and support perf stat
On Tue, 2017-08-15 at 10:56 -0700, Dmitry Rogozhkin wrote: > This patch should probably be squashed with Tvrtko's PMU enabling > patch... > > i915 events don't have a CPU context to work with, so i915 > PMU should work in global mode, i.e. expose perf_invalid_context. > This will make the following call to perf: >perf stat workload.sh > to error out with "failed to read counter". Correct usage would be: >perf stat -a -C0 workload.sh > And we will get expected output: > > Another change required to make perf stat happy is properly support > pmu->del(): comments in del() declaration says that del() is required > to call stop(event, PERF_EF_UPDATE) and perf stat implicitly gets > event count thru this. > > Finally, if perf stat will be ran as follows: >perf stat -a workload.sh > i.e. without '-C0' option, then event will be initilized as many times > as there are CPUs. Thus, patch adds PMU refcounting support to avoid > multiple init/close of internal things. The issue which I did not > overcome is that in this case counters will be multiplied on number > of CPUs. Not sure whether it is possible to have some event enabling > CPU mask or rather I need to simply error out. > > Change-Id: I7d1abe747a4399196e72253f7b66441a6528dbee > Signed-off-by: Dmitry Rogozhkin > Cc: Tvrtko Ursulin > Cc: Peter Zijlstra > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_pmu.c | 106 > ++-- > 2 files changed, 60 insertions(+), 47 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index b59da2c..215d47b 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2663,6 +2663,7 @@ struct drm_i915_private { > struct { > struct pmu base; > spinlock_t lock; > + unsigned int ref; > struct hrtimer timer; > bool timer_enabled; > u64 enable; > diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c > index bcdf2bc..0972203 100644 > --- a/drivers/gpu/drm/i915/i915_pmu.c > +++ b/drivers/gpu/drm/i915/i915_pmu.c > @@ -451,34 +451,39 @@ static void i915_pmu_enable(struct perf_event *event) > container_of(event->pmu, typeof(*i915), pmu.base); > struct intel_engine_cs *engine = NULL; > unsigned long flags; > + bool start_timer = false; > > spin_lock_irqsave(&i915->pmu.lock, flags); > > - if (is_engine_event(event)) { > - engine = intel_engine_lookup_user(i915, > - engine_event_class(event), > - engine_event_instance(event)); > - GEM_BUG_ON(!engine); > - engine->pmu.enable |= BIT(engine_event_sample(event)); > - } > - > - i915->pmu.enable |= event_enabled_mask(event); > + if (i915->pmu.ref++ == 0) { This was a stupid me: with this I support single busy_stat event only. Correct way to do that is to make busy_stats a refcount. I did that in the updated patch which I just sent. I wonder whether timer staff should be updated with the similar way, but I am not yet tried this part of the code to judge. > + if (is_engine_event(event)) { > + engine = intel_engine_lookup_user(i915, > + > engine_event_class(event), > + > engine_event_instance(event)); > + GEM_BUG_ON(!engine); > + engine->pmu.enable |= BIT(engine_event_sample(event)); > + } > > - if (pmu_needs_timer(i915, true) && !i915->pmu.timer_enabled) { > - hrtimer_start_range_ns(&i915->pmu.timer, > -ns_to_ktime(PERIOD), 0, > -HRTIMER_MODE_REL_PINNED); > - i915->pmu.timer_enabled = true; > - } else if (is_engine_event(event) && engine_needs_busy_stats(engine) && > -!engine->pmu.busy_stats) { > - engine->pmu.busy_stats = true; > - if (!cancel_delayed_work(&engine->pmu.disable_busy_stats)) > - queue_work(i915->wq, &engine->pmu.enable_busy_stats); > + i915->pmu.enable |= event_enabled_mask(event); > + > + if (pmu_needs_timer(i915, true) && !i915->pmu.timer_enabled) { > + hrtimer_start_range_ns(&i915->pmu.timer, > + ns_to_ktime(PERIOD), 0, > + HRTIMER_MODE_REL_PINNED); > + i915->pmu.timer_enabled = true; > + } else if (is_engine_event(event) && > engine_needs_busy_stats(engine) && > + !engine->pmu.busy_stats) { > + engine->pmu.busy_stats = true; > + if > (!cancel_delayed_work(&engine-
[Intel-gfx] [RFC v1 1/2] drm/i915/pmu: reorder function to suite next patch
This patch is doing nover except reordering functions to highlight changes in the next patch. Change-Id: I0cd298780503ae8f6f8035b86c59fc8b5191356b Signed-off-by: Dmitry Rogozhkin Cc: Tvrtko Ursulin Cc: Peter Zijlstra --- drivers/gpu/drm/i915/i915_pmu.c | 180 1 file changed, 90 insertions(+), 90 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index 3272ec0..bcdf2bc 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -363,6 +363,88 @@ static bool engine_needs_busy_stats(struct intel_engine_cs *engine) (engine->pmu.enable & BIT(I915_SAMPLE_BUSY)); } +static u64 count_interrupts(struct drm_i915_private *i915) +{ + /* open-coded kstat_irqs() */ + struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq); + u64 sum = 0; + int cpu; + + if (!desc || !desc->kstat_irqs) + return 0; + + for_each_possible_cpu(cpu) + sum += *per_cpu_ptr(desc->kstat_irqs, cpu); + + return sum; +} + +static void i915_pmu_event_read(struct perf_event *event) +{ + struct drm_i915_private *i915 = + container_of(event->pmu, typeof(*i915), pmu.base); + u64 val = 0; + + if (is_engine_event(event)) { + u8 sample = engine_event_sample(event); + struct intel_engine_cs *engine; + + engine = intel_engine_lookup_user(i915, + engine_event_class(event), + engine_event_instance(event)); + + if (WARN_ON_ONCE(!engine)) { + /* Do nothing */ + } else if (sample == I915_SAMPLE_BUSY && + engine->pmu.busy_stats) { + val = ktime_to_ns(intel_engine_get_busy_time(engine)); + } else { + val = engine->pmu.sample[sample]; + } + } else switch (event->attr.config) { + case I915_PMU_ACTUAL_FREQUENCY: + val = i915->pmu.sample[__I915_SAMPLE_FREQ_ACT]; + break; + case I915_PMU_REQUESTED_FREQUENCY: + val = i915->pmu.sample[__I915_SAMPLE_FREQ_REQ]; + break; + case I915_PMU_ENERGY: + val = intel_energy_uJ(i915); + break; + case I915_PMU_INTERRUPTS: + val = count_interrupts(i915); + break; + + case I915_PMU_RC6_RESIDENCY: + if (!i915->gt.awake) + return; + + val = intel_rc6_residency_ns(i915, +IS_VALLEYVIEW(i915) ? +VLV_GT_RENDER_RC6 : +GEN6_GT_GFX_RC6); + break; + + case I915_PMU_RC6p_RESIDENCY: + if (!i915->gt.awake) + return; + + if (!IS_VALLEYVIEW(i915)) + val = intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p); + break; + + case I915_PMU_RC6pp_RESIDENCY: + if (!i915->gt.awake) + return; + + if (!IS_VALLEYVIEW(i915)) + val = intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp); + break; + } + + local64_set(&event->count, val); +} + static void i915_pmu_enable(struct perf_event *event) { struct drm_i915_private *i915 = @@ -440,23 +522,6 @@ static void i915_pmu_disable(struct perf_event *event) i915_pmu_timer_cancel(event); } -static int i915_pmu_event_add(struct perf_event *event, int flags) -{ - struct hw_perf_event *hwc = &event->hw; - - if (flags & PERF_EF_START) - i915_pmu_enable(event); - - hwc->state = !(flags & PERF_EF_START); - - return 0; -} - -static void i915_pmu_event_del(struct perf_event *event, int flags) -{ - i915_pmu_disable(event); -} - static void i915_pmu_event_start(struct perf_event *event, int flags) { i915_pmu_enable(event); @@ -467,86 +532,21 @@ static void i915_pmu_event_stop(struct perf_event *event, int flags) i915_pmu_disable(event); } -static u64 count_interrupts(struct drm_i915_private *i915) +static int i915_pmu_event_add(struct perf_event *event, int flags) { - /* open-coded kstat_irqs() */ - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq); - u64 sum = 0; - int cpu; + struct hw_perf_event *hwc = &event->hw; - if (!desc || !desc->kstat_irqs) - return 0; + if (flags & PERF_EF_START) + i915_pmu_enable(event); - for_each_possible_cpu(cpu) - sum += *per_cpu_ptr(desc->kstat_irqs, cpu); + hwc->state = !(flags & PERF_EF_START); - return sum; + return 0; } -static void i915_pmu_event_read(struct
[Intel-gfx] [RFC v1 0/2] Support perf stat with i915 PMU
These patches depend on the RFC patches enabling i915 PMU from Tvrtko: https://patchwork.freedesktop.org/series/27488/ Thus, CI failure to build them is expected. I think that my patches should be squeashed in Tvrtko's one actually. The first patch simply reorders functions and does nothing now comparing to Tvrtko's patches. Next patches adds fixes according to PMU API comments and clarifications from PMU aware engineers. v1: make busy_stats refcounted instead of the whole pmu Dmitry Rogozhkin (2): drm/i915/pmu: reorder function to suite next patch drm/i915/pmu: serve global events and support perf stat drivers/gpu/drm/i915/i915_pmu.c | 215 +--- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 2 files changed, 112 insertions(+), 105 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v1 2/2] drm/i915/pmu: serve global events and support perf stat
This patch should probably be squashed with Tvrtko's PMU enabling patch... i915 events don't have a CPU context to work with, so i915 PMU should work in global mode, i.e. expose perf_invalid_context. This will make the following call to perf: perf stat -e i915/rcs0-busy/ workload.sh to error out with "failed to read counter". Correct usage would be: perf stat -e i915/rcs0-busy/ -a -C0 workload.sh And we will get expected output: Another change required to make perf-stat happy is properly support pmu->del(): comments in del() declaration says that del() is required to call stop(event, PERF_EF_UPDATE) and perf stat implicitly gets event count thru this. Finally, if perf stat will be ran as follows: perf stat -e i915/rcs0-busy/ -a workload.sh i.e. without '-C0' option, then event will be initilized as many times as there are CPUs. Thus, patch adds PMU refcounting support to avoid multiple init/close of internal things. The issue which I did not overcome is that in this case counters will be multiplied on number of CPUs. Not sure whether it is possible to have some event enabling CPU mask or rather I need to simply error out. v1: Make pmu.busy_stats a refcounter to avoid busy stats going away with some deleted event. Change-Id: I7d1abe747a4399196e72253f7b66441a6528dbee Signed-off-by: Dmitry Rogozhkin Cc: Tvrtko Ursulin Cc: Peter Zijlstra --- drivers/gpu/drm/i915/i915_pmu.c | 37 - drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index bcdf2bc..fc29c75 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -469,11 +469,16 @@ static void i915_pmu_enable(struct perf_event *event) ns_to_ktime(PERIOD), 0, HRTIMER_MODE_REL_PINNED); i915->pmu.timer_enabled = true; - } else if (is_engine_event(event) && engine_needs_busy_stats(engine) && - !engine->pmu.busy_stats) { - engine->pmu.busy_stats = true; - if (!cancel_delayed_work(&engine->pmu.disable_busy_stats)) - queue_work(i915->wq, &engine->pmu.enable_busy_stats); + } else if (is_engine_event(event) && engine_needs_busy_stats(engine)) { + /* Enable busy stats for the first event demanding it, next +* events just reference counter. So, if some events will go +* away, we will still have busy stats enabled till remaining +* events still use them. +*/ + if (engine->pmu.busy_stats++ == 0) { + if (!cancel_delayed_work(&engine->pmu.disable_busy_stats)) + queue_work(i915->wq, &engine->pmu.enable_busy_stats); + } } spin_unlock_irqrestore(&i915->pmu.lock, flags); @@ -495,16 +500,16 @@ static void i915_pmu_disable(struct perf_event *event) enum intel_engine_id id; engine = intel_engine_lookup_user(i915, - engine_event_class(event), - engine_event_instance(event)); + engine_event_class(event), + engine_event_instance(event)); GEM_BUG_ON(!engine); engine->pmu.enable &= ~BIT(engine_event_sample(event)); - if (engine->pmu.busy_stats && - !engine_needs_busy_stats(engine)) { - engine->pmu.busy_stats = false; - queue_delayed_work(i915->wq, - &engine->pmu.disable_busy_stats, - round_jiffies_up_relative(2 * HZ)); + if (!engine_needs_busy_stats(engine)) { + if (engine->pmu.busy_stats && --engine->pmu.busy_stats == 0) { + queue_delayed_work(i915->wq, + &engine->pmu.disable_busy_stats, + round_jiffies_up_relative(2 * HZ)); + } } mask = 0; for_each_engine(engine, i915, id) @@ -529,6 +534,8 @@ static void i915_pmu_event_start(struct perf_event *event, int flags) static void i915_pmu_event_stop(struct perf_event *event, int flags) { + if (flags & PERF_EF_UPDATE) + i915_pmu_event_read(event); i915_pmu_disable(event); } @@ -546,7 +553,7 @@ static int i915_pmu_event_add(struct perf_event *event, int flags) static void i915_pmu_event_del(struct perf_event *event, int flags) { - i915_pmu_disable(event); + i915_pmu_event_stop(event, PERF_EF_UPDATE); }
Re: [Intel-gfx] [PATCH v2 1/8] drm/dp: Add defines for DP SDP types
On Fri, May 19, 2017 at 04:17:18PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add defines for the secondary data packet (SDP) types from the spec. > These are the DP specific ones, and in addition HDMI infoframe types > (see enum hdmi_infoframe_type) are also valid SDP types. > > v2: Add more SDP types > > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Ville Syrjälä > --- > include/drm/drm_dp_helper.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index f7007e544f29..8db4513b9195 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -869,6 +869,17 @@ void drm_dp_link_train_channel_eq_delay(const u8 > dpcd[DP_RECEIVER_CAP_SIZE]); > u8 drm_dp_link_rate_to_bw_code(int link_rate); > int drm_dp_bw_code_to_link_rate(u8 link_bw); > > +#define DP_SDP_AUDIO_TIMESTAMP 0x01 > +#define DP_SDP_AUDIO_STREAM 0x02 > +#define DP_SDP_EXTENSION 0x04 > +#define DP_SDP_AUDIO_COPYMANAGEMENT 0x05 > +#define DP_SDP_ISRC 0x06 > +#define DP_SDP_VSC 0x07 > +#define DP_SDP_CAMERA_GENERIC(i) (0x08 + (i)) /* 0-7 */ > +#define DP_SDP_PPS 0x10 for a moment I couldn't find this and others below, so I checked DP 1.4 instead of the DP 1.3 and could verify that. maybe deserves a comment /* DP 1.4 */ ? Anyways: Reviewed-by: Rodrigo Vivi > +#define DP_SDP_VSC_EXT_VESA 0x20 > +#define DP_SDP_VSC_EXT_CEA 0x21 > + > struct edp_sdp_header { > u8 HB0; /* Secondary Data Packet ID */ > u8 HB1; /* Secondary Data Packet Type */ > -- > 2.10.2 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 01:44:14PM -0700, Rodrigo Vivi wrote: > On Thu, Aug 17, 2017 at 1:11 PM, Pandiyan, Dhinakaran > wrote: > > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote: > >> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: > >> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare > >> ><[1]manasi.d.nav...@intel.com> wrote: > >> > > >> > In case of eDP because the panel has a fixed mode we cannot > >> > link train fallback and prune modes since this results in > >> > no modes available for eDP connector. > >> > > >> >What about downclock modes?! > >> > >> What are the downclock modes? We have seen an issue with pruning modes > >> in case of eDP panel where we end up pruning the mode due to link train > >> fallback and then we get an error saying "No modes available for the > >> connector" > >> > > > > fwiw I've got two laptops with eDP's having more than ten modes. > > those ten are probably a list of modes with scaler right?! > > Anyways, there are eDP panels that supports multiple modes like same > resolution but different clocks. > Like the ones with 60Hz and 48Hz where we cannot get PSR on 60 and can > get on 48 one. > > This made Jim to do this patch: > https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.br...@linux.intel.com > > that now is merged already and allow we select different modes on eDP > per request. > > this case proves that there are eDP panels out there where this bug > wouldn't occur. > > So I think we need to find a different way to handle this case where > there is no other mode > or fix the link status somehow > Thanks Rodrigo for this explanation. Yes those modes advertised to the userspace would be the modes with scalar. But the HW would still only support the fixed mode ot the alternate DRRS mode. Infact in case of link training fallback, when the userspace triggers a new modeset, it will call mode_valid() hook where if the requested mode's hdisplay or vdisplay are greater than the fixed mode's hdisplay or vdisplay then it returns error MODE_PANEL instead of MODE_OK. Also Jim brought up a point that for some eDP panels only 2 lanes could be wired in which case we do want link train fallback in order to retry modeset with fewer lanes. So we need fallback I suppose but handle this no mode situation differently. Daniel, Jani any thoughts on how this could be handled? Regards Manasi > > > >> > > >> > Also since its a panel, link training should not fail dynamically > >> > based on cable conditions like in case of DP. > >> > > >> >Is there any bug associated with this patch? > >> > >> Yes this is the bug: > >> https://bugs.freedesktop.org/show_bug.cgi?id=101518 > > Please add this for reference in a future patch or version: > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518 > > >> But the reason I didnt have this in the Fixes tab is because > >> this patch will not fix the bug, it will just isolate to it being > >> a bug with AUX Timeouts warning. > >> > >> Regards > >> Manasi > >> > >> > > >> > Cc: Jani Nikula <[2]jani.nik...@linux.intel.com> > >> > Cc: Jim Bride <[3]jim.br...@linux.intel.com> > >> > Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com> > >> > Cc: Daniel Vetter <[5]daniel.vet...@intel.com> > >> > Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com> > >> > --- > >> > drivers/gpu/drm/i915/intel_dp.c | 2 +- > >> > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > >> > drivers/gpu/drm/i915/intel_drv.h | 1 + > >> > 3 files changed, 4 insertions(+), 2 deletions(-) > >> > diff --git a/drivers/gpu/drm/i915/intel_dp.c > >> > b/drivers/gpu/drm/i915/intel_dp.c > >> > index 4fd4853..edac0c8 100644 > >> > --- a/drivers/gpu/drm/i915/intel_dp.c > >> > +++ b/drivers/gpu/drm/i915/intel_dp.c > >> > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, > >> > 27, 54 }; > >> >* If a CPU or PCH DP output is attached to an eDP panel, this > >> > function > >> >* will return true, and false otherwise. > >> >*/ > >> > -static bool is_edp(struct intel_dp *intel_dp) > >> > +bool is_edp(struct intel_dp *intel_dp) > >> > { > >> > struct intel_digital_port *intel_dig_port = > >> > dp_to_dig_port(intel_dp); > >> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > >> > b/drivers/gpu/drm/i915/intel_dp_link_training.c > >> > index 05907fa..18ec61f 100644 > >> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > >> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > >> > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp > >> > *intel_dp) > >> >intel_connector->[7]base.base.id, > >> >intel_connector->[8]base.name, > >> >
Re: [Intel-gfx] [PATCH] drm/i915: Split pin mapping into per platform functions
>-Original Message- >From: Zanoni, Paulo R >Sent: Thursday, August 17, 2017 1:24 PM >To: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org >Cc: Ville Syrjala ; Vivi, Rodrigo >; Taylor, Clinton A >Subject: Re: [PATCH] drm/i915: Split pin mapping into per platform functions > >Em Qua, 2017-08-16 às 16:45 -0700, Anusha Srivatsa escreveu: >> Cleanup the code. Map the pins in accordance to individual platforms >> rather than according to ports. >> Create separate functions for platforms. >> >> v2: >> - Add missing condition for CoffeeLake. Make platform >> specific functions static. Add function >> i915_ddc_pin_mapping(). >> >> v3: >> - Rename functions to x_port_to_ddc_pin() which directly >> indicates the purpose. Correct default return values on CNP >> and BXT. Rename i915_port_to_ to g4x_port_to since that was >> the first platform to run this. Correct code style. (Paulo) >> > >Reviewed-by: Paulo Zanoni > Thanks for the review Paulo! Anusha >> Sugested-by Ville Syrjala >> Cc: Ville Syrjala >> Cc: Paulo Zanoni >> Cc: Rodrigo Vivi >> Cc: Clinton Tayloe >> Signed-off-by: Anusha Srivatsa >> --- >> drivers/gpu/drm/i915/intel_hdmi.c | 113 >> ++ >> 1 file changed, 91 insertions(+), 22 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c >> b/drivers/gpu/drm/i915/intel_hdmi.c >> index e30c27a..e8abea7 100644 >> --- a/drivers/gpu/drm/i915/intel_hdmi.c >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c >> @@ -1843,45 +1843,114 @@ void >> intel_hdmi_handle_sink_scrambling(struct intel_encoder *encoder, >> DRM_DEBUG_KMS("sink scrambling handled\n"); >> } >> >> -static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv, >> - enum port port) >> +static u8 chv_port_to_ddc_pin(struct drm_i915_private *dev_priv, >> enum port port) >> { >> -const struct ddi_vbt_port_info *info = >> -&dev_priv->vbt.ddi_port_info[port]; >> u8 ddc_pin; >> >> -if (info->alternate_ddc_pin) { >> -DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c >> (VBT)\n", >> - info->alternate_ddc_pin, >> port_name(port)); >> -return info->alternate_ddc_pin; >> +switch (port) { >> +case PORT_B: >> +ddc_pin = GMBUS_PIN_DPB; >> +break; >> +case PORT_C: >> +ddc_pin = GMBUS_PIN_DPC; >> +break; >> +case PORT_D: >> +ddc_pin = GMBUS_PIN_DPD_CHV; >> +break; >> +default: >> +MISSING_CASE(port); >> +ddc_pin = GMBUS_PIN_DPB; >> +break; >> } >> +return ddc_pin; >> +} >> + >> +static u8 bxt_port_to_ddc_pin(struct drm_i915_private *dev_priv, >> enum port port) >> +{ >> +u8 ddc_pin; >> >> switch (port) { >> case PORT_B: >> -if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) >> -ddc_pin = GMBUS_PIN_1_BXT; >> -else >> -ddc_pin = GMBUS_PIN_DPB; >> +ddc_pin = GMBUS_PIN_1_BXT; >> break; >> case PORT_C: >> -if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) >> -ddc_pin = GMBUS_PIN_2_BXT; >> -else >> -ddc_pin = GMBUS_PIN_DPC; >> +ddc_pin = GMBUS_PIN_2_BXT; >> +break; >> +default: >> +MISSING_CASE(port); >> +ddc_pin = GMBUS_PIN_1_BXT; >> +break; >> +} >> +return ddc_pin; >> +} >> + >> +static u8 cnp_port_to_ddc_pin(struct drm_i915_private *dev_priv, >> + enum port port) >> +{ >> +u8 ddc_pin; >> + >> +switch (port) { >> +case PORT_B: >> +ddc_pin = GMBUS_PIN_1_BXT; >> +break; >> +case PORT_C: >> +ddc_pin = GMBUS_PIN_2_BXT; >> break; >> case PORT_D: >> -if (HAS_PCH_CNP(dev_priv)) >> -ddc_pin = GMBUS_PIN_4_CNP; >> -else if (IS_CHERRYVIEW(dev_priv)) >> -ddc_pin = GMBUS_PIN_DPD_CHV; >> -else >> -ddc_pin = GMBUS_PIN_DPD; >> +ddc_pin = GMBUS_PIN_4_CNP; >> +break; >> +default: >> +MISSING_CASE(port); >> +ddc_pin = GMBUS_PIN_1_BXT; >> +break; >> +} >> +return ddc_pin; >> +} >> + >> +static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv, >> + enum port port) >> +{ >> +u8 ddc_pin; >> + >> +switch (port) { >> +case PORT_B: >> +ddc_pin = GMBUS_PIN_DPB; >> +break; >> +case PORT_C: >> +ddc_pin = GMBUS_PIN_DPC; >> +break; >> +case PORT_D: >> +ddc_pin = GMBUS_PIN_DPD; >> break; >> default: >> MISSING_CASE(port); >> ddc_pin = GMBUS_PIN_DPB; >> break; >> } >> +return ddc_pin; >> +} >> + >> +static u8 intel_hdmi_
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 02:01:05PM -0700, Manasi Navare wrote: > On Thu, Aug 17, 2017 at 01:11:00PM -0700, Pandiyan, Dhinakaran wrote: > > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote: > > > On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: > > > >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare > > > ><[1]manasi.d.nav...@intel.com> wrote: > > > > > > > > In case of eDP because the panel has a fixed mode we cannot > > > > link train fallback and prune modes since this results in > > > > no modes available for eDP connector. > > > > > > > >What about downclock modes?! > > > > > > What are the downclock modes? We have seen an issue with pruning modes > > > in case of eDP panel where we end up pruning the mode due to link train > > > fallback and then we get an error saying "No modes available for the > > > connector" > > > > > > > fwiw I've got two laptops with eDP's having more than ten modes. > > Hmm, I have always dealt with laptops with eDPs with a fixed mode and so are the systems in CI which are giving this "no mode left on the connector error". Manasi > > Yes but link training is not supposed to fail for eDP since its a > fixed connection and so after discussing with Daniel and Jani, this is > the consensus that we shouldnt be falling back and retraining in case > of eDP since most eDP panels are going to have 1 or 2 modes. > > Manasi > > > > > > > > > Also since its a panel, link training should not fail dynamically > > > > based on cable conditions like in case of DP. > > > > > > > >Is there any bug associated with this patch? > > > > > > Yes this is the bug: > > > https://bugs.freedesktop.org/show_bug.cgi?id=101518 > > > But the reason I didnt have this in the Fixes tab is because > > > this patch will not fix the bug, it will just isolate to it being > > > a bug with AUX Timeouts warning. > > > > > > Regards > > > Manasi > > > > > > > > > > > Cc: Jani Nikula <[2]jani.nik...@linux.intel.com> > > > > Cc: Jim Bride <[3]jim.br...@linux.intel.com> > > > > Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com> > > > > Cc: Daniel Vetter <[5]daniel.vet...@intel.com> > > > > Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com> > > > > --- > > > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > > > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > > > 3 files changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > index 4fd4853..edac0c8 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, > > > > 27, 54 }; > > > >* If a CPU or PCH DP output is attached to an eDP panel, this > > > > function > > > >* will return true, and false otherwise. > > > >*/ > > > > -static bool is_edp(struct intel_dp *intel_dp) > > > > +bool is_edp(struct intel_dp *intel_dp) > > > > { > > > > struct intel_digital_port *intel_dig_port = > > > > dp_to_dig_port(intel_dp); > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > index 05907fa..18ec61f 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp > > > > *intel_dp) > > > >intel_connector->[7]base.base.id, > > > >intel_connector->[8]base.name, > > > >intel_dp->link_rate, intel_dp->lane_count); > > > > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > > > > + /* Dont fallback and prune modes if its eDP */ > > > > + if (!is_edp(intel_dp) && > > > > !intel_dp_get_link_train_fallback_values(intel_dp, > > > > > > > > intel_dp->link_rate, > > > > > > > > intel_dp->lane_count)) > > > > /* Schedule a Hotplug Uevent to userspace to start > > > > modeset */ > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > > > b/drivers/gpu/drm/i915/intel_drv.h > > > > index fa47285..9800a15 100644 > > > > --- a/drivers/gpu/drm/i915/intel_drv.h > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > > > @@ -1548,6 +1548,7 @@ static inline unsigned int > > > > intel_dp_unused_lane_mask(int lane_count) > > > > } > > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > > > > +bool is_edp(struct intel_dp *intel_dp); > > > > int intel_dp_link_required(int pixel_clock, int bpp); > > > > int intel_dp_max_data_ra
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 01:11:00PM -0700, Pandiyan, Dhinakaran wrote: > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote: > > On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: > > >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare > > ><[1]manasi.d.nav...@intel.com> wrote: > > > > > > In case of eDP because the panel has a fixed mode we cannot > > > link train fallback and prune modes since this results in > > > no modes available for eDP connector. > > > > > >What about downclock modes?! > > > > What are the downclock modes? We have seen an issue with pruning modes > > in case of eDP panel where we end up pruning the mode due to link train > > fallback and then we get an error saying "No modes available for the > > connector" > > > > fwiw I've got two laptops with eDP's having more than ten modes. > Yes but link training is not supposed to fail for eDP since its a fixed connection and so after discussing with Daniel and Jani, this is the consensus that we shouldnt be falling back and retraining in case of eDP since most eDP panels are going to have 1 or 2 modes. Manasi > > > > > > Also since its a panel, link training should not fail dynamically > > > based on cable conditions like in case of DP. > > > > > >Is there any bug associated with this patch? > > > > Yes this is the bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=101518 > > But the reason I didnt have this in the Fixes tab is because > > this patch will not fix the bug, it will just isolate to it being > > a bug with AUX Timeouts warning. > > > > Regards > > Manasi > > > > > > > > Cc: Jani Nikula <[2]jani.nik...@linux.intel.com> > > > Cc: Jim Bride <[3]jim.br...@linux.intel.com> > > > Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com> > > > Cc: Daniel Vetter <[5]daniel.vet...@intel.com> > > > Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com> > > > --- > > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > > 3 files changed, 4 insertions(+), 2 deletions(-) > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > b/drivers/gpu/drm/i915/intel_dp.c > > > index 4fd4853..edac0c8 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, > > > 27, 54 }; > > >* If a CPU or PCH DP output is attached to an eDP panel, this > > > function > > >* will return true, and false otherwise. > > >*/ > > > -static bool is_edp(struct intel_dp *intel_dp) > > > +bool is_edp(struct intel_dp *intel_dp) > > > { > > > struct intel_digital_port *intel_dig_port = > > > dp_to_dig_port(intel_dp); > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > index 05907fa..18ec61f 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp > > > *intel_dp) > > >intel_connector->[7]base.base.id, > > >intel_connector->[8]base.name, > > >intel_dp->link_rate, intel_dp->lane_count); > > > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > > > + /* Dont fallback and prune modes if its eDP */ > > > + if (!is_edp(intel_dp) && > > > !intel_dp_get_link_train_fallback_values(intel_dp, > > > > > > intel_dp->link_rate, > > > > > > intel_dp->lane_count)) > > > /* Schedule a Hotplug Uevent to userspace to start > > > modeset */ > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > > b/drivers/gpu/drm/i915/intel_drv.h > > > index fa47285..9800a15 100644 > > > --- a/drivers/gpu/drm/i915/intel_drv.h > > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > > @@ -1548,6 +1548,7 @@ static inline unsigned int > > > intel_dp_unused_lane_mask(int lane_count) > > > } > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > > > +bool is_edp(struct intel_dp *intel_dp); > > > int intel_dp_link_required(int pixel_clock, int bpp); > > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > > > bool intel_digital_port_connected(struct drm_i915_private > > > *dev_priv, > > > -- > > > 2.1.4 > > > ___ > > > Intel-gfx mailing list > > > [9]Intel-gfx@lists.freedesktop.org > > > [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > References > > > > > >1. mailto:manasi.d.n
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 1:11 PM, Pandiyan, Dhinakaran wrote: > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote: >> On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: >> >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare >> ><[1]manasi.d.nav...@intel.com> wrote: >> > >> > In case of eDP because the panel has a fixed mode we cannot >> > link train fallback and prune modes since this results in >> > no modes available for eDP connector. >> > >> >What about downclock modes?! >> >> What are the downclock modes? We have seen an issue with pruning modes >> in case of eDP panel where we end up pruning the mode due to link train >> fallback and then we get an error saying "No modes available for the >> connector" >> > > fwiw I've got two laptops with eDP's having more than ten modes. those ten are probably a list of modes with scaler right?! Anyways, there are eDP panels that supports multiple modes like same resolution but different clocks. Like the ones with 60Hz and 48Hz where we cannot get PSR on 60 and can get on 48 one. This made Jim to do this patch: https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.br...@linux.intel.com that now is merged already and allow we select different modes on eDP per request. this case proves that there are eDP panels out there where this bug wouldn't occur. So I think we need to find a different way to handle this case where there is no other mode or fix the link status somehow > >> > >> > Also since its a panel, link training should not fail dynamically >> > based on cable conditions like in case of DP. >> > >> >Is there any bug associated with this patch? >> >> Yes this is the bug: >> https://bugs.freedesktop.org/show_bug.cgi?id=101518 Please add this for reference in a future patch or version: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518 >> But the reason I didnt have this in the Fixes tab is because >> this patch will not fix the bug, it will just isolate to it being >> a bug with AUX Timeouts warning. >> >> Regards >> Manasi >> >> > >> > Cc: Jani Nikula <[2]jani.nik...@linux.intel.com> >> > Cc: Jim Bride <[3]jim.br...@linux.intel.com> >> > Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com> >> > Cc: Daniel Vetter <[5]daniel.vet...@intel.com> >> > Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com> >> > --- >> > drivers/gpu/drm/i915/intel_dp.c | 2 +- >> > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- >> > drivers/gpu/drm/i915/intel_drv.h | 1 + >> > 3 files changed, 4 insertions(+), 2 deletions(-) >> > diff --git a/drivers/gpu/drm/i915/intel_dp.c >> > b/drivers/gpu/drm/i915/intel_dp.c >> > index 4fd4853..edac0c8 100644 >> > --- a/drivers/gpu/drm/i915/intel_dp.c >> > +++ b/drivers/gpu/drm/i915/intel_dp.c >> > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, >> > 27, 54 }; >> >* If a CPU or PCH DP output is attached to an eDP panel, this >> > function >> >* will return true, and false otherwise. >> >*/ >> > -static bool is_edp(struct intel_dp *intel_dp) >> > +bool is_edp(struct intel_dp *intel_dp) >> > { >> > struct intel_digital_port *intel_dig_port = >> > dp_to_dig_port(intel_dp); >> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c >> > b/drivers/gpu/drm/i915/intel_dp_link_training.c >> > index 05907fa..18ec61f 100644 >> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c >> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c >> > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp >> > *intel_dp) >> >intel_connector->[7]base.base.id, >> >intel_connector->[8]base.name, >> >intel_dp->link_rate, intel_dp->lane_count); >> > - if (!intel_dp_get_link_train_fallback_values(intel_dp, >> > + /* Dont fallback and prune modes if its eDP */ >> > + if (!is_edp(intel_dp) && >> > !intel_dp_get_link_train_fallback_values(intel_dp, >> > >> > intel_dp->link_rate, >> > >> > intel_dp->lane_count)) >> > /* Schedule a Hotplug Uevent to userspace to start >> > modeset */ >> > diff --git a/drivers/gpu/drm/i915/intel_drv.h >> > b/drivers/gpu/drm/i915/intel_drv.h >> > index fa47285..9800a15 100644 >> > --- a/drivers/gpu/drm/i915/intel_drv.h >> > +++ b/drivers/gpu/drm/i915/intel_drv.h >> > @@ -1548,6 +1548,7 @@ static inline unsigned int >> > intel_dp_unused_lane_mask(int lane_count) >> > } >> > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); >> > +bool is_edp(struct intel_dp *intel_dp); >> > int intel_dp_link_required(int pixel_clock, int bpp); >> > int intel_dp_max_data_rate(int max_
Re: [Intel-gfx] [PATCH] drm/i915: Split pin mapping into per platform functions
Em Qua, 2017-08-16 às 16:45 -0700, Anusha Srivatsa escreveu: > Cleanup the code. Map the pins in accordance to > individual platforms rather than according to ports. > Create separate functions for platforms. > > v2: > - Add missing condition for CoffeeLake. Make platform > specific functions static. Add function > i915_ddc_pin_mapping(). > > v3: > - Rename functions to x_port_to_ddc_pin() which directly > indicates the purpose. Correct default return values on CNP > and BXT. Rename i915_port_to_ to g4x_port_to since that was > the first platform to run this. Correct code style. (Paulo) > Reviewed-by: Paulo Zanoni > Sugested-by Ville Syrjala > Cc: Ville Syrjala > Cc: Paulo Zanoni > Cc: Rodrigo Vivi > Cc: Clinton Tayloe > Signed-off-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/intel_hdmi.c | 113 > ++ > 1 file changed, 91 insertions(+), 22 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index e30c27a..e8abea7 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1843,45 +1843,114 @@ void > intel_hdmi_handle_sink_scrambling(struct intel_encoder *encoder, > DRM_DEBUG_KMS("sink scrambling handled\n"); > } > > -static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv, > - enum port port) > +static u8 chv_port_to_ddc_pin(struct drm_i915_private *dev_priv, > enum port port) > { > - const struct ddi_vbt_port_info *info = > - &dev_priv->vbt.ddi_port_info[port]; > u8 ddc_pin; > > - if (info->alternate_ddc_pin) { > - DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c > (VBT)\n", > - info->alternate_ddc_pin, > port_name(port)); > - return info->alternate_ddc_pin; > + switch (port) { > + case PORT_B: > + ddc_pin = GMBUS_PIN_DPB; > + break; > + case PORT_C: > + ddc_pin = GMBUS_PIN_DPC; > + break; > + case PORT_D: > + ddc_pin = GMBUS_PIN_DPD_CHV; > + break; > + default: > + MISSING_CASE(port); > + ddc_pin = GMBUS_PIN_DPB; > + break; > } > + return ddc_pin; > +} > + > +static u8 bxt_port_to_ddc_pin(struct drm_i915_private *dev_priv, > enum port port) > +{ > + u8 ddc_pin; > > switch (port) { > case PORT_B: > - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) > - ddc_pin = GMBUS_PIN_1_BXT; > - else > - ddc_pin = GMBUS_PIN_DPB; > + ddc_pin = GMBUS_PIN_1_BXT; > break; > case PORT_C: > - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) > - ddc_pin = GMBUS_PIN_2_BXT; > - else > - ddc_pin = GMBUS_PIN_DPC; > + ddc_pin = GMBUS_PIN_2_BXT; > + break; > + default: > + MISSING_CASE(port); > + ddc_pin = GMBUS_PIN_1_BXT; > + break; > + } > + return ddc_pin; > +} > + > +static u8 cnp_port_to_ddc_pin(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + u8 ddc_pin; > + > + switch (port) { > + case PORT_B: > + ddc_pin = GMBUS_PIN_1_BXT; > + break; > + case PORT_C: > + ddc_pin = GMBUS_PIN_2_BXT; > break; > case PORT_D: > - if (HAS_PCH_CNP(dev_priv)) > - ddc_pin = GMBUS_PIN_4_CNP; > - else if (IS_CHERRYVIEW(dev_priv)) > - ddc_pin = GMBUS_PIN_DPD_CHV; > - else > - ddc_pin = GMBUS_PIN_DPD; > + ddc_pin = GMBUS_PIN_4_CNP; > + break; > + default: > + MISSING_CASE(port); > + ddc_pin = GMBUS_PIN_1_BXT; > + break; > + } > + return ddc_pin; > +} > + > +static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + u8 ddc_pin; > + > + switch (port) { > + case PORT_B: > + ddc_pin = GMBUS_PIN_DPB; > + break; > + case PORT_C: > + ddc_pin = GMBUS_PIN_DPC; > + break; > + case PORT_D: > + ddc_pin = GMBUS_PIN_DPD; > break; > default: > MISSING_CASE(port); > ddc_pin = GMBUS_PIN_DPB; > break; > } > + return ddc_pin; > +} > + > +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + const struct ddi_vbt_port_info *info = > + &dev_priv->vbt.ddi_port_info[port]; > + u8 ddc_pin; > + > + if (info->alternate_ddc_pin) { > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c > (VBT)\n", > + info->alternate_ddc_pin,
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote: > On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: > >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare > ><[1]manasi.d.nav...@intel.com> wrote: > > > > In case of eDP because the panel has a fixed mode we cannot > > link train fallback and prune modes since this results in > > no modes available for eDP connector. > > > >What about downclock modes?! > > What are the downclock modes? We have seen an issue with pruning modes > in case of eDP panel where we end up pruning the mode due to link train > fallback and then we get an error saying "No modes available for the > connector" > fwiw I've got two laptops with eDP's having more than ten modes. > > > > Also since its a panel, link training should not fail dynamically > > based on cable conditions like in case of DP. > > > >Is there any bug associated with this patch? > > Yes this is the bug: > https://bugs.freedesktop.org/show_bug.cgi?id=101518 > But the reason I didnt have this in the Fixes tab is because > this patch will not fix the bug, it will just isolate to it being > a bug with AUX Timeouts warning. > > Regards > Manasi > > > > > Cc: Jani Nikula <[2]jani.nik...@linux.intel.com> > > Cc: Jim Bride <[3]jim.br...@linux.intel.com> > > Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com> > > Cc: Daniel Vetter <[5]daniel.vet...@intel.com> > > Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com> > > --- > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > 3 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index 4fd4853..edac0c8 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, > > 27, 54 }; > >* If a CPU or PCH DP output is attached to an eDP panel, this > > function > >* will return true, and false otherwise. > >*/ > > -static bool is_edp(struct intel_dp *intel_dp) > > +bool is_edp(struct intel_dp *intel_dp) > > { > > struct intel_digital_port *intel_dig_port = > > dp_to_dig_port(intel_dp); > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > index 05907fa..18ec61f 100644 > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp > > *intel_dp) > >intel_connector->[7]base.base.id, > >intel_connector->[8]base.name, > >intel_dp->link_rate, intel_dp->lane_count); > > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > > + /* Dont fallback and prune modes if its eDP */ > > + if (!is_edp(intel_dp) && > > !intel_dp_get_link_train_fallback_values(intel_dp, > > > > intel_dp->link_rate, > > > > intel_dp->lane_count)) > > /* Schedule a Hotplug Uevent to userspace to start > > modeset */ > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > b/drivers/gpu/drm/i915/intel_drv.h > > index fa47285..9800a15 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -1548,6 +1548,7 @@ static inline unsigned int > > intel_dp_unused_lane_mask(int lane_count) > > } > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > > +bool is_edp(struct intel_dp *intel_dp); > > int intel_dp_link_required(int pixel_clock, int bpp); > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > > bool intel_digital_port_connected(struct drm_i915_private > > *dev_priv, > > -- > > 2.1.4 > > ___ > > Intel-gfx mailing list > > [9]Intel-gfx@lists.freedesktop.org > > [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > References > > > >1. mailto:manasi.d.nav...@intel.com > >2. mailto:jani.nik...@linux.intel.com > >3. mailto:jim.br...@linux.intel.com > >4. mailto:ville.syrj...@linux.intel.com > >5. mailto:daniel.vet...@intel.com > >6. mailto:manasi.d.nav...@intel.com > >7. http://base.base.id/ > >8. http://base.name/ > >9. mailto:Intel-gfx@lists.freedesktop.org > > 10. https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman
Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote: > On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote: > > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote: > > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote: > > > > This set of changes has some history to them. There were several > > > > attempts > > > > to add what was called "fast link training" to i915, which actually > > > > wasn't > > > > fast link training as per the DP spec. These changes were: > > > > > > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization") > > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization") > > > > > > > > which were eventually hand-reverted by: > > > > > > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training > > > > feature") > > > > > > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had > > > > some > > > > very bad side-effects on PSR functionality on Skylake. The issue at > > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3 > > > > (depending on the original link configuration) in order to quickly get > > > > the source and sink back in synchronization across the link before > > > > handing > > > > control back to the i915. There's an assumption that none of the link > > > > configuration information has changed (and thus it's still valid) since > > > > the > > > > last full link training operation. The revert above was identified via > > > > a > > > > bisect as the cause of some of Skylake's PSR woes. This patch, largely > > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training > > > > optimization") > > > > puts the eDP portions of this patch back in place. None of the > > > > flickering > > > > issues that spurred the revert have been seen, and I suspect the real > > > > culprits here were addressed by some of the recent link training changes > > > > that Manasi has implemented, and PSR on Skylake is definitely more happy > > > > with these changes in-place. > > > > > > > > v2 and v3: Rebase > > > > v4: * Clean up accesses to train_set_valid a bit for easier > > > > reading. (Chris) > > > > * Rebase > > > > v5: * Checkpatch cleanup > > > > * Rebase > > > > > > > > Cc: Chris Wilson > > > > Cc: Rodrigo Vivi > > > > Cc: Paulo Zanoni > > > > Cc: Manasi D Navare > > > > Cc: Mika Kahola > > > > Cc: Jani Nikula > > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training > > > > feature") > > > > Signed-off-by: Jim Bride > > > > --- > > > > drivers/gpu/drm/i915/intel_dp.c | 4 +++- > > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++- > > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > > > > 3 files changed, 19 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > index 76c8a0b..4bd409c 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, > > > > 27, 54 }; > > > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > > > * will return true, and false otherwise. > > > > */ > > > > -static bool is_edp(struct intel_dp *intel_dp) > > > > +bool is_edp(struct intel_dp *intel_dp) > > > > { > > > > struct intel_digital_port *intel_dig_port = > > > > dp_to_dig_port(intel_dp); > > > > > > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector > > > > *intel_connector) > > > > intel_dp->max_link_rate = > > > > intel_dp_max_common_rate(intel_dp); > > > > > > > > intel_dp->reset_link_params = false; > > > > + intel_dp->train_set_valid = false; > > > > } > > > > > > > > intel_dp_print_rates(intel_dp); > > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port > > > > *intel_dig_port, > > > > intel_dp_set_source_rates(intel_dp); > > > > > > > > intel_dp->reset_link_params = true; > > > > + intel_dp->train_set_valid = false; > > > > intel_dp->pps_pipe = INVALID_PIPE; > > > > intel_dp->active_pipe = INVALID_PIPE; > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > index 05907fa..67032cf 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > @@ -94,7 +94,8 @@ static bool > > > > intel_dp_reset_link_train(struct intel_dp *intel_dp, > > > > uint8_t dp_train_pat) > > > > { > > > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set)); > > > > + if (!intel_dp->train_set_valid) > > > > + memset(intel_dp->train_set, 0, > > > > sizeof(intel_dp->train_set
Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder
> > > Signed-off-by: Lyude > > > > No full name? Or is it your full name? > Looks like I forgot to change my desktop's S-B identity to full name, > but it shouldn't be a big deal. I've got tons of other patches already > upstream like this. I'd much prefer a full name. But more importantly, what I definately need is some review/ack/whatever because I don't know enough about this stuff (other than knowing it is a fragile area). Maybe you could resend with full name and the acpi list on CC? Regards, Wolfram signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote: > On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote: > > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote: > > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote: > > > > This set of changes has some history to them. There were several > > > > attempts > > > > to add what was called "fast link training" to i915, which actually > > > > wasn't > > > > fast link training as per the DP spec. These changes were: > > > > > > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization") > > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization") > > > > > > > > which were eventually hand-reverted by: > > > > > > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training > > > > feature") > > > > > > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had > > > > some > > > > very bad side-effects on PSR functionality on Skylake. The issue at > > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3 > > > > (depending on the original link configuration) in order to quickly get > > > > the source and sink back in synchronization across the link before > > > > handing > > > > control back to the i915. There's an assumption that none of the link > > > > configuration information has changed (and thus it's still valid) since > > > > the > > > > last full link training operation. The revert above was identified via > > > > a > > > > bisect as the cause of some of Skylake's PSR woes. This patch, largely > > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training > > > > optimization") > > > > puts the eDP portions of this patch back in place. None of the > > > > flickering > > > > issues that spurred the revert have been seen, and I suspect the real > > > > culprits here were addressed by some of the recent link training changes > > > > that Manasi has implemented, and PSR on Skylake is definitely more happy > > > > with these changes in-place. > > > > > > > > v2 and v3: Rebase > > > > v4: * Clean up accesses to train_set_valid a bit for easier > > > > reading. (Chris) > > > > * Rebase > > > > v5: * Checkpatch cleanup > > > > * Rebase > > > > > > > > Cc: Chris Wilson > > > > Cc: Rodrigo Vivi > > > > Cc: Paulo Zanoni > > > > Cc: Manasi D Navare > > > > Cc: Mika Kahola > > > > Cc: Jani Nikula > > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training > > > > feature") > > > > Signed-off-by: Jim Bride > > > > --- > > > > drivers/gpu/drm/i915/intel_dp.c | 4 +++- > > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++- > > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > > > > 3 files changed, 19 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > index 76c8a0b..4bd409c 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, > > > > 27, 54 }; > > > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > > > * will return true, and false otherwise. > > > > */ > > > > -static bool is_edp(struct intel_dp *intel_dp) > > > > +bool is_edp(struct intel_dp *intel_dp) I also need this function to be exposed to files outside of intel_dp.c for the patch: https://patchwork.freedesktop.org/series/28900/ But one of the review comments I got is to prefix the name of this function with intel_dp when exposing it to outside of intel_dp.c which makes sense as per the naming conventions of the other functions. But we already have a function intel_dp_is_edp() used to get VBT information. Any suggestions for the name? And do you want to make this change as part of your series so I can rebase my patch on top of this? Regards Manasi > > > > { > > > > struct intel_digital_port *intel_dig_port = > > > > dp_to_dig_port(intel_dp); > > > > > > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector > > > > *intel_connector) > > > > intel_dp->max_link_rate = > > > > intel_dp_max_common_rate(intel_dp); > > > > > > > > intel_dp->reset_link_params = false; > > > > + intel_dp->train_set_valid = false; > > > > } > > > > > > > > intel_dp_print_rates(intel_dp); > > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port > > > > *intel_dig_port, > > > > intel_dp_set_source_rates(intel_dp); > > > > > > > > intel_dp->reset_link_params = true; > > > > + intel_dp->train_set_valid = false; > > > > intel_dp->pps_pipe = INVALID_PIPE; > > > > intel_dp->active_pipe = INVALID_PIPE; > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > b/drivers/gpu/drm/
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 07:01:05AM +, Rodrigo Vivi wrote: >On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare ><[1]manasi.d.nav...@intel.com> wrote: > > In case of eDP because the panel has a fixed mode we cannot > link train fallback and prune modes since this results in > no modes available for eDP connector. > >What about downclock modes?! What are the downclock modes? We have seen an issue with pruning modes in case of eDP panel where we end up pruning the mode due to link train fallback and then we get an error saying "No modes available for the connector" > > Also since its a panel, link training should not fail dynamically > based on cable conditions like in case of DP. > >Is there any bug associated with this patch? Yes this is the bug: https://bugs.freedesktop.org/show_bug.cgi?id=101518 But the reason I didnt have this in the Fixes tab is because this patch will not fix the bug, it will just isolate to it being a bug with AUX Timeouts warning. Regards Manasi > > Cc: Jani Nikula <[2]jani.nik...@linux.intel.com> > Cc: Jim Bride <[3]jim.br...@linux.intel.com> > Cc: Ville Syrjälä <[4]ville.syrj...@linux.intel.com> > Cc: Daniel Vetter <[5]daniel.vet...@intel.com> > Signed-off-by: Manasi Navare <[6]manasi.d.nav...@intel.com> > --- > drivers/gpu/drm/i915/intel_dp.c | 2 +- > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > drivers/gpu/drm/i915/intel_drv.h | 1 + > 3 files changed, 4 insertions(+), 2 deletions(-) > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index 4fd4853..edac0c8 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, > 27, 54 }; >* If a CPU or PCH DP output is attached to an eDP panel, this > function >* will return true, and false otherwise. >*/ > -static bool is_edp(struct intel_dp *intel_dp) > +bool is_edp(struct intel_dp *intel_dp) > { > struct intel_digital_port *intel_dig_port = > dp_to_dig_port(intel_dp); > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > b/drivers/gpu/drm/i915/intel_dp_link_training.c > index 05907fa..18ec61f 100644 > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp > *intel_dp) >intel_connector->[7]base.base.id, >intel_connector->[8]base.name, >intel_dp->link_rate, intel_dp->lane_count); > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > + /* Dont fallback and prune modes if its eDP */ > + if (!is_edp(intel_dp) && > !intel_dp_get_link_train_fallback_values(intel_dp, > > intel_dp->link_rate, > > intel_dp->lane_count)) > /* Schedule a Hotplug Uevent to userspace to start > modeset */ > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index fa47285..9800a15 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1548,6 +1548,7 @@ static inline unsigned int > intel_dp_unused_lane_mask(int lane_count) > } > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > +bool is_edp(struct intel_dp *intel_dp); > int intel_dp_link_required(int pixel_clock, int bpp); > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > bool intel_digital_port_connected(struct drm_i915_private > *dev_priv, > -- > 2.1.4 > ___ > Intel-gfx mailing list > [9]Intel-gfx@lists.freedesktop.org > [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > References > >1. mailto:manasi.d.nav...@intel.com >2. mailto:jani.nik...@linux.intel.com >3. mailto:jim.br...@linux.intel.com >4. mailto:ville.syrj...@linux.intel.com >5. mailto:daniel.vet...@intel.com >6. mailto:manasi.d.nav...@intel.com >7. http://base.base.id/ >8. http://base.name/ >9. mailto:Intel-gfx@lists.freedesktop.org > 10. https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 12:28:56PM -0700, Pandiyan, Dhinakaran wrote: > On Thu, 2017-08-17 at 12:29 -0700, Manasi Navare wrote: > > On Thu, Aug 17, 2017 at 12:51:27PM +0300, Jani Nikula wrote: > > > On Wed, 16 Aug 2017, Manasi Navare wrote: > > > > In case of eDP because the panel has a fixed mode we cannot > > > > link train fallback and prune modes since this results in > > > > no modes available for eDP connector. > > > > Also since its a panel, link training should not fail dynamically > > > > based on cable conditions like in case of DP. > > > > > > > > Cc: Jani Nikula > > > > Cc: Jim Bride > > > > Cc: Ville Syrjälä > > > > Cc: Daniel Vetter > > > > Signed-off-by: Manasi Navare > > > > --- > > > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > > > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > > > 3 files changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > > b/drivers/gpu/drm/i915/intel_dp.c > > > > index 4fd4853..edac0c8 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, > > > > 27, 54 }; > > > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > > > * will return true, and false otherwise. > > > > */ > > > > -static bool is_edp(struct intel_dp *intel_dp) > > > > +bool is_edp(struct intel_dp *intel_dp) > > > > > > Make that intel_dp_is_edp when you expose it outside of intel_dp.c > > > > > > BR, > > > Jani > > > > > > > Yea renaming it as intel_dp_is_edp() makes sense after making it a non > > static function. > > So should I make a seperate patch for this change and changing the name at > > all places > > that call is_edp() currently? > > > > Regards > > Manasi > > > > Don't we already have a intel_dp_is_edp() that checks VBT? That'll need > to be renamed if is_edp() is going to become intel_dp_is_edp() > Yes just noticed we do have that intel_dp_is_edp(). But I agree that we need to add intel_dp prefix if we are going to expose the is_edp() function. Do you have any suggestions for the name? > Btw I remember seeing Jim's psr patch making this function > global(non-static?) too. > Yes I have looked at it and that patch is still in review, so this review comment applies to his patch as well. So either he makes this change in his or it happens here. I plan to add this comment to Jim's PSR patch review too. Regards Manasi > > > > > { > > > > struct intel_digital_port *intel_dig_port = > > > > dp_to_dig_port(intel_dp); > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > index 05907fa..18ec61f 100644 > > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp) > > > > intel_connector->base.base.id, > > > > intel_connector->base.name, > > > > intel_dp->link_rate, intel_dp->lane_count); > > > > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > > > > + /* Dont fallback and prune modes if its eDP */ > > > > + if (!is_edp(intel_dp) && > > > > !intel_dp_get_link_train_fallback_values(intel_dp, > > > > > > > > intel_dp->link_rate, > > > > > > > > intel_dp->lane_count)) > > > > /* Schedule a Hotplug Uevent to userspace to start > > > > modeset */ > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > > > b/drivers/gpu/drm/i915/intel_drv.h > > > > index fa47285..9800a15 100644 > > > > --- a/drivers/gpu/drm/i915/intel_drv.h > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > > > @@ -1548,6 +1548,7 @@ static inline unsigned int > > > > intel_dp_unused_lane_mask(int lane_count) > > > > } > > > > > > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > > > > +bool is_edp(struct intel_dp *intel_dp); > > > > int intel_dp_link_required(int pixel_clock, int bpp); > > > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > > > > bool intel_digital_port_connected(struct drm_i915_private *dev_priv, > > > > > > -- > > > Jani Nikula, Intel Open Source Technology Center > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, 2017-08-17 at 12:29 -0700, Manasi Navare wrote: > On Thu, Aug 17, 2017 at 12:51:27PM +0300, Jani Nikula wrote: > > On Wed, 16 Aug 2017, Manasi Navare wrote: > > > In case of eDP because the panel has a fixed mode we cannot > > > link train fallback and prune modes since this results in > > > no modes available for eDP connector. > > > Also since its a panel, link training should not fail dynamically > > > based on cable conditions like in case of DP. > > > > > > Cc: Jani Nikula > > > Cc: Jim Bride > > > Cc: Ville Syrjälä > > > Cc: Daniel Vetter > > > Signed-off-by: Manasi Navare > > > --- > > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > > 3 files changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > b/drivers/gpu/drm/i915/intel_dp.c > > > index 4fd4853..edac0c8 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 27, > > > 54 }; > > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > > * will return true, and false otherwise. > > > */ > > > -static bool is_edp(struct intel_dp *intel_dp) > > > +bool is_edp(struct intel_dp *intel_dp) > > > > Make that intel_dp_is_edp when you expose it outside of intel_dp.c > > > > BR, > > Jani > > > > Yea renaming it as intel_dp_is_edp() makes sense after making it a non static > function. > So should I make a seperate patch for this change and changing the name at > all places > that call is_edp() currently? > > Regards > Manasi > Don't we already have a intel_dp_is_edp() that checks VBT? That'll need to be renamed if is_edp() is going to become intel_dp_is_edp() Btw I remember seeing Jim's psr patch making this function global(non-static?) too. > > > { > > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > index 05907fa..18ec61f 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp) > > > intel_connector->base.base.id, > > > intel_connector->base.name, > > > intel_dp->link_rate, intel_dp->lane_count); > > > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > > > + /* Dont fallback and prune modes if its eDP */ > > > + if (!is_edp(intel_dp) && > > > !intel_dp_get_link_train_fallback_values(intel_dp, > > >intel_dp->link_rate, > > >intel_dp->lane_count)) > > > /* Schedule a Hotplug Uevent to userspace to start modeset */ > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > > b/drivers/gpu/drm/i915/intel_drv.h > > > index fa47285..9800a15 100644 > > > --- a/drivers/gpu/drm/i915/intel_drv.h > > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > > @@ -1548,6 +1548,7 @@ static inline unsigned int > > > intel_dp_unused_lane_mask(int lane_count) > > > } > > > > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > > > +bool is_edp(struct intel_dp *intel_dp); > > > int intel_dp_link_required(int pixel_clock, int bpp); > > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > > > bool intel_digital_port_connected(struct drm_i915_private *dev_priv, > > > > -- > > Jani Nikula, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Thu, Aug 17, 2017 at 12:51:27PM +0300, Jani Nikula wrote: > On Wed, 16 Aug 2017, Manasi Navare wrote: > > In case of eDP because the panel has a fixed mode we cannot > > link train fallback and prune modes since this results in > > no modes available for eDP connector. > > Also since its a panel, link training should not fail dynamically > > based on cable conditions like in case of DP. > > > > Cc: Jani Nikula > > Cc: Jim Bride > > Cc: Ville Syrjälä > > Cc: Daniel Vetter > > Signed-off-by: Manasi Navare > > --- > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > 3 files changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index 4fd4853..edac0c8 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 27, > > 54 }; > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > * will return true, and false otherwise. > > */ > > -static bool is_edp(struct intel_dp *intel_dp) > > +bool is_edp(struct intel_dp *intel_dp) > > Make that intel_dp_is_edp when you expose it outside of intel_dp.c > > BR, > Jani > Yea renaming it as intel_dp_is_edp() makes sense after making it a non static function. So should I make a seperate patch for this change and changing the name at all places that call is_edp() currently? Regards Manasi > > { > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > index 05907fa..18ec61f 100644 > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp) > > intel_connector->base.base.id, > > intel_connector->base.name, > > intel_dp->link_rate, intel_dp->lane_count); > > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > > + /* Dont fallback and prune modes if its eDP */ > > + if (!is_edp(intel_dp) && > > !intel_dp_get_link_train_fallback_values(intel_dp, > > intel_dp->link_rate, > > intel_dp->lane_count)) > > /* Schedule a Hotplug Uevent to userspace to start modeset */ > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > b/drivers/gpu/drm/i915/intel_drv.h > > index fa47285..9800a15 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -1548,6 +1548,7 @@ static inline unsigned int > > intel_dp_unused_lane_mask(int lane_count) > > } > > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > > +bool is_edp(struct intel_dp *intel_dp); > > int intel_dp_link_required(int pixel_clock, int bpp); > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > > bool intel_digital_port_connected(struct drm_i915_private *dev_priv, > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote: > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote: > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote: > > > This set of changes has some history to them. There were several attempts > > > to add what was called "fast link training" to i915, which actually wasn't > > > fast link training as per the DP spec. These changes were: > > > > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization") > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization") > > > > > > which were eventually hand-reverted by: > > > > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training > > > feature") > > > > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some > > > very bad side-effects on PSR functionality on Skylake. The issue at > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3 > > > (depending on the original link configuration) in order to quickly get > > > the source and sink back in synchronization across the link before handing > > > control back to the i915. There's an assumption that none of the link > > > configuration information has changed (and thus it's still valid) since > > > the > > > last full link training operation. The revert above was identified via a > > > bisect as the cause of some of Skylake's PSR woes. This patch, largely > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization") > > > puts the eDP portions of this patch back in place. None of the flickering > > > issues that spurred the revert have been seen, and I suspect the real > > > culprits here were addressed by some of the recent link training changes > > > that Manasi has implemented, and PSR on Skylake is definitely more happy > > > with these changes in-place. > > > > > > v2 and v3: Rebase > > > v4: * Clean up accesses to train_set_valid a bit for easier > > > reading. (Chris) > > > * Rebase > > > v5: * Checkpatch cleanup > > > * Rebase > > > > > > Cc: Chris Wilson > > > Cc: Rodrigo Vivi > > > Cc: Paulo Zanoni > > > Cc: Manasi D Navare > > > Cc: Mika Kahola > > > Cc: Jani Nikula > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training > > > feature") > > > Signed-off-by: Jim Bride > > > --- > > > drivers/gpu/drm/i915/intel_dp.c | 4 +++- > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++- > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > > > 3 files changed, 19 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > b/drivers/gpu/drm/i915/intel_dp.c > > > index 76c8a0b..4bd409c 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, > > > 54 }; > > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > > * will return true, and false otherwise. > > > */ > > > -static bool is_edp(struct intel_dp *intel_dp) > > > +bool is_edp(struct intel_dp *intel_dp) > > > { > > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > > > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector > > > *intel_connector) > > > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp); > > > > > > intel_dp->reset_link_params = false; > > > + intel_dp->train_set_valid = false; > > > } > > > > > > intel_dp_print_rates(intel_dp); > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port > > > *intel_dig_port, > > > intel_dp_set_source_rates(intel_dp); > > > > > > intel_dp->reset_link_params = true; > > > + intel_dp->train_set_valid = false; > > > intel_dp->pps_pipe = INVALID_PIPE; > > > intel_dp->active_pipe = INVALID_PIPE; > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > index 05907fa..67032cf 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > > @@ -94,7 +94,8 @@ static bool > > > intel_dp_reset_link_train(struct intel_dp *intel_dp, > > > uint8_t dp_train_pat) > > > { > > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set)); > > > + if (!intel_dp->train_set_valid) > > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set)); > > > intel_dp_set_signal_levels(intel_dp); > > > return intel_dp_set_link_train(intel_dp, dp_train_pat); > > > } > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct > > > intel_dp *intel_dp) > > > DP_TRAINING_PATTERN_1 | > > > DP_LINK_SCRAMBLING_DISABLE)) { > > > DRM_ERROR("failed to enable link training\n"); > > > + intel_d
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Enable Audio Pin Buffer.
On Thu, 2017-08-17 at 18:55 +, Vivi, Rodrigo wrote: > On Thu, 2017-08-17 at 09:26 +0530, Sanyog Kale wrote: > > On Wed, Aug 16, 2017 at 06:46:26PM -0500, Pandiyan, Dhinakaran wrote: > > > On Thu, 2017-07-06 at 14:03 -0700, Rodrigo Vivi wrote: > > > > Starting on CNL, we need to enable Audio Pin Buffer. > > > > > > > > By the spec it seems that this is part of audio programming, > > > > > > I am not very clear where the pin buffer enabling/disabling step falls > > > in the audio programming sequence. From what I understand, audio codec > > > enable/disable is controlled by i915, if pin buffer enable/disable is > > > part of that, then we don't need a call back. It's difficult to know > > > where this function is going to be used without seeing the audio driver > > > patch that makes of use of this. > > Sanyog, I couldn't find all the old emails with spec pointing out the > time that we needed to set this bit. Do you still have? > Anything you could share when publishing the patches? > > > > > > > > From audio point of view, we are working on correct sequence where this ops > > will be called. However during CNL Power-ON we enabled the pin buf using ops > > as part of azx_reset. > > Ok, so let's put this on hold while audio drivers are not ready. > It will be on internal branch anyways. > When audio driver gets ready we re-submit all together. > That makes a lot of sense to me. > > > > > > so let's give them the hability to set/unset this as needed. > > > > > > typo s/hability/ability > > > > > > > > v2: With a hook so audio driver can control it. > > > > v3: Put back reg definition lost on v2. > > > > > > > > Cc: Dhinakaran Pandiyan > > > > Cc: Jani Nikula > > > > Cc: Sanyog Kale > > > > Signed-off-by: Rodrigo Vivi > > > > --- > > > > drivers/gpu/drm/i915/i915_reg.h| 3 +++ > > > > drivers/gpu/drm/i915/intel_audio.c | 16 > > > > include/drm/i915_component.h | 6 ++ > > > > 3 files changed, 25 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > > b/drivers/gpu/drm/i915/i915_reg.h > > > > index 64cc674..aab38da 100644 > > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > > @@ -2643,6 +2643,9 @@ enum skl_disp_power_wells { > > > > #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000) > > > > #define I915_HDMI_LPE_AUDIO_SIZE 0x1000 > > > > > > > > +#define AUDIO_PIN_BUF_CTL _MMIO(0x48414) > > > > +#define AUDIO_PIN_BUF_ENABLE (1 << 31) > > > > + > > > > /* DisplayPort Audio w/ LPE */ > > > > #define VLV_AUD_CHICKEN_BIT_REG_MMIO(VLV_DISPLAY_BASE > > > > + 0x62F38) > > > > #define VLV_CHICKEN_BIT_DBG_ENABLE (1 << 0) > > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c > > > > b/drivers/gpu/drm/i915/intel_audio.c > > > > index d805b6e..0c83254 100644 > > > > --- a/drivers/gpu/drm/i915/intel_audio.c > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c > > > > @@ -865,6 +865,21 @@ static int i915_audio_component_get_eld(struct > > > > device *kdev, int port, > > > > return ret; > > > > } > > > > > > > > +static void i915_audio_component_pin_buf(struct device *kdev, bool > > > > enable) > > > > +{ > > > > > > Does it matter whether the audio codec is enabled or disabled when this > > > call comes in? i.e., do we need some sort of check here? Or do we assume > > > the audio driver knows exactly when to enable or disable pin buffer? > > > > > > > > > > > > > + struct drm_i915_private *dev_priv = kdev_to_i915(kdev); > > > > + > > > > + if (!IS_CANNONLAKE(dev_priv)) > > > > > > Should this be a INTEL_GEN() < 10 since the register is gen10+? I am not > > > particular about either of the options. > > > > > > > + return; > > > > + > > > > + if (enable) > > > > + I915_WRITE(AUDIO_PIN_BUF_CTL, > > > > I915_READ(AUDIO_PIN_BUF_CTL) | > > > > + AUDIO_PIN_BUF_ENABLE); > > > > + else > > > > + I915_WRITE(AUDIO_PIN_BUF_CTL, > > > > I915_READ(AUDIO_PIN_BUF_CTL) & > > > > + ~AUDIO_PIN_BUF_ENABLE); > > > > +} > > > > + > > > > static const struct i915_audio_component_ops i915_audio_component_ops > > > > = { > > > > .owner = THIS_MODULE, > > > > .get_power = i915_audio_component_get_power, > > > > @@ -873,6 +888,7 @@ static int i915_audio_component_get_eld(struct > > > > device *kdev, int port, > > > > .get_cdclk_freq = i915_audio_component_get_cdclk_freq, > > > > .sync_audio_rate = i915_audio_component_sync_audio_rate, > > > > .get_eld= i915_audio_component_get_eld, > > > > + .pin_buf= i915_audio_component_pin_buf, > > > > }; > > > > > > > > static int i915_audio_component_bind(struct device *i915_kdev, > > > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h > > > > index 545c6e0..b8875d4 100644
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Enable Audio Pin Buffer.
On Thu, 2017-08-17 at 09:26 +0530, Sanyog Kale wrote: > On Wed, Aug 16, 2017 at 06:46:26PM -0500, Pandiyan, Dhinakaran wrote: > > On Thu, 2017-07-06 at 14:03 -0700, Rodrigo Vivi wrote: > > > Starting on CNL, we need to enable Audio Pin Buffer. > > > > > > By the spec it seems that this is part of audio programming, > > > > I am not very clear where the pin buffer enabling/disabling step falls > > in the audio programming sequence. From what I understand, audio codec > > enable/disable is controlled by i915, if pin buffer enable/disable is > > part of that, then we don't need a call back. It's difficult to know > > where this function is going to be used without seeing the audio driver > > patch that makes of use of this. Sanyog, I couldn't find all the old emails with spec pointing out the time that we needed to set this bit. Do you still have? Anything you could share when publishing the patches? > > > > From audio point of view, we are working on correct sequence where this ops > will be called. However during CNL Power-ON we enabled the pin buf using ops > as part of azx_reset. Ok, so let's put this on hold while audio drivers are not ready. It will be on internal branch anyways. When audio driver gets ready we re-submit all together. > > > > so let's give them the hability to set/unset this as needed. > > > > typo s/hability/ability > > > > > > v2: With a hook so audio driver can control it. > > > v3: Put back reg definition lost on v2. > > > > > > Cc: Dhinakaran Pandiyan > > > Cc: Jani Nikula > > > Cc: Sanyog Kale > > > Signed-off-by: Rodrigo Vivi > > > --- > > > drivers/gpu/drm/i915/i915_reg.h| 3 +++ > > > drivers/gpu/drm/i915/intel_audio.c | 16 > > > include/drm/i915_component.h | 6 ++ > > > 3 files changed, 25 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > b/drivers/gpu/drm/i915/i915_reg.h > > > index 64cc674..aab38da 100644 > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > @@ -2643,6 +2643,9 @@ enum skl_disp_power_wells { > > > #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000) > > > #define I915_HDMI_LPE_AUDIO_SIZE 0x1000 > > > > > > +#define AUDIO_PIN_BUF_CTL_MMIO(0x48414) > > > +#define AUDIO_PIN_BUF_ENABLE (1 << 31) > > > + > > > /* DisplayPort Audio w/ LPE */ > > > #define VLV_AUD_CHICKEN_BIT_REG _MMIO(VLV_DISPLAY_BASE + > > > 0x62F38) > > > #define VLV_CHICKEN_BIT_DBG_ENABLE (1 << 0) > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c > > > b/drivers/gpu/drm/i915/intel_audio.c > > > index d805b6e..0c83254 100644 > > > --- a/drivers/gpu/drm/i915/intel_audio.c > > > +++ b/drivers/gpu/drm/i915/intel_audio.c > > > @@ -865,6 +865,21 @@ static int i915_audio_component_get_eld(struct > > > device *kdev, int port, > > > return ret; > > > } > > > > > > +static void i915_audio_component_pin_buf(struct device *kdev, bool > > > enable) > > > +{ > > > > Does it matter whether the audio codec is enabled or disabled when this > > call comes in? i.e., do we need some sort of check here? Or do we assume > > the audio driver knows exactly when to enable or disable pin buffer? > > > > > > > > > + struct drm_i915_private *dev_priv = kdev_to_i915(kdev); > > > + > > > + if (!IS_CANNONLAKE(dev_priv)) > > > > Should this be a INTEL_GEN() < 10 since the register is gen10+? I am not > > particular about either of the options. > > > > > + return; > > > + > > > + if (enable) > > > + I915_WRITE(AUDIO_PIN_BUF_CTL, I915_READ(AUDIO_PIN_BUF_CTL) | > > > +AUDIO_PIN_BUF_ENABLE); > > > + else > > > + I915_WRITE(AUDIO_PIN_BUF_CTL, I915_READ(AUDIO_PIN_BUF_CTL) & > > > +~AUDIO_PIN_BUF_ENABLE); > > > +} > > > + > > > static const struct i915_audio_component_ops i915_audio_component_ops = { > > > .owner = THIS_MODULE, > > > .get_power = i915_audio_component_get_power, > > > @@ -873,6 +888,7 @@ static int i915_audio_component_get_eld(struct device > > > *kdev, int port, > > > .get_cdclk_freq = i915_audio_component_get_cdclk_freq, > > > .sync_audio_rate = i915_audio_component_sync_audio_rate, > > > .get_eld= i915_audio_component_get_eld, > > > + .pin_buf= i915_audio_component_pin_buf, > > > }; > > > > > > static int i915_audio_component_bind(struct device *i915_kdev, > > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h > > > index 545c6e0..b8875d4 100644 > > > --- a/include/drm/i915_component.h > > > +++ b/include/drm/i915_component.h > > > @@ -79,6 +79,12 @@ struct i915_audio_component_ops { > > >*/ > > > int (*get_eld)(struct device *, int port, int pipe, bool *enabled, > > > unsigned char *buf, int max_bytes); > > > + /** > > > + * @pin_buf: Enable or disable pin buffer. > > > + * > > > + * Allow audio driver the toggle pin buffer. > > > + */ > > > + void (*pin_buf)(s
Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Avoid old DDI translation functions on Cannonlake.
On Thu, 2017-08-17 at 15:59 +0300, Mika Kahola wrote: > On Thu, 2017-07-06 at 13:54 -0700, Rodrigo Vivi wrote: > > Cannonlake uses a different swing voltage initalization > > sequence scheme that doesn't require these old functions. > > > > All other DDI, voltage swing and PLLs initialialization > > and configuration are already in place for Cannonlake. > > This patch only removes unecessary steps probably saving > > us from some useless warnings. > > > > Cc: Clint Taylor > > Cc: Mika Kahola > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/intel_ddi.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > b/drivers/gpu/drm/i915/intel_ddi.c > > index 80e96f1..9e9bfbe 100644 > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > @@ -596,7 +596,7 @@ static int intel_ddi_hdmi_level(struct > > drm_i915_private *dev_priv, enum port por > > > > hdmi_level = dev_priv- > > >vbt.ddi_port_info[port].hdmi_level_shift; > > > > - if (IS_GEN9_LP(dev_priv)) > > + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) > Can we assume that this holds always for GEN10 and above platforms? Hi Mika, thanks for looking, but please ignore this patch here. I should have told earlier, sorry, but this patch should be replaced by: https://patchwork.freedesktop.org/series/28883/ reviews and suggestions there are welcome... Thanks, Rodrigo. > > > return hdmi_level; > > > > if (IS_GEN9_BC(dev_priv)) { > > @@ -688,7 +688,7 @@ static void intel_prepare_dp_ddi_buffers(struct > > intel_encoder *encoder) > > enum port port = intel_ddi_get_encoder_port(encoder); > > const struct ddi_buf_trans *ddi_translations; > > > > - if (IS_GEN9_LP(dev_priv)) > > + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) > > return; > > > > switch (encoder->type) { > > @@ -741,7 +741,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct > > intel_encoder *encoder) > > enum port port = intel_ddi_get_encoder_port(encoder); > > const struct ddi_buf_trans *ddi_translations_hdmi; > > > > - if (IS_GEN9_LP(dev_priv)) > > + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) > > return; > > > > hdmi_level = intel_ddi_hdmi_level(dev_priv, port); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.
On Thu, Aug 17, 2017 at 10:33 AM, Jani Nikula wrote: > On Thu, 17 Aug 2017, Rodrigo Vivi wrote: >> On my own workflow I was missing a way to download mboxes >> directly from patchwork with the patchwork id. So my first >> reflex was to modify dim to fulfil my needs. However that >> was increasing dim in complexity and dependencies and leaving >> that messy. >> >> That was when Jani suggested me the dimrc extension with the >> example that is now part of this spec. >> >> That was clean and simple enough to understand, so Daniel >> suggested me to add it to the spec. >> >> For record let's put my final local solution that lays now on >> my own ~/.dimrc >> >> dim_pwaq() >> { >> if [ -n "$1" ]; then >> curl https://patchwork.freedesktop.org/patch/$1/mbox/ | >> dim_apply_queued >> else >> echo "Give me a patchwork id" >> fi >> } >> >> Cc: Jani Nikula >> Cc: Daniel Vetter >> Signed-off-by: Rodrigo Vivi >> --- >> dim.rst | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/dim.rst b/dim.rst >> index 802c776e03f9..c6728d186554 100644 >> --- a/dim.rst >> +++ b/dim.rst >> @@ -441,6 +441,22 @@ usage >> Short form usage help listing all subcommands. Run by default or if an >> unknown >> subcommand was passed on the cmdline. >> >> +ALIASES >> +=== >> + >> +Extending **dim** functionalities >> +- >> + >> +It is possible to create your own dim helper and aliases by adding them to >> \$HOME/.dimrc >> + >> +dim_my_fancy_list_aliases() >> +{ >> + echo "Hello world!" >> + dim_list_aliases >> +} >> + >> +dim_alias_list_aliases=my-fancy-list-aliases >> + > > Naughty, naughty: > > $ make check > shellcheck -e SC2001 -e SC2034 -e SC2046 -e SC2086 -e SC2115 -e SC2119 -e > SC2120 -e SC2143 dim bash_completion > rst2man --strict --no-raw dim.rst >/dev/null > dim.rst:453: (INFO/1) Possible title underline, too short for the title. > Treating it as ordinary text because it's so short. > Exiting due to level-1 (INFO) system message. > Makefile:49: recipe for target 'mancheck' failed > make: *** [mancheck] Error 1 hm... it seems I need to update my shellcheck package... what version do you use? here shellcheck complains in non-sense stuff and make check doesn't proceed to that point... > > > BR, > Jani. > > >> ENVIRONMENT >> === > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch
So far we could use *dim* to apply a whole series in a mbox, but only the very last patch was receiving all the checks and patchwork link. So this patch remove this limitation by using git mailsplit to split the mbox and than use git am and checks individually on each patch. Cc: Jani Nikula Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- dim | 45 + 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/dim b/dim index 11aa675cc3bc..5457006631d6 100755 --- a/dim +++ b/dim @@ -767,38 +767,43 @@ function dim_apply_branch branch=${1:?$usage} shift file=$(mktemp) + dir=$(mktemp -d) assert_branch $branch assert_repo_clean + committer_email=$(git_committer_email) + cat > $file + git mailsplit -o$dir $file > /dev/null - message_id=$(message_get_id $file) + for patch in `ls $dir`; do - committer_email=$(git_committer_email) + message_id=$(message_get_id $dir/$patch) - patch_from=$(grep "From:" "$file" | head -1) - if [[ "$patch_from" != *"$committer_email"* ]] ; then - sob=-s - fi + patch_from=$(grep "From:" "$dir/$patch" | head -1) + if [[ "$patch_from" != *"$committer_email"* ]] ; then + sob=-s + fi - git am --scissors -3 $sob "$@" $file + git am --scissors -3 $sob "$@" $dir/$patch - if [ -n "$message_id" ]; then - dim_commit_add_tag "Link: https://patchwork.freedesktop.org/patch/msgid/$message_id"; - else - echoerr "WARNING: No message-id found in the patch file." - rv=1 - fi + if [ -n "$message_id" ]; then + dim_commit_add_tag "Link: https://patchwork.freedesktop.org/patch/msgid/$message_id"; + else + echoerr "WARNING: No message-id found in the patch file." + rv=1 + fi - if ! checkpatch_commit HEAD; then - rv=1 - fi - if ! check_maintainer $branch HEAD; then - rv=1 - fi + if ! checkpatch_commit HEAD; then + rv=1 + fi + if ! check_maintainer $branch HEAD; then + rv=1 + fi - eval $DRY $DIM_POST_APPLY_ACTION + eval $DRY $DIM_POST_APPLY_ACTION + done return $rv } -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote: > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote: > > This set of changes has some history to them. There were several attempts > > to add what was called "fast link training" to i915, which actually wasn't > > fast link training as per the DP spec. These changes were: > > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization") > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization") > > > > which were eventually hand-reverted by: > > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training > > feature") > > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some > > very bad side-effects on PSR functionality on Skylake. The issue at > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3 > > (depending on the original link configuration) in order to quickly get > > the source and sink back in synchronization across the link before handing > > control back to the i915. There's an assumption that none of the link > > configuration information has changed (and thus it's still valid) since the > > last full link training operation. The revert above was identified via a > > bisect as the cause of some of Skylake's PSR woes. This patch, largely > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization") > > puts the eDP portions of this patch back in place. None of the flickering > > issues that spurred the revert have been seen, and I suspect the real > > culprits here were addressed by some of the recent link training changes > > that Manasi has implemented, and PSR on Skylake is definitely more happy > > with these changes in-place. > > > > v2 and v3: Rebase > > v4: * Clean up accesses to train_set_valid a bit for easier > > reading. (Chris) > > * Rebase > > v5: * Checkpatch cleanup > > * Rebase > > > > Cc: Chris Wilson > > Cc: Rodrigo Vivi > > Cc: Paulo Zanoni > > Cc: Manasi D Navare > > Cc: Mika Kahola > > Cc: Jani Nikula > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature") > > Signed-off-by: Jim Bride > > --- > > drivers/gpu/drm/i915/intel_dp.c | 4 +++- > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++- > > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > > 3 files changed, 19 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index 76c8a0b..4bd409c 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, > > 54 }; > > * If a CPU or PCH DP output is attached to an eDP panel, this function > > * will return true, and false otherwise. > > */ > > -static bool is_edp(struct intel_dp *intel_dp) > > +bool is_edp(struct intel_dp *intel_dp) > > { > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector > > *intel_connector) > > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp); > > > > intel_dp->reset_link_params = false; > > + intel_dp->train_set_valid = false; > > } > > > > intel_dp_print_rates(intel_dp); > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port > > *intel_dig_port, > > intel_dp_set_source_rates(intel_dp); > > > > intel_dp->reset_link_params = true; > > + intel_dp->train_set_valid = false; > > intel_dp->pps_pipe = INVALID_PIPE; > > intel_dp->active_pipe = INVALID_PIPE; > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > > b/drivers/gpu/drm/i915/intel_dp_link_training.c > > index 05907fa..67032cf 100644 > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > @@ -94,7 +94,8 @@ static bool > > intel_dp_reset_link_train(struct intel_dp *intel_dp, > > uint8_t dp_train_pat) > > { > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set)); > > + if (!intel_dp->train_set_valid) > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set)); > > intel_dp_set_signal_levels(intel_dp); > > return intel_dp_set_link_train(intel_dp, dp_train_pat); > > } > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp > > *intel_dp) > >DP_TRAINING_PATTERN_1 | > >DP_LINK_SCRAMBLING_DISABLE)) { > > DRM_ERROR("failed to enable link training\n"); > > + intel_dp->train_set_valid = false; > > return false; > > } > > > > + /* > > +* The initial set of link parameters are set by this point, so go > > +* ahead and set intel_dp->train_set_valid to false in case any of > > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop touching forcewake following a gen6+ engine reset
== Series Details == Series: drm/i915: Stop touching forcewake following a gen6+ engine reset URL : https://patchwork.freedesktop.org/series/28936/ State : success == Summary == Series 28936v1 drm/i915: Stop touching forcewake following a gen6+ engine reset https://patchwork.freedesktop.org/api/1.0/series/28936/revisions/1/mbox/ fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:458s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:437s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:545s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:523s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:529s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:619s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:445s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:426s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:509s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:601s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:597s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:531s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:471s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:490s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:484s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:409s e1b18fbd4daecb1c1cf31ca101f64e29a8933bcf drm-tip: 2017y-08m-17d-14h-58m-23s UTC integration manifest 289f21608f26 drm/i915: Stop touching forcewake following a gen6+ engine reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5431/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset
On 17/08/17 10:32, Chris Wilson wrote: Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2e7095: Author: Mika Kuoppala Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. Reported-by: Michel Thierry Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang recovery") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Michel Thierry --- drivers/gpu/drm/i915/intel_uncore.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index deb4430541cf..1d7b879cc68c 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1497,7 +1497,6 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, [VECS] = GEN6_GRDOM_VECS, }; u32 hw_mask; - int ret; if (engine_mask == ALL_ENGINES) { hw_mask = GEN6_GRDOM_FULL; @@ -1509,11 +1508,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, hw_mask |= hw_engine_mask[engine->id]; } - ret = gen6_hw_domain_reset(dev_priv, hw_mask); - - intel_uncore_forcewake_reset(dev_priv, true); - - return ret; + return gen6_hw_domain_reset(dev_priv, hw_mask); } /** Thanks for digging out the commit history. Reviewed-by Michel Thierry ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.
On Thu, 17 Aug 2017, Rodrigo Vivi wrote: > On my own workflow I was missing a way to download mboxes > directly from patchwork with the patchwork id. So my first > reflex was to modify dim to fulfil my needs. However that > was increasing dim in complexity and dependencies and leaving > that messy. > > That was when Jani suggested me the dimrc extension with the > example that is now part of this spec. > > That was clean and simple enough to understand, so Daniel > suggested me to add it to the spec. > > For record let's put my final local solution that lays now on > my own ~/.dimrc > > dim_pwaq() > { > if [ -n "$1" ]; then > curl https://patchwork.freedesktop.org/patch/$1/mbox/ | > dim_apply_queued > else > echo "Give me a patchwork id" > fi > } > > Cc: Jani Nikula > Cc: Daniel Vetter > Signed-off-by: Rodrigo Vivi > --- > dim.rst | 16 > 1 file changed, 16 insertions(+) > > diff --git a/dim.rst b/dim.rst > index 802c776e03f9..c6728d186554 100644 > --- a/dim.rst > +++ b/dim.rst > @@ -441,6 +441,22 @@ usage > Short form usage help listing all subcommands. Run by default or if an > unknown > subcommand was passed on the cmdline. > > +ALIASES > +=== > + > +Extending **dim** functionalities > +- > + > +It is possible to create your own dim helper and aliases by adding them to > \$HOME/.dimrc > + > +dim_my_fancy_list_aliases() > +{ > + echo "Hello world!" > + dim_list_aliases > +} > + > +dim_alias_list_aliases=my-fancy-list-aliases > + Naughty, naughty: $ make check shellcheck -e SC2001 -e SC2034 -e SC2046 -e SC2086 -e SC2115 -e SC2119 -e SC2120 -e SC2143 dim bash_completion rst2man --strict --no-raw dim.rst >/dev/null dim.rst:453: (INFO/1) Possible title underline, too short for the title. Treating it as ordinary text because it's so short. Exiting due to level-1 (INFO) system message. Makefile:49: recipe for target 'mancheck' failed make: *** [mancheck] Error 1 BR, Jani. > ENVIRONMENT > === -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Stop touching forcewake following a gen6+ engine reset
Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2e7095: Author: Mika Kuoppala Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. Reported-by: Michel Thierry Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang recovery") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Michel Thierry --- drivers/gpu/drm/i915/intel_uncore.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index deb4430541cf..1d7b879cc68c 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1497,7 +1497,6 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, [VECS] = GEN6_GRDOM_VECS, }; u32 hw_mask; - int ret; if (engine_mask == ALL_ENGINES) { hw_mask = GEN6_GRDOM_FULL; @@ -1509,11 +1508,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, hw_mask |= hw_engine_mask[engine->id]; } - ret = gen6_hw_domain_reset(dev_priv, hw_mask); - - intel_uncore_forcewake_reset(dev_priv, true); - - return ret; + return gen6_hw_domain_reset(dev_priv, hw_mask); } /** -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.
On my own workflow I was missing a way to download mboxes directly from patchwork with the patchwork id. So my first reflex was to modify dim to fulfil my needs. However that was increasing dim in complexity and dependencies and leaving that messy. That was when Jani suggested me the dimrc extension with the example that is now part of this spec. That was clean and simple enough to understand, so Daniel suggested me to add it to the spec. For record let's put my final local solution that lays now on my own ~/.dimrc dim_pwaq() { if [ -n "$1" ]; then curl https://patchwork.freedesktop.org/patch/$1/mbox/ | dim_apply_queued else echo "Give me a patchwork id" fi } Cc: Jani Nikula Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- dim.rst | 16 1 file changed, 16 insertions(+) diff --git a/dim.rst b/dim.rst index 802c776e03f9..c6728d186554 100644 --- a/dim.rst +++ b/dim.rst @@ -441,6 +441,22 @@ usage Short form usage help listing all subcommands. Run by default or if an unknown subcommand was passed on the cmdline. +ALIASES +=== + +Extending **dim** functionalities +- + +It is possible to create your own dim helper and aliases by adding them to \$HOME/.dimrc + +dim_my_fancy_list_aliases() +{ + echo "Hello world!" + dim_list_aliases +} + +dim_alias_list_aliases=my-fancy-list-aliases + ENVIRONMENT === -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: Accept patchwork URLs as apply-branch optional argument.
On Thu, Aug 17, 2017 at 9:18 AM, Rodrigo Vivi wrote: > On Thu, Aug 17, 2017 at 12:45 AM, Jani Nikula wrote: >> On Wed, 16 Aug 2017, Rodrigo Vivi wrote: >>> On Wed, Aug 16, 2017 at 11:13 AM, Rodrigo Vivi >>> wrote: Instead of having to manually download mbox from patchwork let's make dim to do it directly. Cc: Daniel Vetter Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- dim | 18 ++ 1 file changed, 18 insertions(+) diff --git a/dim b/dim index e98d23b24ec0..73b48da7f436 100755 --- a/dim +++ b/dim @@ -756,6 +756,16 @@ function dim_push dim_push_branch $(git_current_branch) "$@" } +function download_mbox +{ + wget -q --spider ${1} + if [ $? -ne "0" ]; then + echoerr "URL ${1} not found." + exit 1 + fi + wget -q ${1} -O $2 +} + # ensure we're on branch $1, and apply patches. the rest of the arguments are # passed to git am. dim_alias_ab=apply-branch @@ -772,6 +782,14 @@ function dim_apply_branch assert_repo_clean case $1 in + *"patchwork.freedesktop.org"*"mbox") + download_mbox $1 $file + shift + ;; + *"patchwork.freedesktop.org"*) >>> >>> Another thing that I'd like to do is to be able to give the patchwork >>> id directly, but I don't want to mess with the $@ going to git >>> directly so I'm not sure which way would be better... >> >> Personally I prefer using message-id based patchwork references: >> >> http://patchwork.freedesktop.org/patch/msgid/2017083907.6716-1-jani.nik...@intel.com > > well remembered... > in the end it gets converted to > https://patchwork.freedesktop.org/patch/171432/ > > so we can get > https://patchwork.freedesktop.org/patch/171432/mbox > >> >>> maybe parse for something like >>> "pw="*) >>> download_mbox ${1#pw=} $file >>> so we could use >>> dim aq pw=170802 >>> >>> ? >>> suggestions? >> >> The ways around this are argument parsing in apply-branch or adding >> another dim subcommand. > > Usage: dim apply-branch [apply-branch options] branch [--] [git options] > > -i > -m > -u > > hmm but not sure it goes well with the aliases were we would need to convert > > dim aq -m 2017083907.6716-1-jani.nik...@intel.com [git options] > to > dim apply-branch -m 2017083907.6716-1-jani.nik...@intel.com > drm-intel-next-queued [git options] nevermind... please entirely ignore this.. I solved my own needs with: dim_pwaq() { if [ -n "$1" ]; then curl https://patchwork.freedesktop.org/patch/$1/mbox/ | dim_apply_queued else echo "Give me a patchwork id" fi } using as: $ dim pwaq 172141 > >> >> Btw one missing piece is handling series mboxes, which do apply, but >> only the last commit from an mbox gets all the checks and Link: tags >> etc. > > yeap! well remembered! I suffered from this behaviour already and seen > other folks also complaining about it. > > So, for this should we iterate over patches inside mbox somehow and > git apply one by one or should we apply and then rebase && amend ? > not sure how to deal whit this in a cleaner way... this part is still valid.. > >> >> >> BR, >> Jani. >> >> >>> >>> + download_mbox $1/mbox $file + shift + ;; *".patch" | *".mbox") cat $1 > $file shift -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> -- >> Jani Nikula, Intel Open Source Technology Center > > > > -- > Rodrigo Vivi > Blog: http://blog.vivi.eng.br -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH 1/2] dim: Accept .mbox and .patch files as apply-branch optional argument.
On Thu, Aug 17, 2017 at 12:57 AM, Daniel Vetter wrote: > On Thu, Aug 17, 2017 at 10:30:02AM +0300, Jani Nikula wrote: >> On Wed, 16 Aug 2017, Rodrigo Vivi wrote: >> > Instead of forcing users to cat .patch or .mbox let's accept them >> > as optional argument for dim apply-branches. >> >> Well, that's a useless use of cat anyway. You could do >> >> $ dim apply-branch branch < patch.mbox >> >> > Cc: Daniel Vetter >> > Cc: Jani Nikula >> > Signed-off-by: Rodrigo Vivi >> > --- >> > dim | 10 +- >> > dim.rst | 2 +- >> > 2 files changed, 10 insertions(+), 2 deletions(-) >> > >> > diff --git a/dim b/dim >> > index 11aa675cc3bc..e98d23b24ec0 100755 >> > --- a/dim >> > +++ b/dim >> > @@ -771,7 +771,15 @@ function dim_apply_branch >> > assert_branch $branch >> > assert_repo_clean >> > >> > - cat > $file >> > + case $1 in >> > + *".patch" | *".mbox") >> > + cat $1 > $file >> > + shift >> > + ;; >> > + *) >> > + cat > $file >> > + ;; >> > + esac >> >> This would really be a surprising interface, argument parsing based on >> file suffixes. I don't approve. >> >> You'll need to make this handle options before the branch argument, >> something like: >> >> Usage: dim apply-branch [apply-branch options] branch [--] [git options] >> >> Is stdin redirection really such a bad thing? > > +1 on that. If I pick it from patchwork or an mbox, I just < patch.mbox or > curl patchwork.url | dim apply. I don't see the value in baking that into > the script ... oh, I had missed this before I commented on the other one. good idea to use curl... > > What we could do (and we have a jira for that already) is to check > patchwork for the updated .mbox with all the r-b/t-b/a-b tags auto-added. > That would greatly improve at least my workflow. > > And I also agree with Jani on keeping the dim design clean. We can add > stuff where it makes sense, and where dim really can add value (with > additional safety checks and convenience features). agree! > > One thing we maybe could be doing is a more fancy aliasing feature, along > the lines of git aliases, where you can do whatever you want. Then you > could do a dim apply-curl alias which resolves to curl $arg | dim apply. > Not sure how to implement that though ... I will try to use and to create my own alias and document it.. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib: Add audio library with dedicated helpers
== Series Details == Series: series starting with [1/3] lib: Add audio library with dedicated helpers URL : https://patchwork.freedesktop.org/series/28929/ State : success == Summary == IGT patchset tested on top of latest successful build 5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decoding of child device structure with latest DRM-Tip kernel build CI_DRM_2971 e1b18fbd4dae drm-tip: 2017y-08m-17d-14h-58m-23s UTC integration manifest Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:451s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:440s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:555s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:533s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:527s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:610s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:443s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:420s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:498s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:595s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:604s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:463s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:445s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:508s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:414s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_72/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: Accept patchwork URLs as apply-branch optional argument.
On Thu, Aug 17, 2017 at 12:45 AM, Jani Nikula wrote: > On Wed, 16 Aug 2017, Rodrigo Vivi wrote: >> On Wed, Aug 16, 2017 at 11:13 AM, Rodrigo Vivi >> wrote: >>> Instead of having to manually download mbox from patchwork >>> let's make dim to do it directly. >>> >>> Cc: Daniel Vetter >>> Cc: Jani Nikula >>> Signed-off-by: Rodrigo Vivi >>> --- >>> dim | 18 ++ >>> 1 file changed, 18 insertions(+) >>> >>> diff --git a/dim b/dim >>> index e98d23b24ec0..73b48da7f436 100755 >>> --- a/dim >>> +++ b/dim >>> @@ -756,6 +756,16 @@ function dim_push >>> dim_push_branch $(git_current_branch) "$@" >>> } >>> >>> +function download_mbox >>> +{ >>> + wget -q --spider ${1} >>> + if [ $? -ne "0" ]; then >>> + echoerr "URL ${1} not found." >>> + exit 1 >>> + fi >>> + wget -q ${1} -O $2 >>> +} >>> + >>> # ensure we're on branch $1, and apply patches. the rest of the arguments >>> are >>> # passed to git am. >>> dim_alias_ab=apply-branch >>> @@ -772,6 +782,14 @@ function dim_apply_branch >>> assert_repo_clean >>> >>> case $1 in >>> + *"patchwork.freedesktop.org"*"mbox") >>> + download_mbox $1 $file >>> + shift >>> + ;; >>> + *"patchwork.freedesktop.org"*) >> >> Another thing that I'd like to do is to be able to give the patchwork >> id directly, but I don't want to mess with the $@ going to git >> directly so I'm not sure which way would be better... > > Personally I prefer using message-id based patchwork references: > > http://patchwork.freedesktop.org/patch/msgid/2017083907.6716-1-jani.nik...@intel.com well remembered... in the end it gets converted to https://patchwork.freedesktop.org/patch/171432/ so we can get https://patchwork.freedesktop.org/patch/171432/mbox > >> maybe parse for something like >> "pw="*) >> download_mbox ${1#pw=} $file >> so we could use >> dim aq pw=170802 >> >> ? >> suggestions? > > The ways around this are argument parsing in apply-branch or adding > another dim subcommand. Usage: dim apply-branch [apply-branch options] branch [--] [git options] -i -m -u hmm but not sure it goes well with the aliases were we would need to convert dim aq -m 2017083907.6716-1-jani.nik...@intel.com [git options] to dim apply-branch -m 2017083907.6716-1-jani.nik...@intel.com drm-intel-next-queued [git options] > > Btw one missing piece is handling series mboxes, which do apply, but > only the last commit from an mbox gets all the checks and Link: tags > etc. yeap! well remembered! I suffered from this behaviour already and seen other folks also complaining about it. So, for this should we iterate over patches inside mbox somehow and git apply one by one or should we apply and then rebase && amend ? not sure how to deal whit this in a cleaner way... > > > BR, > Jani. > > >> >> >>> + download_mbox $1/mbox $file >>> + shift >>> + ;; >>> *".patch" | *".mbox") >>> cat $1 > $file >>> shift >>> -- >>> 2.13.2 >>> >>> ___ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: Accept patchwork URLs as apply-branch optional argument.
On Thu, Aug 17, 2017 at 12:37 AM, Jani Nikula wrote: > On Wed, 16 Aug 2017, Rodrigo Vivi wrote: >> Instead of having to manually download mbox from patchwork >> let's make dim to do it directly. >> >> Cc: Daniel Vetter >> Cc: Jani Nikula >> Signed-off-by: Rodrigo Vivi >> --- >> dim | 18 ++ >> 1 file changed, 18 insertions(+) >> >> diff --git a/dim b/dim >> index e98d23b24ec0..73b48da7f436 100755 >> --- a/dim >> +++ b/dim >> @@ -756,6 +756,16 @@ function dim_push >> dim_push_branch $(git_current_branch) "$@" >> } >> >> +function download_mbox >> +{ >> + wget -q --spider ${1} > > What's the benefit of doing this first? it check if links exist before trying to download anything. at least it returns fast when link is not valid > >> + if [ $? -ne "0" ]; then >> + echoerr "URL ${1} not found." >> + exit 1 > > Always just return 1 on errors, and set -e will handle the abort. This > way the caller can decide to use foo || true to ignore the error. oh of course! > >> + fi >> + wget -q ${1} -O $2 >> +} >> + >> # ensure we're on branch $1, and apply patches. the rest of the arguments >> are >> # passed to git am. >> dim_alias_ab=apply-branch >> @@ -772,6 +782,14 @@ function dim_apply_branch >> assert_repo_clean >> >> case $1 in >> + *"patchwork.freedesktop.org"*"mbox") >> + download_mbox $1 $file >> + shift >> + ;; >> + *"patchwork.freedesktop.org"*) >> + download_mbox $1/mbox $file >> + shift >> + ;; > > Really, the interface gets worse and worse here! actually was the other way around... I made this bad one and decided to extend to files :P > > --- > > I may sound like a pedant looking after style and consistency in a shell > script, but this one has grown beyond the size where we can just ignore > its maintenance. I've put in quite a bit of effort since the user base > went from 1 to 2 to keep it together. you are absolutely right. it is not just a shell script... it is our tool and we should care! > > > BR, > Jani. > > >> *".patch" | *".mbox") >> cat $1 > $file >> shift > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] tests: Introduce audio tests, starting with HDMI signal integrity
This introduces a new test for audio going through display connectors. It currently contains a single subtest for HDMI signal integrity, but other test cases will be added later on. The test setup consists in using an HDMI-VGA bridge that separates the audio out (via a 3.5 mm jack) and feeding this back to the DUT's line-in where it can be recorded by ALSA with controls correctly configured. The audio test makes use of the audio and ALSA igt libraries helpers. Signed-off-by: Paul Kocialkowski --- tests/Makefile.am | 12 tests/audio.c | 170 ++ 2 files changed, 182 insertions(+) create mode 100644 tests/audio.c diff --git a/tests/Makefile.am b/tests/Makefile.am index f9d11e6c..471f3818 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -20,6 +20,15 @@ TESTS_progs += \ $(NULL) endif +if HAVE_ALSA +if HAVE_GSL +TESTS_progs += \ + audio \ + $(NULL) +endif +endif + + if BUILD_TESTS test-list.txt: Makefile.sources @echo TESTLIST > $@ @@ -134,6 +143,9 @@ vc4_wait_seqno_LDADD = $(LDADD) $(DRM_VC4_LIBS) chamelium_CFLAGS = $(AM_CFLAGS) $(XMLRPC_CFLAGS) $(LIBUDEV_CFLAGS) chamelium_LDADD = $(LDADD) $(XMLRPC_LIBS) $(LIBUDEV_LIBS) +audio_CFLAGS = $(AM_CFLAGS) $(ALSA_CFLAGS) +audio_LDADD = $(LDADD) $(ALSA_LIBS) + amdgpu_amd_basic_CFLAGS = $(AM_CFLAGS) $(DRM_AMDGPU_CFLAGS) amdgpu_amd_basic_LDADD = $(LDADD) $(DRM_AMDGPU_LIBS) amdgpu_amd_cs_nop_CFLAGS = $(AM_CFLAGS) $(DRM_AMDGPU_CFLAGS) diff --git a/tests/audio.c b/tests/audio.c new file mode 100644 index ..7099dd99 --- /dev/null +++ b/tests/audio.c @@ -0,0 +1,170 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + * Paul Kocialkowski + */ + +#include "config.h" +#include "igt.h" + +#define PLAYBACK_CHANNELS 2 +#define PLAYBACK_FRAMES1024 + +#define CAPTURE_SAMPLE_RATE48000 +#define CAPTURE_CHANNELS 2 +#define CAPTURE_DEVICE_NAME"default" +#define CAPTURE_FRAMES 2048 + +#define RUN_TIMEOUT2000 + +struct test_data { + struct alsa *alsa; + struct audio_signal *signal; + + int streak; +}; + +static int sampling_rates[] = { + 32000, + 44100, + 48000, + 88200, + 96000, + 176400, + 192000, +}; + +static int sampling_rates_count = sizeof(sampling_rates) / sizeof(int); + +static int test_frequencies[] = { + 300, + 600, + 1200, + 8, + 1, +}; + +static int test_frequencies_count = sizeof(test_frequencies) / sizeof(int); + +static int output_callback(void *data, short *buffer, int frames) +{ + struct test_data *test_data = (struct test_data *) data; + + audio_signal_fill(test_data->signal, buffer, frames); + + return 0; +} + +static int input_callback(void *data, short *buffer, int frames) +{ + struct test_data *test_data = (struct test_data *) data; + bool detect; + + detect = audio_signal_detect(test_data->signal, CAPTURE_CHANNELS, +CAPTURE_SAMPLE_RATE, buffer, frames); + if (detect) + test_data->streak++; + else + test_data->streak = 0; + + /* A streak of 3 gives confidence that the signal is good. */ + if (test_data->streak == 3) + return 1; + + return 0; +} + +static void test_integrity(const char *device_name) +{ + struct test_data data; + int sampling_rate; + bool run = false; + bool test; + int i, j; + int ret; + + data.alsa = alsa_init(); + igt_assert(data.alsa); + + ret = alsa_open_output(data.alsa, device_name); + igt_assert(ret >= 0); + + ret = alsa_open_input(data.alsa, CAPTURE_DEVICE_NAME); + igt_assert(ret >= 0); + + alsa_configure_input(data.alsa, CAPTURE_CH
[Intel-gfx] [PATCH i-g-t 2/3] lib: Add ALSA library with dedicated helpers
This introduces an ALSA library, with dedicated helpers for handling playback and capture. It handles ALSA device identification and configuration as well as a run loop with callback mechanisms for feeding output data and handling input data. This library paves the way for testing audio going through display connectors, such as HDMI. Signed-off-by: Paul Kocialkowski --- configure.ac | 3 + .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/Makefile.am| 7 + lib/igt.h | 1 + lib/igt_alsa.c | 624 + lib/igt_alsa.h | 60 ++ 6 files changed, 696 insertions(+) create mode 100644 lib/igt_alsa.c create mode 100644 lib/igt_alsa.h diff --git a/configure.ac b/configure.ac index 50aa86b5..e66273a4 100644 --- a/configure.ac +++ b/configure.ac @@ -219,6 +219,9 @@ if test "x$enable_chamelium" = xyes; then AC_DEFINE(HAVE_CHAMELIUM, 1, [Enable Chamelium support]) fi +PKG_CHECK_MODULES(ALSA, [alsa], [alsa=yes], [alsa=no]) +AM_CONDITIONAL(HAVE_ALSA, [test "x$alsa" = xyes]) + # - # Configuration options # - diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml index c77159cf..0c34e4a5 100644 --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml @@ -16,6 +16,7 @@ API Reference + diff --git a/lib/Makefile.am b/lib/Makefile.am index 5ea08314..3ff14f66 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -38,6 +38,13 @@ lib_source_list += \ $(NULL) endif +if HAVE_ALSA +lib_source_list += \ + igt_alsa.c \ + igt_alsa.h \ + $(NULL) +endif + AM_CPPFLAGS = -I$(top_srcdir) AM_CFLAGS = \ $(CWARNFLAGS) \ diff --git a/lib/igt.h b/lib/igt.h index a75d2db7..ebf92349 100644 --- a/lib/igt.h +++ b/lib/igt.h @@ -35,6 +35,7 @@ #include "igt_dummyload.h" #include "igt_fb.h" #include "igt_frame.h" +#include "igt_alsa.h" #include "igt_audio.h" #include "igt_gt.h" #include "igt_kms.h" diff --git a/lib/igt_alsa.c b/lib/igt_alsa.c new file mode 100644 index ..d8bd0873 --- /dev/null +++ b/lib/igt_alsa.c @@ -0,0 +1,624 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + * Paul Kocialkowski + */ + +#include "config.h" + +#include + +#include "igt.h" + +#define HANDLES_MAX8 + +/** + * SECTION:igt_alsa + * @short_description: Library with ALSA helpers + * @title: ALSA + * @include: igt_alsa.h + * + * This library contains helpers for ALSA playback and capture. + */ + +struct alsa { + snd_pcm_t *output_handles[HANDLES_MAX]; + int output_handles_count; + int output_sampling_rate; + int output_channels; + + int (*output_callback)(void *data, short *buffer, int samples); + void *output_callback_data; + int output_samples_trigger; + + snd_pcm_t *input_handle; + int input_sampling_rate; + int input_channels; + + int (*input_callback)(void *data, short *buffer, int samples); + void *input_callback_data; + int input_samples_trigger; +}; + +static void alsa_error_handler(const char *file, int line, const char *function, + int err, const char *fmt, ...) +{ + if (err) + igt_debug("[ALSA] %s: %s\n", function, snd_strerror(err)); +} + +/** + * alsa_init: + * Allocate and initialize an alsa structure and configure the erro
[Intel-gfx] [PATCH i-g-t 1/3] lib: Add audio library with dedicated helpers
This introduces an audio library, with dedicated helpers for both generating signals and detecting peak frequencies in a signal. This library paves the way for testing audio going through display connectors, such as HDMI. Signed-off-by: Paul Kocialkowski --- .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/Makefile.am| 2 + lib/igt.h | 1 + lib/igt_audio.c| 326 + lib/igt_audio.h| 47 +++ 5 files changed, 377 insertions(+) create mode 100644 lib/igt_audio.c create mode 100644 lib/igt_audio.h diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml index f88afd2a..c77159cf 100644 --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml @@ -16,6 +16,7 @@ API Reference + diff --git a/lib/Makefile.am b/lib/Makefile.am index 9c932d6f..5ea08314 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -33,6 +33,8 @@ if HAVE_GSL lib_source_list += \ igt_frame.c \ igt_frame.h \ + igt_audio.c \ + igt_audio.h \ $(NULL) endif diff --git a/lib/igt.h b/lib/igt.h index d16a4991..a75d2db7 100644 --- a/lib/igt.h +++ b/lib/igt.h @@ -35,6 +35,7 @@ #include "igt_dummyload.h" #include "igt_fb.h" #include "igt_frame.h" +#include "igt_audio.h" #include "igt_gt.h" #include "igt_kms.h" #include "igt_pm.h" diff --git a/lib/igt_audio.c b/lib/igt_audio.c new file mode 100644 index ..527a4930 --- /dev/null +++ b/lib/igt_audio.c @@ -0,0 +1,326 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + * Paul Kocialkowski + */ + +#include "config.h" + +#include +#include + +#include "igt.h" + +#define FREQS_MAX 8 + +/** + * SECTION:igt_audio + * @short_description: Library for audio-related tests + * @title: Audio + * @include: igt_audio.h + * + * This library contains helpers for audio-related tests. More specifically, + * it allows generating additions of sine signals as well as detecting them. + */ + +struct audio_signal_freq { + int freq; + + short *period; + int frames; + int offset; +}; + +struct audio_signal { + int channels; + int sampling_rate; + + struct audio_signal_freq freqs[FREQS_MAX]; + int freqs_count; +}; + +/** + * audio_signal_init: + * @channels: The number of channels to use for the signal + * @sampling_rate: The sampling rate to use for the signal + * + * Allocate and initialize an audio signal structure with the given parameters. + * + * Returns: A newly-allocated audio signal structure + */ +struct audio_signal *audio_signal_init(int channels, int sampling_rate) +{ + struct audio_signal *signal; + + signal = malloc(sizeof(struct audio_signal)); + memset(signal, 0, sizeof(struct audio_signal)); + + signal->sampling_rate = sampling_rate; + signal->channels = channels; + + return signal; +} + +/** + * audio_signal_add_frequency: + * @signal: The target signal structure + * @frequency: The frequency to add to the signal + * + * Add a frequency to the signal. + * + * Returns: An integer equal to zero for success and negative for failure + */ +int audio_signal_add_frequency(struct audio_signal *signal, int frequency) +{ + int index = signal->freqs_count; + + if (index == FREQS_MAX) + return -1; + + /* Stay within the Nyquist–Shannon sampling theorem. */ + if (frequency > signal->sampling_rate / 2) + return -1; + + /* Clip the frequency to an integer multiple of the sampling rate. +
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Beef up the IPS vs. CRC workaround (rev3)
== Series Details == Series: drm/i915: Beef up the IPS vs. CRC workaround (rev3) URL : https://patchwork.freedesktop.org/series/17084/ State : warning == Summary == Series 17084v3 drm/i915: Beef up the IPS vs. CRC workaround https://patchwork.freedesktop.org/api/1.0/series/17084/revisions/3/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-bdw-5557u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:267 dwarn:1 dfail:0 fail:0 skip:11 time:455s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:443s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:359s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:535s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:531s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:525s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:511s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:607s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:443s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:421s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:428s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:506s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:595s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:596s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:530s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:468s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:485s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:550s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:403s e1b18fbd4daecb1c1cf31ca101f64e29a8933bcf drm-tip: 2017y-08m-17d-14h-58m-23s UTC integration manifest 568266b967eb drm/i915: Beef up the IPS vs. CRC workaround == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5430/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt 2/3] igt/gem_exec_schedule: Basic tests for preemption
Quoting Michał Winiarski (2017-08-17 15:39:12) > On Thu, Aug 03, 2017 at 01:30:28PM +0100, Chris Wilson wrote: > > We queue N low priority hanging batches across the engines > > and check that out high priority write over takes them. > > s/out/our > > > > > Signed-off-by: Chris Wilson > > I'm getting stuck on throttle when spawning 10+ spin_batch instances. Which throttle? <100 spin batches and we won't be blocking on the ring. Hmm, a different of this test will create a new low-prio context for each spinner. The first variant will allow the low-prio requests to be merged together, so we should always be occupying 2 slots. Then if we add a spinner from a new context, we increase the number of slots the high prio has to bypass. The intention was to make sure that for whatever configuration of elsp we could preempt successfully. > Other than that - the tests look good, simple and quick to execute. > (cross-engine failing in my tree... but that's a good thing!) > I thought about adding different spin_batch variants rather than adding > MI_ARB_CHK by default, but I guess it shouldn't matter (and if it does, we > should notice something in other tests). I was surprised that MI_BB_START wasn't a preemption point. The only downside is that we don't have a non-preemption variant. If need be we add flags to spin_batch. There are still a few users who could be converted to spin_batch if the interface were a little more flexible - including igt_hang. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Check context status before looking up our obj/vma
Quoting Mika Kuoppala (2017-08-17 15:10:02) > Chris Wilson writes: > > > Since we keep the context around across the slow lookup where we may > > drop the struct_mutex, we should double check that the context is still > > valid upon reacquisition. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Joonas Lahtinen > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++--- > > 1 file changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > index 359d5dc6d8df..044fb1205554 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > @@ -679,13 +679,6 @@ static int eb_select_context(struct i915_execbuffer > > *eb) > > if (unlikely(!ctx)) > > return -ENOENT; > > > > - if (unlikely(i915_gem_context_is_banned(ctx))) { > > - DRM_DEBUG("Context %u tried to submit while banned\n", > > - ctx->user_handle); > > - i915_gem_context_put(ctx); > > - return -EIO; > > - } > > - > > eb->ctx = ctx; > > eb->vm = ctx->ppgtt ? &ctx->ppgtt->base : &eb->i915->ggtt.base; > > > > @@ -707,6 +700,12 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) > > int slow_pass = -1; > > int err; > > > > + if (unlikely(i915_gem_context_is_closed(eb->ctx))) > > + return -ENOENT; > > + > > + if (unlikely(i915_gem_context_is_banned(eb->ctx))) > > + return -EIO; > > + > > We are referring the lut before the context has been validated. > Not that it matters but for style, please consider assigning > the lut after the context check. ~o~ Not feeling it. If it was checking for an invalid pointer, then yes rearranging the code to avoid the appearance of the early dereference makes sense, but as it is we are just creating an alias for part of the ctx. Should look at whether gcc likes a few more locals... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] igt/gem_ringfill: Adds full ringbuffer preemption test
Quoting Antonio Argenziano (2017-08-17 16:14:04) > > > On 15/08/17 15:35, Chris Wilson wrote: > > Quoting Antonio Argenziano (2017-08-15 22:44:21) > >> Sending as RFC to get feedback on what would be the correct behaviour of > >> the driver and, therefore, if the test is valid. > > > > It's not a preemption specific bug. It is fair to say that any client > > blocking any other client over a non-contended resource is an issue. > > Skip to end for a really easy way to demonstrate this. > > Ok, I'll push a patch then. > > > > >> We do a wait while holding the mutex if we are adding a request and figure > >> out that there is no more space in the ring buffer. > >> Is that considered a bug? > > > > Yes, but it is one of many priority inversion problems we have because > > we have a BKL. Timeframe for fixing it is a few more years. > > > >> +static void wait_batch(int fd, uint32_t handle) > >> +{ > >> + int64_t timeout = 1ull * NSEC_PER_SEC; //1 sec > >> + > >> + if(gem_wait(fd, handle, &timeout) != 0) { > >> + //Force reset and fail the test > >> + igt_force_gpu_reset(fd); > > > > Just terminate the spin batches. > > > >> + igt_assert_f(0, "[0x%x] batch did not complete!", handle); > >> + } > >> +} > >> + > >> +/* > >> + * This test checks that is possible for a high priority request to > >> trigger a > >> + * preemption if another context has filled its ringbuffer. > >> + * The aim of the test is to make sure that high priority requests cannot > >> be > >> + * stalled by low priority tasks. > >> + * */ > >> +static void preempt_while_ringbuffer_full(int fd, uint32_t engine) > >> +{ > >> + uint32_t hp_ctx, lp_ctx; > >> + uint32_t hp_batch; > >> + igt_spin_t *lp_batch; > >> + > >> + struct drm_i915_gem_exec_object2 obj[2]; > >> + struct drm_i915_gem_relocation_entry reloc[1024]; > > > > That's a bit excessive for this pi test, no ? > > Just wanted to reuse the utility functions in the test with minimal changes. > > > > >> + struct drm_i915_gem_execbuffer2 execbuf; > >> + const unsigned timeout = 10; > >> + > >> + lp_ctx = gem_context_create(fd); > >> + ctx_set_priority(fd, lp_ctx, -MAX_PRIO); > >> + > >> + hp_ctx = gem_context_create(fd); > >> + ctx_set_priority(fd, hp_ctx, MAX_PRIO); > >> + > >> + igt_require(setup_execbuf(fd, &execbuf, obj, reloc, engine) == 0); > >> + execbuf.rsvd1 = lp_ctx; > >> + > >> + /*Stall execution and fill ring*/ > >> + lp_batch = igt_spin_batch_new(fd, lp_ctx, engine, 0); > >> + igt_fork(child_no, 1) { > >> + fill_ring(fd, &execbuf, 0, timeout); > >> + } > >> + > >> + /*We don't know when the ring will be full so keep sending in a > >> loop*/ > > > > Yes we do. See measure_ring_size. > > > > static void bind_to_cpu(int cpu) > > { > > const int ncpus = sysconf(_SC_NPROCESSORS_ONLN); > > struct sched_param rt = {.sched_priority = 99 }; > > cpu_set_t allowed; > > > > igt_assert(sched_setscheduler(getpid(), SCHED_RR | > > SCHED_RESET_ON_FORK, &rt) == 0); > > > > CPU_ZERO(&allowed); > > CPU_SET(cpu % ncpus, &allowed); > > igt_assert(sched_setaffinity(getpid(), sizeof(cpu_set_t), &allowed) > > == 0); > > } > > > > setup timer > > execbuf.rsvd1 = ctx_lo; > > while (__raw_gem_execbuf(fd, &execbuf) == 0) > > ; > > > > /* steal cpu */ > > bind_to_cpu(0); > > igt_fork(child, 1) { > > /* this child is forced to wait for parent to sleep */ > > execbuf.rsvd1 = ctx_hi; > > setup timer; > > *success = __raw_gem_execbuf(fd, &execbuf) == 0; > > } > > setup 2*timer > > __raw_gem_execbuf(fd, &execbuf); /* sleeps under mutex, releasing child > > */ > > > > igt_terminate_spin_batches(); > > igt_waitchildren(); > > > > igt_assert(*success); > > > > Timer can be safely 10ms. > > Isn't this a bit too complicated? Wouldn't a "keep poking at it for a > while" approach just do the same while being more readable? Be explicit and use fine control to exactly describe the behaviour you want. This case is one client exhausts their ring, it will block not only itself but all users. Please don't add this to gem_ringfill, if you consider it a scheduling / priority inversion issue, add it to gem_exec_scheduler. If you want to tackle more generally as being just one of many, many ways a client can block another client, start a new test. Considering just how general this problem is, I'd rather we tackle the problem of modelling the driver and a system to find all such contention points. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs (rev2)
== Series Details == Series: series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs (rev2) URL : https://patchwork.freedesktop.org/series/28859/ State : success == Summary == Series 28859v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/28859/revisions/2/mbox/ fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:455s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:445s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:556s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:526s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:526s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:512s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:610s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:448s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:507s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:595s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:604s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:527s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:471s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:492s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:443s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:484s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s e1b18fbd4daecb1c1cf31ca101f64e29a8933bcf drm-tip: 2017y-08m-17d-14h-58m-23s UTC integration manifest 7c0a37b11bd0 drm/i915: Mark the GT as busy before idling the previous request 0e4845519fbb drm/i915: Trivial grammar fix s/opt of/opt out of/ in comment 6928515da09d drm/i915: Replace execbuf vma ht with an idr dca8988c612a drm/i915: Simplify eb_lookup_vmas() 84ca392b85e3 drm/i915: Convert execbuf to use struct-of-array packing for critical fields a9902e0bff38 drm/i915: Check context status before looking up our obj/vma 155bcaa01da6 drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5429/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] igt/gem_ringfill: Adds full ringbuffer preemption test
On 15/08/17 15:35, Chris Wilson wrote: Quoting Antonio Argenziano (2017-08-15 22:44:21) Sending as RFC to get feedback on what would be the correct behaviour of the driver and, therefore, if the test is valid. It's not a preemption specific bug. It is fair to say that any client blocking any other client over a non-contended resource is an issue. Skip to end for a really easy way to demonstrate this. Ok, I'll push a patch then. We do a wait while holding the mutex if we are adding a request and figure out that there is no more space in the ring buffer. Is that considered a bug? Yes, but it is one of many priority inversion problems we have because we have a BKL. Timeframe for fixing it is a few more years. +static void wait_batch(int fd, uint32_t handle) +{ + int64_t timeout = 1ull * NSEC_PER_SEC; //1 sec + + if(gem_wait(fd, handle, &timeout) != 0) { + //Force reset and fail the test + igt_force_gpu_reset(fd); Just terminate the spin batches. + igt_assert_f(0, "[0x%x] batch did not complete!", handle); + } +} + +/* + * This test checks that is possible for a high priority request to trigger a + * preemption if another context has filled its ringbuffer. + * The aim of the test is to make sure that high priority requests cannot be + * stalled by low priority tasks. + * */ +static void preempt_while_ringbuffer_full(int fd, uint32_t engine) +{ + uint32_t hp_ctx, lp_ctx; + uint32_t hp_batch; + igt_spin_t *lp_batch; + + struct drm_i915_gem_exec_object2 obj[2]; + struct drm_i915_gem_relocation_entry reloc[1024]; That's a bit excessive for this pi test, no ? Just wanted to reuse the utility functions in the test with minimal changes. + struct drm_i915_gem_execbuffer2 execbuf; + const unsigned timeout = 10; + + lp_ctx = gem_context_create(fd); + ctx_set_priority(fd, lp_ctx, -MAX_PRIO); + + hp_ctx = gem_context_create(fd); + ctx_set_priority(fd, hp_ctx, MAX_PRIO); + + igt_require(setup_execbuf(fd, &execbuf, obj, reloc, engine) == 0); + execbuf.rsvd1 = lp_ctx; + + /*Stall execution and fill ring*/ + lp_batch = igt_spin_batch_new(fd, lp_ctx, engine, 0); + igt_fork(child_no, 1) { + fill_ring(fd, &execbuf, 0, timeout); + } + + /*We don't know when the ring will be full so keep sending in a loop*/ Yes we do. See measure_ring_size. static void bind_to_cpu(int cpu) { const int ncpus = sysconf(_SC_NPROCESSORS_ONLN); struct sched_param rt = {.sched_priority = 99 }; cpu_set_t allowed; igt_assert(sched_setscheduler(getpid(), SCHED_RR | SCHED_RESET_ON_FORK, &rt) == 0); CPU_ZERO(&allowed); CPU_SET(cpu % ncpus, &allowed); igt_assert(sched_setaffinity(getpid(), sizeof(cpu_set_t), &allowed) == 0); } setup timer execbuf.rsvd1 = ctx_lo; while (__raw_gem_execbuf(fd, &execbuf) == 0) ; /* steal cpu */ bind_to_cpu(0); igt_fork(child, 1) { /* this child is forced to wait for parent to sleep */ execbuf.rsvd1 = ctx_hi; setup timer; *success = __raw_gem_execbuf(fd, &execbuf) == 0; } setup 2*timer __raw_gem_execbuf(fd, &execbuf); /* sleeps under mutex, releasing child */ igt_terminate_spin_batches(); igt_waitchildren(); igt_assert(*success); Timer can be safely 10ms. Isn't this a bit too complicated? Wouldn't a "keep poking at it for a while" approach just do the same while being more readable? -Antonio Similarly: race set-domain (pretty much any GEM ioctl ends up in set-domain) vs spin-batch, when successful then try any set-domain ioctl from a second client and observe that it too is blocked on the first client hogging. end: For the purpose of testing, just create a debugfs that acquires struct_mutex on opening. Then test every ioctl and trap from a second client. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization
Hi, My bad, I forgot to modify cover-letter before sending series to intel-gfx. yes this is for upstream consideration. -Mahesh On Thursday 17 August 2017 08:10 PM, Jani Nikula wrote: On Thu, 17 Aug 2017, Mahesh Kumar wrote: This is a Trybot Version of series. What do you mean? Is this for upstream consideration or not? BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Beef up the IPS vs. CRC workaround
From: Ville Syrjälä Oneshot disabling of IPS when CRC capturing is started is insufficient. IPS may get re-enabled by any plane update, and hence tests that keep CRC capturing on across plane updates will start to see inconsistent results as soon as IPS kicks back in. Add a new knob into the crtc state to make sure IPS stays disabled as long as CRC capturing is enabled. Forcing a modeset is the easiest way to handle this since that's already how we do the panel fitter workaround. It's a little heavy handed just for IPS, but seeing as we might already do the panel fitter workaround I think it's better to follow that. We migth want to optimize both cases later if someone gets too upset by the extra delay from the modeset. v2: Check the right thing when deciding whether to force a modeset v3: Rebase, check HAS_IPS before forcing a modeset, move ips_force_disable check into pipe_config_supports_ips() Cc: Paulo Zanoni Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Marta Lofstedt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664 Reviewed-by: Paulo Zanoni Tested-by: Marta Lofsted #v2 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 7 +++- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pipe_crc.c | 62 --- 3 files changed, 36 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0e93ec201fe3..e8a24b59c91c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6263,6 +6263,9 @@ static int ironlake_fdi_compute_config(struct intel_crtc *intel_crtc, static bool pipe_config_supports_ips(struct drm_i915_private *dev_priv, struct intel_crtc_state *pipe_config) { + if (pipe_config->ips_force_disable) + return false; + if (pipe_config->pipe_bpp > 24) return false; @@ -10830,7 +10833,7 @@ clear_intel_crtc_state(struct intel_crtc_state *crtc_state) struct intel_dpll_hw_state dpll_hw_state; struct intel_shared_dpll *shared_dpll; struct intel_crtc_wm_state wm_state; - bool force_thru; + bool force_thru, ips_force_disable; /* FIXME: before the switch to atomic started, a new pipe_config was * kzalloc'd. Code that depends on any field being zero should be @@ -10841,6 +10844,7 @@ clear_intel_crtc_state(struct intel_crtc_state *crtc_state) shared_dpll = crtc_state->shared_dpll; dpll_hw_state = crtc_state->dpll_hw_state; force_thru = crtc_state->pch_pfit.force_thru; + ips_force_disable = crtc_state->ips_force_disable; if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) wm_state = crtc_state->wm; @@ -10854,6 +10858,7 @@ clear_intel_crtc_state(struct intel_crtc_state *crtc_state) crtc_state->shared_dpll = shared_dpll; crtc_state->dpll_hw_state = dpll_hw_state; crtc_state->pch_pfit.force_thru = force_thru; + crtc_state->ips_force_disable = ips_force_disable; if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) crtc_state->wm = wm_state; diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index fa47285918f4..8a9db2279bbd 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -753,6 +753,7 @@ struct intel_crtc_state { struct intel_link_m_n fdi_m_n; bool ips_enabled; + bool ips_force_disable; bool enable_fbc; diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c b/drivers/gpu/drm/i915/intel_pipe_crc.c index 8fbd2bd0877f..4e22bb927fed 100644 --- a/drivers/gpu/drm/i915/intel_pipe_crc.c +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c @@ -506,8 +506,8 @@ static int ilk_pipe_crc_ctl_reg(enum intel_pipe_crc_source *source, return 0; } -static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv, - bool enable) +static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv, + bool enable) { struct drm_device *dev = &dev_priv->drm; struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A); @@ -533,10 +533,24 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv, goto put_state; } - pipe_config->pch_pfit.force_thru = enable; - if (pipe_config->cpu_transcoder == TRANSCODER_EDP && - pipe_config->pch_pfit.enabled != enable) - pipe_config->base.connectors_changed = true; + if (HAS_IPS(dev_priv)) { + /* +* When IPS gets enabled, the pipe CRC changes. Since IPS gets +* enabled and disabled dynamically based on package C states, +* user space can't make r
Re: [Intel-gfx] [PATCH v3 RESEND] drm/i915/opregion: let user specify override VBT via firmware load
On Thu, 17 Aug 2017, Jani Nikula wrote: > Sometimes it would be most enlightening to debug systems by replacing > the VBT to be used. For example, in the referenced bug the BIOS provides > different VBT depending on the boot mode (UEFI vs. legacy). It would be > interesting to try the failing boot mode with the VBT from the working > boot, and see if that makes a difference. > > Add a module parameter to load the VBT using the firmware loader, not > unlike the EDID firmware mechanism. > > As a starting point for experimenting, one can pick up the BIOS provided > VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt. > > v2: clarify firmware load return value check (Bob) > > v3: kfree the loaded firmware blob > > References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83 > Reviewed-by: Bob Paauwe > Signed-off-by: Jani Nikula And pushed, with Daniel's additional irc ack. BR, Jani. > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_params.c| 4 > drivers/gpu/drm/i915/i915_params.h| 1 + > drivers/gpu/drm/i915/intel_opregion.c | 45 > +++ > 4 files changed, 51 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 6c25c8520c87..3ee4fd2a9b41 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -646,6 +646,7 @@ struct intel_opregion { > u32 swsci_sbcb_sub_functions; > struct opregion_asle *asle; > void *rvda; > + void *vbt_firmware; > const void *vbt; > u32 vbt_size; > u32 *lid_state; > diff --git a/drivers/gpu/drm/i915/i915_params.c > b/drivers/gpu/drm/i915/i915_params.c > index 14e2c2e57f96..8ab003dca113 100644 > --- a/drivers/gpu/drm/i915/i915_params.c > +++ b/drivers/gpu/drm/i915/i915_params.c > @@ -118,6 +118,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type, > module_param_named_unsafe(reset, i915.reset, int, 0600); > MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, > 2=engine reset [default])"); > > +module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400); > +MODULE_PARM_DESC(vbt_firmware, > + "Load VBT from specified file under /lib/firmware"); > + > #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) > module_param_named(error_capture, i915.error_capture, bool, 0600); > MODULE_PARM_DESC(error_capture, > diff --git a/drivers/gpu/drm/i915/i915_params.h > b/drivers/gpu/drm/i915/i915_params.h > index febbfdbd30bd..ac844709c97e 100644 > --- a/drivers/gpu/drm/i915/i915_params.h > +++ b/drivers/gpu/drm/i915/i915_params.h > @@ -28,6 +28,7 @@ > #include /* for __read_mostly */ > > #define I915_PARAMS_FOR_EACH(func) \ > + func(char *, vbt_firmware); \ > func(int, modeset); \ > func(int, panel_ignore_lid); \ > func(int, semaphores); \ > diff --git a/drivers/gpu/drm/i915/intel_opregion.c > b/drivers/gpu/drm/i915/intel_opregion.c > index 2bd03001cc70..98154efcb2f4 100644 > --- a/drivers/gpu/drm/i915/intel_opregion.c > +++ b/drivers/gpu/drm/i915/intel_opregion.c > @@ -27,6 +27,7 @@ > > #include > #include > +#include > #include > > #include > @@ -829,6 +830,10 @@ void intel_opregion_unregister(struct drm_i915_private > *dev_priv) > memunmap(opregion->rvda); > opregion->rvda = NULL; > } > + if (opregion->vbt_firmware) { > + kfree(opregion->vbt_firmware); > + opregion->vbt_firmware = NULL; > + } > opregion->header = NULL; > opregion->acpi = NULL; > opregion->swsci = NULL; > @@ -912,6 +917,43 @@ static const struct dmi_system_id > intel_no_opregion_vbt[] = { > { } > }; > > +static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv) > +{ > + struct intel_opregion *opregion = &dev_priv->opregion; > + const struct firmware *fw = NULL; > + const char *name = i915.vbt_firmware; > + int ret; > + > + if (!name || !*name) > + return -ENOENT; > + > + ret = request_firmware(&fw, name, &dev_priv->drm.pdev->dev); > + if (ret) { > + DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n", > + name, ret); > + return ret; > + } > + > + if (intel_bios_is_valid_vbt(fw->data, fw->size)) { > + opregion->vbt_firmware = kmemdup(fw->data, fw->size, > GFP_KERNEL); > + if (opregion->vbt_firmware) { > + DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n", > name); > + opregion->vbt = opregion->vbt_firmware; > + opregion->vbt_size = fw->size; > + ret = 0; > + } else { > + ret = -ENOMEM; > + } > + } else { > + DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name); > + ret = -EINVAL; > + } > + > + release_firmware(fw); > + > + return ret; > +} > + > int
Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Add fast-feedback-simulation.testlist
On 17/08/17 00:50, Daniel Vetter wrote: On Wed, Aug 16, 2017 at 05:30:08PM -0700, Kelvin Gardiner wrote: On 16/08/17 07:04, Daniel Vetter wrote: On Wed, Aug 16, 2017 at 11:33 AM, Petri Latvala wrote: On Tue, Jun 27, 2017 at 02:04:51PM -0700, Kelvin Gardiner wrote: Added an initial list of fast feedback tests for simulation environments. Merged, thanks. Yes I'm a bit late, just noticed this fly by: How does this interact wit igt_skip_on_simulation? What's the significance of this list, are we going to see CI run these? Have platform owners acked this as the PO list? This is a list of tests seen to be good in a simulation environment. It is meant as a starting point to have a reference list, to which we can add. seen by whom? That was pretty much my question/concern here. I chatted with Petri, and apparently this list is also used by the helsinki CI, and that should have been noted. But just today I've seen a mail fly by that e.g. Rodrigo has a power-on testlist. Which I guess is again something else, but doesn't help making things less confusing. I mean you can add whatever you want to igt and let it rot there, but if you expect platform owners, test engineers and developers to support it, we need a consensus. Otherwise it won't really happen, and this patch here looked like that consensus engineering work wasn't done (and that's really the hard work, not the patch itself). With regards to igt_skip_on_simulation, some times this is erroneously included in a test, other times it is missing, some tests need to reduce iterations etc, (where this still give a valid test) when this is set (as some already do). In short some work is needed to clean up the use of this flag. So ... who's doing that work? Or are we just going to let 2 half-solutions rot side-by-side? -Daniel We have this on our to do list. I was thinking if we create a list of tests that need attention the 2 val teams can work through the list to make the fixes. VPG validation is just one team here, imo adding something like this needs a lot more buy-in. Or we're just once again adding a list no one is actually using, which is pointless. Imo if we can't get acks from platform owners that they are actively using this list, and CI that they are also actively using this list, then it should be removed again. Thanks, Daniel -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Mark the GT as busy before idling the previous request
In a synchronous setup, we may retire the last request before we complete allocating the next request. As the last request is retired, we queue a timer to mark the device as idle, and promptly have to execute ad cancel that timer once we complete allocating the request and need to keep the device awake. If we rearrange the mark_busy() to occur before we retire the previous request, we can skip this ping-pong. v2: Joonas pointed out that unreserve_seqno() was now doing more than doing seqno handling and should be renamed to reflect its wider purpose. That also highlighted the new asymmetry with reserve_seqno(), so fixup that and rename both to [un]reserve_seqno(). Signed-off-by: Chris Wilson Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_request.c | 87 + 1 file changed, 44 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index 9eedd33eb524..5716b6d78e8e 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -244,27 +244,59 @@ int i915_gem_set_global_seqno(struct drm_device *dev, u32 seqno) return reset_all_global_seqno(dev_priv, seqno - 1); } -static int reserve_seqno(struct intel_engine_cs *engine) +static void mark_busy(struct drm_i915_private *i915) { + if (i915->gt.awake) + return; + + GEM_BUG_ON(!i915->gt.active_requests); + + intel_runtime_pm_get_noresume(i915); + i915->gt.awake = true; + + intel_enable_gt_powersave(i915); + i915_update_gfx_val(i915); + if (INTEL_GEN(i915) >= 6) + gen6_rps_busy(i915); + + queue_delayed_work(i915->wq, + &i915->gt.retire_work, + round_jiffies_up_relative(HZ)); +} + +static int reserve_engine(struct intel_engine_cs *engine) +{ + struct drm_i915_private *i915 = engine->i915; u32 active = ++engine->timeline->inflight_seqnos; u32 seqno = engine->timeline->seqno; int ret; /* Reservation is fine until we need to wrap around */ - if (likely(!add_overflows(seqno, active))) - return 0; - - ret = reset_all_global_seqno(engine->i915, 0); - if (ret) { - engine->timeline->inflight_seqnos--; - return ret; + if (unlikely(add_overflows(seqno, active))) { + ret = reset_all_global_seqno(i915, 0); + if (ret) { + engine->timeline->inflight_seqnos--; + return ret; + } } + if (!i915->gt.active_requests++) + mark_busy(i915); + return 0; } -static void unreserve_seqno(struct intel_engine_cs *engine) +static void unreserve_engine(struct intel_engine_cs *engine) { + struct drm_i915_private *i915 = engine->i915; + + if (!--i915->gt.active_requests) { + GEM_BUG_ON(!i915->gt.awake); + mod_delayed_work(i915->wq, +&i915->gt.idle_work, +msecs_to_jiffies(100)); + } + GEM_BUG_ON(!engine->timeline->inflight_seqnos); engine->timeline->inflight_seqnos--; } @@ -333,13 +365,7 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) list_del_init(&request->link); spin_unlock_irq(&engine->timeline->lock); - if (!--request->i915->gt.active_requests) { - GEM_BUG_ON(!request->i915->gt.awake); - mod_delayed_work(request->i915->wq, -&request->i915->gt.idle_work, -msecs_to_jiffies(100)); - } - unreserve_seqno(request->engine); + unreserve_engine(request->engine); advance_ring(request); free_capture_list(request); @@ -575,7 +601,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine, return ERR_CAST(ring); GEM_BUG_ON(!ring); - ret = reserve_seqno(engine); + ret = reserve_engine(engine); if (ret) goto err_unpin; @@ -681,7 +707,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine, kmem_cache_free(dev_priv->requests, req); err_unreserve: - unreserve_seqno(engine); + unreserve_engine(engine); err_unpin: engine->context_unpin(engine, ctx); return ERR_PTR(ret); @@ -863,28 +889,6 @@ i915_gem_request_await_object(struct drm_i915_gem_request *to, return ret; } -static void i915_gem_mark_busy(const struct intel_engine_cs *engine) -{ - struct drm_i915_private *dev_priv = engine->i915; - - if (dev_priv->gt.awake) - return; - - GEM_BUG_ON(!dev_priv->gt.active_requests); - - intel_runtime_pm_get_noresume(dev_priv); - dev_priv->gt.awake = true; - - intel_enable_gt_powersave(dev_priv); - i915_update_gfx_val(dev_priv); -
Re: [Intel-gfx] [PATCH igt 2/3] igt/gem_exec_schedule: Basic tests for preemption
On Thu, Aug 03, 2017 at 01:30:28PM +0100, Chris Wilson wrote: > We queue N low priority hanging batches across the engines > and check that out high priority write over takes them. s/out/our > > Signed-off-by: Chris Wilson I'm getting stuck on throttle when spawning 10+ spin_batch instances. Other than that - the tests look good, simple and quick to execute. (cross-engine failing in my tree... but that's a good thing!) I thought about adding different spin_batch variants rather than adding MI_ARB_CHK by default, but I guess it shouldn't matter (and if it does, we should notice something in other tests). Reviewed-by: Michał Winiarski Note that we still don't have preemption or API for context priority merged, so we probably should hold on with this one? -Michał ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization
On Thu, 17 Aug 2017, Mahesh Kumar wrote: > This is a Trybot Version of series. What do you mean? Is this for upstream consideration or not? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests
On Thu, Aug 17, 2017 at 07:16:03AM -0700, Jason Ekstrand wrote: > On Thu, Aug 17, 2017 at 2:56 AM, Imre Deak wrote: > > > On Thu, Aug 17, 2017 at 12:50:37PM +0300, Dan Carpenter wrote: > > > On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote: > > > > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote: > > > > > There are some potential integer overflows here on 64 bit systems. > > > > > > > > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > > > > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > > > > > check for now and look a couple lines after: > > > > > > > > > > if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) > > > > > ^^^ > > > > > "nfences" is an unsigned int, so if we set it to UINT_MAX and > > multiply > > > > > by two, it's going to have an integer overflow. > > > > > > > > AFAICS it wouldn't overflow due the promotion to unsigned long > > > > by '* sizeof(u32)'. > > > > > > > > > > It first multplies "nfences * 2" as unsigned int, then it type promotes > > > to size_t and multiplies by sizeof(). Only the first multiplication has > > > an integer overflow bug. > > > > Err, that's correct. Sorry for the noise. > > > > Why not just replace the "2 * sizeof(u32)" with a "sizeof(*user)". That's > what we really want to check. I have no idea how it ended up being "2 * > sizeof(u32)" Yeah. That's more readable. I will resend. regards, dan carpenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests
On Thu, Aug 17, 2017 at 2:56 AM, Imre Deak wrote: > On Thu, Aug 17, 2017 at 12:50:37PM +0300, Dan Carpenter wrote: > > On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote: > > > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote: > > > > There are some potential integer overflows here on 64 bit systems. > > > > > > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > > > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > > > > check for now and look a couple lines after: > > > > > > > > if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) > > > > ^^^ > > > > "nfences" is an unsigned int, so if we set it to UINT_MAX and > multiply > > > > by two, it's going to have an integer overflow. > > > > > > AFAICS it wouldn't overflow due the promotion to unsigned long > > > by '* sizeof(u32)'. > > > > > > > It first multplies "nfences * 2" as unsigned int, then it type promotes > > to size_t and multiplies by sizeof(). Only the first multiplication has > > an integer overflow bug. > > Err, that's correct. Sorry for the noise. > Why not just replace the "2 * sizeof(u32)" with a "sizeof(*user)". That's what we really want to check. I have no idea how it ended up being "2 * sizeof(u32)" --Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Check context status before looking up our obj/vma
Chris Wilson writes: > Since we keep the context around across the slow lookup where we may > drop the struct_mutex, we should double check that the context is still > valid upon reacquisition. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Joonas Lahtinen > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 359d5dc6d8df..044fb1205554 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -679,13 +679,6 @@ static int eb_select_context(struct i915_execbuffer *eb) > if (unlikely(!ctx)) > return -ENOENT; > > - if (unlikely(i915_gem_context_is_banned(ctx))) { > - DRM_DEBUG("Context %u tried to submit while banned\n", > - ctx->user_handle); > - i915_gem_context_put(ctx); > - return -EIO; > - } > - > eb->ctx = ctx; > eb->vm = ctx->ppgtt ? &ctx->ppgtt->base : &eb->i915->ggtt.base; > > @@ -707,6 +700,12 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) > int slow_pass = -1; > int err; > > + if (unlikely(i915_gem_context_is_closed(eb->ctx))) > + return -ENOENT; > + > + if (unlikely(i915_gem_context_is_banned(eb->ctx))) > + return -EIO; > + We are referring the lut before the context has been validated. Not that it matters but for style, please consider assigning the lut after the context check. Reviewed-by: Mika Kuoppala > INIT_LIST_HEAD(&eb->relocs); > INIT_LIST_HEAD(&eb->unbound); > > -- > 2.13.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote: > a long time ago I had agreed with Daniel that we would only add new > platforms after it was enabled by default on previous platforms. > a big reason for that is that we was willing to reduce the platforms > to validate and do better validation one by one before enabling. > > However now I believe it would be beneficial to have that supported > added so we can get more brave people using in different platforms so > we could capture more corner cases before we enable it by default. > Also we can still enable by default one platform at time if needed. > > So: > > Acked-by: Rodrigo Vivi > > I also checked the spec to see if there was anything else new or > different for these platforms and didn't find anything so: > > Reviewed-by: Rodrigo Vivi > > But let's wait a bit to merge to give Daniel or others a time to nack ;) A bit more testing shows that while our GLK systems work perfectly fine with PSR (and gets the expected power savings), the BXT system we tested on didn't cope quite so well. I'll have to dig into this a bit to see if there's something Broxton-related info on PSR in Bspec I missed, or if it's just our BXT-P RVP that's buggy. Kind regards, David > Cheers, > Rodrigo. > > > On Tue, Aug 8, 2017 at 3:09 AM, David Weinehall > wrote: > > While testing Jim Bride's latest batch of PSR patches I noticed > > that gen9lp doesn't include the has_psr flag, and that our GLK > > system thus reported PSR as unsupported. > > > > This patch simply adds has_psr. > > > > Signed-off-by: David Weinehall > > --- > > drivers/gpu/drm/i915/i915_pci.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c > > b/drivers/gpu/drm/i915/i915_pci.c > > index 09d97e0990b7..11f0e8aa1fe4 100644 > > --- a/drivers/gpu/drm/i915/i915_pci.c > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > @@ -377,6 +377,7 @@ static const struct intel_device_info > > intel_skylake_gt3_info = { > > .has_ddi = 1, \ > > .has_fpga_dbg = 1, \ > > .has_fbc = 1, \ > > + .has_psr = 1, \ > > .has_runtime_pm = 1, \ > > .has_pooled_eu = 0, \ > > .has_csr = 1, \ > > -- > > 2.14.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Rodrigo Vivi > Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Fixed16.16 wrapper cleanup & wm optimization (rev7)
== Series Details == Series: Fixed16.16 wrapper cleanup & wm optimization (rev7) URL : https://patchwork.freedesktop.org/series/25692/ State : warning == Summary == Series 25692v7 Fixed16.16 wrapper cleanup & wm optimization https://patchwork.freedesktop.org/api/1.0/series/25692/revisions/7/mbox/ Test kms_cursor_legacy: Subgroup basic-flip-before-cursor-legacy: pass -> DMESG-WARN (fi-glk-2a) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:453s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:433s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:549s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:516s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:525s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:514s fi-glk-2atotal:279 pass:259 dwarn:1 dfail:0 fail:0 skip:19 time:603s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:443s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:421s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:426s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:595s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:604s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:470s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:500s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:550s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest e0e32e4ac1e2 drm/i915/skl+: debugfs entry to control IPC 12f5253026e1 drm/i915/bxt+: Enable IPC support 3e79e9613276 drm/i915/gen9+: Add has_ipc flag in device info structure 410b43002f50 drm/i915/cnl: Extend WM workaround with IPC for CNL 2a11f5bc0617 drm/i915/glk: IPC linetime watermark workaround for GLK 0a852b3adca3 drm/i915/gen10: Calculate and enable transition WM cf509cd38a16 drm/i915/skl+: Optimize WM calculation 930e260ada22 drm/i915: Fixed point fixed16 wrapper cleanup == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5428/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/cnl: Extend WM workaround with IPC for CNL
From: "Kumar, Mahesh" CNL:A & CNL:B have same workaround as KBL to increase wm level latency by 4us if IPC is enabled. Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 5dcf76217f7d..aee1a387a65a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4486,7 +4486,8 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv, } /* Display WA #1141: kbl,cfl */ - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) && + if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || + IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && dev_priv->ipc_enabled) latency += 4; -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/gen9+: Add has_ipc flag in device info structure
From: "Kumar, Mahesh" New Isochronous Priority Control (IPC) capability is introduced in newer GEN platforms. This patch adds a device info flag to indicate if platform supports IPC. Patch also sets this flag in supported platforms. Signed-off-by: Mahesh Kumar Cc: Chris Wilson Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/i915_pci.c | 4 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 320da875d7e0..de79ea3e066e 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -779,7 +779,8 @@ struct intel_csr { func(cursor_needs_physical); \ func(hws_needs_physical); \ func(overlay_needs_physical); \ - func(supports_tv); + func(supports_tv); \ + func(has_ipc); struct sseu_dev_info { u8 slice_mask; @@ -3077,6 +3078,8 @@ intel_info(const struct drm_i915_private *dev_priv) #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm) #define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc) +#define HAS_IPC(dev_priv) ((dev_priv)->info.has_ipc) + /* * For now, anything with a GuC requires uCode loading, and then supports * command submission once loaded. But these are logically independent diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 09d97e0990b7..572c01924334 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -390,6 +390,7 @@ static const struct intel_device_info intel_skylake_gt3_info = { .has_full_ppgtt = 1, \ .has_full_48bit_ppgtt = 1, \ .has_reset_engine = 1, \ + .has_ipc = 1, \ GEN_DEFAULT_PIPEOFFSETS, \ IVB_CURSOR_OFFSETS, \ BDW_COLORS @@ -414,6 +415,7 @@ static const struct intel_device_info intel_geminilake_info = { .platform = INTEL_KABYLAKE, \ .has_csr = 1, \ .has_guc = 1, \ + .has_ipc = 1, \ .ddb_size = 896 static const struct intel_device_info intel_kabylake_info = { @@ -432,6 +434,7 @@ static const struct intel_device_info intel_kabylake_gt3_info = { .platform = INTEL_COFFEELAKE, \ .has_csr = 1, \ .has_guc = 1, \ + .has_ipc = 1, \ .ddb_size = 896 static const struct intel_device_info intel_coffeelake_info = { @@ -450,6 +453,7 @@ static const struct intel_device_info intel_cannonlake_info = { .gen = 10, .ddb_size = 1024, .has_csr = 1, + .has_ipc = 1, .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } }; -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915/skl+: Optimize WM calculation
From: "Kumar, Mahesh" Plane configuration parameters doesn't change for each WM-level calculation. Currently we compute same parameters 8 times for each wm-level. This patch optimizes it by calculating these parameters in beginning & reuse during each level-wm calculation. Changes since V1: - rebase on top of Rodrigo's series for CNL Signed-off-by: Mahesh Kumar Acked-by: Maarten Lankhorst Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 14 +++ drivers/gpu/drm/i915/intel_pm.c | 190 ++-- 2 files changed, 119 insertions(+), 85 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index fa5858da2ca0..320da875d7e0 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1811,6 +1811,20 @@ struct skl_wm_level { uint8_t plane_res_l; }; +/* Stores plane specific WM parameters */ +struct skl_wm_params { + bool x_tiled, y_tiled; + bool rc_surface; + uint32_t width; + uint8_t cpp; + uint32_t plane_pixel_rate; + uint32_t y_min_scanlines; + uint32_t plane_bytes_per_line; + uint_fixed_16_16_t plane_blocks_per_line; + uint_fixed_16_16_t y_tile_minimum; + uint32_t linetime_us; +}; + /* * This struct helps tracking the state needed for runtime PM, which puts the * device in PCI D3 state. Notice that when this happens, nothing on the diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ed662937ec3c..47c01da2e109 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4370,134 +4370,146 @@ skl_adjusted_plane_pixel_rate(const struct intel_crtc_state *cstate, downscale_amount); } -static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv, - struct intel_crtc_state *cstate, - const struct intel_plane_state *intel_pstate, - uint16_t ddb_allocation, - int level, - uint16_t *out_blocks, /* out */ - uint8_t *out_lines, /* out */ - bool *enabled /* out */) +static int +skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv, + struct intel_crtc_state *cstate, + const struct intel_plane_state *intel_pstate, + struct skl_wm_params *wp) { struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane); const struct drm_plane_state *pstate = &intel_pstate->base; const struct drm_framebuffer *fb = pstate->fb; - uint32_t latency = dev_priv->wm.skl_latency[level]; - uint_fixed_16_16_t method1, method2; - uint_fixed_16_16_t plane_blocks_per_line; - uint_fixed_16_16_t selected_result; uint32_t interm_pbpl; - uint32_t plane_bytes_per_line; - uint32_t res_blocks, res_lines; - uint8_t cpp; - uint32_t width = 0; - uint32_t plane_pixel_rate; - uint_fixed_16_16_t y_tile_minimum; - uint32_t y_min_scanlines; struct intel_atomic_state *state = to_intel_atomic_state(cstate->base.state); bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state); - bool y_tiled, x_tiled; - if (latency == 0 || - !intel_wm_plane_visible(cstate, intel_pstate)) { - *enabled = false; + if (!intel_wm_plane_visible(cstate, intel_pstate)) return 0; - } - y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED || - fb->modifier == I915_FORMAT_MOD_Yf_TILED || - fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS; - x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED; - - /* Display WA #1141: kbl,cfl */ - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) && - dev_priv->ipc_enabled) - latency += 4; - - if (apply_memory_bw_wa && x_tiled) - latency += 15; + wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED || + fb->modifier == I915_FORMAT_MOD_Yf_TILED || + fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || + fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS; + wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED; + wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS; if (plane->id == PLANE_CURSOR) { - width = intel_pstate->base.crtc_w; + wp->width = intel_pstate->base.crtc_w; } else { /* * Src coordinates are already rotated by 270 degrees for * the 90/270 degr
[Intel-gfx] [PATCH 4/8] drm/i915/glk: IPC linetime watermark workaround for GLK
From: "Kumar, Mahesh" IF IPC is enabled LINETIME_WM value should be half of calculated value line time = ROUNDDOWN(1/2 * Calculated Line Time) Earlier code was rounding-up the value, But updated Bspec says we should take the ROUNDDOWN. This patch corrects that as well. Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 6face465ae48..5dcf76217f7d 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4616,9 +4616,10 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate) linetime_wm = fixed16_to_u32_round_up(mul_u32_fixed16(8, linetime_us)); - /* Display WA #1135: bxt. */ - if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled) - linetime_wm = DIV_ROUND_UP(linetime_wm, 2); + /* Display WA #1135: bxt:ALL GLK:ALL */ + if ((IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv)) && + dev_priv->ipc_enabled) + linetime_wm /= 2; return linetime_wm; } -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915/skl+: debugfs entry to control IPC
From: "Kumar, Mahesh" This patch creates an entry in debugfs to check the status of IPC. This can also be used to enable/disable IPC in supported platforms. Changes since V1: - fix use of HAS_IPC - use kstrtobool_from_user (Maarten) - drm_info log, while enabling IPC (Maarten) Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_debugfs.c | 54 - 1 file changed, 53 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 329fb3649dc3..b6f38802219b 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3528,6 +3528,57 @@ static int i915_wa_registers(struct seq_file *m, void *unused) return 0; } +static int i915_ipc_status_show(struct seq_file *m, void *data) +{ + struct drm_i915_private *dev_priv = m->private; + + seq_printf(m, "Isochronous Priority Control: %s\n", + enableddisabled(dev_priv->ipc_enabled)); + return 0; +} + +static int i915_ipc_status_open(struct inode *inode, struct file *file) +{ + struct drm_i915_private *dev_priv = inode->i_private; + + if (!HAS_IPC(dev_priv)) + return -ENODEV; + + return single_open(file, i915_ipc_status_show, dev_priv); +} + +static ssize_t i915_ipc_status_write(struct file *file, const char __user *ubuf, +size_t len, loff_t *offp) +{ + struct seq_file *m = file->private_data; + struct drm_i915_private *dev_priv = m->private; + int ret; + bool enable; + + ret = kstrtobool_from_user(ubuf, len, &enable); + if (ret < 0) + return ret; + + intel_runtime_pm_get(dev_priv); + if (!dev_priv->ipc_enabled && enable) + DRM_INFO("Enabling IPC: WM will be proper only after next commit\n"); + dev_priv->wm.distrust_bios_wm = true; + dev_priv->ipc_enabled = enable; + intel_enable_ipc(dev_priv); + intel_runtime_pm_put(dev_priv); + + return len; +} + +static const struct file_operations i915_ipc_status_fops = { + .owner = THIS_MODULE, + .open = i915_ipc_status_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, + .write = i915_ipc_status_write +}; + static int i915_ddb_info(struct seq_file *m, void *unused) { struct drm_i915_private *dev_priv = node_to_i915(m->private); @@ -4864,7 +4915,8 @@ static const struct i915_debugfs_files { {"i915_dp_test_type", &i915_displayport_test_type_fops}, {"i915_dp_test_active", &i915_displayport_test_active_fops}, {"i915_guc_log_control", &i915_guc_log_control_fops}, - {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops} + {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops}, + {"i915_ipc_status", &i915_ipc_status_fops} }; int i915_debugfs_register(struct drm_i915_private *dev_priv) -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/bxt+: Enable IPC support
From: "Kumar, Mahesh" This patch adds IPC support. This patch also enables IPC in all supported platforms based on has_ipc flag. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read priority of Display. When IPC is enabled, plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower priority until dropping below the level 0 watermark. The lower priority requests allow other memory clients to have better memory access. When IPC is disabled, all plane read requests are sent at high priority. Changes since V1: - Remove commandline parameter to disable ipc - Address Paulo's comments Changes since V2: - Address review comments - Set ipc_enabled flag Changes since V3: - move ipc_enabled flag assignment inside intel_ipc_enable function Changes since V4: - Re-enable IPC after suspend/resume Changes since V5: - Enable IPC for all gen >=9 except SKL Changes since V6: - fix commit msg - after resume program IPC based on SW state. Changes since V7: - Modify IPC support check based on HAS_IPC macro (suggested by Chris) Signed-off-by: Mahesh Kumar Cc: Chris Wilson Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.c | 4 +++- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_pm.c | 24 5 files changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 43100229613c..f655973bcb26 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1340,7 +1340,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) intel_runtime_pm_enable(dev_priv); - dev_priv->ipc_enabled = false; + intel_init_ipc(dev_priv); if (IS_ENABLED(CONFIG_DRM_I915_DEBUG)) DRM_INFO("DRM_I915_DEBUG enabled\n"); @@ -2602,6 +2602,8 @@ static int intel_runtime_resume(struct device *kdev) if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) intel_hpd_init(dev_priv); + intel_enable_ipc(dev_priv); + enable_rpm_wakeref_asserts(dev_priv); if (ret) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ed7cd9ee2c2a..7240c0a3641c 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6934,6 +6934,7 @@ enum { #define DISP_FBC_WM_DIS (1<<15) #define DISP_ARB_CTL2 _MMIO(0x45004) #define DISP_DATA_PARTITION_5_6 (1<<6) +#define DISP_IPC_ENABLE (1<<3) #define DBUF_CTL _MMIO(0x45008) #define DBUF_POWER_REQUEST(1<<31) #define DBUF_POWER_STATE (1<<30) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0e93ec201fe3..e11bb3b430a2 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15164,6 +15164,7 @@ void intel_display_resume(struct drm_device *dev) if (!ret) ret = __intel_display_resume(dev, state, &ctx); + intel_enable_ipc(dev_priv); drm_modeset_drop_locks(&ctx); drm_modeset_acquire_fini(&ctx); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index fa47285918f4..a17c602319eb 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1867,6 +1867,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev); int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6); int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc, struct intel_crtc_state *cstate); +void intel_init_ipc(struct drm_i915_private *dev_priv); +void intel_enable_ipc(struct drm_i915_private *dev_priv); static inline int intel_enable_rc6(void) { return i915.enable_rc6; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index aee1a387a65a..8d7af30ed0b0 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5818,6 +5818,30 @@ void intel_update_watermarks(struct intel_crtc *crtc) dev_priv->display.update_wm(crtc); } +void intel_enable_ipc(struct drm_i915_private *dev_priv) +{ + u32 val; + + val = I915_READ(DISP_ARB_CTL2); + + if (dev_priv->ipc_enabled) + val |= DISP_IPC_ENABLE; + else + val &= ~DISP_IPC_ENABLE; + + I915_WRITE(DISP_ARB_CTL2, val); +} + +void intel_init_ipc(struct drm_i915_private *dev_priv) +{ + dev_priv->ipc_enabled = false; + if (!HAS_IPC(dev_priv)) + return; + + dev_priv->ipc_enabled = true; + intel_enable_ipc(dev_priv); +} + /* * Lock protecting IPS related data structures */ -- 2.13.0
[Intel-gfx] [PATCH 3/8] drm/i915/gen10: Calculate and enable transition WM
From: "Kumar, Mahesh" GEN > 9 require transition WM to be programmed if IPC is enabled. This patch calculates & enable transition WM for supported platforms. If transition WM is enabled, Plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower priority until dropping below the level-0 WM. The lower priority requests allow other memory clients to have better memory access. transition minimum is the minimum amount needed for trans_wm to work to ensure the demote does not happen before enough data has been read to meet the level 0 watermark requirements. transition amount is configurable value. Higher values will tend to cause longer periods of high priority reads followed by longer periods of lower priority reads. Tuning to lower values will tend to cause shorter periods of high and lower priority reads. Keeping transition amount to 10 in this patch, as suggested by HW team. Changes since V1: - Address review comments from Maarten Signed-off-by: Mahesh Kumar Acked-by: Maarten Lankhorst Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 52 +++-- 1 file changed, 50 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 47c01da2e109..6face465ae48 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4624,12 +4624,56 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate) } static void skl_compute_transition_wm(struct intel_crtc_state *cstate, + struct skl_wm_params *wp, + struct skl_wm_level *wm_l0, + uint16_t ddb_allocation, struct skl_wm_level *trans_wm /* out */) { + struct drm_device *dev = cstate->base.crtc->dev; + const struct drm_i915_private *dev_priv = to_i915(dev); + uint16_t trans_min, trans_y_tile_min; + const uint16_t trans_amount = 10; /* This is configurable amount */ + uint16_t trans_offset_b, res_blocks; + if (!cstate->base.active) + goto exit; + + /* Transition WM are not recommended by HW team for GEN9 */ + if (INTEL_GEN(dev_priv) <= 9) + goto exit; + + /* Transition WM don't make any sense if ipc is disabled */ + if (!dev_priv->ipc_enabled) + goto exit; + + if (INTEL_GEN(dev_priv) >= 10) + trans_min = 4; + + trans_offset_b = trans_min + trans_amount; + + if (wp->y_tiled) { + trans_y_tile_min = (uint16_t) mul_round_up_u32_fixed16(2, + wp->y_tile_minimum); + res_blocks = max(wm_l0->plane_res_b, trans_y_tile_min) + + trans_offset_b; + } else { + res_blocks = wm_l0->plane_res_b + trans_offset_b; + + /* WA BUG:1938466 add one block for non y-tile planes */ + if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0)) + res_blocks += 1; + + } + + res_blocks += 1; + + if (res_blocks < ddb_allocation) { + trans_wm->plane_res_b = res_blocks; + trans_wm->plane_en = true; return; + } - /* Until we know more, just disable transition WMs */ +exit: trans_wm->plane_en = false; } @@ -4656,8 +4700,11 @@ static int skl_build_pipe_wm(struct intel_crtc_state *cstate, to_intel_plane_state(pstate); enum plane_id plane_id = to_intel_plane(plane)->id; struct skl_wm_params wm_params; + enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe; + uint16_t ddb_blocks; wm = &pipe_wm->planes[plane_id]; + ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][plane_id]); memset(&wm_params, 0, sizeof(struct skl_wm_params)); ret = skl_compute_plane_wm_params(dev_priv, cstate, @@ -4669,7 +4716,8 @@ static int skl_build_pipe_wm(struct intel_crtc_state *cstate, intel_pstate, &wm_params, wm); if (ret) return ret; - skl_compute_transition_wm(cstate, &wm->trans_wm); + skl_compute_transition_wm(cstate, &wm_params, &wm->wm[0], + ddb_blocks, &wm->trans_wm); } pipe_wm->linetime = skl_compute_linetime_wm(cstate); -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] Fixed16.16 wrapper cleanup & wm optimization
This is a Trybot Version of series. This series Include patches for: clean fixed16.16 wrappers optimize wm calculation code enable/Implement trans wm calculation create a DebugFS entry for IPC status Kumar, Mahesh (8): drm/i915: Fixed point fixed16 wrapper cleanup drm/i915/skl+: Optimize WM calculation drm/i915/gen10: Calculate and enable transition WM drm/i915/glk: IPC linetime watermark workaround for GLK drm/i915/cnl: Extend WM workaround with IPC for CNL drm/i915/gen9+: Add has_ipc flag in device info structure drm/i915/bxt+: Enable IPC support drm/i915/skl+: debugfs entry to control IPC drivers/gpu/drm/i915/i915_debugfs.c | 54 ++- drivers/gpu/drm/i915/i915_drv.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 33 - drivers/gpu/drm/i915/i915_pci.c | 4 + drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 274 +++ 8 files changed, 273 insertions(+), 100 deletions(-) -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Fixed point fixed16 wrapper cleanup
From: "Kumar, Mahesh" As per suggestion from Jani, cleanup the code. Cleanup includes - Instead of left shifting & check, compare with U32/16_MAX - Use typecast instead of clamp_t Signed-off-by: Mahesh Kumar Cc: Jani Nikula Reviewed-by: Jani Nikula Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 6c25c8520c87..fa5858da2ca0 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -126,7 +126,7 @@ static inline uint_fixed_16_16_t u32_to_fixed16(uint32_t val) { uint_fixed_16_16_t fp; - WARN_ON(val >> 16); + WARN_ON(val > U16_MAX); fp.val = val << 16; return fp; @@ -163,8 +163,8 @@ static inline uint_fixed_16_16_t max_fixed16(uint_fixed_16_16_t max1, static inline uint_fixed_16_16_t clamp_u64_to_fixed16(uint64_t val) { uint_fixed_16_16_t fp; - WARN_ON(val >> 32); - fp.val = clamp_t(uint32_t, val, 0, ~0); + WARN_ON(val > U32_MAX); + fp.val = (uint32_t) val; return fp; } @@ -181,8 +181,8 @@ static inline uint32_t mul_round_up_u32_fixed16(uint32_t val, intermediate_val = (uint64_t) val * mul.val; intermediate_val = DIV_ROUND_UP_ULL(intermediate_val, 1 << 16); - WARN_ON(intermediate_val >> 32); - return clamp_t(uint32_t, intermediate_val, 0, ~0); + WARN_ON(intermediate_val > U32_MAX); + return (uint32_t) intermediate_val; } static inline uint_fixed_16_16_t mul_fixed16(uint_fixed_16_16_t val, @@ -211,8 +211,8 @@ static inline uint32_t div_round_up_u32_fixed16(uint32_t val, interm_val = (uint64_t)val << 16; interm_val = DIV_ROUND_UP_ULL(interm_val, d.val); - WARN_ON(interm_val >> 32); - return clamp_t(uint32_t, interm_val, 0, ~0); + WARN_ON(interm_val > U32_MAX); + return (uint32_t) interm_val; } static inline uint_fixed_16_16_t mul_u32_fixed16(uint32_t val, -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Trivial grammar fix s/opt of/opt out of/ in comment
On Wed, 2017-08-16 at 09:52 +0100, Chris Wilson wrote: > The word out was dropped from the sentence across the line break, put it > back. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Mark the GT as busy before idling the previous request
On Wed, 2017-08-16 at 09:52 +0100, Chris Wilson wrote: > In a synchronous setup, we may retire the last request before we > complete allocating the next request. As the last request is retired, we > queue a timer to mark the device as idle, and promptly have to execute > ad cancel that timer once we complete allocating the request and need to > keep the device awake. If we rearrange the mark_busy() to occur before > we retire the previous request, we can skip this ping-pong. > > Signed-off-by: Chris Wilson > +++ b/drivers/gpu/drm/i915/i915_gem_request.c > @@ -265,6 +265,13 @@ static int reserve_seqno(struct intel_engine_cs *engine) > > static void unreserve_seqno(struct intel_engine_cs *engine) > { > + if (!--engine->i915->gt.active_requests) { > + GEM_BUG_ON(!engine->i915->gt.awake); > + mod_delayed_work(engine->i915->wq, > + &engine->i915->gt.idle_work, > + msecs_to_jiffies(100)); > + } This function could use a better name, now it seems to tightly tie to seqno only, and idle work is very unexpected. How about just unreserve_engine vs. reserve_engine? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Boost GPU clocks if we miss the pageflip's vblank
== Series Details == Series: drm/i915: Boost GPU clocks if we miss the pageflip's vblank URL : https://patchwork.freedesktop.org/series/28921/ State : failure == Summary == Series 28921v1 drm/i915: Boost GPU clocks if we miss the pageflip's vblank https://patchwork.freedesktop.org/api/1.0/series/28921/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-skl-6260u) fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:456s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:361s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:548s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:524s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:524s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:608s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:446s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:422s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:422s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:511s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:596s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:596s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:532s fi-skl-6260u total:237 pass:229 dwarn:0 dfail:0 fail:0 skip:7 fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:483s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:484s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:551s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:411s ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest 87e8bf68f70d drm/i915: Boost GPU clocks if we miss the pageflip's vblank == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5427/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Avoid old DDI translation functions on Cannonlake.
On Thu, 2017-07-06 at 13:54 -0700, Rodrigo Vivi wrote: > Cannonlake uses a different swing voltage initalization > sequence scheme that doesn't require these old functions. > > All other DDI, voltage swing and PLLs initialialization > and configuration are already in place for Cannonlake. > This patch only removes unecessary steps probably saving > us from some useless warnings. > > Cc: Clint Taylor > Cc: Mika Kahola > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_ddi.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 80e96f1..9e9bfbe 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -596,7 +596,7 @@ static int intel_ddi_hdmi_level(struct > drm_i915_private *dev_priv, enum port por > > hdmi_level = dev_priv- > >vbt.ddi_port_info[port].hdmi_level_shift; > > - if (IS_GEN9_LP(dev_priv)) > + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) Can we assume that this holds always for GEN10 and above platforms? > return hdmi_level; > > if (IS_GEN9_BC(dev_priv)) { > @@ -688,7 +688,7 @@ static void intel_prepare_dp_ddi_buffers(struct > intel_encoder *encoder) > enum port port = intel_ddi_get_encoder_port(encoder); > const struct ddi_buf_trans *ddi_translations; > > - if (IS_GEN9_LP(dev_priv)) > + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) > return; > > switch (encoder->type) { > @@ -741,7 +741,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct > intel_encoder *encoder) > enum port port = intel_ddi_get_encoder_port(encoder); > const struct ddi_buf_trans *ddi_translations_hdmi; > > - if (IS_GEN9_LP(dev_priv)) > + if (IS_GEN9_LP(dev_priv) || INTEL_GEN(dev_priv) >= 10) > return; > > hdmi_level = intel_ddi_hdmi_level(dev_priv, port); -- Mika Kahola - Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank
If we miss the current vblank because the gpu was busy, that may cause a jitter as the frame rate temporarily drops. We try to limit the impact of this by then boosting the GPU clock to deliver the frame as quickly as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU frequency if we detect outstanding pageflips") but was never forward ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915: Rip out legacy page_flip completion/irq handling"). References: https://bugs.freedesktop.org/show_bug.cgi?id=102199 Signed-off-by: Chris Wilson Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 59 drivers/gpu/drm/i915/intel_drv.h | 1 - drivers/gpu/drm/i915/intel_pm.c | 42 ++--- 3 files changed, 62 insertions(+), 40 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0e93ec201fe3..7d5b19553637 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12636,6 +12636,55 @@ static const struct drm_crtc_funcs intel_crtc_funcs = { .set_crc_source = intel_crtc_set_crc_source, }; +struct wait_rps_boost { + struct wait_queue_entry wait; + + struct drm_crtc *crtc; + struct drm_i915_gem_request *request; +}; + +static int do_rps_boost(struct wait_queue_entry *_wait, + unsigned mode, int sync, void *key) +{ + struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait); + struct drm_i915_gem_request *rq = wait->request; + + gen6_rps_boost(rq, NULL); + i915_gem_request_put(rq); + + drm_crtc_vblank_put(wait->crtc); + + list_del(&wait->wait.entry); + kfree(wait); + return 1; +} + +static void add_rps_boost_after_vblank(struct drm_crtc *crtc, + struct dma_fence *fence) +{ + struct wait_rps_boost *wait; + + if (!dma_fence_is_i915(fence)) + return; + + if (drm_crtc_vblank_get(crtc)) + return; + + wait = kmalloc(sizeof(*wait), GFP_KERNEL); + if (!wait) { + drm_crtc_vblank_put(crtc); + return; + } + + wait->request = to_request(dma_fence_get(fence)); + wait->crtc = crtc; + + wait->wait.func = do_rps_boost; + wait->wait.flags = 0; + + add_wait_queue(drm_crtc_vblank_waitqueue(crtc), &wait->wait); +} + /** * intel_prepare_plane_fb - Prepare fb for usage on plane * @plane: drm plane to prepare for @@ -12733,12 +12782,22 @@ intel_prepare_plane_fb(struct drm_plane *plane, return ret; if (!new_state->fence) { /* implicit fencing */ + struct dma_fence *fence; + ret = i915_sw_fence_await_reservation(&intel_state->commit_ready, obj->resv, NULL, false, I915_FENCE_TIMEOUT, GFP_KERNEL); if (ret < 0) return ret; + + fence = reservation_object_get_excl_rcu(obj->resv); + if (fence) { + add_rps_boost_after_vblank(new_state->crtc, fence); + dma_fence_put(fence); + } + } else { + add_rps_boost_after_vblank(new_state->crtc, new_state->fence); } return 0; diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index fa47285918f4..e092354b4d63 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1844,7 +1844,6 @@ void gen6_rps_reset_ei(struct drm_i915_private *dev_priv); void gen6_rps_idle(struct drm_i915_private *dev_priv); void gen6_rps_boost(struct drm_i915_gem_request *rq, struct intel_rps_client *rps); -void intel_queue_rps_boost_for_request(struct drm_i915_gem_request *req); void g4x_wm_get_hw_state(struct drm_device *dev); void vlv_wm_get_hw_state(struct drm_device *dev); void ilk_wm_get_hw_state(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ed662937ec3c..c9fa2eb1903c 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6169,6 +6169,7 @@ void gen6_rps_boost(struct drm_i915_gem_request *rq, struct intel_rps_client *rps) { struct drm_i915_private *i915 = rq->i915; + unsigned long flags; bool boost; /* This is intentionally racy! We peek at the state here, then @@ -6178,13 +6179,13 @@ void gen6_rps_boost(struct drm_i915_gem_request *rq, return; boost = false; - spin_lock_irq(&rq->lock); + spin_lock_irqsave(&rq->lock, flags); if (!rq->waitboost && !i915_gem_request_completed(rq)) {
Re: [Intel-gfx] [PATCH v2] drm/i915: Beef up the IPS vs. CRC workaround
On Thu, Aug 17, 2017 at 03:16:46PM +0300, Ville Syrjälä wrote: > On Thu, Aug 17, 2017 at 10:00:52AM +0200, Maarten Lankhorst wrote: > > Op 16-08-17 om 16:39 schreef ville.syrj...@linux.intel.com: > > > From: Ville Syrjälä > > > > > > Oneshot disabling of IPS when CRC capturing is started is insufficient. > > > IPS may get re-enabled by any plane update, and hence tests that keep > > > CRC capturing on across plane updates will start to see inconsistent > > > results as soon as IPS kicks back in. Add a new knob into the crtc state > > > to make sure IPS stays disabled as long as CRC capturing is enabled. > > > > > > Forcing a modeset is the easiest way to handle this since that's already > > > how we do the panel fitter workaround. It's a little heavy handed just > > > for IPS, but seeing as we might already do the panel fitter workaround > > > I think it's better to follow that. We migth want to optimize both cases > > > later if someone gets too upset by the extra delay from the modeset. > > > > > > v2: Check the right thing when deciding whether to force a modeset > > > > > > Cc: Paulo Zanoni > > > Cc: Daniel Vetter > > > Cc: Maarten Lankhorst > > > Cc: Marta Lofstedt > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664 > > > Reviewed-by: Paulo Zanoni > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 5 +++- > > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > > drivers/gpu/drm/i915/intel_pipe_crc.c | 43 > > > +++ > > > 3 files changed, 28 insertions(+), 21 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index ef5dde5ab1cf..1ce479614f52 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -7189,6 +7189,7 @@ static void hsw_compute_ips_config(struct > > > intel_crtc *crtc, > > > struct drm_i915_private *dev_priv = to_i915(dev); > > > > > > pipe_config->ips_enabled = i915.enable_ips && > > > + !pipe_config->ips_force_disable && > > > hsw_crtc_supports_ips(crtc) && > > > pipe_config_supports_ips(dev_priv, pipe_config); > > > } > > > @@ -12958,7 +12959,7 @@ clear_intel_crtc_state(struct intel_crtc_state > > > *crtc_state) > > > struct intel_crtc_scaler_state scaler_state; > > > struct intel_dpll_hw_state dpll_hw_state; > > > struct intel_shared_dpll *shared_dpll; > > > - bool force_thru; > > > + bool force_thru, ips_force_disable; > > > > > > /* FIXME: before the switch to atomic started, a new pipe_config was > > >* kzalloc'd. Code that depends on any field being zero should be > > > @@ -12970,6 +12971,7 @@ clear_intel_crtc_state(struct intel_crtc_state > > > *crtc_state) > > > shared_dpll = crtc_state->shared_dpll; > > > dpll_hw_state = crtc_state->dpll_hw_state; > > > force_thru = crtc_state->pch_pfit.force_thru; > > > + ips_force_disable = crtc_state->ips_force_disable; > > > > > > memset(crtc_state, 0, sizeof *crtc_state); > > > > > > @@ -12978,6 +12980,7 @@ clear_intel_crtc_state(struct intel_crtc_state > > > *crtc_state) > > > crtc_state->shared_dpll = shared_dpll; > > > crtc_state->dpll_hw_state = dpll_hw_state; > > > crtc_state->pch_pfit.force_thru = force_thru; > > > + crtc_state->ips_force_disable = ips_force_disable; > > > } > > > > > > static int > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > > b/drivers/gpu/drm/i915/intel_drv.h > > > index 025e4c8b3e63..cadba9b92cc9 100644 > > > --- a/drivers/gpu/drm/i915/intel_drv.h > > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > > @@ -651,6 +651,7 @@ struct intel_crtc_state { > > > struct intel_link_m_n fdi_m_n; > > > > > > bool ips_enabled; > > > + bool ips_force_disable; > > Could we rename this to collecting_crc throughout the patch? > > If we do, then we should probably kill off the separate pfit > force_thru boolean as well and just use 'collecting_crc' for > the pipe A routing decisions as well. On further thought that name would be somewhat misleading if we only set it for HSW/BDW+pipe A. > > > > > And as Marta noted, intel_crtc_set_crc_source also needs fixing. :) > > Doh. I thought I retipped the patch, but apparently I didn't. > > > > > > > bool enable_fbc; > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c > > > index ef0c0e195164..74780b090d1e 100644 > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c > > > @@ -547,8 +547,8 @@ static int ilk_pipe_crc_ctl_reg(enum > > > intel_pipe_crc_source *source, > > > return 0; > > > } > > > > > > -static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private > > > *dev_priv, > > > - bool enable) > > > +static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv, > > > + bool enable) > > > { > > >
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()
On Mon, Aug 14, 2017 at 09:58:32PM +0200, Hans de Goede wrote: > intel_uncore_forcewake_reset() does forcewake puts and gets as such > we need to make sure that no-one tries to access the PUNIT->PMIC bus > (on systems where this bus is shared) while it runs, otherwise bad > things happen. > > Normally this is taken care of by the i915_pmic_bus_access_notifier() > which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other > driver tries to access the PMIC bus, so that later forcewake gets are > no-ops (for the duration of the bus access). > > But intel_uncore_forcewake_reset gets called in 3 cases: > 1) Before registering the pmic_bus_access_notifier > 2) After unregistering the pmic_bus_access_notifier > 3) To reset forcewake state on a GPU reset > > In all 3 cases the i915_pmic_bus_access_notifier() protection is > insufficient. > > This commit fixes this race by calling iosf_mbi_punit_acquire() before > calling intel_uncore_forcewake_reset(). In the case where it is called > directly after unregistering the pmic_bus_access_notifier, we need to > hold the punit-lock over both calls to avoid a race where > intel_uncore_fw_release_timer() may execute between the 2 calls. > > To allow holding the lock over both calls we need an unlocked > variant of iosf_mbi_unregister_pmic_bus_access_notifier. Since > intel_uncore.c is the only user of this function, we simply > modify it in this commit. Doing this in a separate commit would > require first adding an unlocked variant, then this commit and > then removing the unused normal variant. > > Signed-off-by: Hans de Goede > --- > Changes in v2: > -Rebase on current (July 6th 2017) drm-next > > Changes in v3: > -Keep punit acquired / locked over the unregister + forcewake_reset > call combo to avoid a race hitting between the 2 calls > -This requires modifying iosf_mbi_unregister_pmic_bus_access_notifier > to not take the lock itself, since we are the only users this is done > in this same commit > --- > arch/x86/include/asm/iosf_mbi.h | 10 -- > arch/x86/platform/intel/iosf_mbi.c | 14 +- > drivers/gpu/drm/i915/intel_uncore.c | 17 + > 3 files changed, 26 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h > index c313cac36f56..f8841bb06d98 100644 > --- a/arch/x86/include/asm/iosf_mbi.h > +++ b/arch/x86/include/asm/iosf_mbi.h > @@ -141,9 +141,14 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct > notifier_block *nb); > /** > * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus notifier You missed the rename in the doc. > * > + * Note the caller must call iosf_mbi_punit_acquire() before calling this > + * to ensure the bus is inactive before unregistering (and call > + * iosf_mbi_punit_release() afterwards). > + * > * @nb: notifier_block to unregister > */ > -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb); > +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked( > + struct notifier_block *nb); > > /** > * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier > chain > @@ -191,7 +196,8 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct > notifier_block *nb) > } > > static inline > -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb) > +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked( > + struct notifier_block *nb) > { > return 0; > } > diff --git a/arch/x86/platform/intel/iosf_mbi.c > b/arch/x86/platform/intel/iosf_mbi.c > index a952ac199741..5596a3ec1b89 100644 > --- a/arch/x86/platform/intel/iosf_mbi.c > +++ b/arch/x86/platform/intel/iosf_mbi.c > @@ -218,19 +218,15 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct > notifier_block *nb) > } > EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier); > > -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb) > +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked( > + struct notifier_block *nb) > { > - int ret; > + WARN_ON(!mutex_is_locked(&iosf_mbi_punit_mutex)); > > - /* Wait for the bus to go inactive before unregistering */ > - mutex_lock(&iosf_mbi_punit_mutex); > - ret = blocking_notifier_chain_unregister( > + return blocking_notifier_chain_unregister( > &iosf_mbi_pmic_bus_access_notifier, nb); > - mutex_unlock(&iosf_mbi_punit_mutex); > - > - return ret; > } > -EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier); > +EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier_unlocked); > > int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v) > { > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index 569d115918eb..7be6150520ed 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -229,6 +229,7 @@ intel_uncor
Re: [Intel-gfx] [PATCH v2] drm/i915: Beef up the IPS vs. CRC workaround
On Thu, Aug 17, 2017 at 10:00:52AM +0200, Maarten Lankhorst wrote: > Op 16-08-17 om 16:39 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > Oneshot disabling of IPS when CRC capturing is started is insufficient. > > IPS may get re-enabled by any plane update, and hence tests that keep > > CRC capturing on across plane updates will start to see inconsistent > > results as soon as IPS kicks back in. Add a new knob into the crtc state > > to make sure IPS stays disabled as long as CRC capturing is enabled. > > > > Forcing a modeset is the easiest way to handle this since that's already > > how we do the panel fitter workaround. It's a little heavy handed just > > for IPS, but seeing as we might already do the panel fitter workaround > > I think it's better to follow that. We migth want to optimize both cases > > later if someone gets too upset by the extra delay from the modeset. > > > > v2: Check the right thing when deciding whether to force a modeset > > > > Cc: Paulo Zanoni > > Cc: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Marta Lofstedt > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101664 > > Reviewed-by: Paulo Zanoni > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_display.c | 5 +++- > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > drivers/gpu/drm/i915/intel_pipe_crc.c | 43 > > +++ > > 3 files changed, 28 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index ef5dde5ab1cf..1ce479614f52 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -7189,6 +7189,7 @@ static void hsw_compute_ips_config(struct intel_crtc > > *crtc, > > struct drm_i915_private *dev_priv = to_i915(dev); > > > > pipe_config->ips_enabled = i915.enable_ips && > > + !pipe_config->ips_force_disable && > > hsw_crtc_supports_ips(crtc) && > > pipe_config_supports_ips(dev_priv, pipe_config); > > } > > @@ -12958,7 +12959,7 @@ clear_intel_crtc_state(struct intel_crtc_state > > *crtc_state) > > struct intel_crtc_scaler_state scaler_state; > > struct intel_dpll_hw_state dpll_hw_state; > > struct intel_shared_dpll *shared_dpll; > > - bool force_thru; > > + bool force_thru, ips_force_disable; > > > > /* FIXME: before the switch to atomic started, a new pipe_config was > > * kzalloc'd. Code that depends on any field being zero should be > > @@ -12970,6 +12971,7 @@ clear_intel_crtc_state(struct intel_crtc_state > > *crtc_state) > > shared_dpll = crtc_state->shared_dpll; > > dpll_hw_state = crtc_state->dpll_hw_state; > > force_thru = crtc_state->pch_pfit.force_thru; > > + ips_force_disable = crtc_state->ips_force_disable; > > > > memset(crtc_state, 0, sizeof *crtc_state); > > > > @@ -12978,6 +12980,7 @@ clear_intel_crtc_state(struct intel_crtc_state > > *crtc_state) > > crtc_state->shared_dpll = shared_dpll; > > crtc_state->dpll_hw_state = dpll_hw_state; > > crtc_state->pch_pfit.force_thru = force_thru; > > + crtc_state->ips_force_disable = ips_force_disable; > > } > > > > static int > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > b/drivers/gpu/drm/i915/intel_drv.h > > index 025e4c8b3e63..cadba9b92cc9 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -651,6 +651,7 @@ struct intel_crtc_state { > > struct intel_link_m_n fdi_m_n; > > > > bool ips_enabled; > > + bool ips_force_disable; > Could we rename this to collecting_crc throughout the patch? If we do, then we should probably kill off the separate pfit force_thru boolean as well and just use 'collecting_crc' for the pipe A routing decisions as well. > > And as Marta noted, intel_crtc_set_crc_source also needs fixing. :) Doh. I thought I retipped the patch, but apparently I didn't. > > > > bool enable_fbc; > > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c > > b/drivers/gpu/drm/i915/intel_pipe_crc.c > > index ef0c0e195164..74780b090d1e 100644 > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c > > @@ -547,8 +547,8 @@ static int ilk_pipe_crc_ctl_reg(enum > > intel_pipe_crc_source *source, > > return 0; > > } > > > > -static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv, > > - bool enable) > > +static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv, > > + bool enable) > > { > > struct drm_device *dev = &dev_priv->drm; > > struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A); > > @@ -570,11 +570,23 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct > > drm_i915_private *dev_priv, > > goto out; > > } > > > > - pipe_config->pch_pfit.force_thru = enable; > > - if (pipe_co
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/opregion: let user specify override VBT via firmware load (rev2)
== Series Details == Series: drm/i915/opregion: let user specify override VBT via firmware load (rev2) URL : https://patchwork.freedesktop.org/series/25105/ State : success == Summary == Series 25105v2 drm/i915/opregion: let user specify override VBT via firmware load https://patchwork.freedesktop.org/api/1.0/series/25105/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:451s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:441s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:552s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:524s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:525s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:519s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:609s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:444s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:506s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:595s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:599s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:527s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:470s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:488s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:515s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:404s ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest e3823ff65946 drm/i915/opregion: let user specify override VBT via firmware load == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5426/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 RESEND] drm/i915/opregion: let user specify override VBT via firmware load
Sometimes it would be most enlightening to debug systems by replacing the VBT to be used. For example, in the referenced bug the BIOS provides different VBT depending on the boot mode (UEFI vs. legacy). It would be interesting to try the failing boot mode with the VBT from the working boot, and see if that makes a difference. Add a module parameter to load the VBT using the firmware loader, not unlike the EDID firmware mechanism. As a starting point for experimenting, one can pick up the BIOS provided VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt. v2: clarify firmware load return value check (Bob) v3: kfree the loaded firmware blob References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83 Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_params.c| 4 drivers/gpu/drm/i915/i915_params.h| 1 + drivers/gpu/drm/i915/intel_opregion.c | 45 +++ 4 files changed, 51 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 6c25c8520c87..3ee4fd2a9b41 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -646,6 +646,7 @@ struct intel_opregion { u32 swsci_sbcb_sub_functions; struct opregion_asle *asle; void *rvda; + void *vbt_firmware; const void *vbt; u32 vbt_size; u32 *lid_state; diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 14e2c2e57f96..8ab003dca113 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -118,6 +118,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type, module_param_named_unsafe(reset, i915.reset, int, 0600); MODULE_PARM_DESC(reset, "Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default])"); +module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400); +MODULE_PARM_DESC(vbt_firmware, +"Load VBT from specified file under /lib/firmware"); + #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) module_param_named(error_capture, i915.error_capture, bool, 0600); MODULE_PARM_DESC(error_capture, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index febbfdbd30bd..ac844709c97e 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -28,6 +28,7 @@ #include /* for __read_mostly */ #define I915_PARAMS_FOR_EACH(func) \ + func(char *, vbt_firmware); \ func(int, modeset); \ func(int, panel_ignore_lid); \ func(int, semaphores); \ diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 2bd03001cc70..98154efcb2f4 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -27,6 +27,7 @@ #include #include +#include #include #include @@ -829,6 +830,10 @@ void intel_opregion_unregister(struct drm_i915_private *dev_priv) memunmap(opregion->rvda); opregion->rvda = NULL; } + if (opregion->vbt_firmware) { + kfree(opregion->vbt_firmware); + opregion->vbt_firmware = NULL; + } opregion->header = NULL; opregion->acpi = NULL; opregion->swsci = NULL; @@ -912,6 +917,43 @@ static const struct dmi_system_id intel_no_opregion_vbt[] = { { } }; +static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv) +{ + struct intel_opregion *opregion = &dev_priv->opregion; + const struct firmware *fw = NULL; + const char *name = i915.vbt_firmware; + int ret; + + if (!name || !*name) + return -ENOENT; + + ret = request_firmware(&fw, name, &dev_priv->drm.pdev->dev); + if (ret) { + DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n", + name, ret); + return ret; + } + + if (intel_bios_is_valid_vbt(fw->data, fw->size)) { + opregion->vbt_firmware = kmemdup(fw->data, fw->size, GFP_KERNEL); + if (opregion->vbt_firmware) { + DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n", name); + opregion->vbt = opregion->vbt_firmware; + opregion->vbt_size = fw->size; + ret = 0; + } else { + ret = -ENOMEM; + } + } else { + DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name); + ret = -EINVAL; + } + + release_firmware(fw); + + return ret; +} + int intel_opregion_setup(struct drm_i915_private *dev_priv) { struct intel_opregion *opregion = &dev_priv->opregion; @@ -974,6 +1016,9 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv) if (mboxes & MBOX_ASLE_EXT) DRM_DEBUG_DRIVER
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: use NULL for GPIO connection ID (rev2)
== Series Details == Series: drm/i915/bxt: use NULL for GPIO connection ID (rev2) URL : https://patchwork.freedesktop.org/series/20011/ State : success == Summary == Series 20011v2 drm/i915/bxt: use NULL for GPIO connection ID https://patchwork.freedesktop.org/api/1.0/series/20011/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:454s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:452s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:364s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:552s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:524s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:531s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:518s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:617s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:426s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:511s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:596s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:595s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:478s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:493s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:489s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:548s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:409s ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest 9920a7e829ce drm/i915/bxt: use NULL for GPIO connection ID == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5425/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: use NULL for GPIO connection ID
Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01) Tested-by: Mika Kahola On Thu, 2017-08-17 at 13:55 +0300, Andy Shevchenko wrote: > The commit 213e08ad60ba > ("drm/i915/bxt: add bxt dsi gpio element support") > enables GPIO support for Broxton based platforms. > > While using that API we might get into troubles in the future, > because > we can't rely on label name in the driver since vendor firmware might > provide any GPIO pin there, e.g. "reset", and even mark it in _DSD > (in > which case the request will fail). > > To avoid inconsistency and potential issues we have two options: > a) generate GPIO ACPI mapping table and supply it via > acpi_dev_add_driver_gpios(), or > b) just pass NULL as connection ID. > > The b) approach is much simpler and would work since the driver > relies > on GPIO indices only. Moreover, the _CRS fallback mechanism, when > requesting GPIO, has been made stricter, and supplying non-NULL > connection ID when neither _DSD, nor GPIO ACPI mapping is present, is > making request fail. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921 > Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO > lookups") > Cc: Mika Kahola > Cc: Jani Nikula > Signed-off-by: Andy Shevchenko > --- > v2: > - adjust commit message for proper time tenses > - add Fixes: and Bugzilla: tags > drivers/gpu/drm/i915/intel_dsi_vbt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c > b/drivers/gpu/drm/i915/intel_dsi_vbt.c > index 7158c7ce9c09..91c07b0c8db9 100644 > --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c > +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c > @@ -306,7 +306,7 @@ static void bxt_exec_gpio(struct drm_i915_private > *dev_priv, > > if (!gpio_desc) { > gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev, > - "panel", > gpio_index, > + NULL, gpio_index, > value ? > GPIOD_OUT_LOW : > GPIOD_OUT_HIGH); > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix integer overflow tests (rev3)
== Series Details == Series: drm/i915: Fix integer overflow tests (rev3) URL : https://patchwork.freedesktop.org/series/28898/ State : success == Summary == Series 28898v3 drm/i915: Fix integer overflow tests https://patchwork.freedesktop.org/api/1.0/series/28898/revisions/3/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:449s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:434s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:362s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:545s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:521s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:523s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:514s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:607s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:444s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:422s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:424s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:483s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:590s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:599s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:528s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:475s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:483s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:486s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:407s ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest 777232c3b82a drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5424/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/bxt: use NULL for GPIO connection ID
The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element support") enables GPIO support for Broxton based platforms. While using that API we might get into troubles in the future, because we can't rely on label name in the driver since vendor firmware might provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in which case the request will fail). To avoid inconsistency and potential issues we have two options: a) generate GPIO ACPI mapping table and supply it via acpi_dev_add_driver_gpios(), or b) just pass NULL as connection ID. The b) approach is much simpler and would work since the driver relies on GPIO indices only. Moreover, the _CRS fallback mechanism, when requesting GPIO, has been made stricter, and supplying non-NULL connection ID when neither _DSD, nor GPIO ACPI mapping is present, is making request fail. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921 Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") Cc: Mika Kahola Cc: Jani Nikula Signed-off-by: Andy Shevchenko --- v2: - adjust commit message for proper time tenses - add Fixes: and Bugzilla: tags drivers/gpu/drm/i915/intel_dsi_vbt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c b/drivers/gpu/drm/i915/intel_dsi_vbt.c index 7158c7ce9c09..91c07b0c8db9 100644 --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c @@ -306,7 +306,7 @@ static void bxt_exec_gpio(struct drm_i915_private *dev_priv, if (!gpio_desc) { gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev, -"panel", gpio_index, +NULL, gpio_index, value ? GPIOD_OUT_LOW : GPIOD_OUT_HIGH); -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects
We check whether the multiplies will overflow prior to calling kmalloc_array so that we can respond with -EINVAL for the invalid user arguments rather than treating it as an -ENOMEM that would otherwise occur. However, as Dan Carpenter pointed out, we did an addition on the unsigned int prior to passing to kmalloc_array where it would be promoted to size_t for the calculation, thereby allowing it to overflow and underallocate. v2: buffer_count is currently limited to INT_MAX because we treat it as signaled variable for LUT_HANDLE in eb_lookup_vma Reported-by: Dan Carpenter Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 33 -- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8e8bc7aefd9c..b1cfbe3ae959 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -2143,7 +2143,7 @@ static struct drm_syncobj ** get_fence_array(struct drm_i915_gem_execbuffer2 *args, struct drm_file *file) { - const unsigned int nfences = args->num_cliprects; + const size_t nfences = args->num_cliprects; struct drm_i915_gem_exec_fence __user *user; struct drm_syncobj **fences; unsigned int n; @@ -2152,14 +2152,14 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args, if (!(args->flags & I915_EXEC_FENCE_ARRAY)) return NULL; - if (nfences > SIZE_MAX / sizeof(*fences)) + if (nfences > SIZE_MAX / max(sizeof(*fences), 2*sizeof(u32))) return ERR_PTR(-EINVAL); user = u64_to_user_ptr(args->cliprects_ptr); if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) return ERR_PTR(-EFAULT); - fences = kvmalloc_array(args->num_cliprects, sizeof(*fences), + fences = kvmalloc_array(nfences, sizeof(*fences), __GFP_NOWARN | GFP_TEMPORARY); if (!fences) return ERR_PTR(-ENOMEM); @@ -2517,11 +2517,13 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, struct drm_i915_gem_execbuffer2 exec2; struct drm_i915_gem_exec_object *exec_list = NULL; struct drm_i915_gem_exec_object2 *exec2_list = NULL; + const size_t count = args->buffer_count; unsigned int i; int err; - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) { - DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count); + /* Lookups via HANDLE_LUT are limited to INT_MAX (see eb_create()) */ + if (count < 1 || count > INT_MAX || count > SIZE_MAX / sz - 1) { + DRM_DEBUG("execbuf2 with %zd buffers\n", count); return -EINVAL; } @@ -2540,9 +2542,9 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, return -EINVAL; /* Copy in the exec list from userland */ - exec_list = kvmalloc_array(args->buffer_count, sizeof(*exec_list), + exec_list = kvmalloc_array(count, sizeof(*exec_list), __GFP_NOWARN | GFP_TEMPORARY); - exec2_list = kvmalloc_array(args->buffer_count + 1, sz, + exec2_list = kvmalloc_array(count + 1, sz, __GFP_NOWARN | GFP_TEMPORARY); if (exec_list == NULL || exec2_list == NULL) { DRM_DEBUG("Failed to allocate exec list for %d buffers\n", @@ -2553,7 +2555,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, } err = copy_from_user(exec_list, u64_to_user_ptr(args->buffers_ptr), -sizeof(*exec_list) * args->buffer_count); +sizeof(*exec_list) * count); if (err) { DRM_DEBUG("copy %d exec entries failed %d\n", args->buffer_count, err); @@ -2607,10 +2609,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data, struct drm_i915_gem_execbuffer2 *args = data; struct drm_i915_gem_exec_object2 *exec2_list; struct drm_syncobj **fences = NULL; + const size_t count = args->buffer_count; int err; - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) { - DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count); + if (count < 1 || count > SIZE_MAX / sz - 1) { + DRM_DEBUG("execbuf2 with %zd buffers\n", count); return -EINVAL; } @@ -2618,17 +2621,17 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data, return -EINVAL; /* Allocate an extra slot for use by the command parser */ - exec2_list = kvmalloc_array(args->buffer_count + 1, sz, + exec2_list = kvmalloc_array(count + 1, sz, __GFP_NOWARN | GFP_TEMPORARY); if (exec2_lis
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix integer overflow tests (rev2)
== Series Details == Series: drm/i915: Fix integer overflow tests (rev2) URL : https://patchwork.freedesktop.org/series/28898/ State : success == Summary == Series 28898v2 drm/i915: Fix integer overflow tests https://patchwork.freedesktop.org/api/1.0/series/28898/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:460s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:442s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:563s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:519s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:524s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:513s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:609s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:443s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:427s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:598s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:597s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:538s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:492s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:440s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:480s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:412s ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s UTC integration manifest bdc340d1c6e8 drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5423/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects
We check whether the multiplies will overflow prior to calling kmalloc_array so that we can respond with -EINVAL for the invalid user arguments rather than treating it as an -ENOMEM that would otherwise occur. However, as Dan Carpenter pointed out, we did an addition on the unsigned int prior to passing to kmalloc_array where it would be promoted to size_t for the calculation, thereby allowing it to overflow and underallocate. Reported-by: Dan Carpenter Signed-off-by: Chris Wilson --- I want to keep that check for reporting an attempted overflow as -EINVAL so we can keep distinguishing rogue parameters from the excessively large allocations. So we just need to do the promotion ourselves, right? -Chris --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8e8bc7aefd9c..2d69af40ab68 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -2143,7 +2143,7 @@ static struct drm_syncobj ** get_fence_array(struct drm_i915_gem_execbuffer2 *args, struct drm_file *file) { - const unsigned int nfences = args->num_cliprects; + const size_t nfences = args->num_cliprects; struct drm_i915_gem_exec_fence __user *user; struct drm_syncobj **fences; unsigned int n; @@ -2152,14 +2152,14 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args, if (!(args->flags & I915_EXEC_FENCE_ARRAY)) return NULL; - if (nfences > SIZE_MAX / sizeof(*fences)) + if (nfences > SIZE_MAX / max(sizeof(*fences), 2*sizeof(u32))) return ERR_PTR(-EINVAL); user = u64_to_user_ptr(args->cliprects_ptr); if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) return ERR_PTR(-EFAULT); - fences = kvmalloc_array(args->num_cliprects, sizeof(*fences), + fences = kvmalloc_array(nfences, sizeof(*fences), __GFP_NOWARN | GFP_TEMPORARY); if (!fences) return ERR_PTR(-ENOMEM); @@ -2517,10 +2517,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, struct drm_i915_gem_execbuffer2 exec2; struct drm_i915_gem_exec_object *exec_list = NULL; struct drm_i915_gem_exec_object2 *exec2_list = NULL; + const size_t count = args->buffer_count; unsigned int i; int err; - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) { + if (count < 1 || count > SIZE_MAX / sz - 1) { DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count); return -EINVAL; } @@ -2540,9 +2541,9 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, return -EINVAL; /* Copy in the exec list from userland */ - exec_list = kvmalloc_array(args->buffer_count, sizeof(*exec_list), + exec_list = kvmalloc_array(count, sizeof(*exec_list), __GFP_NOWARN | GFP_TEMPORARY); - exec2_list = kvmalloc_array(args->buffer_count + 1, sz, + exec2_list = kvmalloc_array(count + 1, sz, __GFP_NOWARN | GFP_TEMPORARY); if (exec_list == NULL || exec2_list == NULL) { DRM_DEBUG("Failed to allocate exec list for %d buffers\n", @@ -2553,7 +2554,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, } err = copy_from_user(exec_list, u64_to_user_ptr(args->buffers_ptr), -sizeof(*exec_list) * args->buffer_count); +sizeof(*exec_list) * count); if (err) { DRM_DEBUG("copy %d exec entries failed %d\n", args->buffer_count, err); @@ -2607,10 +2608,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data, struct drm_i915_gem_execbuffer2 *args = data; struct drm_i915_gem_exec_object2 *exec2_list; struct drm_syncobj **fences = NULL; + const size_t count = args->buffer_count; int err; - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) { - DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count); + if (count < 1 || count > SIZE_MAX / sz - 1) { + DRM_DEBUG("execbuf2 with %zd buffers\n", count); return -EINVAL; } @@ -2618,17 +2620,17 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data, return -EINVAL; /* Allocate an extra slot for use by the command parser */ - exec2_list = kvmalloc_array(args->buffer_count + 1, sz, + exec2_list = kvmalloc_array(count + 1, sz, __GFP_NOWARN | GFP_TEMPORARY); if (exec2_list == NULL) { - DRM_DEBUG("Failed to allocate e
Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests
On Thu, Aug 17, 2017 at 12:50:37PM +0300, Dan Carpenter wrote: > On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote: > > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote: > > > There are some potential integer overflows here on 64 bit systems. > > > > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > > > check for now and look a couple lines after: > > > > > > if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) > > > ^^^ > > > "nfences" is an unsigned int, so if we set it to UINT_MAX and multiply > > > by two, it's going to have an integer overflow. > > > > AFAICS it wouldn't overflow due the promotion to unsigned long > > by '* sizeof(u32)'. > > > > It first multplies "nfences * 2" as unsigned int, then it type promotes > to size_t and multiplies by sizeof(). Only the first multiplication has > an integer overflow bug. Err, that's correct. Sorry for the noise. > > regards, > dan carpenter > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests
On Thu, Aug 17, 2017 at 12:37:00PM +0300, Imre Deak wrote: > On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote: > > There are some potential integer overflows here on 64 bit systems. > > > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > > check for now and look a couple lines after: > > > > if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) > > ^^^ > > "nfences" is an unsigned int, so if we set it to UINT_MAX and multiply > > by two, it's going to have an integer overflow. > > AFAICS it wouldn't overflow due the promotion to unsigned long > by '* sizeof(u32)'. > It first multplies "nfences * 2" as unsigned int, then it type promotes to size_t and multiplies by sizeof(). Only the first multiplication has an integer overflow bug. regards, dan carpenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch net-next 0/3] net/sched: Improve getting objects by indexes
Am 16.08.2017 um 04:12 schrieb Chris Mi: Using current TC code, it is very slow to insert a lot of rules. In order to improve the rules update rate in TC, we introduced the following two changes: 1) changed cls_flower to use IDR to manage the filters. 2) changed all act_xxx modules to use IDR instead of a small hash table But IDR has a limitation that it uses int. TC handle uses u32. To make sure there is no regression, we also changed IDR to use unsigned long. All clients of IDR are changed to use new IDR API. WOW, wait a second. The idr change is touching a lot of drivers and to be honest doesn't looks correct at all. Just look at the first chunk of your modification: @@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct device *parent, mutex_lock(&bsg_mutex); - ret = idr_alloc(&bsg_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL); - if (ret < 0) { + ret = idr_alloc(&bsg_minor_idr, bcd, &idr_index, 0, BSG_MAX_DEVS, + GFP_KERNEL); + if (ret) { if (ret == -ENOSPC) { printk(KERN_ERR "bsg: too many bsg devices\n"); ret = -EINVAL; The condition "if (ret)" will now always be true after the first allocation and so we always run into the error handling after that. I've never read the bsg code before, but that's certainly not correct. And that incorrect pattern repeats over and over again in this code. Apart from that why the heck do you want to allocate more than 1<<31 handles? Regards, Christian. Chris Mi (3): idr: Use unsigned long instead of int net/sched: Change cls_flower to use IDR net/sched: Change act_api and act_xxx modules to use IDR block/bsg.c | 8 +- block/genhd.c | 12 +- drivers/atm/nicstar.c | 11 +- drivers/block/drbd/drbd_main.c | 31 +-- drivers/block/drbd/drbd_nl.c| 22 ++- drivers/block/drbd/drbd_proc.c | 3 +- drivers/block/drbd/drbd_receiver.c | 15 +- drivers/block/drbd/drbd_state.c | 34 ++-- drivers/block/drbd/drbd_worker.c| 6 +- drivers/block/loop.c| 17 +- drivers/block/nbd.c | 20 +- drivers/block/zram/zram_drv.c | 9 +- drivers/char/tpm/tpm-chip.c | 10 +- drivers/char/tpm/tpm.h | 2 +- drivers/dca/dca-sysfs.c | 9 +- drivers/firewire/core-cdev.c| 18 +- drivers/firewire/core-device.c | 15 +- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- drivers/gpu/drm/drm_auth.c | 9 +- drivers/gpu/drm/drm_connector.c | 10 +- drivers/gpu/drm/drm_context.c | 20 +- drivers/gpu/drm/drm_dp_aux_dev.c| 11 +- drivers/gpu/drm/drm_drv.c | 6 +- drivers/gpu/drm/drm_gem.c | 19 +- drivers/gpu/drm/drm_info.c | 2 +- drivers/gpu/drm/drm_mode_object.c | 11 +- drivers/gpu/drm/drm_syncobj.c | 18 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 25 ++- drivers/gpu/drm/i915/gvt/display.c | 2 +- drivers/gpu/drm/i915/gvt/kvmgt.c| 2 +- drivers/gpu/drm/i915/gvt/vgpu.c | 9 +- drivers/gpu/drm/i915/i915_debugfs.c | 6 +- drivers/gpu/drm/i915/i915_gem_context.c | 9 +- drivers/gpu/drm/qxl/qxl_cmd.c | 8 +- drivers/gpu/drm/qxl/qxl_release.c | 14 +- drivers/gpu/drm/sis/sis_mm.c| 8 +- drivers/gpu/drm/tegra/drm.c | 10 +- drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c| 3 +- drivers/gpu/drm/vgem/vgem_fence.c | 12 +- drivers/gpu/drm/via/via_mm.c| 8 +- drivers/gpu/drm/virtio/virtgpu_kms.c| 5 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 5 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 9 +- drivers/i2c/i2c-core-base.c | 19 +- drivers/infiniband/core/cm.c| 8 +- drivers/infiniband/core/cma.c | 12 +- drivers/infiniband/core/rdma_core.c | 9 +- drivers/infiniband/core/sa_query.c | 23 +-- drivers/infiniband/core/ucm.c | 7 +- drivers/infiniband/core/ucma.c | 14 +- drivers/infiniband/hw/cxgb3/iwch.c | 4 +- drivers/infiniband/hw/cxgb3/iwch.h
Re: [Intel-gfx] [patch net-next 0/3] net/sched: Improve getting objects by indexes
Quoting Christian König (2017-08-16 08:49:07) > Am 16.08.2017 um 04:12 schrieb Chris Mi: > > Using current TC code, it is very slow to insert a lot of rules. > > > > In order to improve the rules update rate in TC, > > we introduced the following two changes: > > 1) changed cls_flower to use IDR to manage the filters. > > 2) changed all act_xxx modules to use IDR instead of > > a small hash table > > > > But IDR has a limitation that it uses int. TC handle uses u32. > > To make sure there is no regression, we also changed IDR to use > > unsigned long. All clients of IDR are changed to use new IDR API. > > WOW, wait a second. The idr change is touching a lot of drivers and to > be honest doesn't looks correct at all. > > Just look at the first chunk of your modification: > > @@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct > > device *parent, > > > > mutex_lock(&bsg_mutex); > > > > - ret = idr_alloc(&bsg_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL); > > - if (ret < 0) { > > + ret = idr_alloc(&bsg_minor_idr, bcd, &idr_index, 0, BSG_MAX_DEVS, > > + GFP_KERNEL); > > + if (ret) { > > if (ret == -ENOSPC) { > > printk(KERN_ERR "bsg: too many bsg devices\n"); > > ret = -EINVAL; > The condition "if (ret)" will now always be true after the first > allocation and so we always run into the error handling after that. ret is now purely the error code, so it doesn't look that suspicious. > I've never read the bsg code before, but that's certainly not correct. > And that incorrect pattern repeats over and over again in this code. > > Apart from that why the heck do you want to allocate more than 1<<31 > handles? And more to the point, arbitrarily changing the maximum to ULONG_MAX where the ABI only supports U32_MAX is dangerous. Unless you do the analysis otherwise, you have to replace all the end=0 with end=INT_MAX to maintain existing behaviour. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
On Wed, 16 Aug 2017, Manasi Navare wrote: > In case of eDP because the panel has a fixed mode we cannot > link train fallback and prune modes since this results in > no modes available for eDP connector. > Also since its a panel, link training should not fail dynamically > based on cable conditions like in case of DP. > > Cc: Jani Nikula > Cc: Jim Bride > Cc: Ville Syrjälä > Cc: Daniel Vetter > Signed-off-by: Manasi Navare > --- > drivers/gpu/drm/i915/intel_dp.c | 2 +- > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++- > drivers/gpu/drm/i915/intel_drv.h | 1 + > 3 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 4fd4853..edac0c8 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000, 27, > 54 }; > * If a CPU or PCH DP output is attached to an eDP panel, this function > * will return true, and false otherwise. > */ > -static bool is_edp(struct intel_dp *intel_dp) > +bool is_edp(struct intel_dp *intel_dp) Make that intel_dp_is_edp when you expose it outside of intel_dp.c BR, Jani > { > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > b/drivers/gpu/drm/i915/intel_dp_link_training.c > index 05907fa..18ec61f 100644 > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp) > intel_connector->base.base.id, > intel_connector->base.name, > intel_dp->link_rate, intel_dp->lane_count); > - if (!intel_dp_get_link_train_fallback_values(intel_dp, > + /* Dont fallback and prune modes if its eDP */ > + if (!is_edp(intel_dp) && > !intel_dp_get_link_train_fallback_values(intel_dp, >intel_dp->link_rate, >intel_dp->lane_count)) > /* Schedule a Hotplug Uevent to userspace to start modeset */ > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index fa47285..9800a15 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1548,6 +1548,7 @@ static inline unsigned int > intel_dp_unused_lane_mask(int lane_count) > } > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp); > +bool is_edp(struct intel_dp *intel_dp); > int intel_dp_link_required(int pixel_clock, int bpp); > int intel_dp_max_data_rate(int max_link_clock, int max_lanes); > bool intel_digital_port_connected(struct drm_i915_private *dev_priv, -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tools/intel_vbt_decode: Fix decoding of child device structure
On Wed, 16 Aug 2017, Clint Taylor wrote: > This patch fixes the alignment. I spotted another issue with teh > structure and will fix it once this one is merged. I'm sure there are plenty of issues; patches welcome! BR, Jani. > > Reviewed-by: Clint Taylor > Tested-by: Clint Taylor > > > On 08/16/2017 07:20 AM, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> Fix decoding of the start of the child device structure. I had >> accidentally duplicated the "device class/type" member and forgot to >> include the add-in offset later. Fortunately both were two byte fields >> so they effectively cancelled each other out and thus the remainder of >> the child device structure was being decoded correctly. But of course >> anything sitting between these two fieds was being decoded incorrectly. >> >> Fixes: 86a546f6f798 ("tools/intel_bios_reader: Dump out more information >> from the child device structure") >> Signed-off-by: Ville Syrjälä >> --- >> tools/intel_bios.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/intel_bios.h b/tools/intel_bios.h >> index ca0d2c587120..f2ccb55ab6c3 100644 >> --- a/tools/intel_bios.h >> +++ b/tools/intel_bios.h >> @@ -273,7 +273,6 @@ struct child_device_config { >> struct efp_child_device_config { >> uint16_t handle; >> uint16_t device_type; >> -uint16_t device_class; >> uint8_t i2c_speed; >> uint8_t dp_onboard_redriver; /* 158 */ >> uint8_t dp_ondock_redriver; /* 158 */ >> @@ -289,6 +288,7 @@ struct efp_child_device_config { >> uint8_t skip1:4; >> uint8_t slave_port; /* 202 */ >> uint8_t skip2; >> +uint16_t addin_offset; >> uint8_t port; >> uint8_t i2c_pin; /* for add-in card */ >> uint8_t slave_addr; /* for add-in card */ > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix integer overflow tests
On Thu, Aug 17, 2017 at 09:23:10AM +0300, Dan Carpenter wrote: > There are some potential integer overflows here on 64 bit systems. > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > check for now and look a couple lines after: > > if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32))) > ^^^ > "nfences" is an unsigned int, so if we set it to UINT_MAX and multiply > by two, it's going to have an integer overflow. AFAICS it wouldn't overflow due the promotion to unsigned long by '* sizeof(u32)'. > The "args->buffer_count" > is also an unsigned int so it could overflow if it's set to UINT_MAX > when we do: > > exec2_list = kvmalloc_array(args->buffer_count + 1, sz, > ^^ Yes, this could overflow. > Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the > execobjects array") > Signed-off-by: Dan Carpenter > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 15ab3e6792f9..f569721aad1a 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -2152,7 +2152,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args, > if (!(args->flags & I915_EXEC_FENCE_ARRAY)) > return NULL; > > - if (nfences > SIZE_MAX / sizeof(*fences)) > + if (nfences > UINT_MAX / sizeof(*fences)) > return ERR_PTR(-EINVAL); > > user = u64_to_user_ptr(args->cliprects_ptr); > @@ -2520,7 +2520,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data, > unsigned int i; > int err; > > - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) { > + if (args->buffer_count < 1 || args->buffer_count > UINT_MAX / sz - 1) { > DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count); > return -EINVAL; > } > @@ -2609,7 +2609,7 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data, > struct drm_syncobj **fences = NULL; > int err; > > - if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) { > + if (args->buffer_count < 1 || args->buffer_count > UINT_MAX / sz - 1) { > DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count); > return -EINVAL; > } > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH 1/2] dim: Accept .mbox and .patch files as apply-branch optional argument.
On Thu, Aug 17, 2017 at 10:12 AM, Jani Nikula wrote: > On Thu, 17 Aug 2017, Daniel Vetter wrote: >> One thing we maybe could be doing is a more fancy aliasing feature, along >> the lines of git aliases, where you can do whatever you want. Then you >> could do a dim apply-curl alias which resolves to curl $arg | dim apply. >> Not sure how to implement that though ... > > We *already* have a fancy aliasing feature. You can add arbitrary > subcommands of your own, and you can override existing subcommands. Try > this in your ~/.dimrc: > > dim_my_fancy_list_aliases() > { > echo "Hello world!" > dim_list_aliases > } > > dim_alias_list_aliases=my-fancy-list-aliases > > This first part will give you a new "dim my-fancy-list-aliases" > subcommand, and the second part will use it for "dim list-aliases". > > Go wild. ;) Maybe we just need to document this better? Rodrigo, you're up for a patch to dim.rst, with the above example in a new ALIASES sections? I'd put it right above ENVIRONMENT. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH 1/2] dim: Accept .mbox and .patch files as apply-branch optional argument.
On Thu, 17 Aug 2017, Daniel Vetter wrote: > One thing we maybe could be doing is a more fancy aliasing feature, along > the lines of git aliases, where you can do whatever you want. Then you > could do a dim apply-curl alias which resolves to curl $arg | dim apply. > Not sure how to implement that though ... We *already* have a fancy aliasing feature. You can add arbitrary subcommands of your own, and you can override existing subcommands. Try this in your ~/.dimrc: dim_my_fancy_list_aliases() { echo "Hello world!" dim_list_aliases } dim_alias_list_aliases=my-fancy-list-aliases This first part will give you a new "dim my-fancy-list-aliases" subcommand, and the second part will use it for "dim list-aliases". Go wild. ;) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx