Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function
On Wed, 26 Aug 2015, Sivakumar Thulasimani
wrote:
> On 8/20/2015 1:17 PM, Jani Nikula wrote:
>> Add a common intel_digital_port_connected() that splits out to functions
>> for different platforms. No functional changes.
>>
>> v2: make the function return a boolean
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 41
>> ++---
>> 1 file changed, 22 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index f08859471841..f947951a01d4 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
>> return status;
>> }
>>
>> -/*
>> - * ibx_digital_port_connected - is the specified port connected?
>> - * @dev_priv: i915 private structure
>> - * @port: the port to test
>> - *
>> - * Returns true if @port is connected, false otherwise.
>> - */
>> static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
>> struct intel_digital_port *port)
>> {
>> @@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct
>> drm_i915_private *dev_priv,
>> return I915_READ(SDEISR) & bit;
>> }
>>
>> -static bool g4x_digital_port_connected(struct drm_device *dev,
>> +static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
>> struct intel_digital_port *port)
>> {
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>> uint32_t bit;
>>
>> -if (IS_VALLEYVIEW(dev)) {
>> +if (IS_VALLEYVIEW(dev_priv)) {
> this might not work :(. just noted this as part of another review.
> please fix this since
> it is merged.
Sorry, what might not work?
Jani.
>> switch (port->port) {
>> case PORT_B:
>> bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
>> @@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct
>> drm_device *dev,
>> return I915_READ(PORT_HOTPLUG_STAT) & bit;
>> }
>>
>> +/*
>> + * intel_digital_port_connected - is the specified port connected?
>> + * @dev_priv: i915 private structure
>> + * @port: the port to test
>> + *
>> + * Return %true if @port is connected, %false otherwise.
>> + */
>> +static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>> + struct intel_digital_port *port)
>> +{
>> +if (HAS_PCH_SPLIT(dev_priv))
>> +return ibx_digital_port_connected(dev_priv, port);
>> +else
>> +return g4x_digital_port_connected(dev_priv, port);
>> +}
>> +
>> static enum drm_connector_status
>> ironlake_dp_detect(struct intel_dp *intel_dp)
>> {
>> @@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>>
>> -if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
>> +if (!intel_digital_port_connected(dev_priv, intel_dig_port))
>> return connector_status_disconnected;
>>
>> return intel_dp_detect_dpcd(intel_dp);
>> @@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
>> return status;
>> }
>>
>> -if (!g4x_digital_port_connected(dev, intel_dig_port))
>> +if (!intel_digital_port_connected(dev->dev_private, intel_dig_port))
>> return connector_status_disconnected;
>>
>> return intel_dp_detect_dpcd(intel_dp);
>> @@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
>> *intel_dig_port, bool long_hpd)
>> /* indicate that we need to restart link training */
>> intel_dp->train_set_valid = false;
>>
>> -if (HAS_PCH_SPLIT(dev)) {
>> -if (!ibx_digital_port_connected(dev_priv,
>> intel_dig_port))
>> -goto mst_fail;
>> -} else {
>> -if (!g4x_digital_port_connected(dev, intel_dig_port))
>> -goto mst_fail;
>> -}
>> +if (!intel_digital_port_connected(dev_priv, intel_dig_port))
>> +goto mst_fail;
>>
>> if (!intel_dp_get_dpcd(intel_dp)) {
>> goto mst_fail;
>
> --
> regards,
> Sivakumar
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/2] drm/i915: Factor out intel_crtc_has_encoders()
On Wed, 26 Aug 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the code mode readable by pulling the "does this crtc have any
> encoders?" deduction into a separate function.
>
> Cc: Maarten Lankhorst
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9e92915..ac2c2f1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14855,13 +14855,22 @@ intel_check_plane_mapping(struct intel_crtc *crtc)
> return true;
> }
>
> +static bool intel_crtc_has_encoders(struct intel_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct intel_encoder *encoder;
> +
> + for_each_encoder_on_crtc(dev, &crtc->base, encoder)
> + return true;
> +
> + return false;
> +}
> +
> static void intel_sanitize_crtc(struct intel_crtc *crtc)
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_encoder *encoder;
> u32 reg;
> - bool enable;
>
> /* Clear any frame start delays used for debugging left by the BIOS */
> reg = PIPECONF(crtc->config->cpu_transcoder);
> @@ -14905,16 +14914,11 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc)
>
> /* Adjust the state of the output pipe according to whether we
>* have active connectors/encoders. */
> - enable = false;
> - for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
> - enable = true;
> - break;
> - }
> -
> - if (!enable)
> + if (!intel_crtc_has_encoders(crtc))
> intel_crtc_disable_noatomic(&crtc->base);
>
> if (crtc->active != crtc->base.state->active) {
> + struct intel_encoder *encoder;
>
> /* This can happen either due to bugs in the get_hw_state
>* functions or because of calls to intel_crtc_disable_noatomic,
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Introduce spt_irq_handler()
On Thu, 27 Aug 2015, Paulo Zanoni wrote:
> 2015-08-12 12:44 GMT-03:00 :
>> From: Ville Syrjälä
>>
>> Starting from SPT the only interrupts living in the south are GMBUS and
>> HPD. What's worse some of the SPT specific new bits conflict with some
>> other bits on earlier PCH generations. So better not use the
>> cpt_irq_handler() for SPT+ anymore.
>>
>> Also kill the hand rolled port E handling with something more
>> standardish. This also avoids accidentally confusing port B and port E
>> long pulses since the bits occupy the same positions, just in different
>> registers.
>>
>> Also add a comment noting that the short pulse duration bits are
>> reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the
>> MBZ in the spec.
>>
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 123
>> +++-
>> 1 file changed, 83 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index d12106c..e2485bd 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1260,6 +1260,16 @@ static bool bxt_port_hotplug_long_detect(enum port
>> port, u32 val)
>> }
>> }
>>
>> +static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
>> +{
>> + switch (port) {
>> + case PORT_E:
>> + return val & PORTE_HOTPLUG_LONG_DETECT;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> static bool pch_port_hotplug_long_detect(enum port port, u32 val)
>> {
>> switch (port) {
>> @@ -1269,8 +1279,6 @@ static bool pch_port_hotplug_long_detect(enum port
>> port, u32 val)
>> return val & PORTC_HOTPLUG_LONG_DETECT;
>> case PORT_D:
>> return val & PORTD_HOTPLUG_LONG_DETECT;
>> - case PORT_E:
>> - return val & PORTE_HOTPLUG_LONG_DETECT;
>> default:
>> return false;
>> }
>> @@ -1771,12 +1779,7 @@ static void cpt_irq_handler(struct drm_device *dev,
>> u32 pch_iir)
>> {
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> int pipe;
>> - u32 hotplug_trigger;
>> -
>> - if (HAS_PCH_SPT(dev))
>> - hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT;
>> - else
>> - hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
>> + u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
>>
>> if (hotplug_trigger) {
>> u32 dig_hotplug_reg, pin_mask, long_mask;
>> @@ -1784,22 +1787,10 @@ static void cpt_irq_handler(struct drm_device *dev,
>> u32 pch_iir)
>> dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
>> I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
>>
>> - if (HAS_PCH_SPT(dev)) {
>> - intel_get_hpd_pins(&pin_mask, &long_mask,
>> - hotplug_trigger,
>> - dig_hotplug_reg, hpd_spt,
>> - pch_port_hotplug_long_detect);
>> -
>> - /* detect PORTE HP event */
>> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
>> - if (pch_port_hotplug_long_detect(PORT_E,
>> -dig_hotplug_reg))
>> - long_mask |= 1 << HPD_PORT_E;
>> - } else
>> - intel_get_hpd_pins(&pin_mask, &long_mask,
>> - hotplug_trigger,
>> - dig_hotplug_reg, hpd_cpt,
>> - pch_port_hotplug_long_detect);
>> + intel_get_hpd_pins(&pin_mask, &long_mask,
>> + hotplug_trigger,
>> + dig_hotplug_reg, hpd_cpt,
>> + pch_port_hotplug_long_detect);
>>
>> intel_hpd_irq_handler(dev, pin_mask, long_mask);
>> }
>> @@ -1833,6 +1824,42 @@ static void cpt_irq_handler(struct drm_device *dev,
>> u32 pch_iir)
>> cpt_serr_int_handler(dev);
>> }
>>
>> +static void spt_irq_handler(struct drm_device *dev, u32 pch_iir)
>> +{
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT &
>> + ~SDE_PORTE_HOTPLUG_SPT;
>> + u32 hotplug2_trigger = pch_iir & SDE_PORTE_HOTPLUG_SPT;
>> +
>> + if (hotplug_trigger) {
>> + u32 dig_hotplug_reg, pin_mask, long_mask;
>> +
>> + dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
>> + I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
>> +
>> + intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
>> + dig_hotplug_reg, hpd_spt,
>> +
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Support for pre-populating the object with system pages
On Thu, Aug 27, 2015 at 12:04:37PM +0530, Ankitprasad Sharma wrote:
> On Tue, 2015-08-25 at 11:51 +0100, Siluvery, Arun wrote:
> > On 24/08/2015 12:58, ankitprasad.r.sha...@intel.com wrote:
> > > From: Ankitprasad Sharma
> > >
> > > This patch provides support for the User to populate the object
> > > with system pages at its creation time. Since this can be safely
> > > performed without holding the 'struct_mutex', it would help to reduce
> > > the time 'struct_mutex' is kept locked especially during the exec-buffer
> > > path, where it is generally held for the longest time.
> > >
> > > Signed-off-by: Ankitprasad Sharma
> > > ---
> > > drivers/gpu/drm/i915/i915_dma.c | 2 +-
> > > drivers/gpu/drm/i915/i915_gem.c | 51
> > > +++--
> > > include/uapi/drm/i915_drm.h | 11 -
> > > 3 files changed, 45 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > b/drivers/gpu/drm/i915/i915_dma.c
> > > index 8319e07..955aa16 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -171,7 +171,7 @@ static int i915_getparam(struct drm_device *dev, void
> > > *data,
> > > value = HAS_RESOURCE_STREAMER(dev);
> > > break;
> > > case I915_PARAM_CREATE_VERSION:
> > > - value = 2;
> > > + value = 3;
> > > break;
> > > default:
> > > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index c44bd05..3904feb 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -46,6 +46,7 @@ static void
> > > i915_gem_object_retire__write(struct drm_i915_gem_object *obj);
> > > static void
> > > i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring);
> > > +static int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
> > >
> > > static bool cpu_cache_is_coherent(struct drm_device *dev,
> > > enum i915_cache_level level)
> > > @@ -414,6 +415,18 @@ i915_gem_create(struct drm_file *file,
> > > if (obj == NULL)
> > > return -ENOMEM;
> > >
> > > + if (flags & I915_CREATE_POPULATE) {
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > +
> > > + ret = __i915_gem_object_get_pages(obj);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(&dev->struct_mutex);
> > > + list_add_tail(&obj->global_list, &dev_priv->mm.unbound_list);
> > > + mutex_unlock(&dev->struct_mutex);
> > > + }
> > > +
> > > ret = drm_gem_handle_create(file, &obj->base, &handle);
> >
> > If I915_CREATE_POPULATE is set, don't we have to release the pages when
> > this call fails?
> I guess the i915_gem_object_get_pages_* takes care of releasing the
> pages when returning an error.
Oh, it should just be calling drm_gem_object_unreference_unlocked(). No
need to worry about obj->pages as they will be reaped along with the
object.
> One more thing,
> What can be preferred here when an error is returned by
> __i915_gem_object_get_pages?
> Shall we return error to the userspace after unreferencing the object or
> to continue without pre-populating pages (and returning object handle)?
Report the error. Userspace can then decide if it wants to allocate an
object without prepulated pages, try searching/reaping its own caches
harder for an available object, or do something different entirely to
avoid excess memory usage.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Support for pre-populating the object with system pages
On Thu, Aug 27, 2015 at 11:18:15AM +0530, Ankitprasad Sharma wrote: > On Mon, 2015-08-24 at 13:35 +0100, Chris Wilson wrote: > > I am tempted to say this should be in a new > > > > __i915_gem_object_get_pages__tail_locked() > > > > so that we don't have to hunt down users if we ever need to modify the > > global lists. > Could not get you here. > is it just to add list_add_tail in a separate function > __i915_gem_object_get_pages__tail_locked(), Yes. It's just a preventative maintenance step for when we need something other than just adding the object to the global list. I would rather not have core state tracking dotted around random callers. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: refuse changing CRTC for planes directly
On Wed, Aug 26, 2015 at 05:51:46PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 3:49 PM, Daniel Vetter wrote:
> > Very strictly speaking this is possible if you have special hw and
> > genlocked CRTCs. In general switching a plane between two active CRTC
> > just won't work so well and is probably not tested at all. Just forbid
> > it.
> >
> > I've put this into the core since right now no helper or driver copes
> > with it, no userspace has code for it and no one asks for it. Yes
> > there's piles of corner-cases where this would be possible to do this
> > like:
> > - switch from inactive crtc to active crtc
> > - swithc from active crtc to inactive crtc
> > - genlocked display
> > - invisible plane (to do whatever)
> > - idle plane hw due to dsi cmd mode/psr
> > - whatever
> > but looking at details it's not that easy to implement this correctly.
> > Hence just put it into the core and add a comment, since the only
> > userspace we have right now for atomic (weston) doesn't want to use
> > direct plane switching either.
>
> I suspect that eventually we'll want to make this a helper exposed to
> drivers and push this check down into the drivers.. perhaps that is
> not until weston (and/or atomic based hwc) grows driver specific
> userspace plugin type API to make smarter hw specific decisions..
> until then, this is probably the most reasonable thing to do.. so
Yeah this really is just to plug a "undefined behaviour" gap in the abi
until we know what exactly we want and have some userspace needing this.
> (w/ s/swihc/switch/ fix smashed in above)
>
> Reviewed-by: Rob Clark
Fixed&merged to drm-misc, thanks for the review.
-Daniel
>
>
> > v2: don't bother with complexity and just outright disallow plane
> > switching without the intermediate OFF state. Simplifies drivers, we
> > don't have any hw that could do it anyway and current atomic userspace
> > (weston) works like this already anyway.
> >
> > v3: Bikeshed function name (Ville) and add comment (Rob).
> >
> > v4: Also bikeshed commit message (Rob).
> >
> > Cc: Thierry Reding
> > Cc: Maarten Lankhorst
> > Cc: Daniel Stone
> > Acked-by: Daniel Stone
> > Signed-off-by: Daniel Vetter
> >
> > ---
> >
> > Imo this is bikeshedded enough, so either someone takes this or
> > someone else can mangle this patch more.
> > -Daniel
> > ---
> > drivers/gpu/drm/drm_atomic.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 1066e4b658cf..40ddd6aa100f 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -663,6 +663,27 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > return 0;
> > }
> >
> > +static bool
> > +plane_switching_crtc(struct drm_atomic_state *state,
> > +struct drm_plane *plane,
> > +struct drm_plane_state *plane_state)
> > +{
> > + struct drm_crtc_state *crtc_state, *curr_crtc_state;
> > +
> > + if (!plane->state->crtc || !plane_state->crtc)
> > + return false;
> > +
> > + if (plane->state->crtc == plane_state->crtc)
> > + return false;
> > +
> > + /* This could be refined, but currently there's no helper or driver
> > code
> > +* to implement direct switching of active planes nor userspace to
> > take
> > +* advantage of more direct plane switching without the intermediate
> > +* full OFF state.
> > +*/
> > + return true;
> > +}
> > +
> > /**
> > * drm_atomic_plane_check - check plane state
> > * @plane: plane to check
> > @@ -734,6 +755,12 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > return -ENOSPC;
> > }
> >
> > + if (plane_switching_crtc(state->state, plane, state)) {
> > + DRM_DEBUG_ATOMIC("[PLANE:%d] switching CRTC directly\n",
> > +plane->base.id);
> > + return -EINVAL;
> > + }
> > +
> > return 0;
> > }
> >
> > --
> > 2.5.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function
On 8/27/2015 12:30 PM, Jani Nikula wrote:
On Wed, 26 Aug 2015, Sivakumar Thulasimani
wrote:
On 8/20/2015 1:17 PM, Jani Nikula wrote:
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 41
++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
}
-/*
- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port)
{
@@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & bit;
}
-static bool g4x_digital_port_connected(struct drm_device *dev,
+static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t bit;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_VALLEYVIEW(dev_priv)) {
this might not work :(. just noted this as part of another review.
please fix this since
it is merged.
Sorry, what might not work?
Jani.
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_VALLEYVIEW(dev_priv)) { <- dev_priv is used instead of dev
should be IS_VALLEYVIEW(dev_priv->dev)
switch (port->port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
@@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct drm_device
*dev,
return I915_READ(PORT_HOTPLUG_STAT) & bit;
}
+/*
+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+ if (HAS_PCH_SPLIT(dev_priv))
+ return ibx_digital_port_connected(dev_priv, port);
+ else
+ return g4x_digital_port_connected(dev_priv, port);
+}
+
static enum drm_connector_status
ironlake_dp_detect(struct intel_dp *intel_dp)
{
@@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
+ if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;
return intel_dp_detect_dpcd(intel_dp);
@@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}
- if (!g4x_digital_port_connected(dev, intel_dig_port))
+ if (!intel_digital_port_connected(dev->dev_private, intel_dig_port))
return connector_status_disconnected;
return intel_dp_detect_dpcd(intel_dp);
@@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
- if (HAS_PCH_SPLIT(dev)) {
- if (!ibx_digital_port_connected(dev_priv,
intel_dig_port))
- goto mst_fail;
- } else {
- if (!g4x_digital_port_connected(dev, intel_dig_port))
- goto mst_fail;
- }
+ if (!intel_digital_port_connected(dev_priv, intel_dig_port))
+ goto mst_fail;
if (!intel_dp_get_dpcd(intel_dp)) {
goto mst_fail;
--
regards,
Sivakumar
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function
On Thu, 27 Aug 2015, Sivakumar Thulasimani
wrote:
> On 8/27/2015 12:30 PM, Jani Nikula wrote:
>> On Wed, 26 Aug 2015, Sivakumar Thulasimani
>> wrote:
>>> On 8/20/2015 1:17 PM, Jani Nikula wrote:
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 41
++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
}
-/*
- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
static bool ibx_digital_port_connected(struct drm_i915_private
*dev_priv,
struct intel_digital_port *port)
{
@@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & bit;
}
-static bool g4x_digital_port_connected(struct drm_device *dev,
+static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t bit;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_VALLEYVIEW(dev_priv)) {
>>> this might not work :(. just noted this as part of another review.
>>> please fix this since
>>> it is merged.
>> Sorry, what might not work?
>>
>> Jani.
>
> - if (IS_VALLEYVIEW(dev)) {
> + if (IS_VALLEYVIEW(dev_priv)) { <- dev_priv is used instead of dev
> should be IS_VALLEYVIEW(dev_priv->dev)
Ah, that may be confusing. We're transitioning towards preferring
dev_priv, and instead of switching everything at once (which would not
work) Chris put together some magic to have these macros accept either
drm_i915_private or drm_device pointer. See __I915__ in i915_drv.h.
BR,
Jani.
>
>>
switch (port->port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
@@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct
drm_device *dev,
return I915_READ(PORT_HOTPLUG_STAT) & bit;
}
+/*
+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private
*dev_priv,
+ struct intel_digital_port *port)
+{
+ if (HAS_PCH_SPLIT(dev_priv))
+ return ibx_digital_port_connected(dev_priv, port);
+ else
+ return g4x_digital_port_connected(dev_priv, port);
+}
+
static enum drm_connector_status
ironlake_dp_detect(struct intel_dp *intel_dp)
{
@@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
- if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
+ if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;
return intel_dp_detect_dpcd(intel_dp);
@@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}
- if (!g4x_digital_port_connected(dev, intel_dig_port))
+ if (!intel_digital_port_connected(dev->dev_private, intel_dig_port))
return connector_status_disconnected;
return intel_dp_detect_dpcd(intel_dp);
@@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
- if (HAS_PCH_SPLIT(dev)) {
- if (!ibx_digital_port_connected(dev_priv,
intel_dig_port))
- goto mst_fail;
- } else {
- if (!g4x_digital_port_connected(dev, in
[Intel-gfx] [drm-intel:topic/drm-misc 79/79] drivers/gpu/drm/drm_atomic.c:671:38: warning: unused variable 'curr_crtc_state'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 9b8a36e7534dd8992cfc9d75ece61961eab02e95
commit: 9b8a36e7534dd8992cfc9d75ece61961eab02e95 [79/79] drm/atomic: refuse
changing CRTC for planes directly
config: i386-randconfig-a0-201534 (attached as .config)
reproduce:
git checkout 9b8a36e7534dd8992cfc9d75ece61961eab02e95
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_atomic.c: In function 'plane_switching_crtc':
>> drivers/gpu/drm/drm_atomic.c:671:38: warning: unused variable
>> 'curr_crtc_state' [-Wunused-variable]
struct drm_crtc_state *crtc_state, *curr_crtc_state;
^
>> drivers/gpu/drm/drm_atomic.c:671:25: warning: unused variable 'crtc_state'
>> [-Wunused-variable]
struct drm_crtc_state *crtc_state, *curr_crtc_state;
^
vim +/curr_crtc_state +671 drivers/gpu/drm/drm_atomic.c
655 } else if (property == config->rotation_property) {
656 *val = state->rotation;
657 } else if (plane->funcs->atomic_get_property) {
658 return plane->funcs->atomic_get_property(plane, state,
property, val);
659 } else {
660 return -EINVAL;
661 }
662
663 return 0;
664 }
665
666 static bool
667 plane_switching_crtc(struct drm_atomic_state *state,
668 struct drm_plane *plane,
669 struct drm_plane_state *plane_state)
670 {
> 671 struct drm_crtc_state *crtc_state, *curr_crtc_state;
672
673 if (!plane->state->crtc || !plane_state->crtc)
674 return false;
675
676 if (plane->state->crtc == plane_state->crtc)
677 return false;
678
679 /* This could be refined, but currently there's no helper or
driver code
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.2.0-rc3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function
On 8/27/2015 1:38 PM, Jani Nikula wrote:
On Thu, 27 Aug 2015, Sivakumar Thulasimani
wrote:
On 8/27/2015 12:30 PM, Jani Nikula wrote:
On Wed, 26 Aug 2015, Sivakumar Thulasimani
wrote:
On 8/20/2015 1:17 PM, Jani Nikula wrote:
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 41
++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
}
-/*
- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port)
{
@@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & bit;
}
-static bool g4x_digital_port_connected(struct drm_device *dev,
+static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t bit;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_VALLEYVIEW(dev_priv)) {
this might not work :(. just noted this as part of another review.
please fix this since
it is merged.
Sorry, what might not work?
Jani.
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_VALLEYVIEW(dev_priv)) { <- dev_priv is used instead of dev
should be IS_VALLEYVIEW(dev_priv->dev)
Ah, that may be confusing. We're transitioning towards preferring
dev_priv, and instead of switching everything at once (which would not
work) Chris put together some magic to have these macros accept either
drm_i915_private or drm_device pointer. See __I915__ in i915_drv.h.
BR,
Jani.
sorry, missed that part :(.
switch (port->port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
@@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct drm_device
*dev,
return I915_READ(PORT_HOTPLUG_STAT) & bit;
}
+/*
+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+ if (HAS_PCH_SPLIT(dev_priv))
+ return ibx_digital_port_connected(dev_priv, port);
+ else
+ return g4x_digital_port_connected(dev_priv, port);
+}
+
static enum drm_connector_status
ironlake_dp_detect(struct intel_dp *intel_dp)
{
@@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
+ if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;
return intel_dp_detect_dpcd(intel_dp);
@@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}
- if (!g4x_digital_port_connected(dev, intel_dig_port))
+ if (!intel_digital_port_connected(dev->dev_private, intel_dig_port))
return connector_status_disconnected;
return intel_dp_detect_dpcd(intel_dp);
@@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
- if (HAS_PCH_SPLIT(dev)) {
- if (!ibx_digital_port_connected(dev_priv,
intel_dig_port))
- goto mst_fail;
- } else {
- if (!g4x_digital_port_connected(dev, intel_dig_port))
- goto mst_fail;
- }
+ if (!intel_digital_port_connected(dev_priv, intel_dig_port))
+ goto mst_fail;
if (!intel_dp_get_dpcd(intel_dp)) {
goto mst_fail;
--
regards,
Sivakumar
--
regards,
Sivakumar
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop
Re: [Intel-gfx] [PATCH 4/4] drm/i915: fix link rates reported for SKL
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7225 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT 283/283 283/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set the map-and-fenceable flag for preallocated objects
On Wed, 26 Aug 2015, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:
>> As we mark the preallocated objects as bound, we should also flag them
>> correctly as being map-and-fenceable (if appropriate!) so that latter
>> users do not get confused and try and rebind the pinned vma in order to
>> get a map-and-fenceable binding.
>>
>> Signed-off-by: Chris Wilson
>> Cc: "Goel, Akash"
>> Cc: Daniel Vetter
>> Cc: Jesse Barnes
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Daniel Vetter
>
> Jani, can you please pick up both? And some bugzilla references for either
> would be great too - Chris?
Both pushed to drm-intel-next-fixes. Thanks for the patches and review.
BR,
Jani.
>
> Oh and does patch 1 fix the execlist resume troubles? Execlist having
> bigger contexts might be enough explanations for the apparent regression.
>
> And can we igt patch 1 somehow? E.g. with memory pressure plus doing an
> mmap on the legacy fbdev ...
> -Daniel
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/gpu/drm/i915/i915_gem.c | 43
>> +
>> drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
>> 3 files changed, 26 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 55611d81ec6c..ec731e6db126 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2798,6 +2798,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object
>> *obj,
>>
>> int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
>>u32 flags);
>> +void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
>> int __must_check i915_vma_unbind(struct i915_vma *vma);
>> int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
>> void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 407b6b3576ae..39571e67f9a5 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3980,6 +3980,29 @@ i915_vma_misplaced(struct i915_vma *vma, uint32_t
>> alignment, uint64_t flags)
>> return false;
>> }
>>
>> +void __i915_vma_set_map_and_fenceable(struct i915_vma *vma)
>> +{
>> +struct drm_i915_gem_object *obj = vma->obj;
>> +bool mappable, fenceable;
>> +u32 fence_size, fence_alignment;
>> +
>> +fence_size = i915_gem_get_gtt_size(obj->base.dev,
>> + obj->base.size,
>> + obj->tiling_mode);
>> +fence_alignment = i915_gem_get_gtt_alignment(obj->base.dev,
>> + obj->base.size,
>> + obj->tiling_mode,
>> + true);
>> +
>> +fenceable = (vma->node.size == fence_size &&
>> + (vma->node.start & (fence_alignment - 1)) == 0);
>> +
>> +mappable = (vma->node.start + fence_size <=
>> +to_i915(obj->base.dev)->gtt.mappable_end);
>> +
>> +obj->map_and_fenceable = mappable && fenceable;
>> +}
>> +
>> static int
>> i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
>> struct i915_address_space *vm,
>> @@ -4047,25 +4070,7 @@ i915_gem_object_do_pin(struct drm_i915_gem_object
>> *obj,
>>
>> if (ggtt_view && ggtt_view->type == I915_GGTT_VIEW_NORMAL &&
>> (bound ^ vma->bound) & GLOBAL_BIND) {
>> -bool mappable, fenceable;
>> -u32 fence_size, fence_alignment;
>> -
>> -fence_size = i915_gem_get_gtt_size(obj->base.dev,
>> - obj->base.size,
>> - obj->tiling_mode);
>> -fence_alignment = i915_gem_get_gtt_alignment(obj->base.dev,
>> - obj->base.size,
>> - obj->tiling_mode,
>> - true);
>> -
>> -fenceable = (vma->node.size == fence_size &&
>> - (vma->node.start & (fence_alignment - 1)) == 0);
>> -
>> -mappable = (vma->node.start + fence_size <=
>> -dev_priv->gtt.mappable_end);
>> -
>> -obj->map_and_fenceable = mappable && fenceable;
>> -
>> +__i915_vma_set_map_and_fenceable(vma);
>> WARN_ON(flags & PIN_MAPPABLE && !obj->map_and_fenceable);
>> }
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 4a76807143b1..112d84c32257 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -2586,6 +2586,7 @@ static int i915_gem_setup_global_gtt(struct drm_device
>> *dev,
>> r
[Intel-gfx] [PATCH 0/4] Detect DP displays based on sink count change
From: "Thulasimani,Sivakumar" These patches together help detect DP displays on short pulse HPD and pass the respective compliance test case (4.2.2.8) v2: modifed first patch so we will read sink_count independent of downstream ports availablility. v3: split first patch so crtc enabled check is done in one patch and rest of sink_count changes in second patch. Thulasimani,Sivakumar (4): drm/i915: read dpcd 0 - 12 & link_status always drm/i915: read sink_count dpcd always drm/i915: Save sink_count for tracking changes to it drm/i915: force full detect on sink count change drivers/gpu/drm/i915/intel_dp.c | 57 +++--- drivers/gpu/drm/i915/intel_drv.h |1 + 2 files changed, 35 insertions(+), 23 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change
From: "Thulasimani,Sivakumar"
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.
v2: changed variable type from u8 to bool (Jani)
return immediately if perform_full_detect is set(Siva)
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..279e52c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,39 @@ go_again:
* 4. Check link status on receipt of hot-plug interrupt
*/
static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool
*perform_full_detect)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+ u8 old_sink_count = intel_dp->sink_count;
+ bool ret;
u8 link_status[DP_LINK_STATUS_SIZE];
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+ *perform_full_detect = false;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
- /* Now read the DPCD to see if it's actually running */
- if (!intel_dp_get_dpcd(intel_dp)) {
+ /* Now read the DPCD to see if it's actually running
+* Don't return immediately if dpcd read failed,
+* if sink count was 1 and dpcd read failed we need
+* to do full detection
+*/
+ ret = intel_dp_get_dpcd(intel_dp);
+
+ if (old_sink_count != intel_dp->sink_count)
+ *perform_full_detect = true;
+
+ /* No need to proceed if we are going to do full detect */
+ if (!ret || *perform_full_detect)
return;
- }
if (!intel_encoder->base.crtc)
return;
@@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
}
if (!intel_dp->is_mst) {
+ bool full_detect;
/*
* we'll check the link status via the normal hot plug
path later -
* but for short hpds we should check it now
*/
drm_modeset_lock(&dev->mode_config.connection_mutex,
NULL);
- intel_dp_check_link_status(intel_dp);
+ intel_dp_check_link_status(intel_dp, &full_detect);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ if (full_detect)
+ goto put_power;
}
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always
From: "Thulasimani,Sivakumar"
This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.
SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.
Here is a table of possible values and scenarios
sink_count downstream_port
present
0 0 no display is attached
0 1 dongle is connected without display
1 0 display connected directly
1 1 display connected through dongle
v2: moved out crtc enabled checks to prior patch(Jani)
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76561e0..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+ uint8_t reg;
if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
+ if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
+ ®, 1) < 0)
+ return false;
+
+ if (!DP_GET_SINK_COUNT(reg))
+ return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
- /* If we're HPD-aware, SINK_COUNT changes dynamically */
- if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
- intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
- uint8_t reg;
-
- if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
- ®, 1) < 0)
- return connector_status_unknown;
-
- return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
- }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(&intel_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Save sink_count for tracking changes to it
From: "Thulasimani,Sivakumar"
sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c |5 ++---
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9e4e27d..834f513 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,7 +3898,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
- uint8_t reg;
if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3910,10 +3909,10 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return false; /* DPCD not present */
if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
- ®, 1) < 0)
+ &intel_dp->sink_count, 1) < 0)
return false;
- if (!DP_GET_SINK_COUNT(reg))
+ if (!DP_GET_SINK_COUNT(intel_dp->sink_count))
return false;
/* Check if the panel supports PSR */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77..8aca5bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -712,6 +712,7 @@ struct intel_dp {
enum hdmi_force_audio force_audio;
bool limited_color_range;
bool color_range_auto;
+ uint8_t sink_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: read dpcd 0 - 12 & link_status always
From: "Thulasimani,Sivakumar"
Compliance requires the driver to read dpcd register 0 to 12 and
registers 0x200 to 0x205 to be read always.
Current code performs dpcd read for short pulse interrupts only
if the sink is enabled. This patch forces read for link status
and registers 0 to 12.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..76561e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4374,12 +4374,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
- if (!intel_encoder->base.crtc)
- return;
-
- if (!to_intel_crtc(intel_encoder->base.crtc)->active)
- return;
-
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
@@ -4390,6 +4384,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
+ if (!intel_encoder->base.crtc)
+ return;
+
+ if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+ return;
+
/* Try to read the source of the interrupt */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
intel_dp_get_sink_irq(intel_dp, &sink_irq_vector)) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status
Regards
Shashank
On 8/26/2015 8:47 PM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 10:05:00AM +, Jindal, Sonika wrote:
HPD bits control the interrupt but the live status (with some monitors) takes
time to get set.
We had experienced this with VLV and CHV with few monitors.
So Android code always has this retry for live status.
Yes, this was not added in the previous series because we planned to add the
next set of optimization a little while later.
But this seems to be an important one.
It will be great if you can try it with your ivb. But for that you would need
to first change the gen check and add a call to check live status for ivb.
Done (well I just quickly hacked up the same idea on top of your old
patches). Lessons to be learned from this:
- Make sure that you really include _all_ the bugfixes. This pach here
isn't just tuning, it's crucial to make it work. And this isn't the
first time vpg teams upstream something and later on we notice that
important bugfixes have been forgotten.
Because this wasn't done both you & me wasted a lot of time arguing
about these patches and trying to test them.
Agree. We thought once the basic optimization goes in, we will add this
as fine tuning patch. We were afraid of you guys doubting this approach
at first itself. It looks like a little hack, but the HW itself is
screwed up like this, to deal with.
- Please squash this patch in with patch 3 since otherwise we have a
regression. Also please try to dig out why exactly this works like this
since the hpd irq happening _before_ hpd status settles sounds to me
like we have a little time machine in our silicon which can predict the
future ...
Actually this depends on the monitor also. Few monitors are slow to
assert the HPD line, or sometimes they don't provide the right voltage
on that, causing live status to fluctuate for a while. While VLV/CHV
beta testing we have done this experiment with a big range of monitors,
and concluded that 30ms(retry of 10ms * 3) is the optimized time where
most of the monitors respond well.
We saw that we cant delay further, because HDCP compliance expects us to
respond to HPD (out) with in 100ms. So after careful testing with many
monitors, we have concluded this range.
- Please respin the patch series with the IS_VLV || gen >= 8 checks drop,
I'm fairly confident that this bugfix here is the bit we've been looking
for since years. At least it would be good to retest on all platforms
for maximal test coverage.
Sure. Will do that.
Cheers, Daniel
Regards,
Sonika
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, August 26, 2015 3:10 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status
On Tue, Aug 25, 2015 at 05:31:33PM +0530, Sonika Jindal wrote:
Some monitors take time in setting the live status.
So retry for few times if this is a connect HPD
Signed-off-by: Sonika Jindal
Why was this bugfix not part of the original series? Now I have to retest on my
ivb to figure out whether maybe this one here is the issue ...
Also how exactly does this work? I thought the hpd bits control whether we get
an interrupt, not the other way round? Why exactly does this help?
Definitely needs a lot more explanation.
Also this seems to break bisect, since before the preceeding patch to check hpd
status we just retried edid reading for a while.
This kind of hacking doesn't really convince me that hpd status is working,
just that our own testing isn't good enough to catch all real-world issues.
-Daniel
---
drivers/gpu/drm/i915/intel_hdmi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 59518b4..239d70d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1415,6 +1415,7 @@ void intel_hdmi_probe(struct intel_encoder *intel_encoder)
struct intel_connector *intel_connector =
intel_hdmi->attached_connector;
bool live_status = false;
+ unsigned int retry = 3;
/*
* Sometimes DDI ports are enumerated as DP as well as HDMI and @@
-1425,6 +1426,20 @@ void intel_hdmi_probe(struct intel_encoder *intel_encoder)
return;
live_status = intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
+ if (!intel_connector->detect_edid && live_status == false) {
+ /*
+* Hotplug had occurred and old status was disconnected,
+* so it might be possible that live status is not set,
+* so retry for few times
+*/
+ do {
+ mdelay(10);
+ live_status =
intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi));
+ if (live_status)
Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.
On Wed, Aug 26, 2015 at 6:41 PM, Vivi, Rodrigo wrote: > On Wed, 2015-08-26 at 11:06 +0200, Daniel Vetter wrote: >> On Thu, Aug 20, 2015 at 04:12:00PM -0700, Rodrigo Vivi wrote: >> > From: Rodrigo Vivi >> > >> > Let's use a native read with retry as suggested per spec to >> > fix Sink CRC on SKL when PSR is enabled. >> > >> > With PSR enabled panel is probably taking more time to wake >> > and dpcd read is faling. >> > >> > Cc: Sonika Jindal >> > Signed-off-by: Rodrigo Vivi >> >> Seems like we should just move the trickery we do in our own version >> into >> the dp helpers in the core if this is needed all over the place? > > I've wondered this, but I thought there was a good reason to let this > trick separated. I think in general you can assume that if i915 dp sink handling is special it's because we have more testing on various broken hw out there. >> At least in i915 we use it everywhere and it doesn't seem actively >> harmful >> really ... Maybe the only exception would be the i2c-over-dp_aux >> code. > > Why this would be the exception? Maybe this was the good reason? I'd be fairly easy to keep an internal __drm_dp_aux_read (need it anyway to implement this trick) and use that in i2c. At least that's what I'd do without any evidence that we need to make this wake dance also for i2c transactions. i2c uses a special dp-aux mode on the wire, so makes some sense if it's different. See also the recent work from Ville to tune the i2c dp-aux timeouts and retries, it really seems to be a world of its own a bit. -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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/dp: move TPS3 logic to where it's used
There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 31 +--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 50ba527763e9..12bce36065a1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3848,13 +3848,25 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
void
intel_dp_complete_link_train(struct intel_dp *intel_dp)
{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
bool channel_eq = false;
int tries, cr_tries;
uint32_t DP = intel_dp->DP;
uint32_t training_pattern = DP_TRAINING_PATTERN_2;
- /* Training Pattern 3 for HBR2 or 1.2 devices that support it*/
- if (intel_dp->link_rate == 54 || intel_dp->use_tps3)
+ /*
+* Training Pattern 3 for HBR2 or 1.2 devices that support it.
+*
+* Intel platforms that support HBR2 also support TPS3. TPS3 support is
+* also mandatory for downstream devices that support HBR2.
+*
+* Due to WaDisableHBR2 SKL < B0 is the only exception where TPS3 is
+* supported but still not enabled.
+*/
+ if (intel_dp->link_rate == 54 ||
+ (intel_dp_source_supports_hbr2(dev) &&
+intel_dp_tps3_supported(intel_dp->dpcd)))
training_pattern = DP_TRAINING_PATTERN_3;
/* channel equalization */
@@ -4036,18 +4048,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
}
- /* Training Pattern 3 support, Intel platforms that support HBR2 alone
-* have support for TP3 hence that check is used along with dpcd check
-* to ensure TP3 can be enabled.
-* SKL < B0: due it's WaDisableHBR2 is the only exception where TP3 is
-* supported but still not enabled.
-*/
- if (intel_dp_tps3_supported(intel_dp->dpcd) &&
- intel_dp_source_supports_hbr2(dev)) {
- intel_dp->use_tps3 = true;
- DRM_DEBUG_KMS("Displayport TPS3 supported\n");
- } else
- intel_dp->use_tps3 = false;
+ DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
+ intel_dp_source_supports_hbr2(dev) ? "yes" : "no",
+ intel_dp_tps3_supported(intel_dp->dpcd) ? "yes" : "no");
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c61ba47eda7c..fa9840fbccba 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -744,7 +744,6 @@ struct intel_dp {
enum pipe pps_pipe;
struct edp_power_seq pps_delays;
- bool use_tps3;
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] i915/dp: add intel_dp_tps3_supported helper
We can add this to drm dp helpers later.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9e90a2be22fa..12096c1df622 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1222,6 +1222,13 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int
**sink_rates)
return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
}
+static inline bool
+intel_dp_tps3_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_DPCD_REV] >= 0x12 &&
+ dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED;
+}
+
static bool intel_dp_source_supports_hbr2(struct drm_device *dev)
{
/* WaDisableHBR2:skl */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915/dp: use the drm dp helper for determining sink tps3 support
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12096c1df622..50ba527763e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4042,8 +4042,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
* SKL < B0: due it's WaDisableHBR2 is the only exception where TP3 is
* supported but still not enabled.
*/
- if (intel_dp->dpcd[DP_DPCD_REV] >= 0x12 &&
- intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED &&
+ if (intel_dp_tps3_supported(intel_dp->dpcd) &&
intel_dp_source_supports_hbr2(dev)) {
intel_dp->use_tps3 = true;
DRM_DEBUG_KMS("Displayport TPS3 supported\n");
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.
On Thu, 27 Aug 2015, Daniel Vetter wrote: > On Wed, Aug 26, 2015 at 6:41 PM, Vivi, Rodrigo wrote: >> On Wed, 2015-08-26 at 11:06 +0200, Daniel Vetter wrote: >>> On Thu, Aug 20, 2015 at 04:12:00PM -0700, Rodrigo Vivi wrote: >>> > From: Rodrigo Vivi >>> > >>> > Let's use a native read with retry as suggested per spec to >>> > fix Sink CRC on SKL when PSR is enabled. >>> > >>> > With PSR enabled panel is probably taking more time to wake >>> > and dpcd read is faling. >>> > >>> > Cc: Sonika Jindal >>> > Signed-off-by: Rodrigo Vivi >>> >>> Seems like we should just move the trickery we do in our own version >>> into >>> the dp helpers in the core if this is needed all over the place? >> >> I've wondered this, but I thought there was a good reason to let this >> trick separated. > > I think in general you can assume that if i915 dp sink handling is > special it's because we have more testing on various broken hw out > there. In truth our inconsistent use of wake vs. non-wake can be mostly attributed to the fact that we're clueless about sink sleep states, and we've just added more wakes here and there to paper over it. BR, Jani. > >>> At least in i915 we use it everywhere and it doesn't seem actively >>> harmful >>> really ... Maybe the only exception would be the i2c-over-dp_aux >>> code. >> >> Why this would be the exception? Maybe this was the good reason? > > I'd be fairly easy to keep an internal __drm_dp_aux_read (need it > anyway to implement this trick) and use that in i2c. At least that's > what I'd do without any evidence that we need to make this wake dance > also for i2c transactions. i2c uses a special dp-aux mode on the wire, > so makes some sense if it's different. See also the recent work from > Ville to tune the i2c dp-aux timeouts and retries, it really seems to > be a world of its own a bit. > -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 > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add some CHV DPIO lane power state asserts
On Thu, Aug 27, 2015 at 10:06:09AM +0530, Deepak wrote:
>
>
> On 07/09/2015 02:16 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add some checks that the state of the DPIO lanes is more or less what we
> > expect based on the overrides.
> >
> > The hardware only provides two bits per channel indicating whether all
> > or some of the lanes are powered down, so we can't do an exact check.
> >
> > Additionally, CL2 powering down before we can check it adds another
> > twist. To work around this we simply check for the 0 value of the
> > CL2 register (which is what we get when it's powered down) and
> > adjust our expectations.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 8 +
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 54
> > +
> > 2 files changed, 62 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 395f556..586a0f7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1089,6 +1089,12 @@ enum skl_disp_power_wells {
> > #define DPIO_CHV_INT_LOCK_THRESHOLD_SEL_COARSE 1 /* 1: coarse & 0 :
> > fine */
> > #define CHV_PLL_DW9(ch) _PIPE(ch, _CHV_PLL_DW9_CH0, _CHV_PLL_DW9_CH1)
> >
> > +#define _CHV_CMN_DW0_CH0 0x8100
> > +#define DPIO_ALLDL_POWERDOWN_SHIFT_CH0 19
> > +#define DPIO_ANYDL_POWERDOWN_SHIFT_CH0 18
> > +#define DPIO_ALLDL_POWERDOWN (1 << 1)
> > +#define DPIO_ANYDL_POWERDOWN (1 << 0)
> > +
> > #define _CHV_CMN_DW5_CH0 0x8114
> > #define CHV_BUFRIGHTENA1_DISABLE(0 << 20)
> > #define CHV_BUFRIGHTENA1_NORMAL (1 << 20)
> > @@ -1125,6 +1131,8 @@ enum skl_disp_power_wells {
> >
> > #define _CHV_CMN_DW19_CH0 0x814c
> > #define _CHV_CMN_DW6_CH1 0x8098
> > +#define DPIO_ALLDL_POWERDOWN_SHIFT_CH1 30 /* CL2 DW6 only */
> > +#define DPIO_ANYDL_POWERDOWN_SHIFT_CH1 29 /* CL2 DW6 only */
> > #define DPIO_DYNPWRDOWNEN_CH1 (1 << 28) /* CL2 DW6 only */
> > #define CHV_CMN_USEDCLKCHANNEL (1 << 13)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 002b78f..a1d9676 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1026,6 +1026,58 @@ static void chv_dpio_cmn_power_well_disable(struct
> > drm_i915_private *dev_priv,
> > phy, dev_priv->chv_phy_control);
> > }
> >
> > +static void assert_chv_phy_powergate(struct drm_i915_private *dev_priv,
> > enum dpio_phy phy,
> > +enum dpio_channel ch, bool override,
> > unsigned int mask)
> > +{
> > + enum pipe pipe = phy == DPIO_PHY0 ? PIPE_A : PIPE_C;
> Why not PIPE B? I think PIPE B can also be used to drive using PHY0?
Here we only pass 'pipe' to vlv_dpio_read() and it will just use
'DPIO_PHY(pipe)' to turn it back into an enum dpio_phy :) Since pipe A
and B are hooked up the same phy we don't need pipe B here.
I've been meaning to change vlv_dpio_read/write() to take enum dpio_phy
instead of enum pipe to get rid of this kind of sillyness, but haven't
gotten around to it yet. There may also be a few other functions that
could use the same treatment.
> > + u32 reg, val, expected, actual;
> > +
> > + if (ch == DPIO_CH0)
> > + reg = _CHV_CMN_DW0_CH0;
> > + else
> > + reg = _CHV_CMN_DW6_CH1;
> > +
> > + mutex_lock(&dev_priv->sb_lock);
> > + val = vlv_dpio_read(dev_priv, pipe, reg);
> > + mutex_unlock(&dev_priv->sb_lock);
> > +
> > + /*
> > +* This assumes !override is only used when the port is disabled.
> > +* All lanes should power down even without the override when
> > +* the port is disabled.
> > +*/
> > + if (!override || mask == 0xf) {
> > + expected = DPIO_ALLDL_POWERDOWN | DPIO_ANYDL_POWERDOWN;
> > + /*
> > +* If CH1 common lane is not active anymore
> > +* (eg. for pipe B DPLL) the entire channel will
> > +* shut down, which causes the common lane registers
> > +* to read as 0. That means we can't actually check
> > +* the lane power down status bits, but as the entire
> > +* register reads as 0 it's a good indication that the
> > +* channel is indeed entirely powered down.
> > +*/
> > + if (ch == DPIO_CH1 && val == 0)
> > + expected = 0;
> > + } else if (mask != 0x0) {
> > + expected = DPIO_ANYDL_POWERDOWN;
> > + } else {
> > + expected = 0;
> > + }
> > +
> > + if (ch == DPIO_CH0)
> > + actual = val >> DPIO_ANYDL_POWERDOWN_SHIFT_CH0;
> > + else
> > + actual = val >> DPIO_ANYDL_POWERDOWN_SHIFT_CH1;
> > + actual &= DPIO_ALLDL_POWERDOWN | DPIO_ANYDL_POWERDOWN;
Re: [Intel-gfx] drm/i915: Postpone plane readout until after encoder readout, v2.
Hey, Op 26-08-15 om 16:43 schreef Daniel Vetter: > On Wed, Aug 05, 2015 at 12:45:48PM +0200, Maarten Lankhorst wrote: >> From: Patrik Jakobsson >> >> When reading out hw state for planes we disable inactive planes which in >> turn triggers an update of the watermarks. The update depends on the >> crtc_clock being set which is done when reading out encoders. Thus >> postpone the plane readout until after encoder readout. >> >> This prevents a warning in skl_compute_linetime_wm() where pixel_rate >> becomes 0 when crtc_clock is 0. >> >> Changes since v1: >> - Set all modes after all state is read out. (Maarten) >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428 >> Signed-off-by: Patrik Jakobsson >> Signed-off-by: Maarten Lankhorst > Hm I still think we have a bit a mess here - the plane readout code is > still spread out between modeset_readout_hw_state and the per-plane loop > in intel_modeset_init after setup_hw_state. > > I thought that we only ever need to do the plane state readout on initial > load (they're all off on resume anyway and we force a full modeset to make > sure plane state is correct again). Can't we just have a setup_plane_state > which has that loop from the end of modeset_init with all the other plane > state unified there? > Perhaps, but intel_crtc_disable_noatomic cares about visibility state. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Reduce the time for which 'struct_mutex' is held
On Wed, 2015-08-26 at 11:25 +0200, Daniel Vetter wrote: > On Mon, Aug 24, 2015 at 05:28:13PM +0530, ankitprasad.r.sha...@intel.com > wrote: > > From: Ankitprasad Sharma > > > > We are trying to reduce the time for which the global 'struct_mutex' > > is locked. Execbuffer ioctl is one place where it is generally held > > for the longest time. And sometimes because of this occasional > > glitches/flickers are observed in 60 fps playback (due to miss of > > V-blank intervals) as page flip calls gets blocked/delayed because the > > 'struct_mutex' is already locked. > > > > For this, we have exposed two new flags in GEM_CREATE ioctl, to pre-populate > > the object with system memory pages and also do an immediate clflush for the > > new pages. > > > > The third patch too tries to reduce the 'struct_mutex' lock time by > > moving only those objects to CPU domain in put_pages(), that can either > > be used in the future or had a CPU mapping. > > > > This series is based on an earlier series of Stolen Memory patches, > > extending the GEM_CREATE ioctl further > > http://lists.freedesktop.org/archives/intel-gfx/2015-July/072199.html > > > > Ankitprasad Sharma (2): > > drm/i915: Support for pre-populating the object with system pages > > drm/i915: Support for the clflush of pre-populated pages > > > > Chris Wilson (1): > > drm/i915: Only move to the CPU write domain if keeping the GTT pages > > Usual broken maintainer record: Needs igt and userspace. And for the case > of the put_pages optimization probably really nasty igt. Yes, the igt is work in progress. We will extend the gem_create igt for 1st two patches and we are trying to come up with a new igt for the case of put_pages optimization. Also a query regarding the userspace, Where to do the userspace changes? (mesa driver?) and Who should do the implementation? (Should we do it?) Thanks, Ankit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix broken mst get_hw_state.
connector->encoder is initialized as NULL. Fix this by setting it in
during pre enable. MST connectors are not read out during initial hw
readout, and have no fixed encoder mappings. So it's harmless to
return false when the connector has never been assigned to an encoder.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 738178a0ac96..e3922d973db0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6283,7 +6283,7 @@ static void intel_connector_check_state(struct
intel_connector *connector)
connector->base.name);
if (connector->get_hw_state(connector)) {
- struct drm_encoder *encoder = &connector->encoder->base;
+ struct intel_encoder *encoder = connector->encoder;
struct drm_connector_state *conn_state = connector->base.state;
I915_STATE_WARN(!crtc,
@@ -6295,13 +6295,13 @@ static void intel_connector_check_state(struct
intel_connector *connector)
I915_STATE_WARN(!crtc->state->active,
"connector is active, but attached crtc isn't\n");
- if (!encoder)
+ if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
return;
- I915_STATE_WARN(conn_state->best_encoder != encoder,
+ I915_STATE_WARN(conn_state->best_encoder != &encoder->base,
"atomic encoder doesn't match attached encoder\n");
- I915_STATE_WARN(conn_state->crtc != encoder->crtc,
+ I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
"attached encoder crtc differs from connector crtc\n");
} else {
I915_STATE_WARN(crtc && crtc->state->active,
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index ebf205462631..d606721b1788 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -159,6 +159,11 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder)
return;
}
+ /* MST encoders are bound to a crtc, not to a connector,
+* force the mapping here for get_hw_state.
+*/
+ found->encoder = encoder;
+
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
intel_mst->port = found->port;
@@ -392,7 +397,7 @@ static const struct drm_encoder_funcs
intel_dp_mst_enc_funcs = {
static bool intel_dp_mst_get_hw_state(struct intel_connector *connector)
{
- if (connector->encoder) {
+ if (connector->encoder && connector->base.state->crtc) {
enum pipe pipe;
if (!connector->encoder->get_hw_state(connector->encoder,
&pipe))
return false;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Support for the clflush of pre-populated pages
From: Ankitprasad Sharma
This patch provides a support for the User to immediately flush
out the cachelines for the pre-populated pages of an object, at the
time of its creation. This will not lead to any redundancy and would
further reduce the time for which the 'struct_mutex' is kept locked in
execbuffer path, as cache flush of the newly allocated pages is anyways
done when the object is submitted to GPU.
v2: flush_cpu_write_domain expects the struct mutex to be locked which
was triggerring WARN_ONs, hence doing the required changes in an inline
manner (Ankit)
Signed-off-by: Ankitprasad Sharma
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 7 +++
include/uapi/drm/i915_drm.h | 3 ++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 955aa16..eb0b31d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -171,7 +171,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = HAS_RESOURCE_STREAMER(dev);
break;
case I915_PARAM_CREATE_VERSION:
- value = 3;
+ value = 4;
break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4430128..fa4cfb0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -426,6 +426,13 @@ i915_gem_create(struct drm_file *file,
return ret;
}
+ if (flags & I915_CREATE_FLUSH) {
+ if (i915_gem_clflush_object(obj, false))
+ i915_gem_chipset_flush(obj->base.dev);
+
+ obj->base.write_domain = 0;
+ }
+
mutex_lock(&dev->struct_mutex);
__i915_gem_object_get_pages__tail_locked(obj);
mutex_unlock(&dev->struct_mutex);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 26ea715..547305a 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -469,7 +469,8 @@ struct drm_i915_gem_create {
__u32 flags;
#define I915_CREATE_PLACEMENT_STOLEN (1<<0) /* Cannot use CPU mmaps */
#define I915_CREATE_POPULATE (1<<1) /* Pre-populate object pages */
-#define __I915_CREATE_UNKNOWN_FLAGS-(I915_CREATE_POPULATE << 1)
+#define I915_CREATE_FLUSH (1<<2) /* Clflush prepopulated pages */
+#define __I915_CREATE_UNKNOWN_FLAGS-(I915_CREATE_FLUSH << 1)
};
struct drm_i915_gem_pread {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Support for pre-populating the object with system pages
From: Ankitprasad Sharma
This patch provides support for the User to populate the object
with system pages at its creation time. Since this can be safely
performed without holding the 'struct_mutex', it would help to reduce
the time 'struct_mutex' is kept locked especially during the exec-buffer
path, where it is generally held for the longest time.
v2: Corrected error handling on pre-populate failure (Arun),
wrap list_add_tail() in __i915_gem_object_get_pages__tail_locked(),
moved error handling to the caller (Chris)
Signed-off-by: Ankitprasad Sharma
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 50 +++--
include/uapi/drm/i915_drm.h | 11 +
3 files changed, 49 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8319e07..955aa16 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -171,7 +171,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = HAS_RESOURCE_STREAMER(dev);
break;
case I915_PARAM_CREATE_VERSION:
- value = 2;
+ value = 3;
break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c44bd05..4430128 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,6 +46,9 @@ static void
i915_gem_object_retire__write(struct drm_i915_gem_object *obj);
static void
i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring);
+static int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+static void
+__i915_gem_object_get_pages__tail_locked(struct drm_i915_gem_object *obj);
static bool cpu_cache_is_coherent(struct drm_device *dev,
enum i915_cache_level level)
@@ -414,6 +417,20 @@ i915_gem_create(struct drm_file *file,
if (obj == NULL)
return -ENOMEM;
+ if (flags & I915_CREATE_POPULATE) {
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ ret = __i915_gem_object_get_pages(obj);
+ if (ret) {
+ drm_gem_object_unreference_unlocked(&obj->base);
+ return ret;
+ }
+
+ mutex_lock(&dev->struct_mutex);
+ __i915_gem_object_get_pages__tail_locked(obj);
+ mutex_unlock(&dev->struct_mutex);
+ }
+
ret = drm_gem_handle_create(file, &obj->base, &handle);
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(&obj->base);
@@ -2328,6 +2345,30 @@ err_pages:
return ret;
}
+static int
+__i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
+{
+ const struct drm_i915_gem_object_ops *ops = obj->ops;
+ int ret;
+
+ ret = ops->get_pages(obj);
+ if (ret)
+ return ret;
+
+ obj->get_page.sg = obj->pages->sgl;
+ obj->get_page.last = 0;
+
+ return 0;
+}
+
+static void
+__i915_gem_object_get_pages__tail_locked(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
+
+ list_add_tail(&obj->global_list, &dev_priv->mm.unbound_list);
+}
+
/* Ensure that the associated pages are gathered from the backing storage
* and pinned into our object. i915_gem_object_get_pages() may be called
* multiple times before they are released by a single call to
@@ -2338,8 +2379,6 @@ err_pages:
int
i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
{
- struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
- const struct drm_i915_gem_object_ops *ops = obj->ops;
int ret;
if (obj->pages)
@@ -2352,14 +2391,11 @@ i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
BUG_ON(obj->pages_pin_count);
- ret = ops->get_pages(obj);
+ ret = __i915_gem_object_get_pages(obj);
if (ret)
return ret;
- list_add_tail(&obj->global_list, &dev_priv->mm.unbound_list);
-
- obj->get_page.sg = obj->pages->sgl;
- obj->get_page.last = 0;
+ __i915_gem_object_get_pages__tail_locked(obj);
return 0;
}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f71f75c..26ea715 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -457,20 +457,19 @@ struct drm_i915_gem_create {
__u32 handle;
__u32 pad;
/**
-* Requested flags (currently used for placement
-* (which memory domain))
+* Requested flags
*
* You can request that the object be created from special memory
* rather than regular system pages using this parameter. Such
* irregular objects may have certain re
[Intel-gfx] [PATCH v2 0/3] Reduce the time for which 'struct_mutex' is held
From: Ankitprasad Sharma We are trying to reduce the time for which the global 'struct_mutex' is locked. Execbuffer ioctl is one place where it is generally held for the longest time. And sometimes because of this occasional glitches/flickers are observed in 60 fps playback (due to miss of V-blank intervals) as page flip calls gets blocked/delayed because the 'struct_mutex' is already locked. For this, we have exposed two new flags in GEM_CREATE ioctl, to pre-populate the object with system memory pages and also do an immediate clflush for the new pages. The third patch too tries to reduce the 'struct_mutex' lock time by moving only those objects to CPU domain in put_pages(), that can either be used in the future or had a CPU mapping. v2: Addressed comments from Chris/Arun. Fixed warnings in clflush of pre-populated pages. This series is based on an earlier series of Stolen Memory patches, extending the GEM_CREATE ioctl further http://lists.freedesktop.org/archives/intel-gfx/2015-July/072199.html Ankitprasad Sharma (2): drm/i915: Support for pre-populating the object with system pages drm/i915: Support for the clflush of pre-populated pages Chris Wilson (1): drm/i915: Only move to the CPU write domain if keeping the GTT pages drivers/gpu/drm/i915/i915_dma.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_gem.c | 119 include/uapi/drm/i915_drm.h | 12 ++-- 4 files changed, 109 insertions(+), 29 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Only move to the CPU write domain if keeping the GTT pages
From: Chris Wilson
We have for a long time been ultra-paranoid about the situation whereby
we hand back pages to the system that have been written to by the GPU
and potentially simultaneously by the user through a CPU mmapping. We
can relax this restriction when we know that the cache domain tracking
is true and there can be no stale cacheline invalidatations. This is
true if the object has never been CPU mmaped as all internal accesses
(i.e. kmap/iomap) are carefully flushed. For a CPU mmaping, one would
expect that the invalid cache lines are resolved on PTE/TLB shootdown
during munmap(), so the only situation we need to be paranoid about is
when such a CPU mmaping exists at the time of put_pages. Given that we
need to treat put_pages carefully as we may return live data to the
system that we want to use again in the future (i.e. I915_MADV_WILLNEED
pages) we can simply treat a live CPU mmaping as a special case of
WILLNEED (which it is!). Any I915_MADV_DONTNEED pages and their
mmapings are shot down immediately following put_pages.
v2: Add a new flag to check if ever a cached CPU mapping was created
for the object. This is needed as we have verified that the CPU
cachelines are not invalidated upon munmap(). So to ensure correctness,
object still needs to be moved to CPU write domain in put_pages(), even
if there are no live CPU mappings for I915_MADV_DONTNEED pages.
v3: Formatted comments, removed redundant braces (Chris)
Signed-off-by: Chris Wilson
Signed-off-by: Ankitprasad Sharma
---
drivers/gpu/drm/i915/i915_drv.h | 5
drivers/gpu/drm/i915/i915_gem.c | 62 +++--
2 files changed, 52 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8db905a..bb85401 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2096,6 +2096,11 @@ struct drm_i915_gem_object {
unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+ /*
+* Whether the object was ever mapped with cached CPU mapping
+*/
+ unsigned int has_stale_cachelines:1;
+
unsigned int pin_display;
struct sg_table *pages;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fa4cfb0..43e2a9f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1749,7 +1749,17 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
else
addr = -ENOMEM;
up_write(&mm->mmap_sem);
+ } else {
+ mutex_lock(&dev->struct_mutex);
+ /*
+* The cached mapping could lead to stale cachelines. So an
+* invalidation is needed for the object pages, when they are
+* released back to kernel.
+*/
+ to_intel_bo(obj)->has_stale_cachelines = 1;
+ mutex_unlock(&dev->struct_mutex);
}
+
drm_gem_object_unreference_unlocked(obj);
if (IS_ERR((void *)addr))
return addr;
@@ -2166,24 +2176,46 @@ i915_gem_object_put_pages_gtt(struct
drm_i915_gem_object *obj)
BUG_ON(obj->madv == __I915_MADV_PURGED);
- ret = i915_gem_object_set_to_cpu_domain(obj, true);
- if (ret) {
- /* In the event of a disaster, abandon all caches and
-* hope for the best.
-*/
- WARN_ON(ret != -EIO);
- i915_gem_clflush_object(obj, true);
- obj->base.read_domains = obj->base.write_domain =
I915_GEM_DOMAIN_CPU;
- }
-
- i915_gem_gtt_finish_object(obj);
-
- if (i915_gem_object_needs_bit17_swizzle(obj))
- i915_gem_object_save_bit_17_swizzle(obj);
+ /* If we need to access the data in the future, we need to
+* be sure that the contents of the object is coherent with
+* the CPU prior to releasing the pages back to the system.
+* Once we unpin them, the mm is free to move them to different
+* zones or even swap them out to disk - all without our
+* intervention. (Though we could track such operations with our
+* own gemfs, if we ever write one.) As such if we want to keep
+* the data, set it to the CPU domain now just in case someone
+* else touches it.
+*
+* For a long time we have been paranoid about handing back
+* pages to the system with stale cacheline invalidation. For
+* all internal use (kmap/iomap), we know that the domain tracking is
+* accurate. However, the userspace API is lax and the user can CPU
+* mmap the object and invalidate cachelines without our accurate
+* tracking. We have been paranoid to be sure that we always flushed
+* the cachelines when we stopped using the pages. For which we
+* maintain a flag for each object that has been CPU mmapped, based
+
[Intel-gfx] [PATCH] drm/i915: Postpone plane readout until after encoder readout, v3.
When reading out hw state for planes we disable inactive planes which in
turn triggers an update of the watermarks. The update depends on the
crtc_clock being set which is done when reading out encoders. Thus
postpone the plane readout until after encoder readout.
This prevents a warning in skl_compute_linetime_wm() where pixel_rate
becomes 0 when crtc_clock is 0.
Signed-off-by: Patrik Jakobsson
Signed-off-by: Maarten Lankhorst
References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e3922d973db0..118b205e7bd5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15033,30 +15033,6 @@ static bool primary_get_hw_state(struct intel_crtc
*crtc)
return !!(I915_READ(DSPCNTR(crtc->plane)) & DISPLAY_PLANE_ENABLE);
}
-static void readout_plane_state(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state)
-{
- struct intel_plane *p;
- struct intel_plane_state *plane_state;
- bool active = crtc_state->base.active;
-
- for_each_intel_plane(crtc->base.dev, p) {
- if (crtc->pipe != p->pipe)
- continue;
-
- plane_state = to_intel_plane_state(p->base.state);
-
- if (p->base.type == DRM_PLANE_TYPE_PRIMARY)
- plane_state->visible = primary_get_hw_state(crtc);
- else {
- if (active)
- p->disable_plane(&p->base, &crtc->base);
-
- plane_state->visible = false;
- }
- }
-}
-
static void intel_modeset_readout_hw_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -15076,35 +15052,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc->base.state->active = crtc->active;
crtc->base.enabled = crtc->active;
-
- memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
- if (crtc->base.state->active) {
- intel_mode_from_pipe_config(&crtc->base.mode,
crtc->config);
-
intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
- WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state,
&crtc->base.mode));
-
- /*
-* The initial mode needs to be set in order to keep
-* the atomic core happy. It wants a valid mode if the
-* crtc's enabled, so we do the above call.
-*
-* At this point some state updated by the connectors
-* in their ->detect() callback has not run yet, so
-* no recalculation can be done yet.
-*
-* Even if we could do a recalculation and modeset
-* right now it would cause a double modeset if
-* fbdev or userspace chooses a different initial mode.
-*
-* If that happens, someone indicated they wanted a
-* mode change, which means it's safe to do a full
-* recalculation.
-*/
- crtc->base.state->mode.private_flags =
I915_MODE_FLAG_INHERITED;
- }
-
- crtc->base.hwmode = crtc->config->base.adjusted_mode;
- readout_plane_state(crtc,
to_intel_crtc_state(crtc->base.state));
+ to_intel_plane_state(crtc->base.primary->state)->visible =
+ primary_get_hw_state(crtc);
DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
crtc->base.base.id,
@@ -15186,6 +15135,33 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
for_each_pipe(dev_priv, pipe) {
crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ crtc->base.hwmode = crtc->config->base.adjusted_mode;
+ memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
+ if (crtc->base.state->active) {
+ intel_mode_from_pipe_config(&crtc->base.mode,
crtc->config);
+
intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
+ WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state,
&crtc->base.mode));
+
+ /*
+* The initial mode needs to be set in order to keep
+* the atomic core happy. It wants a valid mode if the
+* crtc's enabled, so we do the above call.
+*
+* At this point some state updated by the connectors
+*
[Intel-gfx] [PATCH] drm/atomic: Make sure lock is held in trylock contexts.
This will make sure we get a lockdep spat in all cases
even if the context is a complete garbage pointer.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 9abee87c1501..7c9ca2381d78 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -305,6 +305,8 @@ static inline int modeset_lock(struct drm_modeset_lock
*lock,
WARN_ON(ctx->contended);
if (ctx->trylock_only) {
+ lockdep_assert_held(&ctx->ww_ctx);
+
if (!ww_mutex_trylock(&lock->mutex))
return -EBUSY;
else
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Postpone plane readout until after encoder readout, v3.
On Thu, Aug 27, 2015 at 01:47:26PM +0200, Maarten Lankhorst wrote:
> When reading out hw state for planes we disable inactive planes which in
> turn triggers an update of the watermarks. The update depends on the
> crtc_clock being set which is done when reading out encoders. Thus
> postpone the plane readout until after encoder readout.
>
> This prevents a warning in skl_compute_linetime_wm() where pixel_rate
> becomes 0 when crtc_clock is 0.
>
> Signed-off-by: Patrik Jakobsson
> Signed-off-by: Maarten Lankhorst
> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e3922d973db0..118b205e7bd5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15033,30 +15033,6 @@ static bool primary_get_hw_state(struct intel_crtc
> *crtc)
> return !!(I915_READ(DSPCNTR(crtc->plane)) & DISPLAY_PLANE_ENABLE);
> }
>
> -static void readout_plane_state(struct intel_crtc *crtc,
> - struct intel_crtc_state *crtc_state)
> -{
> - struct intel_plane *p;
> - struct intel_plane_state *plane_state;
> - bool active = crtc_state->base.active;
> -
> - for_each_intel_plane(crtc->base.dev, p) {
> - if (crtc->pipe != p->pipe)
> - continue;
> -
> - plane_state = to_intel_plane_state(p->base.state);
> -
> - if (p->base.type == DRM_PLANE_TYPE_PRIMARY)
> - plane_state->visible = primary_get_hw_state(crtc);
> - else {
> - if (active)
> - p->disable_plane(&p->base, &crtc->base);
> -
> - plane_state->visible = false;
> - }
> - }
> -}
> -
> static void intel_modeset_readout_hw_state(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15076,35 +15052,8 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
>
> crtc->base.state->active = crtc->active;
> crtc->base.enabled = crtc->active;
> -
> - memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
> - if (crtc->base.state->active) {
> - intel_mode_from_pipe_config(&crtc->base.mode,
> crtc->config);
> -
> intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
> - WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state,
> &crtc->base.mode));
> -
> - /*
> - * The initial mode needs to be set in order to keep
> - * the atomic core happy. It wants a valid mode if the
> - * crtc's enabled, so we do the above call.
> - *
> - * At this point some state updated by the connectors
> - * in their ->detect() callback has not run yet, so
> - * no recalculation can be done yet.
> - *
> - * Even if we could do a recalculation and modeset
> - * right now it would cause a double modeset if
> - * fbdev or userspace chooses a different initial mode.
> - *
> - * If that happens, someone indicated they wanted a
> - * mode change, which means it's safe to do a full
> - * recalculation.
> - */
> - crtc->base.state->mode.private_flags =
> I915_MODE_FLAG_INHERITED;
> - }
> -
> - crtc->base.hwmode = crtc->config->base.adjusted_mode;
> - readout_plane_state(crtc,
> to_intel_crtc_state(crtc->base.state));
> + to_intel_plane_state(crtc->base.primary->state)->visible =
> + primary_get_hw_state(crtc);
The commit message is for a totally different patch it seems.
Hmm. Looking at this, I should have just moved the entire mode setup
block in my hwmode fix patch to the end of the function, and things would
be fixed.
>
> DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
> crtc->base.base.id,
> @@ -15186,6 +15135,33 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
>
> for_each_pipe(dev_priv, pipe) {
> crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> + crtc->base.hwmode = crtc->config->base.adjusted_mode;
> + memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
> + if (crtc->base.state->active) {
> + intel_mode_from_pipe_config(&crtc->base.mode,
> crtc->config);
> +
> intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
> + WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state,
> &crtc->base.mode));
> +
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/dp: move TPS3 logic to where it's used
On Thu, Aug 27, 2015 at 01:25:38PM +0300, Jani Nikula wrote:
> There is no need to have a separate flag for tps3 as the information is
> only used at one location. Move the logic there to make it easier to
> follow.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 31 +--
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 2 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 50ba527763e9..12bce36065a1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3848,13 +3848,25 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> void
> intel_dp_complete_link_train(struct intel_dp *intel_dp)
> {
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> bool channel_eq = false;
> int tries, cr_tries;
> uint32_t DP = intel_dp->DP;
> uint32_t training_pattern = DP_TRAINING_PATTERN_2;
>
> - /* Training Pattern 3 for HBR2 or 1.2 devices that support it*/
> - if (intel_dp->link_rate == 54 || intel_dp->use_tps3)
> + /*
> + * Training Pattern 3 for HBR2 or 1.2 devices that support it.
> + *
> + * Intel platforms that support HBR2 also support TPS3. TPS3 support is
> + * also mandatory for downstream devices that support HBR2.
> + *
> + * Due to WaDisableHBR2 SKL < B0 is the only exception where TPS3 is
> + * supported but still not enabled.
> + */
> + if (intel_dp->link_rate == 54 ||
> + (intel_dp_source_supports_hbr2(dev) &&
> + intel_dp_tps3_supported(intel_dp->dpcd)))
I'm thinking we could just kill the link_rate check here. It would
only make a difference if the sink lied in its DPCD.
> training_pattern = DP_TRAINING_PATTERN_3;
>
> /* channel equalization */
> @@ -4036,18 +4048,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> }
> }
>
> - /* Training Pattern 3 support, Intel platforms that support HBR2 alone
> - * have support for TP3 hence that check is used along with dpcd check
> - * to ensure TP3 can be enabled.
> - * SKL < B0: due it's WaDisableHBR2 is the only exception where TP3 is
> - * supported but still not enabled.
> - */
> - if (intel_dp_tps3_supported(intel_dp->dpcd) &&
> - intel_dp_source_supports_hbr2(dev)) {
> - intel_dp->use_tps3 = true;
> - DRM_DEBUG_KMS("Displayport TPS3 supported\n");
> - } else
> - intel_dp->use_tps3 = false;
> + DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
> + intel_dp_source_supports_hbr2(dev) ? "yes" : "no",
> + intel_dp_tps3_supported(intel_dp->dpcd) ? "yes" : "no");
I guess we don't have a one true yesno() macro. I think we have such
things in specific files. Maybe make it available everywhere?
But anyway, those are just food for thought, and the series looks good
so
Reviewed-by: Ville Syrjälä
>
> /* Intermediate frequency support */
> if (is_edp(intel_dp) &&
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index c61ba47eda7c..fa9840fbccba 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -744,7 +744,6 @@ struct intel_dp {
> enum pipe pps_pipe;
> struct edp_power_seq pps_delays;
>
> - bool use_tps3;
> bool can_mst; /* this port supports mst */
> bool is_mst;
> int active_mst_links;
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Fix bookkeeping with TEST_ONLY.
Hi,
On 4 August 2015 at 12:34, Maarten Lankhorst
wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
> the vblank events should be cleared as on failure.
Bikeshedding a bit ...
An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
to mention this in the commit message; in this case, the main change
is about plane->{,old_}fb.
> @@ -1532,7 +1533,7 @@ retry:
> ret = drm_atomic_check_only(state);
> /* _check_only() does not free state, unlike _commit() */
> if (!ret)
> - drm_atomic_state_free(state);
> + goto free;
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_async_commit(state);
> } else {
> @@ -1566,6 +1567,7 @@ out:
> }
>
> if (ret) {
> +free:
This is a bit nasty. Can we please move the label above the
conditional and change the condition to (ret || flags & TEST_ONLY)?
Doing that, you could also move the label above the (ret == -EDEADLK)
check, which would cover ->atomic_check needing to grab other states
(global resources?) and failing.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
Op 27-08-15 om 14:19 schreef Daniel Stone:
> Hi,
>
> On 4 August 2015 at 12:34, Maarten Lankhorst
> wrote:
>> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
>> "drm/atomic: Cleanup on error properly in the atomic ioctl."
>> cleaned up some error paths, but didn't fix the TEST_ONLY path.
>> In the check only case plane->fb shouldn't be updated, and
>> the vblank events should be cleared as on failure.
> Bikeshedding a bit ...
>
> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> to mention this in the commit message; in this case, the main change
> is about plane->{,old_}fb.
Even testing with PAGE_FLIP_EVENT would be useful because
event && !crtc_state->active should not be allowed. In that case test
could succeed but commit could fail.
Though I guess you're right and it's currently not allowed.
>> @@ -1532,7 +1533,7 @@ retry:
>> ret = drm_atomic_check_only(state);
>> /* _check_only() does not free state, unlike _commit() */
>> if (!ret)
>> - drm_atomic_state_free(state);
>> + goto free;
>> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>> ret = drm_atomic_async_commit(state);
>> } else {
>> @@ -1566,6 +1567,7 @@ out:
>> }
>>
>> if (ret) {
>> +free:
> This is a bit nasty. Can we please move the label above the
> conditional and change the condition to (ret || flags & TEST_ONLY)?
> Doing that, you could also move the label above the (ret == -EDEADLK)
> check, which would cover ->atomic_check needing to grab other states
> (global resources?) and failing.
If our bookkeeping is correct then it won't be harmful to fixup old_fb.
Cleaning up more old_fb for more planes than initially had fb updates can always
happen anyway, because a modeset will add all affected planes.
How about the below patch? Apply with git am --scissors
>8--
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but allowed -EDEADLK to
leak vblank events.
Additionally check_only was updating plane->fb, which should
not be done when checking a new configuration only.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2448f42480f..78ffb4965548 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1542,7 +1542,8 @@ retry:
copied_props++;
}
- if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
+ if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
+ !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
plane = obj_to_plane(obj);
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
@@ -1564,10 +1565,11 @@ retry:
}
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
+ /*
+* Unlike commit, check_only does not clean up state.
+* Below we call drm_atomic_state_free for it.
+*/
ret = drm_atomic_check_only(state);
- /* _check_only() does not free state, unlike _commit() */
- if (!ret)
- drm_atomic_state_free(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_async_commit(state);
} else {
@@ -1594,25 +1596,24 @@ out:
plane->old_fb = NULL;
}
+ if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ if (!crtc_state->event)
+ continue;
+
+ destroy_vblank_event(dev, file_priv,
+crtc_state->event);
+ }
+ }
+
if (ret == -EDEADLK) {
drm_atomic_state_clear(state);
drm_modeset_backoff(&ctx);
goto retry;
}
- if (ret) {
- if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
- for_each_crtc_in_state(state, crtc, crtc_state, i) {
- if (!crtc_state->event)
- continue;
-
- destroy_vblank_event(dev, file_priv,
-crtc_state->event);
- }
- }
-
+ if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
drm_atomic_state_free(state);
- }
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:19 schreef Daniel Stone:
> > Hi,
> >
> > On 4 August 2015 at 12:34, Maarten Lankhorst
> > wrote:
> >> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> >> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> >> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> >> In the check only case plane->fb shouldn't be updated, and
> >> the vblank events should be cleared as on failure.
> > Bikeshedding a bit ...
> >
> > An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> > to mention this in the commit message; in this case, the main change
> > is about plane->{,old_}fb.
> Even testing with PAGE_FLIP_EVENT would be useful because
> event && !crtc_state->active should not be allowed. In that case test
> could succeed but commit could fail.
Why would commit fail when the we're in DPMS off? I would suggest it
should be allowed. The operation would just a be a nop from a HW point
of view, all the calculation/checks would still be performed.
>
> Though I guess you're right and it's currently not allowed.
> >> @@ -1532,7 +1533,7 @@ retry:
> >> ret = drm_atomic_check_only(state);
> >> /* _check_only() does not free state, unlike _commit() */
> >> if (!ret)
> >> - drm_atomic_state_free(state);
> >> + goto free;
> >> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> >> ret = drm_atomic_async_commit(state);
> >> } else {
> >> @@ -1566,6 +1567,7 @@ out:
> >> }
> >>
> >> if (ret) {
> >> +free:
> > This is a bit nasty. Can we please move the label above the
> > conditional and change the condition to (ret || flags & TEST_ONLY)?
> > Doing that, you could also move the label above the (ret == -EDEADLK)
> > check, which would cover ->atomic_check needing to grab other states
> > (global resources?) and failing.
> If our bookkeeping is correct then it won't be harmful to fixup old_fb.
> Cleaning up more old_fb for more planes than initially had fb updates can
> always
> happen anyway, because a modeset will add all affected planes.
>
> How about the below patch? Apply with git am --scissors
>
> >8--
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but allowed -EDEADLK to
> leak vblank events.
>
> Additionally check_only was updating plane->fb, which should
> not be done when checking a new configuration only.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2448f42480f..78ffb4965548 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1542,7 +1542,8 @@ retry:
> copied_props++;
> }
>
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
> + if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> + !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
> plane = obj_to_plane(obj);
> plane_mask |= (1 << drm_plane_index(plane));
> plane->old_fb = plane->fb;
> @@ -1564,10 +1565,11 @@ retry:
> }
>
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> + /*
> + * Unlike commit, check_only does not clean up state.
> + * Below we call drm_atomic_state_free for it.
> + */
> ret = drm_atomic_check_only(state);
> - /* _check_only() does not free state, unlike _commit() */
> - if (!ret)
> - drm_atomic_state_free(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_async_commit(state);
> } else {
> @@ -1594,25 +1596,24 @@ out:
> plane->old_fb = NULL;
> }
>
> + if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc_state->event)
> + continue;
> +
> + destroy_vblank_event(dev, file_priv,
> + crtc_state->event);
> + }
> + }
> +
> if (ret == -EDEADLK) {
> drm_atomic_state_clear(state);
> drm_modeset_backoff(&ctx);
> goto retry;
> }
>
> - if (ret) {
> - if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (!crtc_state->event)
> - continue;
> -
> - destroy_vblank_event(dev, file_priv,
> - crtc_state->event);
> - }
>
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:19 schreef Daniel Stone:
>>> Hi,
>>>
>>> On 4 August 2015 at 12:34, Maarten Lankhorst
>>> wrote:
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.
>>> Bikeshedding a bit ...
>>>
>>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>>> to mention this in the commit message; in this case, the main change
>>> is about plane->{,old_}fb.
>> Even testing with PAGE_FLIP_EVENT would be useful because
>> event && !crtc_state->active should not be allowed. In that case test
>> could succeed but commit could fail.
> Why would commit fail when the we're in DPMS off? I would suggest it
> should be allowed. The operation would just a be a nop from a HW point
> of view, all the calculation/checks would still be performed.
>
You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:19 schreef Daniel Stone:
> >>> Hi,
> >>>
> >>> On 4 August 2015 at 12:34, Maarten Lankhorst
> >>> wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
> the vblank events should be cleared as on failure.
> >>> Bikeshedding a bit ...
> >>>
> >>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> >>> to mention this in the commit message; in this case, the main change
> >>> is about plane->{,old_}fb.
> >> Even testing with PAGE_FLIP_EVENT would be useful because
> >> event && !crtc_state->active should not be allowed. In that case test
> >> could succeed but commit could fail.
> > Why would commit fail when the we're in DPMS off? I would suggest it
> > should be allowed. The operation would just a be a nop from a HW point
> > of view, all the calculation/checks would still be performed.
> >
> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
What's so special about the event here? Just send it out as soon as the
state has been swapped.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/13] drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM
On Thu, 2015-08-20 at 18:11 -0700, Matt Roper wrote:
> Just pull the info out of the state structures rather than staging
> it in an additional set of structures.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 304
> ++--
> 1 file changed, 135 insertions(+), 169 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b9bcb85..0cfba0a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1779,13 +1779,6 @@ static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t
> horiz_pixels,
> return DIV_ROUND_UP(pri_val * 64, horiz_pixels * bytes_per_pixel) + 2;
> }
>
> -struct skl_pipe_wm_parameters {
> - bool active;
> - uint32_t pipe_htotal;
> - uint32_t pixel_rate; /* in KHz */
> - struct intel_plane_wm_parameters plane[I915_MAX_PLANES + 1];
> -};
> -
> struct ilk_wm_maximums {
> uint16_t pri;
> uint16_t spr;
> @@ -2826,18 +2819,40 @@ static bool ilk_disable_lp_wm(struct drm_device *dev)
> #define SKL_DDB_SIZE 896 /* in blocks */
> #define BXT_DDB_SIZE 512
>
> +/*
> + * Return the index of a plane in the SKL DDB and wm result arrays. Primary
> + * plane is always in slot 0, cursor is always in slot I915_MAX_PLANES, and
> + * other universal planes are in indices 1..n. Note that this may leave
> + * unused indices between the top "sprite" plane and the cursor.
> + */
> +static int
> +skl_wm_plane_id(const struct intel_plane *plane)
> +{
> + switch (plane->base.type) {
> + case DRM_PLANE_TYPE_PRIMARY:
> + return 0;
> + case DRM_PLANE_TYPE_CURSOR:
> + return I915_MAX_PLANES;
> + case DRM_PLANE_TYPE_OVERLAY:
> + return plane->plane;
> + default:
> + MISSING_CASE(plane->base.type);
> + return plane->plane;
> + }
> +}
> +
> static void
> skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
> struct drm_crtc *for_crtc,
> const struct intel_wm_config *config,
> -const struct skl_pipe_wm_parameters *params,
> +const struct intel_crtc_state *cstate,
> struct skl_ddb_entry *alloc /* out */)
> {
> struct drm_crtc *crtc;
> unsigned int pipe_size, ddb_size;
> int nth_active_pipe;
>
> - if (!params->active) {
> + if (!cstate->base.active) {
> alloc->start = 0;
> alloc->end = 0;
> return;
> @@ -2903,19 +2918,27 @@ void skl_ddb_get_hw_state(struct drm_i915_private
> *dev_priv,
> }
>
> static unsigned int
> -skl_plane_relative_data_rate(const struct intel_plane_wm_parameters *p, int
> y)
> +skl_plane_relative_data_rate(const struct drm_plane_state *state, int y)
> {
> + struct intel_crtc *intel_crtc = to_intel_crtc(state->crtc);
> + struct drm_framebuffer *fb = state->fb;
>
> /* for planar format */
> - if (p->y_bytes_per_pixel) {
> + if (fb->pixel_format == DRM_FORMAT_NV12) {
> if (y) /* y-plane data rate */
> - return p->horiz_pixels * p->vert_pixels *
> p->y_bytes_per_pixel;
> + return intel_crtc->config->pipe_src_w *
> + intel_crtc->config->pipe_src_h *
> + drm_format_plane_cpp(fb->pixel_format, 0);
> else/* uv-plane data rate */
> - return (p->horiz_pixels/2) * (p->vert_pixels/2) *
> p->bytes_per_pixel;
> + return (intel_crtc->config->pipe_src_w/2) *
> + (intel_crtc->config->pipe_src_h/2) *
> + drm_format_plane_cpp(fb->pixel_format, 1);
> }
>
> /* for packed formats */
> - return p->horiz_pixels * p->vert_pixels * p->bytes_per_pixel;
> + return intel_crtc->config->pipe_src_w *
> + intel_crtc->config->pipe_src_h *
> + fb->bits_per_pixel / 8;
> }
>
> /*
> @@ -2924,23 +2947,24 @@ skl_plane_relative_data_rate(const struct
> intel_plane_wm_parameters *p,
> int y)
> * 3 * 4096 * 8192 * 4 < 2^32
> */
> static unsigned int
> -skl_get_total_relative_data_rate(struct intel_crtc *intel_crtc,
> - const struct skl_pipe_wm_parameters *params)
> +skl_get_total_relative_data_rate(const struct intel_crtc *intel_crtc)
> {
> + struct drm_device *dev = intel_crtc->base.dev;
> + const struct intel_plane *intel_plane;
> unsigned int total_data_rate = 0;
> - int plane;
>
> - for (plane = 0; plane < intel_num_planes(intel_crtc); plane++) {
> - const struct intel_plane_wm_parameters *p;
> + for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> + const struct drm_plane_state *state = intel_plane->base.state;
>
> -
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
Op 27-08-15 om 14:52 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
>>> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
Op 27-08-15 om 14:19 schreef Daniel Stone:
> Hi,
>
> On 4 August 2015 at 12:34, Maarten Lankhorst
> wrote:
>> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
>> "drm/atomic: Cleanup on error properly in the atomic ioctl."
>> cleaned up some error paths, but didn't fix the TEST_ONLY path.
>> In the check only case plane->fb shouldn't be updated, and
>> the vblank events should be cleared as on failure.
> Bikeshedding a bit ...
>
> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> to mention this in the commit message; in this case, the main change
> is about plane->{,old_}fb.
Even testing with PAGE_FLIP_EVENT would be useful because
event && !crtc_state->active should not be allowed. In that case test
could succeed but commit could fail.
>>> Why would commit fail when the we're in DPMS off? I would suggest it
>>> should be allowed. The operation would just a be a nop from a HW point
>>> of view, all the calculation/checks would still be performed.
>>>
>> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
> What's so special about the event here? Just send it out as soon as the
> state has been swapped.
Previously this has been disallowed for legacy page flips. I don't see why this
should be relaxed. It just complicates things and you have nothing to stick in
for the vblank counter.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Fix clock readout when pipes are enabled w/o ports
Op 26-08-15 om 18:39 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > The BIOS sometimes likes to enable pipes w/o any ports, at least on > older machines. Currently we fail to assign anything sensible to > crtc->hwmode.crtc_clock which leads to complaints from the vblank code. > Deal with active pipes w/o ports and assign something sensible to > crtc_clock in i9xx_get_pipe_config(). The encoder .get_config() will > override this if the port is enabled. > > Gets rid of rest of these on my gen4: > [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate > constants, dotclock = 0! > [drm:i915_get_vblank_timestamp] crtc 1 is disabled > > v2: Fill out crtc_clock already in i9xx_get_pipe_config() (Maarten) > > Cc: Maarten Lankhorst > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index dde8597..9e92915 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8107,6 +8107,14 @@ static bool i9xx_get_pipe_config(struct intel_crtc > *crtc, > else > i9xx_crtc_clock_get(crtc, pipe_config); > > + /* > + * Normally the dotclock is filled in by the encoder .get_config() > + * but in case the pipe is enabled w/o any ports we need a sane > + * default. > + */ > + pipe_config->base.adjusted_mode.crtc_clock = > + pipe_config->port_clock / pipe_config->pixel_multiplier; > + > return true; > } > This patch + 1/2 and 3/2. Reviewed-by: Maarten Lankhorst I'll send a separate patch for killing off the plane sanitization. :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix module initialisation, v2.
Set DRIVER_MODESET and DRIVER_ATOMIC by default. The driver is fully atomic.
Remove the legacy suspend/resume, to fix a warning introduced by:
"drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers"
and removing the .get_vblank_timestamp reset to NULL. It's a noop without UMS.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 097d4ba0421c..f0eaa6f8826b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -364,12 +364,12 @@ static void i915_switcheroo_set_state(struct pci_dev
*pdev, enum vga_switcheroo_
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
/* i915 resume handler doesn't set to D0 */
pci_set_power_state(dev->pdev, PCI_D0);
- i915_resume_legacy(dev);
+ i915_resume_switcheroo(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
pr_err("switched off\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
- i915_suspend_legacy(dev, pmm);
+ i915_suspend_switcheroo(dev, pmm);
dev->switch_power_state = DRM_SWITCH_POWER_OFF;
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ce3bd0c713b9..4646fe1a0499 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -679,7 +679,7 @@ static int i915_drm_suspend_late(struct drm_device
*drm_dev, bool hibernation)
return 0;
}
-int i915_suspend_legacy(struct drm_device *dev, pm_message_t state)
+int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
{
int error;
@@ -812,7 +812,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
return ret;
}
-int i915_resume_legacy(struct drm_device *dev)
+int i915_resume_switcheroo(struct drm_device *dev)
{
int ret;
@@ -1649,7 +1649,7 @@ static struct drm_driver driver = {
*/
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
- DRIVER_RENDER,
+ DRIVER_RENDER | DRIVER_MODESET,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
@@ -1658,10 +1658,6 @@ static struct drm_driver driver = {
.postclose = i915_driver_postclose,
.set_busid = drm_pci_set_busid,
- /* Used in place of i915_pm_ops for non-DRIVER_MODESET */
- .suspend = i915_suspend_legacy,
- .resume = i915_resume_legacy,
-
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = i915_debugfs_init,
.debugfs_cleanup = i915_debugfs_cleanup,
@@ -1704,7 +1700,6 @@ static int __init i915_init(void)
* either the i915.modeset prarameter or by the
* vga_text_mode_force boot option.
*/
- driver.driver_features |= DRIVER_MODESET;
if (i915.modeset == 0)
driver.driver_features &= ~DRIVER_MODESET;
@@ -1715,17 +1710,11 @@ static int __init i915_init(void)
#endif
if (!(driver.driver_features & DRIVER_MODESET)) {
- driver.get_vblank_timestamp = NULL;
/* Silently fail loading to not upset userspace. */
DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
return 0;
}
- /*
-* FIXME: Note that we're lying to the DRM core here so that we can get
access
-* to the atomic ioctl and the atomic properties. Only plane
operations on
-* a single CRTC will actually work.
-*/
if (i915.nuclear_pageflip)
driver.driver_features |= DRIVER_ATOMIC;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c938451a05e..5c2541ddf212 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2607,8 +2607,8 @@ struct drm_i915_cmd_table {
extern const struct drm_ioctl_desc i915_ioctls[];
extern int i915_max_ioctl;
-extern int i915_suspend_legacy(struct drm_device *dev, pm_message_t state);
-extern int i915_resume_legacy(struct drm_device *dev);
+extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
+extern int i915_resume_switcheroo(struct drm_device *dev);
/* i915_params.c */
struct i915_params {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] follow-up
These three patches address Ville's review comments on top of the series. BR, Jani. Jani Nikula (3): drm/i915: ignore link rate in TPS3 selection drm/i915: add yesno utility function drm/i915: use the yesno helper for logging drivers/gpu/drm/i915/i915_debugfs.c | 22 +++--- drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gpu_error.c | 5 - drivers/gpu/drm/i915/intel_dp.c | 11 ++- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 5 files changed, 20 insertions(+), 27 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: ignore link rate in TPS3 selection
TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, regardless of the link rate being selected.
Log an error if the sink has advertized HBR2 capability without TPS3
capability.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12bce36065a1..4e68681465d2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3864,10 +3864,11 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
* Due to WaDisableHBR2 SKL < B0 is the only exception where TPS3 is
* supported but still not enabled.
*/
- if (intel_dp->link_rate == 54 ||
- (intel_dp_source_supports_hbr2(dev) &&
-intel_dp_tps3_supported(intel_dp->dpcd)))
+ if (intel_dp_source_supports_hbr2(dev) &&
+ intel_dp_tps3_supported(intel_dp->dpcd))
training_pattern = DP_TRAINING_PATTERN_3;
+ else if (intel_dp->link_rate == 54)
+ DRM_ERROR("5.4 Gbps link rate without HBR2/TPS3 support\n");
/* channel equalization */
if (!intel_dp_set_link_train(intel_dp, &DP,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: use the yesno helper for logging
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index de7ae1c398ec..df24ac399416 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1382,17 +1382,16 @@ static int ironlake_drpc_info(struct seq_file *m)
intel_runtime_pm_put(dev_priv);
mutex_unlock(&dev->struct_mutex);
- seq_printf(m, "HD boost: %s\n", (rgvmodectl & MEMMODE_BOOST_EN) ?
- "yes" : "no");
+ seq_printf(m, "HD boost: %s\n", yesno(rgvmodectl & MEMMODE_BOOST_EN));
seq_printf(m, "Boost freq: %d\n",
(rgvmodectl & MEMMODE_BOOST_FREQ_MASK) >>
MEMMODE_BOOST_FREQ_SHIFT);
seq_printf(m, "HW control enabled: %s\n",
- rgvmodectl & MEMMODE_HWIDLE_EN ? "yes" : "no");
+ yesno(rgvmodectl & MEMMODE_HWIDLE_EN));
seq_printf(m, "SW control enabled: %s\n",
- rgvmodectl & MEMMODE_SWMODE_EN ? "yes" : "no");
+ yesno(rgvmodectl & MEMMODE_SWMODE_EN));
seq_printf(m, "Gated voltage change: %s\n",
- rgvmodectl & MEMMODE_RCLK_GATE ? "yes" : "no");
+ yesno(rgvmodectl & MEMMODE_RCLK_GATE));
seq_printf(m, "Starting frequency: P%d\n",
(rgvmodectl & MEMMODE_FSTART_MASK) >> MEMMODE_FSTART_SHIFT);
seq_printf(m, "Max P-state: P%d\n",
@@ -1401,7 +1400,7 @@ static int ironlake_drpc_info(struct seq_file *m)
seq_printf(m, "RS1 VID: %d\n", (crstandvid & 0x3f));
seq_printf(m, "RS2 VID: %d\n", ((crstandvid >> 8) & 0x3f));
seq_printf(m, "Render standby enabled: %s\n",
- (rstdbyctl & RCX_SW_EXIT) ? "no" : "yes");
+ yesno(!(rstdbyctl & RCX_SW_EXIT)));
seq_puts(m, "Current RS state: ");
switch (rstdbyctl & RSX_STATUS_MASK) {
case RSX_STATUS_ON:
@@ -2842,8 +2841,7 @@ static void intel_dp_info(struct seq_file *m,
struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
- seq_printf(m, "\taudio support: %s\n", intel_dp->has_audio ? "yes" :
- "no");
+ seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
if (intel_encoder->type == INTEL_OUTPUT_EDP)
intel_panel_info(m, &intel_connector->panel);
}
@@ -2854,8 +2852,7 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_encoder *intel_encoder = intel_connector->encoder;
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&intel_encoder->base);
- seq_printf(m, "\taudio support: %s\n", intel_hdmi->has_audio ? "yes" :
- "no");
+ seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
}
static void intel_lvds_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4e68681465d2..b55c136cd786 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4050,8 +4050,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
- intel_dp_source_supports_hbr2(dev) ? "yes" : "no",
- intel_dp_tps3_supported(intel_dp->dpcd) ? "yes" : "no");
+ yesno(intel_dp_source_supports_hbr2(dev)),
+ yesno(intel_dp_tps3_supported(intel_dp->dpcd)));
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fff0c22682ee..2a463ed3071a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5549,7 +5549,7 @@ static void cherryview_enable_rps(struct drm_device *dev)
/* RPS code assumes GPLL is used */
WARN_ONCE((val & GPLLENABLE) == 0, "GPLL not enabled\n");
- DRM_DEBUG_DRIVER("GPLL enabled? %s\n", val & GPLLENABLE ? "yes" : "no");
+ DRM_DEBUG_DRIVER("GPLL enabled? %s\n", yesno(val & GPLLENABLE));
DRM_DEBUG_DRIVER("GPU status: 0x%08x\n", val);
dev_priv->rps.cur_freq = (val >> 8) & 0xff;
@@ -5639,7 +5639,7 @@ static void valleyview_enable_rps(struct drm_device *dev)
/* RPS code assumes GPLL is used */
WARN_ONCE((val & GPLLENABLE) == 0, "GPLL not enabled\n");
- DRM_DEBUG_DRIVER("GPLL enabled? %s\n", val & GPLLENABLE ? "yes" : "no");
+ DRM_DEBUG_DRIVER("GPLL enabled? %s\n", yesno(val & GPLLENABLE));
DRM_DEBUG_DRIVER("GPU status: 0x%08x\n", val);
dev_priv->rps.cur_freq = (val >> 8) & 0xff;
--
2.1.4
___
Intel
[Intel-gfx] [PATCH 2/3] drm/i915: add yesno utility function
Add a common function to return "yes" or "no" string based on the
argument, and drop the local versions of it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 -
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4088cb1b95d9..de7ae1c398ec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -46,11 +46,6 @@ enum {
PINNED_LIST,
};
-static const char *yesno(int v)
-{
- return v ? "yes" : "no";
-}
-
/* As the drm_debugfs_init() routines are called before dev->dev_private is
* allocated we need to hook into the minor for release. */
static int
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c938451a05e..118223a3e155 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -106,6 +106,11 @@
unlikely(__ret_warn_on);\
})
+static inline const char *yesno(bool v)
+{
+ return v ? "yes" : "no";
+}
+
enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 493e9b294a69..3379f9c1ef88 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -30,11 +30,6 @@
#include
#include "i915_drv.h"
-static const char *yesno(int v)
-{
- return v ? "yes" : "no";
-}
-
static const char *ring_str(int ring)
{
switch (ring) {
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add yesno utility function
On Thu, Aug 27, 2015 at 04:23:30PM +0300, Jani Nikula wrote: > Add a common function to return "yes" or "no" string based on the > argument, and drop the local versions of it. Purely out of curiosity, gcc is able to amalgamate the constant strings (I remember reading that it is intelligent enough to do so), right? i.e. size i915.ko doesn't change (at least .data, we may see .text differences for gcc having different ideas about inlines)? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
Hi,
On 27 August 2015 at 13:43, Maarten Lankhorst
wrote:
> Op 27-08-15 om 14:19 schreef Daniel Stone:
>> On 4 August 2015 at 12:34, Maarten Lankhorst
>> wrote:
>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>> to mention this in the commit message; in this case, the main change
>> is about plane->{,old_}fb.
> Even testing with PAGE_FLIP_EVENT would be useful because
> event && !crtc_state->active should not be allowed. In that case test
> could succeed but commit could fail.
Will reply to that in the (very old) thread.
>> This is a bit nasty. Can we please move the label above the
>> conditional and change the condition to (ret || flags & TEST_ONLY)?
>> Doing that, you could also move the label above the (ret == -EDEADLK)
>> check, which would cover ->atomic_check needing to grab other states
>> (global resources?) and failing.
> If our bookkeeping is correct then it won't be harmful to fixup old_fb.
> Cleaning up more old_fb for more planes than initially had fb updates can
> always
> happen anyway, because a modeset will add all affected planes.
It won't happen: plane_mask will always be 0, because it's only set in
the branch which is now !TEST_ONLY. So yeah, it's safe to just skip
the label completely.
> How about the below patch? Apply with git am --scissors
>
> >8--
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but allowed -EDEADLK to
> leak vblank events.
>
> Additionally check_only was updating plane->fb, which should
> not be done when checking a new configuration only.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2448f42480f..78ffb4965548 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1542,7 +1542,8 @@ retry:
> copied_props++;
> }
>
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
> + if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> + !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
> plane = obj_to_plane(obj);
> plane_mask |= (1 << drm_plane_index(plane));
> plane->old_fb = plane->fb;
> @@ -1564,10 +1565,11 @@ retry:
> }
>
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> + /*
> +* Unlike commit, check_only does not clean up state.
> +* Below we call drm_atomic_state_free for it.
> +*/
> ret = drm_atomic_check_only(state);
> - /* _check_only() does not free state, unlike _commit() */
> - if (!ret)
> - drm_atomic_state_free(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_async_commit(state);
> } else {
> @@ -1594,25 +1596,24 @@ out:
> plane->old_fb = NULL;
> }
>
> + if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc_state->event)
> + continue;
> +
> + destroy_vblank_event(dev, file_priv,
> +crtc_state->event);
> + }
> + }
Yeah, moving this looks good for fixing the -EDEADLK leak. So, great.
Can you please add a comment above though noting that we don't need to
call this branch on (ret == 0 && flags & DRM_MODE_ATOMIC_TEST_ONLY),
as we do for freeing the state, because TEST_ONLY and PAGE_FLIP_EVENT
are mutually exclusive? Otherwise the next person to come along and
have the same idea of allowing them is probably going to break this.
:P
With that though, feel free to send it directly with:
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] drm/i915: Always try to inherit the initial fb.
The initial state is read out correctly and the state is atomic,
so it's safe to preserve the fb without any hacks if it's suitable.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_fbdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 6333241624c4..179c2c37c1b0 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -578,9 +578,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
struct intel_crtc *intel_crtc;
unsigned int max_size = 0;
- if (!i915.fastboot)
- return false;
-
/* Find the largest fb */
for_each_crtc(dev, crtc) {
struct drm_i915_gem_object *obj =
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] drm/i915: skip modeset if compatible for everyone.
This is done as a separate commit, to make it easier to revert
when things break.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_params.c | 5 -
drivers/gpu/drm/i915/intel_display.c | 3 +--
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61244455347f..c75d343ff26b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2628,7 +2628,6 @@ struct i915_params {
int enable_cmd_parser;
/* leave bools at the end to not create holes */
bool enable_hangcheck;
- bool fastboot;
bool prefault_disable;
bool load_detect_test;
bool reset;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0aba564..47d41da9d942 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -40,7 +40,6 @@ struct i915_params i915 __read_mostly = {
.preliminary_hw_support =
IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
.disable_power_well = 1,
.enable_ips = 1,
- .fastboot = 0,
.prefault_disable = 0,
.load_detect_test = 0,
.reset = true,
@@ -132,10 +131,6 @@ MODULE_PARM_DESC(disable_power_well,
module_param_named(enable_ips, i915.enable_ips, int, 0600);
MODULE_PARM_DESC(enable_ips, "Enable IPS (default: true)");
-module_param_named(fastboot, i915.fastboot, bool, 0600);
-MODULE_PARM_DESC(fastboot,
- "Try to skip unnecessary mode sets at boot time (default: false)");
-
module_param_named_unsafe(prefault_disable, i915.prefault_disable, bool, 0600);
MODULE_PARM_DESC(prefault_disable,
"Disable page prefaulting for pread/pwrite/reloc (default:false). "
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d3874a68cdb9..b4fb5dec2e38 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13035,8 +13035,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
return ret;
- if (i915.fastboot &&
- intel_pipe_config_compare(state->dev,
+ if (intel_pipe_config_compare(state->dev,
to_intel_crtc_state(crtc->state),
pipe_config, true)) {
crtc_state->mode_changed = false;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] drm/i915: Set csc coefficients in update_pipe_size.
This might not have been set during boot, and when we preserve the initial mode this can result in a black screen. Cc: Daniel Stone Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 364104dee32f..7b5dfe2f7b2d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3314,6 +3314,9 @@ static void intel_update_pipe_size(struct intel_crtc *crtc) if (!i915.fastboot) return; + if (HAS_DDI(dev)) + intel_set_pipe_csc(&crtc->base); + /* * Update pipe size and adjust fitter if needed: the reason for this is * that in compute_mode_changes we check the native mode (not the pfit -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] Faster modeset support.
What was previously known as fastboot no longer works. But we can do much better now that we pass the old crtc state to begin_crtc_commit. Even if we decide not to enable modeset this patch is useful, because it cleans up some non-atomic bits in a good way. Maarten Lankhorst (5): drm/i915: Set csc coefficients in update_pipe_size. drm/i915: Remove references to crtc->active from intel_fbdev.c drm/i915: Always try to inherit the initial fb. drm/i915: Make updating pipe without modeset atomic. drm/i915: skip modeset if compatible for everyone. drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_params.c | 5 -- drivers/gpu/drm/i915/intel_atomic.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 116 ++- drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_fbdev.c | 9 +-- 6 files changed, 79 insertions(+), 56 deletions(-) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/i915: Remove references to crtc->active from intel_fbdev.c
It should really use the atomic state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 6c9351b2e3af..6333241624c4 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -587,7 +587,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
intel_fb_obj(crtc->primary->state->fb);
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc->active || !obj) {
+ if (!crtc->state->active || !obj) {
DRM_DEBUG_KMS("pipe %c not active or no fb, skipping\n",
pipe_name(intel_crtc->pipe));
continue;
@@ -612,7 +612,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc->active) {
+ if (!crtc->state->active) {
DRM_DEBUG_KMS("pipe %c not active, skipping\n",
pipe_name(intel_crtc->pipe));
continue;
@@ -675,7 +675,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
for_each_crtc(dev, crtc) {
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc->active)
+ if (!crtc->state->active)
continue;
WARN(!crtc->primary->fb,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] drm/i915: Make updating pipe without modeset atomic.
Instead of doing a hack during primary plane commit the state
is updated during atomic evasion. It handles differences in
pipe size and the panel fitter.
This is continuing on top of Daniel's work to make faster
modesets atomic, and not yet enabled by default.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 110 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 72 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 9336e8030980..8287b81287a0 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -98,8 +98,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
return NULL;
__drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->base);
-
crtc_state->base.crtc = crtc;
+ crtc_state->update_pipe = false;
return &crtc_state->base;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7b5dfe2f7b2d..d3874a68cdb9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -108,6 +108,9 @@ static void skl_init_scalers(struct drm_device *dev, struct
intel_crtc *intel_cr
struct intel_crtc_state *crtc_state);
static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
int num_connectors);
+static void skylake_pfit_enable(struct intel_crtc *crtc);
+static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
+static void ironlake_pfit_enable(struct intel_crtc *crtc);
static void intel_modeset_setup_hw_state(struct drm_device *dev);
typedef struct {
@@ -3305,14 +3308,20 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc
*crtc)
return pending;
}
-static void intel_update_pipe_size(struct intel_crtc *crtc)
+static void intel_update_pipe_config(struct intel_crtc *crtc,
+struct intel_crtc_state *old_crtc_state)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- const struct drm_display_mode *adjusted_mode;
+ struct intel_crtc_state *pipe_config =
+ to_intel_crtc_state(crtc->base.state);
- if (!i915.fastboot)
- return;
+ /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
+ crtc->base.mode = crtc->base.state->mode;
+
+ DRM_DEBUG_KMS("Updating pipe size %ix%i -> %ix%i\n",
+ old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h,
+ pipe_config->pipe_src_w, pipe_config->pipe_src_h);
if (HAS_DDI(dev))
intel_set_pipe_csc(&crtc->base);
@@ -3324,27 +,26 @@ static void intel_update_pipe_size(struct intel_crtc
*crtc)
* fastboot case, we'll flip, but if we don't update the pipesrc and
* pfit state, we'll end up with a big fb scanned out into the wrong
* sized surface.
-*
-* To fix this properly, we need to hoist the checks up into
-* compute_mode_changes (or above), check the actual pfit state and
-* whether the platform allows pfit disable with pipe active, and only
-* then update the pipesrc and pfit state, even on the flip path.
*/
- adjusted_mode = &crtc->config->base.adjusted_mode;
-
I915_WRITE(PIPESRC(crtc->pipe),
- ((adjusted_mode->crtc_hdisplay - 1) << 16) |
- (adjusted_mode->crtc_vdisplay - 1));
- if (!crtc->config->pch_pfit.enabled &&
- (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
-intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
- I915_WRITE(PF_CTL(crtc->pipe), 0);
- I915_WRITE(PF_WIN_POS(crtc->pipe), 0);
- I915_WRITE(PF_WIN_SZ(crtc->pipe), 0);
+ ((pipe_config->pipe_src_w - 1) << 16) |
+ (pipe_config->pipe_src_h - 1));
+
+ /* on skylake this is done by detaching scalers */
+ if (INTEL_INFO(dev)->gen == 9) {
+ skl_detach_scalers(crtc);
+
+ if (pipe_config->pch_pfit.enabled)
+ skylake_pfit_enable(crtc);
+ }
+ else if (INTEL_INFO(dev)->gen < 9 &&
+HAS_PCH_SPLIT(dev)) {
+ if (pipe_config->pch_pfit.enabled)
+ ironlake_pfit_enable(crtc);
+ else if (old_crtc_state->pch_pfit.enabled)
+ ironlake_pfit_disable(crtc, true);
}
- crtc->config->pipe_src_w = adjusted_mode->crtc_hdisplay;
- crtc->config->pipe_src_h = adjusted_mode->crtc_vdisplay;
}
static void intel_fdi_normal_train(struct drm_crtc *crtc)
@@ -5003,7 +5011,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
}
}
-static void ironlake_pfit_disab
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add yesno utility function
On Thu, 27 Aug 2015, Chris Wilson wrote: > On Thu, Aug 27, 2015 at 04:23:30PM +0300, Jani Nikula wrote: >> Add a common function to return "yes" or "no" string based on the >> argument, and drop the local versions of it. > > Purely out of curiosity, gcc is able to amalgamate the constant strings > (I remember reading that it is intelligent enough to do so), right? i.e. > size i915.ko doesn't change (at least .data, we may see .text > differences for gcc having different ideas about inlines)? I admit to giving GCC the benefit of the doubt. I may be naïve that way, trusting the tools to do what seems like the obviously right thing to do. If GCC lets us down, we could try something like the yesno version in drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c. GCC not doing the right thing with that would be violating the standard. BR, Jani. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
On Thu, Aug 27, 2015 at 03:05:38PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:52 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> >>> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:19 schreef Daniel Stone:
> > Hi,
> >
> > On 4 August 2015 at 12:34, Maarten Lankhorst
> > wrote:
> >> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> >> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> >> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> >> In the check only case plane->fb shouldn't be updated, and
> >> the vblank events should be cleared as on failure.
> > Bikeshedding a bit ...
> >
> > An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> > to mention this in the commit message; in this case, the main change
> > is about plane->{,old_}fb.
> Even testing with PAGE_FLIP_EVENT would be useful because
> event && !crtc_state->active should not be allowed. In that case test
> could succeed but commit could fail.
> >>> Why would commit fail when the we're in DPMS off? I would suggest it
> >>> should be allowed. The operation would just a be a nop from a HW point
> >>> of view, all the calculation/checks would still be performed.
> >>>
> >> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
> > What's so special about the event here? Just send it out as soon as the
> > state has been swapped.
> Previously this has been disallowed for legacy page flips.
I don't think so. Speaking for i915, I think we've just rejected legacy page
flips entirely with the pipe is off on account of drm_vblank_get() failing.
> I don't see why this should be relaxed. It just complicates things and you
> have nothing to stick in for the vblank counter.
We could stick the last vbl count/timestamp in there.
Not allowing means userspace is forced to consider the dpms state
whenever it wants to call the atomic ioctl.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Make updating pipe without modeset atomic.
On Thu, Aug 27, 2015 at 03:44:05PM +0200, Maarten Lankhorst wrote:
> Instead of doing a hack during primary plane commit the state
> is updated during atomic evasion. It handles differences in
> pipe size and the panel fitter.
>
> This is continuing on top of Daniel's work to make faster
> modesets atomic, and not yet enabled by default.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 110
> ++-
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 72 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 9336e8030980..8287b81287a0 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -98,8 +98,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> return NULL;
>
> __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->base);
> -
> crtc_state->base.crtc = crtc;
> + crtc_state->update_pipe = false;
>
> return &crtc_state->base;
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7b5dfe2f7b2d..d3874a68cdb9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -108,6 +108,9 @@ static void skl_init_scalers(struct drm_device *dev,
> struct intel_crtc *intel_cr
> struct intel_crtc_state *crtc_state);
> static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
> int num_connectors);
> +static void skylake_pfit_enable(struct intel_crtc *crtc);
> +static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
> +static void ironlake_pfit_enable(struct intel_crtc *crtc);
> static void intel_modeset_setup_hw_state(struct drm_device *dev);
>
> typedef struct {
> @@ -3305,14 +3308,20 @@ static bool intel_crtc_has_pending_flip(struct
> drm_crtc *crtc)
> return pending;
> }
>
> -static void intel_update_pipe_size(struct intel_crtc *crtc)
> +static void intel_update_pipe_config(struct intel_crtc *crtc,
> + struct intel_crtc_state *old_crtc_state)
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - const struct drm_display_mode *adjusted_mode;
> + struct intel_crtc_state *pipe_config =
> + to_intel_crtc_state(crtc->base.state);
>
> - if (!i915.fastboot)
> - return;
> + /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
> + crtc->base.mode = crtc->base.state->mode;
> +
> + DRM_DEBUG_KMS("Updating pipe size %ix%i -> %ix%i\n",
> + old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h,
> + pipe_config->pipe_src_w, pipe_config->pipe_src_h);
>
> if (HAS_DDI(dev))
> intel_set_pipe_csc(&crtc->base);
> @@ -3324,27 +,26 @@ static void intel_update_pipe_size(struct intel_crtc
> *crtc)
>* fastboot case, we'll flip, but if we don't update the pipesrc and
>* pfit state, we'll end up with a big fb scanned out into the wrong
>* sized surface.
> - *
> - * To fix this properly, we need to hoist the checks up into
> - * compute_mode_changes (or above), check the actual pfit state and
> - * whether the platform allows pfit disable with pipe active, and only
> - * then update the pipesrc and pfit state, even on the flip path.
>*/
>
> - adjusted_mode = &crtc->config->base.adjusted_mode;
> -
> I915_WRITE(PIPESRC(crtc->pipe),
> -((adjusted_mode->crtc_hdisplay - 1) << 16) |
> -(adjusted_mode->crtc_vdisplay - 1));
> - if (!crtc->config->pch_pfit.enabled &&
> - (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
> - intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
> - I915_WRITE(PF_CTL(crtc->pipe), 0);
> - I915_WRITE(PF_WIN_POS(crtc->pipe), 0);
> - I915_WRITE(PF_WIN_SZ(crtc->pipe), 0);
> +((pipe_config->pipe_src_w - 1) << 16) |
> +(pipe_config->pipe_src_h - 1));
> +
> + /* on skylake this is done by detaching scalers */
> + if (INTEL_INFO(dev)->gen == 9) {
> + skl_detach_scalers(crtc);
> +
> + if (pipe_config->pch_pfit.enabled)
> + skylake_pfit_enable(crtc);
> + }
> + else if (INTEL_INFO(dev)->gen < 9 &&
> + HAS_PCH_SPLIT(dev)) {
> + if (pipe_config->pch_pfit.enabled)
> + ironlake_pfit_enable(crtc);
> + else if (old_crtc_state->pch_pfit.enabled)
> + ironlake_pfit_disable(crtc, true);
> }
> - crtc->config->pipe_src_w = adjusted_mode->crtc_hdisplay;
> - crtc->config->pipe_src_h = adjusted_mode->crtc_vdisplay;
> }
>
>
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
Op 27-08-15 om 15:50 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 03:05:38PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:52 schreef Ville Syrjälä:
>>> On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:19 schreef Daniel Stone:
>>> Hi,
>>>
>>> On 4 August 2015 at 12:34, Maarten Lankhorst
>>> wrote:
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.
>>> Bikeshedding a bit ...
>>>
>>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>>> to mention this in the commit message; in this case, the main change
>>> is about plane->{,old_}fb.
>> Even testing with PAGE_FLIP_EVENT would be useful because
>> event && !crtc_state->active should not be allowed. In that case test
>> could succeed but commit could fail.
> Why would commit fail when the we're in DPMS off? I would suggest it
> should be allowed. The operation would just a be a nop from a HW point
> of view, all the calculation/checks would still be performed.
>
You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
>>> What's so special about the event here? Just send it out as soon as the
>>> state has been swapped.
>> Previously this has been disallowed for legacy page flips.
> I don't think so. Speaking for i915, I think we've just rejected legacy page
> flips entirely with the pipe is off on account of drm_vblank_get() failing.
No atomic driver handles this case correctly. You can't get vblank events with
the crtc off.
>> I don't see why this should be relaxed. It just complicates things and you
>> have nothing to stick in for the vblank counter.
> We could stick the last vbl count/timestamp in there.
>
> Not allowing means userspace is forced to consider the dpms state
> whenever it wants to call the atomic ioctl.
Userspace was the one turning off the crtc in the first place; it shouldn't
continue flipping but preserve power. :-)
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Make updating pipe without modeset atomic.
Op 27-08-15 om 15:58 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 03:44:05PM +0200, Maarten Lankhorst wrote:
>> Instead of doing a hack during primary plane commit the state
>> is updated during atomic evasion. It handles differences in
>> pipe size and the panel fitter.
>>
>> This is continuing on top of Daniel's work to make faster
>> modesets atomic, and not yet enabled by default.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c | 2 +-
>> drivers/gpu/drm/i915/intel_display.c | 110
>> ++-
>> drivers/gpu/drm/i915/intel_drv.h | 2 +
>> 3 files changed, 72 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 9336e8030980..8287b81287a0 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -98,8 +98,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>> return NULL;
>>
>> __drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->base);
>> -
>> crtc_state->base.crtc = crtc;
>> +crtc_state->update_pipe = false;
>>
>> return &crtc_state->base;
>> }
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 7b5dfe2f7b2d..d3874a68cdb9 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -108,6 +108,9 @@ static void skl_init_scalers(struct drm_device *dev,
>> struct intel_crtc *intel_cr
>> struct intel_crtc_state *crtc_state);
>> static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
>> int num_connectors);
>> +static void skylake_pfit_enable(struct intel_crtc *crtc);
>> +static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
>> +static void ironlake_pfit_enable(struct intel_crtc *crtc);
>> static void intel_modeset_setup_hw_state(struct drm_device *dev);
>>
>> typedef struct {
>> @@ -3305,14 +3308,20 @@ static bool intel_crtc_has_pending_flip(struct
>> drm_crtc *crtc)
>> return pending;
>> }
>>
>> -static void intel_update_pipe_size(struct intel_crtc *crtc)
>> +static void intel_update_pipe_config(struct intel_crtc *crtc,
>> + struct intel_crtc_state *old_crtc_state)
>> {
>> struct drm_device *dev = crtc->base.dev;
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> -const struct drm_display_mode *adjusted_mode;
>> +struct intel_crtc_state *pipe_config =
>> +to_intel_crtc_state(crtc->base.state);
>>
>> -if (!i915.fastboot)
>> -return;
>> +/* drm_atomic_helper_update_legacy_modeset_state might not be called. */
>> +crtc->base.mode = crtc->base.state->mode;
>> +
>> +DRM_DEBUG_KMS("Updating pipe size %ix%i -> %ix%i\n",
>> + old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h,
>> + pipe_config->pipe_src_w, pipe_config->pipe_src_h);
>>
>> if (HAS_DDI(dev))
>> intel_set_pipe_csc(&crtc->base);
>> @@ -3324,27 +,26 @@ static void intel_update_pipe_size(struct intel_crtc
>> *crtc)
>> * fastboot case, we'll flip, but if we don't update the pipesrc and
>> * pfit state, we'll end up with a big fb scanned out into the wrong
>> * sized surface.
>> - *
>> - * To fix this properly, we need to hoist the checks up into
>> - * compute_mode_changes (or above), check the actual pfit state and
>> - * whether the platform allows pfit disable with pipe active, and only
>> - * then update the pipesrc and pfit state, even on the flip path.
>> */
>>
>> -adjusted_mode = &crtc->config->base.adjusted_mode;
>> -
>> I915_WRITE(PIPESRC(crtc->pipe),
>> - ((adjusted_mode->crtc_hdisplay - 1) << 16) |
>> - (adjusted_mode->crtc_vdisplay - 1));
>> -if (!crtc->config->pch_pfit.enabled &&
>> -(intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
>> - intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
>> -I915_WRITE(PF_CTL(crtc->pipe), 0);
>> -I915_WRITE(PF_WIN_POS(crtc->pipe), 0);
>> -I915_WRITE(PF_WIN_SZ(crtc->pipe), 0);
>> + ((pipe_config->pipe_src_w - 1) << 16) |
>> + (pipe_config->pipe_src_h - 1));
>> +
>> +/* on skylake this is done by detaching scalers */
>> +if (INTEL_INFO(dev)->gen == 9) {
>> +skl_detach_scalers(crtc);
>> +
>> +if (pipe_config->pch_pfit.enabled)
>> +skylake_pfit_enable(crtc);
>> +}
>> +else if (INTEL_INFO(dev)->gen < 9 &&
>> + HAS_PCH_SPLIT(dev)) {
>> +if (pipe_config->pch_pfit.enabled)
>> +ironlake_pfit_enable(crtc);
>> +else if (old_crtc_state->pch_pfit.enabled)
>> +ironlake_pfit_disable(crtc, true);
>> }
>> -crtc->config->pipe_src_w = adjuste
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 15:50 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 03:05:38PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:52 schreef Ville Syrjälä:
> >>> On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:19 schreef Daniel Stone:
> >>> Hi,
> >>>
> >>> On 4 August 2015 at 12:34, Maarten Lankhorst
> >>> wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
> the vblank events should be cleared as on failure.
> >>> Bikeshedding a bit ...
> >>>
> >>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> >>> to mention this in the commit message; in this case, the main change
> >>> is about plane->{,old_}fb.
> >> Even testing with PAGE_FLIP_EVENT would be useful because
> >> event && !crtc_state->active should not be allowed. In that case test
> >> could succeed but commit could fail.
> > Why would commit fail when the we're in DPMS off? I would suggest it
> > should be allowed. The operation would just a be a nop from a HW point
> > of view, all the calculation/checks would still be performed.
> >
> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
> >>> What's so special about the event here? Just send it out as soon as the
> >>> state has been swapped.
> >> Previously this has been disallowed for legacy page flips.
> > I don't think so. Speaking for i915, I think we've just rejected legacy page
> > flips entirely with the pipe is off on account of drm_vblank_get() failing.
> No atomic driver handles this case correctly. You can't get vblank events
> with the crtc off.
I don't understand what you're saying. Should there be a comma after
"No" ? If not, then I'm not sure what they don't handle.
> >> I don't see why this should be relaxed. It just complicates things and you
> >> have nothing to stick in for the vblank counter.
> > We could stick the last vbl count/timestamp in there.
> >
> > Not allowing means userspace is forced to consider the dpms state
> > whenever it wants to call the atomic ioctl.
> Userspace was the one turning off the crtc in the first place; it shouldn't
> continue flipping but preserve power. :-)
Meh. Much simpler to write code when you don't have to worry about such
details.
In the kernel it should amount to
if (!pipe_active)
send_event
We anyway need something like that for the crtc getting disabled case,
don't we?
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 1/4] drm/i915: Add audio pin sense / ELD callback
On Wed, 26 Aug 2015, David Henningsson wrote:
> On 2015-08-26 10:33, Daniel Vetter wrote:
>> On Wed, Aug 19, 2015 at 10:48:55AM +0200, David Henningsson wrote:
>>> This callback will be called by the i915 driver to notify the hda
>>> driver that its HDMI information needs to be refreshed, i e,
>>> that audio output is now available (or unavailable) - usually as a
>>> result of a monitor being plugged in (or unplugged).
>>>
>>> Signed-off-by: David Henningsson
>>> ---
>>> include/drm/i915_component.h | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
>>> index c9a8b64..ab5bde37 100644
>>> --- a/include/drm/i915_component.h
>>> +++ b/include/drm/i915_component.h
>>> @@ -34,6 +34,18 @@ struct i915_audio_component {
>>> void (*codec_wake_override)(struct device *, bool enable);
>>> int (*get_cdclk_freq)(struct device *);
>>> } *ops;
>>> +
>>> + const struct i915_audio_component_audio_ops {
>>> + void *audio_ptr;
>>> + /**
>>> +* Call from i915 driver, notifying the HDA driver that
>>> +* pin sense and/or ELD information has changed.
>>> +* @audio_ptr: HDA driver object
>>> +* @port: Which port has changed (PORTA / PORTB /
>>> PORTC etc)
>>> +* @port_mst_index: Index within that port, for DisplayPort
>>> multistreaming
>>> +*/
>>> + void (*pin_eld_notify)(void *audio_ptr, int port, int
>>> port_mst_index);
>>> + } *audio_ops;
>>
>> This won't work as proper kerneldoc, but you get away with it since it's
>> not pulled into the drm.tmpl. See my comments for the new set_audio_rate
>> callback.
>
> Sorry, my google failed me, so I can't find your comments for the
> set_audio_rate callback.
It's on the related thread [1], specifically the subthread starting at
[2]. I guess there's no direct overlap between the two series, but it
would be helpful if you can look at each other's work so there's no
surprises.
BR,
Jani.
[1] http://mid.gmane.org/1439880714-40931-1-git-send-email-libin.y...@intel.com
[2] http://mid.gmane.org/20150826081735.GZ20434@phenom.ffwll.local
>
> Apart from the kerneldoc issue, are you okay with acking the patch, at
> least the first two i915 ones, and agree with Takashi which tree this
> should go through?
>
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/6] drm/dp: i2c-over-aux short write support
From: Ville Syrjälä I found these lying around in a branch. Most have r-b or ack from last time [1] (the tegra patch doesn't). I also included the radeon 20bit AUX address fix that seems to have fallen through the cracks as well. I rebased these on top of my i2c-over-aux retry count series [2] since that fixes a regression and so it's more urgent to get in. [1] http://lists.freedesktop.org/archives/dri-devel/2015-March/079254.html [2] http://lists.freedesktop.org/archives/dri-devel/2015-August/089250.html Ville Syrjälä (6): drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/ drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests drm/radeon: Send out the full AUX address drivers/gpu/drm/drm_dp_helper.c | 43 drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/radeon/atombios_dp.c | 6 +++-- drivers/gpu/drm/tegra/dpaux.c| 3 ++- include/drm/drm_dp_helper.h | 2 +- 5 files changed, 47 insertions(+), 8 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
From: Ville Syrjälä Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the spec. Acked-by: Alex Deucher Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/tegra/dpaux.c | 2 +- include/drm/drm_dp_helper.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c index 224a7dc..1cc09ff 100644 --- a/drivers/gpu/drm/tegra/dpaux.c +++ b/drivers/gpu/drm/tegra/dpaux.c @@ -149,7 +149,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux *aux, break; - case DP_AUX_I2C_STATUS: + case DP_AUX_I2C_WRITE_STATUS_UPDATE: if (msg->request & DP_AUX_I2C_MOT) value |= DPAUX_DP_AUXCTL_CMD_MOT_RQ; else diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 499e9f6..d0c8810 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -46,7 +46,7 @@ #define DP_AUX_I2C_WRITE 0x0 #define DP_AUX_I2C_READ0x1 -#define DP_AUX_I2C_STATUS 0x2 +#define DP_AUX_I2C_WRITE_STATUS_UPDATE 0x2 #define DP_AUX_I2C_MOT 0x4 #define DP_AUX_NATIVE_WRITE0x8 #define DP_AUX_NATIVE_READ 0x9 -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/radeon: Send out the full AUX address
From: Ville Syrjälä
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/radeon/atombios_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index ca372c5..bd73b40 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -171,8 +171,9 @@ radeon_dp_aux_transfer_atom(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
tx_buf[0] = msg->address & 0xff;
- tx_buf[1] = msg->address >> 8;
- tx_buf[2] = msg->request << 4;
+ tx_buf[1] = (msg->address >> 8) & 0xff;
+ tx_buf[2] = (msg->request << 4) |
+ ((msg->address >> 16) & 0xf);
tx_buf[3] = msg->size ? (msg->size - 1) : 0;
switch (msg->request & ~DP_AUX_I2C_MOT) {
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
From: Ville Syrjälä
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
Looks like radeon doesn't do anything special with the request type,
so hopefully just treating it the same as a i2c write is enough.
Cc: Alex Deucher
Cc: "Christian König"
Acked-by: Alex Deucher
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/radeon/atombios_dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index f81e0d7..ca372c5 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -178,6 +178,7 @@ radeon_dp_aux_transfer_atom(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
/* The atom implementation only supports writes with a max
payload of
* 12 bytes since it uses 4 bits for the total count (header +
payload)
* in the parameter space. The atom interface supports 16 byte
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
From: Ville Syrjälä
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
i915 doesn't try to interpret wht request type apart from separating
reads from writes, and so we should be able to treat this the same as
a normal i2c write.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..acd01da 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -974,6 +974,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
txsize = msg->size ? HEADER_SIZE + msg->size :
BARE_ADDRESS_SIZE;
rxsize = 2; /* 0 or 1 data bytes */
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
From: Ville Syrjälä
A address-only I2C_WRITE can't be replied with a short i2c ack, but I
suppose it could be replied with an i2c defer. So the code should be
prepared for an address-only I2C_WRITE_STATUS_UPDATE.
Cc: Thierry Reding
Cc: "Terje Bergström"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tegra/dpaux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 1cc09ff..6aecb66 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -119,6 +119,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux *aux,
*/
if (msg->size < 1) {
switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
case DP_AUX_I2C_WRITE:
case DP_AUX_I2C_READ:
value = DPAUX_DP_AUXCTL_CMD_ADDRESS_ONLY;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests
From: Ville Syrjälä
When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.
v2: Don't assume DP_AUX_I2C_WRITE is 0 even though it is, to make the
code more obvious to the casual reader (Jani)
Acked-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 43 +
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ee5cd86..a717f4c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -496,6 +496,27 @@ static int drm_dp_i2c_retry_count(const struct
drm_dp_aux_msg *msg,
return DIV_ROUND_UP(i2c_len, aux_len + AUX_RETRY_INTERVAL);
}
+static void drm_dp_i2c_msg_set_request(struct drm_dp_aux_msg *msg,
+ const struct i2c_msg *i2c_msg)
+{
+ msg->request = (i2c_msg->flags & I2C_M_RD) ?
+ DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
+ msg->request |= DP_AUX_I2C_MOT;
+}
+
+static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+{
+ /*
+* In case of i2c defer or short i2c ack reply to a write,
+* we need to switch to WRITE_STATUS_UPDATE to drain the
+* rest of the message
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
+ msg->request &= DP_AUX_I2C_MOT;
+ msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+ }
+}
+
/*
* FIXME currently assumes 10 kHz as some real world devices seem
* to require it. We should query/set the speed via DPCD if supported.
@@ -576,6 +597,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
* Both native ACK and I2C ACK replies received. We
* can assume the transfer was successful.
*/
+ if (ret != msg->size)
+ drm_dp_i2c_msg_write_status_update(msg);
return ret;
case DP_AUX_I2C_REPLY_NACK:
@@ -593,6 +616,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
if (defer_i2c < 7)
defer_i2c++;
usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
100);
+ drm_dp_i2c_msg_write_status_update(msg);
continue;
default:
@@ -658,10 +682,7 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg *msgs,
for (i = 0; i < num; i++) {
msg.address = msgs[i].addr;
- msg.request = (msgs[i].flags & I2C_M_RD) ?
- DP_AUX_I2C_READ :
- DP_AUX_I2C_WRITE;
- msg.request |= DP_AUX_I2C_MOT;
+ drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
/* Send a bare address packet to start the transaction.
* Zero sized messages specify an address only (bare
* address) transaction.
@@ -669,6 +690,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg *msgs,
msg.buffer = NULL;
msg.size = 0;
err = drm_dp_i2c_do_msg(aux, &msg);
+
+ /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+ drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
+
if (err < 0)
break;
/* We want each transaction to be as large as possible, but
@@ -681,6 +709,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg *msgs,
msg.size = min(transfer_size, msgs[i].len - j);
err = drm_dp_i2c_drain_msg(aux, &msg);
+
+ /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+ drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
+
if (err < 0)
break;
transfer_size = err;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
Hi, On 27 August 2015 at 15:09, Ville Syrjälä wrote: > On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote: >> Op 27-08-15 om 15:50 schreef Ville Syrjälä: >> > I don't think so. Speaking for i915, I think we've just rejected legacy >> > page >> > flips entirely with the pipe is off on account of drm_vblank_get() failing. >> No atomic driver handles this case correctly. You can't get vblank events >> with the crtc off. > > I don't understand what you're saying. Should there be a comma after > "No" ? If not, then I'm not sure what they don't handle. I think you're arguing over the definition of 'correctly' perhaps? >> >> I don't see why this should be relaxed. It just complicates things and >> >> you have nothing to stick in for the vblank counter. >> > We could stick the last vbl count/timestamp in there. >> > >> > Not allowing means userspace is forced to consider the dpms state >> > whenever it wants to call the atomic ioctl. >> Userspace was the one turning off the crtc in the first place; it shouldn't >> continue flipping but preserve power. :-) > > Meh. Much simpler to write code when you don't have to worry about such > details. > > In the kernel it should amount to > if (!pipe_active) > send_event No, thankyou. Asking for an event, having the request succeed, and never getting an event, is a deathtrap. PAGE_FLIP_EVENT should mean that either an event gets delivered for every CRTC in crtc_state, or the request getting rejected. Nothing else. > We anyway need something like that for the crtc getting disabled case, > don't we? Yes, which I was getting at previously. We know when the CRTC gets disabled - we have to, in order to sensibly unpin etc - so that's when the event gets sent. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/6] drm/dp: i2c-over-aux short write support
On Thu, 27 Aug 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I found these lying around in a branch. Most have r-b or ack from last time > [1] (the tegra patch doesn't). I also included the radeon 20bit AUX address > fix that seems to have fallen through the cracks as well. > > I rebased these on top of my i2c-over-aux retry count series [2] since that > fixes a regression and so it's more urgent to get in. How about pushing both to a branch on some repo, and throwing them at some of the bugs we have open? BR, Jani. > > [1] http://lists.freedesktop.org/archives/dri-devel/2015-March/079254.html > [2] http://lists.freedesktop.org/archives/dri-devel/2015-August/089250.html > > Ville Syrjälä (6): > drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/ > drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE > drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE > drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes > drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE > requests > drm/radeon: Send out the full AUX address > > drivers/gpu/drm/drm_dp_helper.c | 43 > > drivers/gpu/drm/i915/intel_dp.c | 1 + > drivers/gpu/drm/radeon/atombios_dp.c | 6 +++-- > drivers/gpu/drm/tegra/dpaux.c| 3 ++- > include/drm/drm_dp_helper.h | 2 +- > 5 files changed, 47 insertions(+), 8 deletions(-) > > -- > 2.4.6 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
On 27.08.2015 05:52, Zhang, Xiong Y wrote: >> On Wed, 2015-08-26 at 11:15 +0300, Jani Nikula wrote: >>> On Thu, 13 Aug 2015, "Jindal, Sonika" >>> wrote: On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote: >> On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote: On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote: >> -Original Message- >> From: Vivi, Rodrigo >> Sent: Saturday, August 8, 2015 8:34 AM >> To: intel-gfx@lists.freedesktop.org >> Cc: Vivi, Rodrigo; Zhang, Xiong Y >> Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A >> shares 4 >> lanes. >> >> DDI-A and DDI-E shares the 4 lanes. So when DDI-E is >> present we >> need to configure lane count propperly for both. >> >> This was based on Sonika's >> [PATCH] drm/i915/skl: Select DDIA lane capability based >> upon vbt >> >> Credits-to: Sonika Jindal >> Cc: Xiong Zhang >> Signed-off-by: Rodrigo Vivi >> --- >> drivers/gpu/drm/i915/intel_ddi.c | 12 ++-- >> drivers/gpu/drm/i915/intel_dp.c | 8 +--- >> 2 files changed, 15 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c >> b/drivers/gpu/drm/i915/intel_ddi.c >> index 110d546..557cecf 100644 >> --- a/drivers/gpu/drm/i915/intel_ddi.c >> +++ b/drivers/gpu/drm/i915/intel_ddi.c >> @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct >> drm_device >> *dev, enum port port) >> struct intel_digital_port *intel_dig_port; >> struct intel_encoder *intel_encoder; >> struct drm_encoder *encoder; >> -bool init_hdmi, init_dp; >> +bool init_hdmi, init_dp, ddi_e_present; >> + >> +/* >> + * On SKL we don't have a way to detect DDI-E >> so we >> rely >> on VBT. >> + */ >> +ddie_present = IS_SKYLAKE(dev) && >> +(dev_priv >> ->vbt.ddi_port_info[PORT_E].supports_dp >> + dev_priv >> ->vbt.ddi_port_info[PORT_E].supports_dvi >> + dev_priv >> ->vbt.ddi_port_info[PORT_E].supports_hdmi); > [Zhang, Xiong Y] ddie_present should be ddi_e_present >> >> init_hdmi = (dev_priv >> ->vbt.ddi_port_info[port].supports_dvi || >> dev_priv >> ->vbt.ddi_port_info[port].supports_hdmi); >> @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct >> drm_device >> *dev, enum port port) >> intel_dig_port->port = port; >> intel_dig_port->saved_port_bits = >> I915_READ(DDI_BUF_CTL(port)) & >> >> (DDI_BUF_PORT_REVERSAL | >> - >> DDI_A_4_LANES); >> + >> ddi_e_present ? 0 : >> DDI_A_4_LANES); > [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes > when > DDI-E doesn't exist, I think your patch will do nothing. Actually DDI_A_4_LANES is being already set unconditionally, so Sonika's patch has no effect. >>> [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under >>> many >>> conditions. >>> + if (IS_SKYLAKE(dev) && port == PORT_A >>> + && !(val & DDI_BUF_CTL_ENABLE) >>> + && !dev_priv->vbt.ddi_e_used) >>> + I915_WRITE(DDI_BUF_CTL(port), val | >>> DDI_A_4_LANES) saved_port_bits goes to intel_dp->DP that goes to DDI_BUF_CTL and also it is used to calculate the number of lanes. With this patch we stop setting DDI_A_4_LANES when ddi_e is present so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E >>> [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES >>> when ddi_e >>> is present. >>> But this patch won't set DDI_A_4_LANES under following >>> conditions >>> which is purpose for Sonika patch 1. Bios fail to driver eDP >>> and >>> doesn't enable DDI_A buffer >> >> If DDI_A isn't enabled we don't need to set DDI_A_4_LANES > [Zhang, Xiong Y] From commit message on Sonika patch, she want to > set DDI_A_4_LANES on such case. Maybe she met such fail case on > one high > resolution eDP screen. Let's Sonikia explain it. >> >>> 2. Bios clear DDI_A_4_LANES >>> 3. DDI_E isn't present >> >> I don't agree... This is already covered on current code. >> DDI_A_4_LANES is >> already being set when enabling DDI_A. >> As Zhang mentioned and as my commit message explains, my patch is needed when bios failed to drive edp (In my case it was an intermediate frequency supported panel which wa
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Make updating pipe without modeset atomic.
On Thu, Aug 27, 2015 at 04:06:46PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 15:58 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 03:44:05PM +0200, Maarten Lankhorst wrote:
> >> Instead of doing a hack during primary plane commit the state
> >> is updated during atomic evasion. It handles differences in
> >> pipe size and the panel fitter.
> >>
> >> This is continuing on top of Daniel's work to make faster
> >> modesets atomic, and not yet enabled by default.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/i915/intel_atomic.c | 2 +-
> >> drivers/gpu/drm/i915/intel_display.c | 110
> >> ++-
> >> drivers/gpu/drm/i915/intel_drv.h | 2 +
> >> 3 files changed, 72 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 9336e8030980..8287b81287a0 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -98,8 +98,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> >>return NULL;
> >>
> >>__drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->base);
> >> -
> >>crtc_state->base.crtc = crtc;
> >> + crtc_state->update_pipe = false;
> >>
> >>return &crtc_state->base;
> >> }
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 7b5dfe2f7b2d..d3874a68cdb9 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -108,6 +108,9 @@ static void skl_init_scalers(struct drm_device *dev,
> >> struct intel_crtc *intel_cr
> >>struct intel_crtc_state *crtc_state);
> >> static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
> >> int num_connectors);
> >> +static void skylake_pfit_enable(struct intel_crtc *crtc);
> >> +static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
> >> +static void ironlake_pfit_enable(struct intel_crtc *crtc);
> >> static void intel_modeset_setup_hw_state(struct drm_device *dev);
> >>
> >> typedef struct {
> >> @@ -3305,14 +3308,20 @@ static bool intel_crtc_has_pending_flip(struct
> >> drm_crtc *crtc)
> >>return pending;
> >> }
> >>
> >> -static void intel_update_pipe_size(struct intel_crtc *crtc)
> >> +static void intel_update_pipe_config(struct intel_crtc *crtc,
> >> + struct intel_crtc_state *old_crtc_state)
> >> {
> >>struct drm_device *dev = crtc->base.dev;
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >> - const struct drm_display_mode *adjusted_mode;
> >> + struct intel_crtc_state *pipe_config =
> >> + to_intel_crtc_state(crtc->base.state);
> >>
> >> - if (!i915.fastboot)
> >> - return;
> >> + /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
> >> + crtc->base.mode = crtc->base.state->mode;
> >> +
> >> + DRM_DEBUG_KMS("Updating pipe size %ix%i -> %ix%i\n",
> >> +old_crtc_state->pipe_src_w, old_crtc_state->pipe_src_h,
> >> +pipe_config->pipe_src_w, pipe_config->pipe_src_h);
> >>
> >>if (HAS_DDI(dev))
> >>intel_set_pipe_csc(&crtc->base);
> >> @@ -3324,27 +,26 @@ static void intel_update_pipe_size(struct
> >> intel_crtc *crtc)
> >> * fastboot case, we'll flip, but if we don't update the pipesrc and
> >> * pfit state, we'll end up with a big fb scanned out into the wrong
> >> * sized surface.
> >> - *
> >> - * To fix this properly, we need to hoist the checks up into
> >> - * compute_mode_changes (or above), check the actual pfit state and
> >> - * whether the platform allows pfit disable with pipe active, and only
> >> - * then update the pipesrc and pfit state, even on the flip path.
> >> */
> >>
> >> - adjusted_mode = &crtc->config->base.adjusted_mode;
> >> -
> >>I915_WRITE(PIPESRC(crtc->pipe),
> >> - ((adjusted_mode->crtc_hdisplay - 1) << 16) |
> >> - (adjusted_mode->crtc_vdisplay - 1));
> >> - if (!crtc->config->pch_pfit.enabled &&
> >> - (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
> >> - intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
> >> - I915_WRITE(PF_CTL(crtc->pipe), 0);
> >> - I915_WRITE(PF_WIN_POS(crtc->pipe), 0);
> >> - I915_WRITE(PF_WIN_SZ(crtc->pipe), 0);
> >> + ((pipe_config->pipe_src_w - 1) << 16) |
> >> + (pipe_config->pipe_src_h - 1));
> >> +
> >> + /* on skylake this is done by detaching scalers */
> >> + if (INTEL_INFO(dev)->gen == 9) {
> >> + skl_detach_scalers(crtc);
> >> +
> >> + if (pipe_config->pch_pfit.enabled)
> >> + skylake_pfit_enable(crtc);
> >> + }
> >> + else if (INTEL_INFO(dev)->gen < 9 &&
> >> + HAS_PCH_SPLIT(dev)) {
> >> + if (pipe_config->pch_pfit.enabled)
> >> + ironlake_pfit_ena
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
On Thu, Aug 27, 2015 at 03:28:53PM +0100, Daniel Stone wrote: > Hi, > > On 27 August 2015 at 15:09, Ville Syrjälä > wrote: > > On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote: > >> Op 27-08-15 om 15:50 schreef Ville Syrjälä: > >> > I don't think so. Speaking for i915, I think we've just rejected legacy > >> > page > >> > flips entirely with the pipe is off on account of drm_vblank_get() > >> > failing. > >> No atomic driver handles this case correctly. You can't get vblank events > >> with the crtc off. > > > > I don't understand what you're saying. Should there be a comma after > > "No" ? If not, then I'm not sure what they don't handle. > > I think you're arguing over the definition of 'correctly' perhaps? > > >> >> I don't see why this should be relaxed. It just complicates things and > >> >> you have nothing to stick in for the vblank counter. > >> > We could stick the last vbl count/timestamp in there. > >> > > >> > Not allowing means userspace is forced to consider the dpms state > >> > whenever it wants to call the atomic ioctl. > >> Userspace was the one turning off the crtc in the first place; it > >> shouldn't continue flipping but preserve power. :-) > > > > Meh. Much simpler to write code when you don't have to worry about such > > details. > > > > In the kernel it should amount to > > if (!pipe_active) > > send_event > > No, thankyou. Asking for an event, having the request succeed, and > never getting an event, is a deathtrap. Obviously the event gets sent if the operation succeeds. I never suggested anything else. > PAGE_FLIP_EVENT should mean > that either an event gets delivered for every CRTC in crtc_state, or > the request getting rejected. Nothing else. > > > We anyway need something like that for the crtc getting disabled case, > > don't we? > > Yes, which I was getting at previously. We know when the CRTC gets > disabled - we have to, in order to sensibly unpin etc - so that's when > the event gets sent. > > Cheers, > Daniel -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/atomic: Reject events for inactive crtc's.
Hi,
On 6 August 2015 at 13:49, Daniel Vetter wrote:
> On Thu, Aug 06, 2015 at 01:19:35PM +0200, Maarten Lankhorst wrote:
>> Op 06-08-15 om 11:47 schreef Daniel Stone:
>> > On 30 July 2015 at 08:03, Maarten Lankhorst
>> > wrote:
>> >> + if (!state->active && state->event) {
>> >> + DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not
>> >> active\n",
>> >> +crtc->base.id);
>> >> + return -EINVAL;
>> >> + }
>> > Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
>> > && state->event.
>> How do you want to send a vblank event after disabling?
>
> The event would be when we stop scanning out, but yeah that's a bit a
> tricky one. I guess for now (until we have someone who needs this) we
> could just merge Maarten's patch as the easier thing to do right now?
> Maybe with a small code comment that this is intentional?
Exactly that. Surely this (when the CRTC actually goes dark) is
something we already know? Assuming you don't have atomic_disable /
instant-scanout-stop, and have to wait until the next vblank to kill
it, then how does this work?
- create FB
- assign FB to plane on CRTC
- unreference FB such that plane holds the last remaining reference
- set plane->fb == NULL + crtc->active = 0, i.e. SetCrtc(NULL, 0, 0,
0, 0, ...)
You can't immediately unpin/destroy the FB since you might still be
mid-scanout. So you already need to defer this, and that would be the
point at which you stop scanout. In a lot of hardware, this is just
another latched register which takes effect on the next vblank, for
which you still catch an IRQ - at which point you send the event. If
you actually have atomic_disable hardware that stops scanout
immediately, you can just send the event immediately.
What am I missing?
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/6] drm/dp: i2c-over-aux short write support
On Thu, Aug 27, 2015 at 05:34:45PM +0300, Jani Nikula wrote: > On Thu, 27 Aug 2015, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > I found these lying around in a branch. Most have r-b or ack from last time > > [1] (the tegra patch doesn't). I also included the radeon 20bit AUX address > > fix that seems to have fallen through the cracks as well. > > > > I rebased these on top of my i2c-over-aux retry count series [2] since that > > fixes a regression and so it's more urgent to get in. > > How about pushing both to a branch on some repo, and throwing them at > some of the bugs we have open? Pushed the lot to: git://github.com/vsyrjala/linux.git i2c_aux_short_write_4 It's sitting top of drm-intel-nightly from a few days ago. > > BR, > Jani. > > > > > [1] http://lists.freedesktop.org/archives/dri-devel/2015-March/079254.html > > [2] http://lists.freedesktop.org/archives/dri-devel/2015-August/089250.html > > > > Ville Syrjälä (6): > > drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/ > > drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE > > drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE > > drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes > > drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE > > requests > > drm/radeon: Send out the full AUX address > > > > drivers/gpu/drm/drm_dp_helper.c | 43 > > > > drivers/gpu/drm/i915/intel_dp.c | 1 + > > drivers/gpu/drm/radeon/atombios_dp.c | 6 +++-- > > drivers/gpu/drm/tegra/dpaux.c| 3 ++- > > include/drm/drm_dp_helper.h | 2 +- > > 5 files changed, 47 insertions(+), 8 deletions(-) > > > > -- > > 2.4.6 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Jani Nikula, Intel Open Source Technology Center -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.
On 27 August 2015 at 15:34, Ville Syrjälä wrote: > On Thu, Aug 27, 2015 at 03:28:53PM +0100, Daniel Stone wrote: >> On 27 August 2015 at 15:09, Ville Syrjälä >> wrote: >> > In the kernel it should amount to >> > if (!pipe_active) >> > send_event >> >> No, thankyou. Asking for an event, having the request succeed, and >> never getting an event, is a deathtrap. > > Obviously the event gets sent if the operation succeeds. I never > suggested anything else. Er, yeah. Totally missed the ! in the condition. As you were. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/atomic: Reject events for inactive crtc's.
On Thu, Aug 27, 2015 at 03:36:09PM +0100, Daniel Stone wrote:
> Hi,
>
> On 6 August 2015 at 13:49, Daniel Vetter wrote:
> > On Thu, Aug 06, 2015 at 01:19:35PM +0200, Maarten Lankhorst wrote:
> >> Op 06-08-15 om 11:47 schreef Daniel Stone:
> >> > On 30 July 2015 at 08:03, Maarten Lankhorst
> >> > wrote:
> >> >> + if (!state->active && state->event) {
> >> >> + DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not
> >> >> active\n",
> >> >> +crtc->base.id);
> >> >> + return -EINVAL;
> >> >> + }
> >> > Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
> >> > && state->event.
> >> How do you want to send a vblank event after disabling?
> >
> > The event would be when we stop scanning out, but yeah that's a bit a
> > tricky one. I guess for now (until we have someone who needs this) we
> > could just merge Maarten's patch as the easier thing to do right now?
> > Maybe with a small code comment that this is intentional?
>
> Exactly that. Surely this (when the CRTC actually goes dark) is
> something we already know? Assuming you don't have atomic_disable /
> instant-scanout-stop, and have to wait until the next vblank to kill
> it, then how does this work?
> - create FB
> - assign FB to plane on CRTC
> - unreference FB such that plane holds the last remaining reference
> - set plane->fb == NULL + crtc->active = 0, i.e. SetCrtc(NULL, 0, 0,
> 0, 0, ...)
>
> You can't immediately unpin/destroy the FB since you might still be
> mid-scanout. So you already need to defer this, and that would be the
> point at which you stop scanout. In a lot of hardware, this is just
> another latched register which takes effect on the next vblank, for
> which you still catch an IRQ - at which point you send the event. If
> you actually have atomic_disable hardware that stops scanout
> immediately, you can just send the event immediately.
>
> What am I missing?
The userspace which actually wants this and the testcases which makes sure
it works. Until we have that I'd really prefer to just close that
undefined behaviour gap in the atomic api, similar to how we just merged a
patch to disallow switching live planes.
We can always extend this later on easily, there's lots of little features
like this that people suggested for atomic.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Protect MST retraining with connection_mutex
From: Ville Syrjälä
Grab the connection_mutex around MSR link retraining to protect it
against a concurrent modeset. We already do the same for SST.
DP hpd_pulse can still otherwise race against modeset and ->detect(), so
it's not clear what will happen when both want to scribble into eg.
intel_dp->dpcd[] at the same time. But sorting it all out requires way
more thought than I'm willing to expend now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9e90a2b..1259c9b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4391,6 +4391,7 @@ update_status:
static int
intel_dp_check_mst_status(struct intel_dp *intel_dp)
{
+ struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
bool bret;
if (intel_dp->is_mst) {
@@ -4402,6 +4403,8 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
go_again:
if (bret == true) {
+ drm_modeset_lock(&dev->mode_config.connection_mutex,
NULL);
+
/* check link status - esi[10] = 0x200c */
if (intel_dp->active_mst_links &&
!drm_dp_channel_eq_ok(&esi[10],
intel_dp->lane_count)) {
@@ -4411,6 +4414,8 @@ go_again:
intel_dp_stop_link_train(intel_dp);
}
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
DRM_DEBUG_KMS("got esi %3ph\n", esi);
ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi,
&handled);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: MST link training locking and cleanups
From: Ville Syrjälä While glancing at the MST hpd code I noticed we have no locking in there to protect the link retraining against a concurrent modeset. So I added some, and then ocd struct and had to clean up the code a bit. These patches are available at git://github.com/vsyrjala/linux.git mst_fixes_cleanups In the repo I've also included an earlier patch which attempts to enable the DDI PLL for MST on SKL [1] [1] http://lists.freedesktop.org/archives/intel-gfx/2015-August/073965.html Ville Syrjälä (3): drm/i915: Protect MST retraining with connection_mutex drm/i915: Flatten the mst suspend/resume functions a bit drm/i915: Flatten intel_dp_check_mst_status() drivers/gpu/drm/i915/intel_dp.c | 127 1 file changed, 65 insertions(+), 62 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Flatten the mst suspend/resume functions a bit
From: Ville Syrjälä
I'm not a fan of deeply nested ifs. Just pull most of the conditions
into a single place to flatten things a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1259c9b..6c34784 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6252,15 +6252,14 @@ void intel_dp_mst_suspend(struct drm_device *dev)
/* disable MST */
for (i = 0; i < I915_MAX_PORTS; i++) {
struct intel_digital_port *intel_dig_port =
dev_priv->hotplug.irq_port[i];
- if (!intel_dig_port)
+
+ if (!intel_dig_port ||
+ intel_dig_port->base.type != INTEL_OUTPUT_DISPLAYPORT ||
+ !intel_dig_port->dp.can_mst)
continue;
- if (intel_dig_port->base.type == INTEL_OUTPUT_DISPLAYPORT) {
- if (!intel_dig_port->dp.can_mst)
- continue;
- if (intel_dig_port->dp.is_mst)
-
drm_dp_mst_topology_mgr_suspend(&intel_dig_port->dp.mst_mgr);
- }
+ if (intel_dig_port->dp.is_mst)
+
drm_dp_mst_topology_mgr_suspend(&intel_dig_port->dp.mst_mgr);
}
}
@@ -6271,18 +6270,15 @@ void intel_dp_mst_resume(struct drm_device *dev)
for (i = 0; i < I915_MAX_PORTS; i++) {
struct intel_digital_port *intel_dig_port =
dev_priv->hotplug.irq_port[i];
- if (!intel_dig_port)
- continue;
- if (intel_dig_port->base.type == INTEL_OUTPUT_DISPLAYPORT) {
- int ret;
+ int ret;
- if (!intel_dig_port->dp.can_mst)
- continue;
+ if (!intel_dig_port ||
+ intel_dig_port->base.type != INTEL_OUTPUT_DISPLAYPORT ||
+ !intel_dig_port->dp.can_mst)
+ continue;
- ret =
drm_dp_mst_topology_mgr_resume(&intel_dig_port->dp.mst_mgr);
- if (ret != 0) {
- intel_dp_check_mst_status(&intel_dig_port->dp);
- }
- }
+ ret =
drm_dp_mst_topology_mgr_resume(&intel_dig_port->dp.mst_mgr);
+ if (ret)
+ intel_dp_check_mst_status(&intel_dig_port->dp);
}
}
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Flatten intel_dp_check_mst_status()
From: Ville Syrjälä
Restructure intel_dp_check_mst_status() to be more straightforward to
read.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 92 +
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6c34784..033ee20 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4392,62 +4392,64 @@ static int
intel_dp_check_mst_status(struct intel_dp *intel_dp)
{
struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+ u8 esi[16];
bool bret;
- if (intel_dp->is_mst) {
- u8 esi[16] = { 0 };
- int ret = 0;
- int retry;
+ if (!intel_dp->is_mst)
+ return -EINVAL;
+
+ bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
+
+ if (!bret) {
+ DRM_DEBUG_KMS("failed to get ESI - device may have failed\n");
+ intel_dp->is_mst = false;
+ drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
+ /* send a hotplug event */
+ drm_kms_helper_hotplug_event(dev);
+
+ return -EINVAL;
+ }
+
+ for (;;) {
bool handled;
- bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
-go_again:
- if (bret == true) {
+ int retry;
+ int ret;
- drm_modeset_lock(&dev->mode_config.connection_mutex,
NULL);
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
- /* check link status - esi[10] = 0x200c */
- if (intel_dp->active_mst_links &&
- !drm_dp_channel_eq_ok(&esi[10],
intel_dp->lane_count)) {
- DRM_DEBUG_KMS("channel EQ not ok,
retraining\n");
- intel_dp_start_link_train(intel_dp);
- intel_dp_complete_link_train(intel_dp);
- intel_dp_stop_link_train(intel_dp);
- }
+ /* check link status - esi[10] = 0x200c */
+ if (intel_dp->active_mst_links &&
+ !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) {
+ DRM_DEBUG_KMS("channel EQ not ok, retraining\n");
+ intel_dp_start_link_train(intel_dp);
+ intel_dp_complete_link_train(intel_dp);
+ intel_dp_stop_link_train(intel_dp);
+ }
- drm_modeset_unlock(&dev->mode_config.connection_mutex);
- DRM_DEBUG_KMS("got esi %3ph\n", esi);
- ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi,
&handled);
-
- if (handled) {
- for (retry = 0; retry < 3; retry++) {
- int wret;
- wret = drm_dp_dpcd_write(&intel_dp->aux,
-
DP_SINK_COUNT_ESI+1,
-&esi[1], 3);
- if (wret == 3) {
- break;
- }
- }
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
- bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
- if (bret == true) {
- DRM_DEBUG_KMS("got esi2 %3ph\n", esi);
- goto go_again;
- }
- } else
- ret = 0;
+ DRM_DEBUG_KMS("got esi %3ph\n", esi);
+ ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, &handled);
- return ret;
- } else {
- struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
- DRM_DEBUG_KMS("failed to get ESI - device may have
failed\n");
- intel_dp->is_mst = false;
- drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
- /* send a hotplug event */
-
drm_kms_helper_hotplug_event(intel_dig_port->base.base.dev);
+ if (!handled)
+ return 0;
+
+ for (retry = 0; retry < 3; retry++) {
+ int wret = drm_dp_dpcd_write(&intel_dp->aux,
+DP_SINK_COUNT_ESI+1,
+&esi[1], 3);
+ if (wret == 3)
+ break;
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Rename BXT PORTA HPD defines
On Wed, Aug 26, 2015 at 09:59:13PM +, Runyan, Arthur J wrote: > > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> On Wed, Aug 26, 2015 at 04:13:52PM -0300, Paulo Zanoni wrote: > ... > >> Although the doc for LPT _suggests_ this is only for LPT:LP, it > >> doesn't mark this bit as LPT:LP-specific just like it marks all the > >> other LPT:LP-specific bits in every register, so I wonder if this is > >> really LPT:LP or if there's another way to find this out, like some > >> strap or VBT bit. > > > >Hmm. Indeed. There is that note about the enable being in the north > >on DevLPT:H. I guess that's what gave me the idea for this patch. But > >the rest of the text just talks about PCH being on the same package or > >not. Not sure if the two conditions are entirely the same thing. > > > >For HSW the north register says we need this on DevHSW:ULT. For BDW it > >refers us to a package type indication in FUSE_STRAP3, but the only > >relevant looking bit is the ULT mode bit, which it also says is > >currently unused and should be ignored :( > > > >Art, could you help us out here? How should we actually determine > >(on HSW/BDW) whether to enable the DDI A HPD in the north, south, > >or both? > > The north and south hotplug control registers have text to try to explain > this in the DDI A HPD enable fields, which I pasted below. You always enable > north. You additionally enable south if CPU and PCH are in the same package. OK thanks. That more or less matches my original understanding. > > "This only applies to systems that have the CPU and PCH in the same package, > where the DDI A HPD input is connected to the PCH and the HPD must be enabled > in both the North Display Engine Registers HOTPLUG_CTL and the South Display > Engine Registers SHOTPLUG_CTL. The HPD status is found in North Display > Engine Registers HOTPLUG_CTL. > > On systems that have the CPU and PCH in separate packages, the DDI A HPD > input is connected to the CPU, and the DDI A HPD input must be enabled in > only the North Display Engine Registers HOTPLUG_CTL." > > That fuse may not be correct on all SKUs, but I assume you have other ways to > recognize what kind of package it is. I originally listed out ULT and ULX, > but it became more complicated with BDW. I'm not aware of any way of identifying the package type. My original assumption was LPT-LP -> MCP, LPT-H -> separate package, and most of the material I've managed to dig up would seem to support that. But it's hard to be sure. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set the map-and-fenceable flag for preallocated objects
On 08/27/2015 01:36 AM, Jani Nikula wrote:
> On Wed, 26 Aug 2015, Daniel Vetter wrote:
>> On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:
>>> As we mark the preallocated objects as bound, we should also flag them
>>> correctly as being map-and-fenceable (if appropriate!) so that latter
>>> users do not get confused and try and rebind the pinned vma in order to
>>> get a map-and-fenceable binding.
>>>
>>> Signed-off-by: Chris Wilson
>>> Cc: "Goel, Akash"
>>> Cc: Daniel Vetter
>>> Cc: Jesse Barnes
>>> Cc: sta...@vger.kernel.org
>>
>> Reviewed-by: Daniel Vetter
>>
>> Jani, can you please pick up both? And some bugzilla references for either
>> would be great too - Chris?
>
> Both pushed to drm-intel-next-fixes. Thanks for the patches and review.
This one breaks my HSW. I hit the warn in
int
i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view,
uint32_t alignment,
uint64_t flags)
{
if (WARN_ONCE(!view, "no view specified"))
return -EINVAL;
return i915_gem_object_do_pin(obj, i915_obj_to_ggtt(obj), view,
alignment, flags | PIN_GLOBAL);
}
and the fb console doesn't come up. Is this a merge error somehow? I don't
see how it could have worked... maybe w/o fbdev enabled or something?
Thanks,
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Support GuC version 4.3
On 18/08/15 22:32, yu@intel.com wrote:
From: Alex Dai
The firmware layout changes that now it only has css header +
uCode + RSA signature. Plus, other trivial changes to support
GuC V4.3.
Signed-off-by: Alex Dai
Reviewed-by: Dave Gordon
This works with the version 4.3 binary currently available for download
from 01.org :)
---
drivers/gpu/drm/i915/intel_guc_fwif.h | 11 ---
drivers/gpu/drm/i915/intel_guc_loader.c | 17 ++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 950c7e7..e1f47ba 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -41,7 +41,7 @@
#define GUC_CTX_PRIORITY_NORMAL 3
#define GUC_MAX_GPU_CONTEXTS 1024
-#defineGUC_INVALID_CTX_ID (GUC_MAX_GPU_CONTEXTS + 1)
+#defineGUC_INVALID_CTX_ID GUC_MAX_GPU_CONTEXTS
/* Work queue item header definitions */
#define WQ_STATUS_ACTIVE 1
@@ -75,6 +75,7 @@
#define GUC_CTX_DESC_ATTR_RESET (1 << 4)
#define GUC_CTX_DESC_ATTR_WQLOCKED(1 << 5)
#define GUC_CTX_DESC_ATTR_PCH (1 << 6)
+#define GUC_CTX_DESC_ATTR_TERMINATED (1 << 7)
/* The guc control data is 10 DWORDs */
#define GUC_CTL_CTXINFO 0
@@ -107,6 +108,7 @@
#define GUC_CTL_DISABLE_SCHEDULER (1 << 4)
#define GUC_CTL_PREEMPTION_LOG (1 << 5)
#define GUC_CTL_ENABLE_SLPC (1 << 7)
+#define GUC_CTL_RESET_ON_PREMPT_FAILURE (1 << 8)
#define GUC_CTL_DEBUG 8
#define GUC_LOG_VERBOSITY_SHIFT 0
#define GUC_LOG_VERBOSITY_LOW (0 << GUC_LOG_VERBOSITY_SHIFT)
@@ -116,8 +118,9 @@
/* Verbosity range-check limits, without the shift */
#define GUC_LOG_VERBOSITY_MIN 0
#define GUC_LOG_VERBOSITY_MAX 3
+#define GUC_CTL_RSRVD 9
-#define GUC_CTL_MAX_DWORDS (GUC_CTL_DEBUG + 1)
+#define GUC_CTL_MAX_DWORDS (GUC_CTL_RSRVD + 1)
struct guc_doorbell_info {
u32 db_status;
@@ -207,7 +210,9 @@ struct guc_context_desc {
u32 engine_presence;
- u32 reserved0[1];
+ u8 engine_suspended;
+
+ u8 reserved0[3];
u64 reserved1[1];
u64 desc_private;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index d46195c..7521eac 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,7 +59,7 @@
*
*/
-#define I915_SKL_GUC_UCODE "i915/skl_guc_ver3.bin"
+#define I915_SKL_GUC_UCODE "i915/skl_guc_ver4.bin"
MODULE_FIRMWARE(I915_SKL_GUC_UCODE);
/* User-friendly representation of an enum */
@@ -226,10 +226,6 @@ static inline bool guc_ucode_response(struct
drm_i915_private *dev_priv,
* +---+
* | RSA signature | 256B
* +---+
- * | RSA public Key| 256B
- * +---+
- * | Public key modulus |4B
- * +---+
*
* Architecturally, the DMA engine is bidirectional, and can potentially even
* transfer between GTT locations. This functionality is left out of the API
@@ -244,7 +240,6 @@ static inline bool guc_ucode_response(struct
drm_i915_private *dev_priv,
#define UOS_VER_MAJOR_OFFSET 0x46
#define UOS_CSS_HEADER_SIZE 0x80
#define UOS_RSA_SIG_SIZE 0x100
-#define UOS_CSS_SIGNING_SIZE 0x204
static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv)
{
@@ -256,7 +251,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
*dev_priv)
int i, ret = 0;
/* uCode size, also is where RSA signature starts */
- offset = ucode_size = guc_fw->guc_fw_size - UOS_CSS_SIGNING_SIZE;
+ offset = ucode_size = guc_fw->guc_fw_size - UOS_RSA_SIG_SIZE;
I915_WRITE(DMA_COPY_SIZE, ucode_size);
/* Copy RSA signature from the fw image to HW for verification */
@@ -471,8 +466,8 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
struct drm_i915_gem_object *obj;
const struct firmware *fw;
const u8 *css_header;
- const size_t minsize = UOS_CSS_HEADER_SIZE + UOS_CSS_SIGNING_SIZE;
- const size_t maxsize = GUC_WOPCM_SIZE_VALUE + UOS_CSS_SIGNING_SIZE
+ const size_t minsize = UOS_CSS_HEADER_SIZE + UOS_RSA_SIG_SIZE;
+ const size_t maxsize = GUC_WOPCM_SIZE_VALUE + UOS_RSA_SIG_SIZE
- 0x8000; /* 32k reserved (8K stack + 24k context) */
int err;
@@ -572,8 +567,8 @@ void intel_guc_ucode_init(struct drm_device *dev)
fw_path = NULL;
} else if (IS_SKYLAKE(dev)) {
fw_path = I915_SKL_GUC_UCODE;
- guc_fw->guc_fw_major_wan
Re: [Intel-gfx] [PATCH 04/11] drm/i915: Add HAS_PCH_LPT_LP() macro
On Wed, Aug 26, 2015 at 03:58:11PM -0300, Paulo Zanoni wrote:
> 2015-08-12 12:44 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Make LPT:LP checks look neater by wrapping the details in a
> > new HAS_PCH_LPT_LP() macro.
>
> This has the potential to be confusing since HAS_PCH_LPT() is also
> true for cases where HAS_PCH_LPT_LP() is true. Maybe we could rename
> the macro in some way that it wouldn't be HAS_PCH_XXX in order to
> reduce the probability of confusion? But I can't think of any
> suggestions...
We could rename HAS_PCH_LPT to HAS_PCH_LPT_LP_OR_H but that's just too
ugly IMO. I guess it might be clearer if we also had HAS_PCH_LPT_H but
since we have not use for both adding one is a bit dubious. So no nice
ideas here either.
>
> Anyway, the patch is technically correct, so I'll let the decision to
> you and Daniel.
> Reviewed-by: Paulo Zanoni
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 13 +
> > drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> > 3 files changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 55611d8..4e391dd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2573,6 +2573,7 @@ struct drm_i915_cmd_table {
> > #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
> > #define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
> > #define HAS_PCH_LPT(dev) (INTEL_PCH_TYPE(dev) == PCH_LPT)
> > +#define HAS_PCH_LPT_LP(dev) (__I915__(dev)->pch_id ==
> > INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
> > #define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
> > #define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
> > #define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 4b3012b..97c6368 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8381,8 +8381,7 @@ static void lpt_enable_clkout_dp(struct drm_device
> > *dev, bool with_spread,
> >
> > if (WARN(with_fdi && !with_spread, "FDI requires downspread\n"))
> > with_spread = true;
> > - if (WARN(dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE &&
> > -with_fdi, "LP PCH doesn't have FDI\n"))
> > + if (WARN(HAS_PCH_LPT_LP(dev) && with_fdi, "LP PCH doesn't have
> > FDI\n"))
> > with_fdi = false;
> >
> > mutex_lock(&dev_priv->sb_lock);
> > @@ -8405,8 +8404,7 @@ static void lpt_enable_clkout_dp(struct drm_device
> > *dev, bool with_spread,
> > }
> > }
> >
> > - reg = (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
> > - SBI_GEN0 : SBI_DBUFF0;
> > + reg = HAS_PCH_LPT_LP(dev) ? SBI_GEN0 : SBI_DBUFF0;
> > tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
> > tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
> > intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
> > @@ -8422,8 +8420,7 @@ static void lpt_disable_clkout_dp(struct drm_device
> > *dev)
> >
> > mutex_lock(&dev_priv->sb_lock);
> >
> > - reg = (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
> > - SBI_GEN0 : SBI_DBUFF0;
> > + reg = HAS_PCH_LPT_LP(dev) ? SBI_GEN0 : SBI_DBUFF0;
> > tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
> > tmp &= ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
> > intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
> > @@ -9435,7 +9432,7 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv)
> >
> > DRM_DEBUG_KMS("Enabling package C8+\n");
> >
> > - if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
> > + if (HAS_PCH_LPT_LP(dev)) {
> > val = I915_READ(SOUTH_DSPCLK_GATE_D);
> > val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
> > I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
> > @@ -9455,7 +9452,7 @@ void hsw_disable_pc8(struct drm_i915_private
> > *dev_priv)
> > hsw_restore_lcpll(dev_priv);
> > lpt_init_pch_refclk(dev);
> >
> > - if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
> > + if (HAS_PCH_LPT_LP(dev)) {
> > val = I915_READ(SOUTH_DSPCLK_GATE_D);
> > val |= PCH_LP_PARTITION_LEVEL_DISABLE;
> > I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index fff0c226..ea49661 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6588,7 +6588,7 @@ static void lpt_init_clock_gating(struct drm_device
> > *dev)
> > * TODO: this bit should only be enabled when really needed, then
> > * disabled when not needed anymore in order to save power.
> > */
> > - if (dev_priv->pch_id ==
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Introduce spt_irq_handler()
On Thu, Aug 27, 2015 at 10:38:25AM +0300, Jani Nikula wrote:
> On Thu, 27 Aug 2015, Paulo Zanoni wrote:
> > 2015-08-12 12:44 GMT-03:00 :
> >> From: Ville Syrjälä
> >>
> >> Starting from SPT the only interrupts living in the south are GMBUS and
> >> HPD. What's worse some of the SPT specific new bits conflict with some
> >> other bits on earlier PCH generations. So better not use the
> >> cpt_irq_handler() for SPT+ anymore.
> >>
> >> Also kill the hand rolled port E handling with something more
> >> standardish. This also avoids accidentally confusing port B and port E
> >> long pulses since the bits occupy the same positions, just in different
> >> registers.
> >>
> >> Also add a comment noting that the short pulse duration bits are
> >> reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the
> >> MBZ in the spec.
> >>
> >> Signed-off-by: Ville Syrjälä
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 123
> >> +++-
> >> 1 file changed, 83 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index d12106c..e2485bd 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -1260,6 +1260,16 @@ static bool bxt_port_hotplug_long_detect(enum port
> >> port, u32 val)
> >> }
> >> }
> >>
> >> +static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> >> +{
> >> + switch (port) {
> >> + case PORT_E:
> >> + return val & PORTE_HOTPLUG_LONG_DETECT;
> >> + default:
> >> + return false;
> >> + }
> >> +}
> >> +
> >> static bool pch_port_hotplug_long_detect(enum port port, u32 val)
> >> {
> >> switch (port) {
> >> @@ -1269,8 +1279,6 @@ static bool pch_port_hotplug_long_detect(enum port
> >> port, u32 val)
> >> return val & PORTC_HOTPLUG_LONG_DETECT;
> >> case PORT_D:
> >> return val & PORTD_HOTPLUG_LONG_DETECT;
> >> - case PORT_E:
> >> - return val & PORTE_HOTPLUG_LONG_DETECT;
> >> default:
> >> return false;
> >> }
> >> @@ -1771,12 +1779,7 @@ static void cpt_irq_handler(struct drm_device *dev,
> >> u32 pch_iir)
> >> {
> >> struct drm_i915_private *dev_priv = dev->dev_private;
> >> int pipe;
> >> - u32 hotplug_trigger;
> >> -
> >> - if (HAS_PCH_SPT(dev))
> >> - hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT;
> >> - else
> >> - hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> >> + u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> >>
> >> if (hotplug_trigger) {
> >> u32 dig_hotplug_reg, pin_mask, long_mask;
> >> @@ -1784,22 +1787,10 @@ static void cpt_irq_handler(struct drm_device
> >> *dev, u32 pch_iir)
> >> dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> >> I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> >>
> >> - if (HAS_PCH_SPT(dev)) {
> >> - intel_get_hpd_pins(&pin_mask, &long_mask,
> >> - hotplug_trigger,
> >> - dig_hotplug_reg, hpd_spt,
> >> - pch_port_hotplug_long_detect);
> >> -
> >> - /* detect PORTE HP event */
> >> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
> >> - if (pch_port_hotplug_long_detect(PORT_E,
> >> -dig_hotplug_reg))
> >> - long_mask |= 1 << HPD_PORT_E;
> >> - } else
> >> - intel_get_hpd_pins(&pin_mask, &long_mask,
> >> - hotplug_trigger,
> >> - dig_hotplug_reg, hpd_cpt,
> >> - pch_port_hotplug_long_detect);
> >> + intel_get_hpd_pins(&pin_mask, &long_mask,
> >> + hotplug_trigger,
> >> + dig_hotplug_reg, hpd_cpt,
> >> + pch_port_hotplug_long_detect);
> >>
> >> intel_hpd_irq_handler(dev, pin_mask, long_mask);
> >> }
> >> @@ -1833,6 +1824,42 @@ static void cpt_irq_handler(struct drm_device *dev,
> >> u32 pch_iir)
> >> cpt_serr_int_handler(dev);
> >> }
> >>
> >> +static void spt_irq_handler(struct drm_device *dev, u32 pch_iir)
> >> +{
> >> + struct drm_i915_private *dev_priv = dev->dev_private;
> >> + u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT &
> >> + ~SDE_PORTE_HOTPLUG_SPT;
> >> + u32 hotplug2_trigger = pch_iir & SDE_PORTE_HOTPLUG_SPT;
> >> +
> >> + if (hotplug_trigger) {
> >> + u32 dig_hotplug_reg, pin_mask, long_mask;
> >> +
> >> +
Re: [Intel-gfx] [PATCH] drm/i915: Set the map-and-fenceable flag for preallocated objects
On Thu, Aug 27, 2015 at 09:19:18AM -0700, Jesse Barnes wrote:
> On 08/27/2015 01:36 AM, Jani Nikula wrote:
> > On Wed, 26 Aug 2015, Daniel Vetter wrote:
> >> On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:
> >>> As we mark the preallocated objects as bound, we should also flag them
> >>> correctly as being map-and-fenceable (if appropriate!) so that latter
> >>> users do not get confused and try and rebind the pinned vma in order to
> >>> get a map-and-fenceable binding.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> Cc: "Goel, Akash"
> >>> Cc: Daniel Vetter
> >>> Cc: Jesse Barnes
> >>> Cc: sta...@vger.kernel.org
> >>
> >> Reviewed-by: Daniel Vetter
> >>
> >> Jani, can you please pick up both? And some bugzilla references for either
> >> would be great too - Chris?
> >
> > Both pushed to drm-intel-next-fixes. Thanks for the patches and review.
>
> This one breaks my HSW. I hit the warn in
>
>
> int
> i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
>const struct i915_ggtt_view *view,
>uint32_t alignment,
>uint64_t flags)
> {
> if (WARN_ONCE(!view, "no view specified"))
> return -EINVAL;
>
> return i915_gem_object_do_pin(obj, i915_obj_to_ggtt(obj), view,
> alignment, flags | PIN_GLOBAL);
> }
>
> and the fb console doesn't come up. Is this a merge error somehow? I don't
> see how it could have worked... maybe w/o fbdev enabled or something?
No, it was just written against a different pin interface.
Use i915_gem_obj_ggtt_pin() instead.
Exactly.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Rename BXT PORTA HPD defines
On Wed, Aug 26, 2015 at 04:13:52PM -0300, Paulo Zanoni wrote:
> 2015-08-12 12:44 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > The PORTA HPD defines are not BXT specific. They also exist on SPT,
> > and partially already on LPT:LP.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 2 +-
> > drivers/gpu/drm/i915/i915_reg.h | 10 +-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8a1e35e..d12106c 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1248,7 +1248,7 @@ static bool bxt_port_hotplug_long_detect(enum port
> > port, u32 val)
> > {
> > switch (port) {
> > case PORT_A:
> > - return val & BXT_PORTA_HOTPLUG_LONG_DETECT;
> > + return val & PORTA_HOTPLUG_LONG_DETECT;
> > case PORT_B:
> > return val & PORTB_HOTPLUG_LONG_DETECT;
> > case PORT_C:
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index ed2d150..0e9990b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6002,11 +6002,11 @@ enum skl_disp_power_wells {
> >
> > /* digital port hotplug */
> > #define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
> > -#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
> > -#define BXT_PORTA_HOTPLUG_STATUS_MASK (3 << 24)
> > -#define BXT_PORTA_HOTPLUG_NO_DETECT (0 << 24)
> > -#define BXT_PORTA_HOTPLUG_SHORT_DETECT(1 << 24)
> > -#define BXT_PORTA_HOTPLUG_LONG_DETECT (2 << 24)
> > +#define PORTA_HOTPLUG_ENABLE (1 << 28) /* LPT:LP+ & BXT */
>
> Although the doc for LPT _suggests_ this is only for LPT:LP, it
> doesn't mark this bit as LPT:LP-specific just like it marks all the
> other LPT:LP-specific bits in every register, so I wonder if this is
> really LPT:LP or if there's another way to find this out, like some
> strap or VBT bit.
Just did a quick experiment and the bit won't stick on my desktop machine
with LPT-H, but it will on a ULT with LPT-LP. So looks like that part of
the patch is at least correct, unless some strap would affect whether
the bit even sticks or not.
>
> Reviewed-by: Paulo Zanoni
>
> > +#define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
> > +#define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
> > +#define PORTA_HOTPLUG_SHORT_DETECT(1 << 24) /* SPT+ & BXT */
> > +#define PORTA_HOTPLUG_LONG_DETECT (2 << 24) /* SPT+ & BXT */
> > #define PORTD_HOTPLUG_ENABLE (1 << 20)
> > #define PORTD_PULSE_DURATION_2ms (0 << 18)
> > #define PORTD_PULSE_DURATION_4_5ms(1 << 18)
> > --
> > 2.4.6
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Introduce spt_irq_handler()
On Thu, Aug 27, 2015 at 07:13:49PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 27, 2015 at 10:38:25AM +0300, Jani Nikula wrote:
> > On Thu, 27 Aug 2015, Paulo Zanoni wrote:
> > > 2015-08-12 12:44 GMT-03:00 :
> > >> From: Ville Syrjälä
> > >>
> > >> Starting from SPT the only interrupts living in the south are GMBUS and
> > >> HPD. What's worse some of the SPT specific new bits conflict with some
> > >> other bits on earlier PCH generations. So better not use the
> > >> cpt_irq_handler() for SPT+ anymore.
> > >>
> > >> Also kill the hand rolled port E handling with something more
> > >> standardish. This also avoids accidentally confusing port B and port E
> > >> long pulses since the bits occupy the same positions, just in different
> > >> registers.
> > >>
> > >> Also add a comment noting that the short pulse duration bits are
> > >> reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the
> > >> MBZ in the spec.
> > >>
> > >> Signed-off-by: Ville Syrjälä
> > >> ---
> > >> drivers/gpu/drm/i915/i915_irq.c | 123
> > >> +++-
> > >> 1 file changed, 83 insertions(+), 40 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > >> b/drivers/gpu/drm/i915/i915_irq.c
> > >> index d12106c..e2485bd 100644
> > >> --- a/drivers/gpu/drm/i915/i915_irq.c
> > >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> > >> @@ -1260,6 +1260,16 @@ static bool bxt_port_hotplug_long_detect(enum
> > >> port port, u32 val)
> > >> }
> > >> }
> > >>
> > >> +static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> > >> +{
> > >> + switch (port) {
> > >> + case PORT_E:
> > >> + return val & PORTE_HOTPLUG_LONG_DETECT;
> > >> + default:
> > >> + return false;
> > >> + }
> > >> +}
> > >> +
> > >> static bool pch_port_hotplug_long_detect(enum port port, u32 val)
> > >> {
> > >> switch (port) {
> > >> @@ -1269,8 +1279,6 @@ static bool pch_port_hotplug_long_detect(enum port
> > >> port, u32 val)
> > >> return val & PORTC_HOTPLUG_LONG_DETECT;
> > >> case PORT_D:
> > >> return val & PORTD_HOTPLUG_LONG_DETECT;
> > >> - case PORT_E:
> > >> - return val & PORTE_HOTPLUG_LONG_DETECT;
> > >> default:
> > >> return false;
> > >> }
> > >> @@ -1771,12 +1779,7 @@ static void cpt_irq_handler(struct drm_device
> > >> *dev, u32 pch_iir)
> > >> {
> > >> struct drm_i915_private *dev_priv = dev->dev_private;
> > >> int pipe;
> > >> - u32 hotplug_trigger;
> > >> -
> > >> - if (HAS_PCH_SPT(dev))
> > >> - hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT;
> > >> - else
> > >> - hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> > >> + u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
> > >>
> > >> if (hotplug_trigger) {
> > >> u32 dig_hotplug_reg, pin_mask, long_mask;
> > >> @@ -1784,22 +1787,10 @@ static void cpt_irq_handler(struct drm_device
> > >> *dev, u32 pch_iir)
> > >> dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> > >> I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> > >>
> > >> - if (HAS_PCH_SPT(dev)) {
> > >> - intel_get_hpd_pins(&pin_mask, &long_mask,
> > >> - hotplug_trigger,
> > >> - dig_hotplug_reg, hpd_spt,
> > >> - pch_port_hotplug_long_detect);
> > >> -
> > >> - /* detect PORTE HP event */
> > >> - dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
> > >> - if (pch_port_hotplug_long_detect(PORT_E,
> > >> -
> > >> dig_hotplug_reg))
> > >> - long_mask |= 1 << HPD_PORT_E;
> > >> - } else
> > >> - intel_get_hpd_pins(&pin_mask, &long_mask,
> > >> - hotplug_trigger,
> > >> - dig_hotplug_reg, hpd_cpt,
> > >> - pch_port_hotplug_long_detect);
> > >> + intel_get_hpd_pins(&pin_mask, &long_mask,
> > >> + hotplug_trigger,
> > >> + dig_hotplug_reg, hpd_cpt,
> > >> + pch_port_hotplug_long_detect);
> > >>
> > >> intel_hpd_irq_handler(dev, pin_mask, long_mask);
> > >> }
> > >> @@ -1833,6 +1824,42 @@ static void cpt_irq_handler(struct drm_device
> > >> *dev, u32 pch_iir)
> > >> cpt_serr_int_handler(dev);
> > >> }
> > >>
> > >> +static void spt_irq_handler(struct drm_device *dev, u32 pch_iir)
> > >> +{
> > >> + struct drm_i915_private *dev_priv = dev->dev_private;
> > >> + u32 ho
Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
On Thu, 2015-08-27 at 17:31 +0300, Timo Aaltonen wrote: > On 27.08.2015 05:52, Zhang, Xiong Y wrote: > > > On Wed, 2015-08-26 at 11:15 +0300, Jani Nikula wrote: > > > > On Thu, 13 Aug 2015, "Jindal, Sonika" > > > > wrote: > > > > > On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote: > > > > > > > On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote: > > > > > > > > > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y > > > > > > > > > wrote: > > > > > > > > > > > -Original Message- > > > > > > > > > > > From: Vivi, Rodrigo > > > > > > > > > > > Sent: Saturday, August 8, 2015 8:34 AM > > > > > > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > > > > > > Cc: Vivi, Rodrigo; Zhang, Xiong Y > > > > > > > > > > > Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI > > > > > > > > > > > -A > > > > > > > > > > > shares 4 > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > DDI-A and DDI-E shares the 4 lanes. So when DDI-E > > > > > > > > > > > is > > > > > > > > > > > present we > > > > > > > > > > > need to configure lane count propperly for both. > > > > > > > > > > > > > > > > > > > > > > This was based on Sonika's > > > > > > > > > > > [PATCH] drm/i915/skl: Select DDIA lane capability > > > > > > > > > > > based > > > > > > > > > > > upon vbt > > > > > > > > > > > > > > > > > > > > > > Credits-to: Sonika Jindal < > > > > > > > > > > > sonika.jin...@intel.com> > > > > > > > > > > > Cc: Xiong Zhang > > > > > > > > > > > Signed-off-by: Rodrigo Vivi < > > > > > > > > > > > rodrigo.v...@intel.com> > > > > > > > > > > > --- > > > > > > > > > > > drivers/gpu/drm/i915/intel_ddi.c | 12 > > > > > > > > > > > ++-- > > > > > > > > > > > drivers/gpu/drm/i915/intel_dp.c | 8 +--- > > > > > > > > > > > 2 files changed, 15 insertions(+), 5 deletions( > > > > > > > > > > > -) > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > > > > > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c > > > > > > > > > > > index 110d546..557cecf 100644 > > > > > > > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > > > > > > > > > > @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct > > > > > > > > > > > drm_device > > > > > > > > > > > *dev, enum port port) > > > > > > > > > > > struct intel_digital_port > > > > > > > > > > > *intel_dig_port; > > > > > > > > > > > struct intel_encoder *intel_encoder; > > > > > > > > > > > struct drm_encoder *encoder; > > > > > > > > > > > - bool init_hdmi, init_dp; > > > > > > > > > > > + bool init_hdmi, init_dp, ddi_e_present; > > > > > > > > > > > + > > > > > > > > > > > + /* > > > > > > > > > > > + * On SKL we don't have a way to detect > > > > > > > > > > > DDI-E > > > > > > > > > > > so we > > > > > > > > > > > rely > > > > > > > > > > > on VBT. > > > > > > > > > > > + */ > > > > > > > > > > > + ddie_present = IS_SKYLAKE(dev) && > > > > > > > > > > > + (dev_priv > > > > > > > > > > > ->vbt.ddi_port_info[PORT_E].supports_dp > > > > > > > > > > > > > > > > > > > > > > > > + dev_priv > > > > > > > > > > > ->vbt.ddi_port_info[PORT_E].supports_dvi > > > > > > > > > > > > > > > > > > > > > > > > + dev_priv > > > > > > > > > > > ->vbt.ddi_port_info[PORT_E].supports_hdmi); > > > > > > > > > > [Zhang, Xiong Y] ddie_present should be > > > > > > > > > > ddi_e_present > > > > > > > > > > > > > > > > > > > > > > init_hdmi = (dev_priv > > > > > > > > > > > ->vbt.ddi_port_info[port].supports_dvi || > > > > > > > > > > >dev_priv > > > > > > > > > > > ->vbt.ddi_port_info[port].supports_hdmi); > > > > > > > > > > > @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct > > > > > > > > > > > drm_device > > > > > > > > > > > *dev, enum port port) > > > > > > > > > > > intel_dig_port->port = port; > > > > > > > > > > > intel_dig_port->saved_port_bits = > > > > > > > > > > > I915_READ(DDI_BUF_CTL(port)) & > > > > > > > > > > > > > > > > > > > > > > (DDI_BUF_PORT_REVERSAL | > > > > > > > > > > > - > > > > > > > > > > > DDI_A_4_LANES); > > > > > > > > > > > + > > > > > > > > > > > ddi_e_present ? 0 : > > > > > > > > > > > DDI_A_4_LANES); > > > > > > > > > > [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 > > > > > > > > > > lanes > > > > > > > > > > when > > > > > > > > > > DDI-E doesn't exist, I think your patch will do > > > > > > > > > > nothing. > > > > > > > > > > > > > > > > > > Actually DDI_A_4_LANES is being already set > > > > > > > > > unconditionally, so > > > > > > > > > Sonika's patch has no effect. > > > > > > > > [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES > > > > > > > > under > > > > > > > > many > > > > > > > > conditions. > > > > > > > > + if (IS_SKYLAKE(dev) && port == PORT_A > > > > > > > > + && !(val & DDI_BUF_CTL_ENABLE) > > > > > > > > + && !dev_priv->vbt.ddi_e_used) > > > > > > > > +
[Intel-gfx] [[PATCH]] drm/i915: Detect virtual south bridge
From: Robert Beckett
Virtualized systems often use a virtual P2X4 south bridge.
Detect this in intel_detect_pch and make a best guess as to which PCH
we should be using.
This was seen on vmware esxi hypervisor. When passing the graphics device
through to a guest, it can not pass through the PCH. Instead it simulates
a P2X4 southbridge.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/i915_drv.c | 30 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ce3bd0c..8e158b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -443,6 +443,34 @@ static const struct pci_device_id pciidlist[] = {
/* aka */
MODULE_DEVICE_TABLE(pci, pciidlist);
+static enum intel_pch intel_virt_detect_pch(struct drm_device *dev)
+{
+ enum intel_pch ret = PCH_NOP;
+
+ /*
+* In a virtualized passthrough environment we can be in a
+* setup where the ISA bridge is not able to be passed through.
+* In this case, a south bridge can be emulated and we have to
+* make an educated guess as to which PCH is really there.
+*/
+
+ if (IS_GEN5(dev)) {
+ ret = PCH_IBX;
+ DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
+ } else if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
+ ret = PCH_CPT;
+ DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
+ } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
+ ret = PCH_LPT;
+ DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
+ } else if (IS_SKYLAKE(dev)) {
+ ret = PCH_SPT;
+ DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
+ }
+
+ return ret;
+}
+
void intel_detect_pch(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -503,6 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev));
+ } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
+ dev_priv->pch_type = intel_virt_detect_pch(dev);
} else
continue;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c93845..6eb0230 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2584,6 +2584,7 @@ struct drm_i915_cmd_table {
#define INTEL_PCH_LPT_LP_DEVICE_ID_TYPE0x9c00
#define INTEL_PCH_SPT_DEVICE_ID_TYPE 0xA100
#define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
+#define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
#define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
#define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] doc: drm: Fix mis-spelling of i915_guc_submission includes
On 24/08/15 14:41, Graham Whaley wrote: In commit d1675198e: drm/i915: Integrate GuC-based command submission the drm.tmpl include lines reference the intel_guc_submission.c but the patch adds the file i915_guc_submission.c. drm.tmpl fails to build with: docproc: .//drivers/gpu/drm/i915/intel_guc_submission.c: No such file or directory Change the file reference to the actual file. Signed-off-by: Graham Whaley --- This looks/feels like the right fix to me, but I am not intimate enough with the APIs to verify for sure - some confirmation would be good. Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index a01fca9..66bc646 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -4160,8 +4160,8 @@ int num_ioctls; GuC Client -!Pdrivers/gpu/drm/i915/intel_guc_submission.c GuC-based command submissison -!Idrivers/gpu/drm/i915/intel_guc_submission.c +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison +!Idrivers/gpu/drm/i915/i915_guc_submission.c Yes, that file got renamed late in development, and obviously the drm.tmpl entry wasn't updated to match. Reviewed-by: Dave Gordon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915: Add port A HPD support for ILK/SNB
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> ILK/SNB support port A HPD. While HPD is optional on eDP let's at least
> try to wite it up so that we might notice if the link has issues.
>
> The eDP spec suggests that if HPD is not wired up, one should poll the
> link status instead. We don't even do that currently.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 59
> ++---
> 1 file changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index e2485bd..152be8b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -45,6 +45,10 @@
> * and related files, but that will be described in separate chapters.
> */
>
> +static const u32 hpd_ilk[HPD_NUM_PINS] = {
> + [HPD_PORT_A] = DE_DP_A_HOTPLUG,
> +};
> +
> static const u32 hpd_ibx[HPD_NUM_PINS] = {
> [HPD_CRT] = SDE_CRT_HOTPLUG,
> [HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
> @@ -1270,6 +1274,16 @@ static bool spt_port_hotplug2_long_detect(enum port
> port, u32 val)
> }
> }
>
> +static bool ilk_port_hotplug_long_detect(enum port port, u32 val)
> +{
> + switch (port) {
> + case PORT_A:
> + return val & DIGITAL_PORTA_HOTPLUG_LONG_DETECT;
> + default:
> + return false;
> + }
> +}
> +
> static bool pch_port_hotplug_long_detect(enum port port, u32 val)
> {
> switch (port) {
> @@ -1864,6 +1878,19 @@ static void ilk_display_irq_handler(struct drm_device
> *dev, u32 de_iir)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> enum pipe pipe;
> + u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG;
> +
> + if (hotplug_trigger) {
> + u32 dig_hotplug_reg, pin_mask, long_mask;
> +
> + dig_hotplug_reg = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
> + I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> + dig_hotplug_reg, hpd_ilk,
> + ilk_port_hotplug_long_detect);
> + intel_hpd_irq_handler(dev, pin_mask, long_mask);
> + }
>
> if (de_iir & DE_AUX_CHANNEL_A)
> dp_aux_irq_handler(dev);
> @@ -3105,6 +3132,28 @@ static void spt_hpd_irq_setup(struct drm_device *dev)
> I915_WRITE(PCH_PORT_HOTPLUG2, hotplug);
> }
>
> +static void ilk_hpd_irq_setup(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 hotplug_irqs, hotplug, enabled_irqs;
> +
> + hotplug_irqs = DE_DP_A_HOTPLUG;
> + enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
> +
> + ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
> +
> + /*
> +* Enable digital hotplug on the CPU, and configure the DP short pulse
> +* duration to 2ms (which is the minimum in the Display Port spec)
> +*/
> + hotplug = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
> + hotplug &= ~DIGITAL_PORTA_PULSE_DURATION_MASK;
> + hotplug |= DIGITAL_PORTA_HOTPLUG_ENABLE |
> DIGITAL_PORTA_PULSE_DURATION_2ms;
> + I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, hotplug);
> +
> + ibx_hpd_irq_setup(dev);
> +}
> +
> static void bxt_hpd_irq_setup(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -3203,8 +3252,9 @@ static int ironlake_irq_postinstall(struct drm_device
> *dev)
> DE_AUX_CHANNEL_A |
> DE_PIPEB_CRC_DONE | DE_PIPEA_CRC_DONE |
> DE_POISON);
> - extra_mask = DE_PIPEA_VBLANK | DE_PIPEB_VBLANK | DE_PCU_EVENT
> |
> - DE_PIPEB_FIFO_UNDERRUN |
> DE_PIPEA_FIFO_UNDERRUN;
> + extra_mask = (DE_PIPEA_VBLANK | DE_PIPEB_VBLANK |
> DE_PCU_EVENT |
> + DE_PIPEB_FIFO_UNDERRUN | DE_PIPEA_FIFO_UNDERRUN
> |
> + DE_DP_A_HOTPLUG);
> }
>
> dev_priv->irq_mask = ~display_mask;
> @@ -4220,7 +4270,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> dev->driver->irq_uninstall = ironlake_irq_uninstall;
> dev->driver->enable_vblank = ironlake_enable_vblank;
> dev->driver->disable_vblank = ironlake_disable_vblank;
> - dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
> + if (INTEL_INFO(dev)->gen >= 7)
> + dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
> + else
> + dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
> } else {
> if (INTEL_INFO(dev_priv)->gen == 2) {
> dev->driver->irq_preinstall = i8xx_irq_preinstall;
[Intel-gfx] [RFC 2/2] drm/i915: Skip continguous dwords which are zeros
From: Peter Antoine
To reduce the amount of data being output the dump removes continguous
zeros to try and reduce the dump size. Not all the pages of context
contain valid data so it helps to reduce dump output.
Signed-off-by: Peter Antoine
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9c5c42d..11cdd2c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1983,7 +1983,6 @@ static void i915_dump_lrc_obj(struct seq_file *m,
int i;
int j;
unsigned long ggtt_offset = 0;
- int hws_page_index;
seq_printf(m, "CONTEXT: %s %u\n", ring->name,
intel_execlists_ctx_id(ctx_obj));
@@ -1999,27 +1998,51 @@ static void i915_dump_lrc_obj(struct seq_file *m,
}
i = 0;
- hws_page_index = LRC_PPHWSP_PN;
for_each_sg_page(ctx_obj->pages->sgl, &sg_iter,
ctx_obj->pages->nents, 0) {
if (dump_type == LRC_CONTEXT_DUMP) {
- if (i < hws_page_index) {
+ if (i < LRC_PPHWSP_PN) {
++i;
continue;
- } else if (i > hws_page_index)
+ } else if (i > LRC_PPHWSP_PN)
break;
}
page = sg_page_iter_page(&sg_iter);
if (!WARN_ON(page == NULL)) {
+ int run_length = 0;
+ unsigned long page_offset = ggtt_offset + i*PAGE_SIZE;
+
reg_state = kmap_atomic(page);
+ seq_printf(m, "Context object Page: %d\n", i);
for (j = 0; j < PAGE_SIZE / sizeof(u32); j += 4) {
+ if (reg_state[j + 0] == 0 && reg_state[j + 1]
== 0 &&
+ reg_state[j + 2] == 0 && reg_state[j + 3]
== 0) {
+ run_length += 4;
+ continue;
+ }
+
+ if (run_length > 0) {
+ seq_printf(m, "\t[0x%08lx - 0x%08lx]:
0x\n",
+ page_offset + (j * 4) -
(run_length * 4),
+ page_offset + (j * 4) - 1);
+
+ run_length = 0;
+ }
+
seq_printf(m, "\t[0x%08lx] 0x%08x 0x%08x 0x%08x
0x%08x\n",
- ggtt_offset + 4096 + (j * 4),
- reg_state[j], reg_state[j + 1],
+ page_offset + (j * 4),
+ reg_state[j + 0], reg_state[j + 1],
reg_state[j + 2], reg_state[j + 3]);
}
+
+ if (run_length > 0) {
+ seq_printf(m, "\t[0x%08lx - 0x%08lx]:
0x\n",
+ page_offset + (j * 4) - (run_length
* 4),
+ page_offset + (j * 4) - 1);
+ run_length = 0;
+ }
kunmap_atomic(reg_state);
}
++i;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/2] drm/i915: Add a debugfs file to dump full ring contexts
From: Armin Reese
A 'cat' of the debugfs file i915_dump_lrc, dumps only the first 0x600 bytes
of each ring's register state context. It does not provide information about
the remaining portion of the register state context.
This patch adds a new file i915_context_dump which displays the ring's hws page
along with the ring's full register state context. Having this data in its
entirety will definitely help in debugging GPU hang issues to understand the
state of context.
v1: Original patch
v2: reuse i915_dump_lrc_obj instead of creating new fn.
Signed-off-by: Armin Reese
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_debugfs.c | 73 ++---
1 file changed, 52 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a28de5..9c5c42d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -46,6 +46,11 @@ enum {
PINNED_LIST,
};
+enum {
+ LRC_CONTEXT_DUMP, /* First 1536 bytes of register state ctx */
+ FULL_CONTEXT_DUMP, /* Full context (HW status + reg state ctx) */
+};
+
static const char *yesno(int v)
{
return v ? "yes" : "no";
@@ -1969,18 +1974,16 @@ static int i915_context_status(struct seq_file *m, void
*unused)
static void i915_dump_lrc_obj(struct seq_file *m,
struct intel_engine_cs *ring,
- struct drm_i915_gem_object *ctx_obj)
+ struct drm_i915_gem_object *ctx_obj,
+ unsigned long dump_type)
{
struct page *page;
+ struct sg_page_iter sg_iter;
uint32_t *reg_state;
+ int i;
int j;
unsigned long ggtt_offset = 0;
-
- if (ctx_obj == NULL) {
- seq_printf(m, "Context on %s with no gem object\n",
- ring->name);
- return;
- }
+ int hws_page_index;
seq_printf(m, "CONTEXT: %s %u\n", ring->name,
intel_execlists_ctx_id(ctx_obj));
@@ -1995,29 +1998,44 @@ static void i915_dump_lrc_obj(struct seq_file *m,
return;
}
- page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
- if (!WARN_ON(page == NULL)) {
- reg_state = kmap_atomic(page);
+ i = 0;
+ hws_page_index = LRC_PPHWSP_PN;
+ for_each_sg_page(ctx_obj->pages->sgl, &sg_iter,
+ctx_obj->pages->nents, 0) {
+ if (dump_type == LRC_CONTEXT_DUMP) {
+ if (i < hws_page_index) {
+ ++i;
+ continue;
+ } else if (i > hws_page_index)
+ break;
+ }
- for (j = 0; j < 0x600 / sizeof(u32) / 4; j += 4) {
- seq_printf(m, "\t[0x%08lx] 0x%08x 0x%08x 0x%08x
0x%08x\n",
- ggtt_offset + 4096 + (j * 4),
- reg_state[j], reg_state[j + 1],
- reg_state[j + 2], reg_state[j + 3]);
+ page = sg_page_iter_page(&sg_iter);
+ if (!WARN_ON(page == NULL)) {
+ reg_state = kmap_atomic(page);
+
+ for (j = 0; j < PAGE_SIZE / sizeof(u32); j += 4) {
+ seq_printf(m, "\t[0x%08lx] 0x%08x 0x%08x 0x%08x
0x%08x\n",
+ ggtt_offset + 4096 + (j * 4),
+ reg_state[j], reg_state[j + 1],
+ reg_state[j + 2], reg_state[j + 3]);
+ }
+ kunmap_atomic(reg_state);
}
- kunmap_atomic(reg_state);
+ ++i;
}
seq_putc(m, '\n');
}
-static int i915_dump_lrc(struct seq_file *m, void *unused)
+static int i915_dump_lrc(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring;
struct intel_context *ctx;
+ uintptr_t dump_type = (uintptr_t) node->info_ent->data;
int ret, i;
if (!i915.enable_execlists) {
@@ -2031,9 +2049,21 @@ static int i915_dump_lrc(struct seq_file *m, void
*unused)
list_for_each_entry(ctx, &dev_priv->context_list, link) {
for_each_ring(ring, dev_priv, i) {
- if (ring->default_context != ctx)
- i915_dump_lrc_obj(m, ring,
- ctx->engine[i].state);
+ if (ring->default_context != ctx) {
+ struct drm_i915_gem_object *ctx_obj =
+
Re: [Intel-gfx] [PATCH 08/11] drm/i915: Add port A HPD support for IVB/HSW
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> As with ILK/SNB wire up the port A HPD on IVB/HSW.
>
> This might be more important on HSW with PSR. BSpec tells us that if the
> automagic link training performed by the hardware fails for some reason,
> we're going to get a short HPD and are supposed to re-train the link
> manyally.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 34 +++---
> 1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 152be8b..d994b80 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -49,6 +49,10 @@ static const u32 hpd_ilk[HPD_NUM_PINS] = {
> [HPD_PORT_A] = DE_DP_A_HOTPLUG,
> };
>
> +static const u32 hpd_ivb[HPD_NUM_PINS] = {
> + [HPD_PORT_A] = DE_DP_A_HOTPLUG_IVB,
> +};
> +
> static const u32 hpd_ibx[HPD_NUM_PINS] = {
> [HPD_CRT] = SDE_CRT_HOTPLUG,
> [HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
> @@ -1940,6 +1944,19 @@ static void ivb_display_irq_handler(struct drm_device
> *dev, u32 de_iir)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> enum pipe pipe;
> + u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG_IVB;
> +
> + if (hotplug_trigger) {
> + u32 dig_hotplug_reg, pin_mask, long_mask;
> +
> + dig_hotplug_reg = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
> + I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> + dig_hotplug_reg, hpd_ivb,
> + ilk_port_hotplug_long_detect);
> + intel_hpd_irq_handler(dev, pin_mask, long_mask);
> + }
>
> if (de_iir & DE_ERR_INT_IVB)
> ivb_err_int_handler(dev);
> @@ -3137,8 +3154,13 @@ static void ilk_hpd_irq_setup(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 hotplug_irqs, hotplug, enabled_irqs;
>
> - hotplug_irqs = DE_DP_A_HOTPLUG;
> - enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
> + if (INTEL_INFO(dev)->gen >= 7) {
> + hotplug_irqs = DE_DP_A_HOTPLUG_IVB;
> + enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ivb);
> + } else {
> + hotplug_irqs = DE_DP_A_HOTPLUG;
> + enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
> + }
>
> ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
>
> @@ -3245,7 +3267,8 @@ static int ironlake_irq_postinstall(struct drm_device
> *dev)
> DE_PLANEB_FLIP_DONE_IVB |
> DE_PLANEA_FLIP_DONE_IVB |
> DE_AUX_CHANNEL_A_IVB);
> extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
> - DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB);
> + DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB |
> + DE_DP_A_HOTPLUG_IVB);
> } else {
> display_mask = (DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT
> |
> DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
> @@ -4270,10 +4293,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> dev->driver->irq_uninstall = ironlake_irq_uninstall;
> dev->driver->enable_vblank = ironlake_enable_vblank;
> dev->driver->disable_vblank = ironlake_disable_vblank;
> - if (INTEL_INFO(dev)->gen >= 7)
> - dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
> - else
> - dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
> + dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
> } else {
> if (INTEL_INFO(dev_priv)->gen == 2) {
> dev->driver->irq_preinstall = i8xx_irq_preinstall;
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] drm/i915: LPT:LP needs port A HPD enabled in both north and south
2015-08-12 12:44 GMT-03:00 : > From: Ville Syrjälä > > Supposedly we have to enable port A HPD also in the south on LPT:LP. The correctness of this patch is going to be decided by the discussion of patch 5, and up to this moment the answer we have is not 100% precise. If (conclusion == "CPU and PCH are in the same package _if and only if_ HAS_PCH_LPT_LP") Reviewed-by: Paulo Zanoni > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_irq.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index d994b80..de60174 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -3125,6 +3125,8 @@ static void ibx_hpd_irq_setup(struct drm_device *dev) > hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms; > hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms; > hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms; > + if (HAS_PCH_LPT_LP(dev)) > + hotplug |= PORTA_HOTPLUG_ENABLE; > I915_WRITE(PCH_PORT_HOTPLUG, hotplug); > } > > -- > 2.4.6 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] drm/i915: Add port A HPD support for BDW
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> Wire up the port A HPD for BDW. Compared to earlier platforms the
> interrupt setup is a bit different, but basically everything else
> looks the same.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 72
> +
> 1 file changed, 66 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index de60174..aefa6c4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -53,6 +53,10 @@ static const u32 hpd_ivb[HPD_NUM_PINS] = {
> [HPD_PORT_A] = DE_DP_A_HOTPLUG_IVB,
> };
>
> +static const u32 hpd_bdw[HPD_NUM_PINS] = {
> + [HPD_PORT_A] = GEN8_PORT_DP_A_HOTPLUG,
> +};
> +
> static const u32 hpd_ibx[HPD_NUM_PINS] = {
> [HPD_CRT] = SDE_CRT_HOTPLUG,
> [HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
> @@ -369,6 +373,36 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
> }
>
> /**
> + * bdw_update_port_irq - update DE port interrupt
> + * @dev_priv: driver private
> + * @interrupt_mask: mask of interrupt bits to update
> + * @enabled_irq_mask: mask of interrupt bits to enable
> + */
> +static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
> + uint32_t interrupt_mask,
> + uint32_t enabled_irq_mask)
> +{
> + uint32_t new_val;
> + uint32_t old_val;
> +
> + assert_spin_locked(&dev_priv->irq_lock);
Just like the other similar functions:
WARN_ON(enabled_irq_mask & ~interrupt_mask);
Besides this, there's the recurring "enable PORT A hpd on the PCH"
problem. Don't you have to patch ibx_hpd_irq_setup() to only enable
PORTA_HOTPLUG_ENABLE based on what you read from FUSE_STRAP3? At least
that's what's written on the description of 0x44030 on BDW.
Everything else looks correct.
> +
> + if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> + return;
> +
> + old_val = I915_READ(GEN8_DE_PORT_IMR);
> +
> + new_val = old_val;
> + new_val &= ~interrupt_mask;
> + new_val |= (~enabled_irq_mask & interrupt_mask);
> +
> + if (new_val != old_val) {
> + I915_WRITE(GEN8_DE_PORT_IMR, new_val);
> + POSTING_READ(GEN8_DE_PORT_IMR);
> + }
> +}
> +
> +/**
> * ibx_display_interrupt_update - update SDEIMR
> * @dev_priv: driver private
> * @interrupt_mask: mask of interrupt bits to update
> @@ -2139,10 +2173,23 @@ static irqreturn_t gen8_irq_handler(int irq, void
> *arg)
> tmp = I915_READ(GEN8_DE_PORT_IIR);
> if (tmp) {
> bool found = false;
> + u32 hotplug_trigger = tmp & GEN8_PORT_DP_A_HOTPLUG;
>
> I915_WRITE(GEN8_DE_PORT_IIR, tmp);
> ret = IRQ_HANDLED;
>
> + if (hotplug_trigger) {
> + u32 dig_hotplug_reg, pin_mask, long_mask;
> +
> + dig_hotplug_reg =
> I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
> + I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL,
> dig_hotplug_reg);
> +
> + intel_get_hpd_pins(&pin_mask, &long_mask,
> hotplug_trigger,
> + dig_hotplug_reg, hpd_bdw,
> +
> ilk_port_hotplug_long_detect);
> + intel_hpd_irq_handler(dev, pin_mask,
> long_mask);
> + }
> +
> if (tmp & aux_mask) {
> dp_aux_irq_handler(dev);
> found = true;
> @@ -3156,15 +3203,22 @@ static void ilk_hpd_irq_setup(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 hotplug_irqs, hotplug, enabled_irqs;
>
> - if (INTEL_INFO(dev)->gen >= 7) {
> + if (INTEL_INFO(dev)->gen >= 8) {
> + hotplug_irqs = GEN8_PORT_DP_A_HOTPLUG;
> + enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_bdw);
> +
> + bdw_update_port_irq(dev_priv, hotplug_irqs, enabled_irqs);
> + } else if (INTEL_INFO(dev)->gen >= 7) {
> hotplug_irqs = DE_DP_A_HOTPLUG_IVB;
> enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ivb);
> +
> + ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
> } else {
> hotplug_irqs = DE_DP_A_HOTPLUG;
> enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
> - }
>
> - ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
> + ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
> + }
>
> /*
> * Enable digital hotplug on the CPU, and configure the DP short pulse
> @@ -3477,6 +3531,7 @@ static void gen8_de_irq_postinstall(struct
