Re: [Intel-gfx] [PATCH 2/2] drm/i915: Embellish wait_end trace
On Tue, Jul 29, 2014 at 11:33:43PM -0700, Ben Widawsky wrote: > On Wed, Jul 30, 2014 at 07:19:26AM +0100, Chris Wilson wrote: > > On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote: > > > This adds two new data points to the trace event, wait time, and whether > > > or not the event slept. Both of these should already be obtainable > > > through various means. This patch just makes the data more accessible. > > > > Right, the key point is that since the advent of the wait_begin/_end > > pair is that we now allow concurrent non-blocking waits. > > > > > Wait is obtainable with the current code by matching seqnos in > > > begin/end. In simple cases where begin/ends are always paired, this is > > > trivial. However, if you queue up multiple begins/ends, it can get > > > confusing. We're already calculating wait time, so it's trivially added > > > here. This patch also provides the slightly more accurate wait_time as > > > opposed to the timestamps from the tracepoint. It's observable, but just > > > noise. > > > > > > The second bit of information, whether or not the operation slept is > > > helpful in determining where time went. This is probably also obtainable > > > through the scheduler events. However, we have the information easily at > > > our fingertips, we may as well give it out. > > > > > > This results in an event which looks like: > > > gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: > > > dev=0, ring=3, seqno=4294963203, duration=0.000368225 (slept=yes) > > > > > > While here, rename sleep_time to wait_time since the verb sleep hasn't > > > been true for a long time (several conditions exist where it won't > > > sleep). > > > > > > Signed-off-by: Ben Widawsky > > > > Other than the debate in the earlier patch, this looks fine. > > -Chris > > > > I actually don't think wait_begin is a terribly interesting event after > this patch BTW, but I didn't want to rock the boat too much. If you > agree, I can send that one as well. The only advantage is that wait_begin is before the wait, which may be significant - espcially in a time based profile. -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 2/2] drm/i915: Embellish wait_end trace
On Wed, Jul 30, 2014 at 07:19:26AM +0100, Chris Wilson wrote: > On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote: > > This adds two new data points to the trace event, wait time, and whether > > or not the event slept. Both of these should already be obtainable > > through various means. This patch just makes the data more accessible. > > Right, the key point is that since the advent of the wait_begin/_end > pair is that we now allow concurrent non-blocking waits. > > > Wait is obtainable with the current code by matching seqnos in > > begin/end. In simple cases where begin/ends are always paired, this is > > trivial. However, if you queue up multiple begins/ends, it can get > > confusing. We're already calculating wait time, so it's trivially added > > here. This patch also provides the slightly more accurate wait_time as > > opposed to the timestamps from the tracepoint. It's observable, but just > > noise. > > > > The second bit of information, whether or not the operation slept is > > helpful in determining where time went. This is probably also obtainable > > through the scheduler events. However, we have the information easily at > > our fingertips, we may as well give it out. > > > > This results in an event which looks like: > > gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: > > dev=0, ring=3, seqno=4294963203, duration=0.000368225 (slept=yes) > > > > While here, rename sleep_time to wait_time since the verb sleep hasn't > > been true for a long time (several conditions exist where it won't > > sleep). > > > > Signed-off-by: Ben Widawsky > > Other than the debate in the earlier patch, this looks fine. > -Chris > I actually don't think wait_begin is a terribly interesting event after this patch BTW, but I didn't want to rock the boat too much. If you agree, I can send that one as well. -- Ben Widawsky, 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 1/2] drm/i915: timespec_sub should already be normalized
On Wed, Jul 30, 2014 at 07:15:05AM +0100, Chris Wilson wrote: > On Tue, Jul 29, 2014 at 01:14:29PM -0700, Ben Widawsky wrote: > > So don't bother checking it again. > > This was introduced: > > commit b361237bcc7cea1d99f770490120d8bc2aed > > Author: Chris Wilson > > Date: Fri Aug 24 09:35:08 2012 +0100 > > > > drm/i915: Juggle code order to ease flow of the next patch > > > > Cc: Chris Wilson > > Signed-off-by: Ben Widawsky > > Ah, it is not so much that the timeout may be unnormalized, but that it > *may* be negative. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre >From looking at the code, I thought it didn't matter (ie. I thought it dtrt regardless of negative). However, I just wrote a little test, and you are correct. It is needed. Sorry about that. -- Ben Widawsky, 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 2/2] drm/i915: Embellish wait_end trace
On Tue, Jul 29, 2014 at 01:14:30PM -0700, Ben Widawsky wrote: > This adds two new data points to the trace event, wait time, and whether > or not the event slept. Both of these should already be obtainable > through various means. This patch just makes the data more accessible. Right, the key point is that since the advent of the wait_begin/_end pair is that we now allow concurrent non-blocking waits. > Wait is obtainable with the current code by matching seqnos in > begin/end. In simple cases where begin/ends are always paired, this is > trivial. However, if you queue up multiple begins/ends, it can get > confusing. We're already calculating wait time, so it's trivially added > here. This patch also provides the slightly more accurate wait_time as > opposed to the timestamps from the tracepoint. It's observable, but just > noise. > > The second bit of information, whether or not the operation slept is > helpful in determining where time went. This is probably also obtainable > through the scheduler events. However, we have the information easily at > our fingertips, we may as well give it out. > > This results in an event which looks like: > gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: dev=0, > ring=3, seqno=4294963203, duration=0.000368225 (slept=yes) > > While here, rename sleep_time to wait_time since the verb sleep hasn't > been true for a long time (several conditions exist where it won't > sleep). > > Signed-off-by: Ben Widawsky Other than the debate in the earlier patch, this looks fine. -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/2] drm/i915: timespec_sub should already be normalized
On Tue, Jul 29, 2014 at 01:14:29PM -0700, Ben Widawsky wrote: > So don't bother checking it again. > This was introduced: > commit b361237bcc7cea1d99f770490120d8bc2aed > Author: Chris Wilson > Date: Fri Aug 24 09:35:08 2012 +0100 > > drm/i915: Juggle code order to ease flow of the next patch > > Cc: Chris Wilson > Signed-off-by: Ben Widawsky Ah, it is not so much that the timeout may be unnormalized, but that it *may* be negative. -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 7/8] drm/irq: Implement a generic vblank_wait function
On 30.07.2014 06:32, Daniel Vetter wrote:
> As usual in both a crtc index and a struct drm_crtc * version.
>
> The function assumes that no one drivers their display below 10Hz, and
> it will complain if the vblank wait takes longer than that.
>
> v2: Also check dev->max_vblank_counter since some drivers register a
> fake get_vblank_counter function.
What does that refer to? Can't find any other reference to
max_vblank_counter in the patch.
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 0de123afdb34..76024fdde452 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -999,6 +999,51 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
> EXPORT_SYMBOL(drm_crtc_vblank_put);
>
> /**
> + * drm_vblank_wait - wait for one vblank
> + * @dev: DRM device
> + * @crtc: crtc index
> + *
> + * This waits for one vblank to pass on @crtc, using the irq driver
> interfaces.
> + * It is a failure to call this when the vblank irq for @crtc is disable,
> e.g.
Spelling: 'disabled'
> + * due to lack of driver support or because the crtc is off.
> + */
> +void drm_vblank_wait(struct drm_device *dev, int crtc)
> +{
> + int ret;
> + u32 last;
> +
> + ret = drm_vblank_get(dev, crtc);
> + if (WARN_ON(ret))
> + return;
> +
> + last = drm_vblank_count(dev, crtc);
> +
> +#define C (last != drm_vblank_count(dev, crtc))
> + ret = wait_event_timeout(dev->vblank[crtc].queue,
> + C, msecs_to_jiffies(100));
> +
> + WARN_ON(ret == 0);
> +#undef C
What's the point of the C macro?
> + drm_vblank_put(dev, crtc);
> +}
> +EXPORT_SYMBOL(drm_vblank_wait);
> +
> +/**
> + * drm_crtc_vblank_wait - wait for one vblank
> + * @crtc: DRM crtc
> + *
> + * This waits for one vblank to pass on @crtc, using the irq driver
> interfaces.
> + * It is a failure to call this when the vblank irq for @crtc is disable,
> e.g.
Same typo as above.
> + * due to lack of driver support or because the crtc is off.
> + */
> +void drm_crtc_vblank_wait(struct drm_crtc *crtc)
> +{
> + drm_vblank_wait(crtc->dev, drm_crtc_index(crtc));
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_wait);
> +
> +/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus drm_wait_vblank().
Looks good to me other than that.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/hdmi: call intel_hdmi_prepare for CHV
From: Libin Yang call the intel_hdmi_prepare() in chv_hdmi_pre_enable() for hdmi audio. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 5f8f4ca..5a65e0c 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1374,6 +1374,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder *encoder) int data, i; u32 val; + intel_hdmi_prepare(encoder); mutex_lock(&dev_priv->dpio_lock); /* Deassert soft data lane reset*/ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm: Move ->old_fb from crtc to plane
On Tue, Jul 29, 2014 at 11:32:19PM +0200, Daniel Vetter wrote:
> Atomic implemenations for legacy ioctls must be able to drop locks.
> Which doesn't cause havoc since we only do that while constructing
> the new state, so no driver or hardware state change has happened.
>
> The only troubling bit is the fb refcounting the core does - if
> someone else has snuck in then it might potentially unref an
> outdated framebuffer. To fix that move the old_fb temporary storage
> into struct drm_plane for all ioctls, so that the atomic helpers can
> update it.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 40
> include/drm/drm_crtc.h | 8
> 2 files changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index c09374038f9a..bacf565449d5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
> */
> void drm_plane_force_disable(struct drm_plane *plane)
> {
> - struct drm_framebuffer *old_fb = plane->fb;
> int ret;
>
> - if (!old_fb)
> + if (!plane->fb)
> return;
>
> + plane->old_fb = plane->fb;
> ret = plane->funcs->disable_plane(plane);
> if (ret) {
> DRM_ERROR("failed to disable plane with busy fb\n");
> + plane->old_fb = NULL;
> return;
> }
> /* disconnect the plane from the fb and crtc: */
> - __drm_framebuffer_unreference(old_fb);
> + __drm_framebuffer_unreference(plane->old_fb);
> + plane->old_fb = NULL;
> plane->fb = NULL;
> plane->crtc = NULL;
> }
> @@ -2188,7 +2190,7 @@ static int setplane_internal(struct drm_plane *plane,
>uint32_t src_w, uint32_t src_h)
> {
> struct drm_device *dev = plane->dev;
> - struct drm_framebuffer *old_fb = NULL;
> + struct drm_framebuffer *old_fb;
I think there may be cases where old_fb gets unref'd without ever being
set if we drop the NULL assignment. E.g., if the possible_crtcs test or
the format test fail, we jump down to out and then test the value +
unref which could be garbage.
Would it be simpler to just drm_modeset_lock_all() unconditionally at
the start of the function and then just unlock after the unrefs at the
end of the function so that we don't need a local old_fb?
> int ret = 0;
> unsigned int fb_width, fb_height;
> int i;
> @@ -2196,14 +2198,16 @@ static int setplane_internal(struct drm_plane *plane,
> /* No fb means shut it down */
> if (!fb) {
> drm_modeset_lock_all(dev);
> - old_fb = plane->fb;
> + plane->old_fb = plane->fb;
> ret = plane->funcs->disable_plane(plane);
> if (!ret) {
> plane->crtc = NULL;
> plane->fb = NULL;
> } else {
> - old_fb = NULL;
> + plane->old_fb = NULL;
> }
> + old_fb = plane->old_fb;
> + plane->old_fb = NULL;
> drm_modeset_unlock_all(dev);
> goto out;
> }
> @@ -2245,7 +2249,7 @@ static int setplane_internal(struct drm_plane *plane,
> }
>
> drm_modeset_lock_all(dev);
> - old_fb = plane->fb;
> + plane->old_fb = plane->fb;
> ret = plane->funcs->update_plane(plane, crtc, fb,
>crtc_x, crtc_y, crtc_w, crtc_h,
>src_x, src_y, src_w, src_h);
> @@ -2254,8 +2258,10 @@ static int setplane_internal(struct drm_plane *plane,
> plane->fb = fb;
> fb = NULL;
> } else {
> - old_fb = NULL;
> + plane->old_fb = NULL;
> }
> + old_fb = plane->old_fb;
> + plane->old_fb = NULL;
> drm_modeset_unlock_all(dev);
>
> out:
> @@ -2369,7 +2375,7 @@ int drm_mode_set_config_internal(struct drm_mode_set
> *set)
>* crtcs. Atomic modeset will have saner semantics ...
>*/
> list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head)
> - tmp->old_fb = tmp->primary->fb;
> + tmp->primary->old_fb = tmp->primary->fb;
>
> fb = set->fb;
>
> @@ -2382,8 +2388,9 @@ int drm_mode_set_config_internal(struct drm_mode_set
> *set)
> list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head) {
> if (tmp->primary->fb)
> drm_framebuffer_reference(tmp->primary->fb);
> - if (tmp->old_fb)
> - drm_framebuffer_unreference(tmp->old_fb);
> + if (tmp->primary->old_fb)
> + drm_framebuffer_unreference(tmp->primary->old_fb);
> + tmp->primary->old_fb = NULL;
> }
>
> return ret;
> @@ -4458,7 +4465,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> {
>
Re: [Intel-gfx] [PATCH 4/8] drm: Move ->old_fb from crtc to plane
On 30 July 2014 07:32, Daniel Vetter wrote: > Atomic implemenations for legacy ioctls must be able to drop locks. > Which doesn't cause havoc since we only do that while constructing > the new state, so no driver or hardware state change has happened. > > The only troubling bit is the fb refcounting the core does - if > someone else has snuck in then it might potentially unref an > outdated framebuffer. To fix that move the old_fb temporary storage > into struct drm_plane for all ioctls, so that the atomic helpers can > update it. > > Signed-off-by: Daniel Vetter Seems to make sense to me. Reviewed-by: Dave Airlie ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm: Handle legacy per-crtc locking with full acquire ctx
> ---
> drivers/gpu/drm/drm_crtc.c | 8 ++--
> drivers/gpu/drm/drm_modeset_lock.c | 84
> ++
> include/drm/drm_crtc.h | 6 +++
> include/drm/drm_modeset_lock.h | 5 +++
> 4 files changed, 99 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index ff583bec31f9..c09374038f9a 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2714,7 +2714,7 @@ static int drm_mode_cursor_common(struct drm_device
> *dev,
> if (crtc->cursor)
> return drm_mode_cursor_universal(crtc, req, file_priv);
>
> - drm_modeset_lock(&crtc->mutex, NULL);
> + drm_modeset_lock_crtc(crtc);
> if (req->flags & DRM_MODE_CURSOR_BO) {
> if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
> ret = -ENXIO;
> @@ -2738,7 +2738,7 @@ static int drm_mode_cursor_common(struct drm_device
> *dev,
> }
> }
> out:
> - drm_modeset_unlock(&crtc->mutex);
> + drm_modeset_unlock_crtc(crtc);
>
> return ret;
>
> @@ -4474,7 +4474,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> if (!crtc)
> return -ENOENT;
>
> - drm_modeset_lock(&crtc->mutex, NULL);
> + drm_modeset_lock_crtc(crtc);
> if (crtc->primary->fb == NULL) {
> /* The framebuffer is currently unbound, presumably
> * due to a hotplug event, that userspace has not
> @@ -4558,7 +4558,7 @@ out:
> drm_framebuffer_unreference(fb);
> if (old_fb)
> drm_framebuffer_unreference(old_fb);
> - drm_modeset_unlock(&crtc->mutex);
> + drm_modeset_unlock_crtc(crtc);
>
> return ret;
> }
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 73e6534fd0aa..4d2aa549c614 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -130,6 +130,90 @@ void drm_modeset_unlock_all(struct drm_device *dev)
> EXPORT_SYMBOL(drm_modeset_unlock_all);
>
> /**
> + * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx
> + * @crtc: drm crtc
> + *
> + * This function locks the given crtc using a hidden acquire context. This is
> + * necessary so that drivers internally using the atomic interfaces can grab
> + * furether locks with the lock acquire context.
^ typo - further
Otherwise
Reviewed-by: Dave Airlie
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
On 30 July 2014 07:32, Daniel Vetter wrote: > Somehow we've forgotten about this little bit of OCD. > > Signed-off-by: Daniel Vetter Reviewed-by: Dave Airlie ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm: Add drm_plane/connector_index
On Tue, Jul 29, 2014 at 11:32:16PM +0200, Daniel Vetter wrote:
> In the atomic state we'll have an array of states for crtcs, planes
> and connectors and need to be able to at them by their index. We
> already have a drm_crtc_index function so add the missing ones for
> planes and connectors.
>
> If it later on turns out that the list walking is too expensive we can
> add the index to the relevant modeset objects.
>
> Rob Clark doesn't like the loops too much, but we can always add an
> obj->idx parameter later on. And for now reiterating is actually safer
> since nowadays we have hotpluggable connectors (thanks to DP MST).
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 46
> ++
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 805240b11229..5a494caa8c9a 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> EXPORT_SYMBOL(drm_connector_cleanup);
>
> /**
> + * drm_plane_index - find the index of a registered CRTC
Looks like some copy/paste that needs an update...your kerneldoc calls
the function drm_*PLANE*_index and then talks about CRTC's, but the
actual function is for connectors...
> + * @plane: CRTC to find index for
> + *
> + * Given a registered CRTC, return the index of that CRTC within a DRM
> + * device's list of CRTCs.
> + */
> +unsigned int drm_connector_index(struct drm_connector *connector)
> +{
> + unsigned int index = 0;
> + struct drm_connector *tmp;
> +
> + list_for_each_entry(tmp, &connector->dev->mode_config.connector_list,
> head) {
> + if (tmp == connector)
> + return index;
> +
> + index++;
> + }
> +
> + BUG();
> +}
> +EXPORT_SYMBOL(drm_connector_index);
> +
> +/**
> * drm_connector_register - register a connector
> * @connector: the connector to register
> *
> @@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
> EXPORT_SYMBOL(drm_plane_cleanup);
>
> /**
> + * drm_plane_index - find the index of a registered CRTC
> + * @plane: CRTC to find index for
> + *
> + * Given a registered CRTC, return the index of that CRTC within a DRM
> + * device's list of CRTCs.
> + */
More copy/paste referenecs to CRTC's.
> +unsigned int drm_plane_index(struct drm_plane *plane)
> +{
> + unsigned int index = 0;
> + struct drm_plane *tmp;
> +
> + list_for_each_entry(tmp, &plane->dev->mode_config.plane_list, head) {
> + if (tmp == plane)
> + return index;
> +
> + index++;
> + }
> +
> + BUG();
> +}
> +EXPORT_SYMBOL(drm_plane_index);
> +
> +/**
> * drm_plane_force_disable - Forcibly disable a plane
> * @plane: plane to disable
> *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f1105d0da059..4cae44611ab0 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -903,6 +903,7 @@ int drm_connector_register(struct drm_connector
> *connector);
> void drm_connector_unregister(struct drm_connector *connector);
>
> extern void drm_connector_cleanup(struct drm_connector *connector);
> +extern unsigned int drm_connector_index(struct drm_connector *crtc);
connector?
> /* helper to unplug all connectors from sysfs for device */
> extern void drm_connector_unplug_all(struct drm_device *dev);
>
> @@ -942,6 +943,7 @@ extern int drm_plane_init(struct drm_device *dev,
> const uint32_t *formats, uint32_t format_count,
> bool is_primary);
> extern void drm_plane_cleanup(struct drm_plane *plane);
> +extern unsigned int drm_plane_index(struct drm_plane *crtc);
plane?
> extern void drm_plane_force_disable(struct drm_plane *plane);
> extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
> int x, int y,
> --
> 2.0.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm/i915: Update EDID automated test function for Displayport compliance
2014-07-14 16:10 GMT-03:00 Todd Previte :
> Implements an updated version of the automated testing function that handles
> Displayport compliance for EDID operations.
Both the commit message and the code should mention the name of the
specification that defines these tests, and also mention which
specific tests are implemented by this patch/function. I see that
there are multiple tests being implemented here, but reading the 232
pages of the spec will require too much time, so knowing which ones
are implemented really helps the reviewers :)
Also, you should tell us what happens before and after this patch when
you run your own tests. How many tests were we previously passing? How
many tests are we passing now? I see there are some FIXME lines below,
which leads to the question: is the code you provided enough and
complete, or do we still need more adjustments to pass everything we
can with what you built? In other words: is this patch, alone, already
an improvement to the situation?
>
> Signed-off-by: Todd Previte
> ---
> drivers/gpu/drm/i915/intel_dp.c | 77
> -
> 1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 33b6dc9..88f1bbe 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3408,7 +3408,82 @@ intel_dp_autotest_video_pattern(struct intel_dp
> *intel_dp)
> static uint8_t
> intel_dp_autotest_edid(struct intel_dp *intel_dp)
> {
> - uint8_t test_result = DP_TEST_NAK;
> + struct drm_connector *connector = &intel_dp->attached_connector->base;
> + struct i2c_adapter *adapter = &intel_dp->aux.ddc;
> + struct edid *edid_read = NULL;
> + uint8_t *edid_data = NULL;
> + uint8_t test_result = DP_TEST_NAK, checksum = 0;
> + uint32_t i = 0, ret = 0;
> + struct drm_display_mode *use_mode = NULL;
> + int mode_count = 0;
> + struct drm_mode_set modeset;
You have initialized every single variable you defined. This creates
the problem that unused variables are not pointed by the compiler
unless you enable the flags to warn set-but-not-used variables. For
example, "i" is unused, and "ret" is set but never used. I also don't
really see the point in, for example, NULL-initializing stuff like
edid_data and edid_read.
> +
> + DRM_DEBUG_KMS("Displayport: EDID automated test\n");
> +
> + /* Reset the NACK/DEFER counters */
As I said before, this is a great example of the "comment says what
the code already says" problem.
> + intel_dp->aux.i2c_nack_count = 0;
> + intel_dp->aux.i2c_defer_count = 0;
> + /* Now read out the EDID */
> + edid_read = drm_get_edid(connector, adapter);
> +
> + if (edid_read == NULL) {
> + /* Check for NACKs/DEFERs, goto failsafe if detected
> + (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */
Our coding standard is to put aligned '*'s on each line of a
multi-line comment. So this should be "\t\t * (DP CTS 1.2 etc..."
instead of what is above. In theory, the "/*" and "*/" strings should
be on their own lines, alone, but we are inconsistent regarding this
(even though Daniel randomly complained about this to me a few times
in the past). As usual, check Documentation/CodingStyle for better
explanations.
> + if (intel_dp->aux.i2c_nack_count > 0 ||
> + intel_dp->aux.i2c_defer_count > 0)
We tend to align the contents of the extra line with the '(' char on
the line above.
> + DRM_DEBUG_KMS("Displayport: EDID read generated %d
> I2C NACKs, %d DEFERs\n",
> +
> intel_dp->aux.i2c_nack_count,
> +
> intel_dp->aux.i2c_defer_count);
There are way too many tabs on the 2 lines above.
> + goto failsafe;
> + }
> +
> + /* FIXME: Need to determine how to detect E-DDC here (4.2.2.9) */
But what is the problem with the current code? What are the
consequences of not implementing the FIXME?
> + edid_data = (uint8_t *) edid_read;
> +
> + if (intel_dp_compute_edid_checksum(edid_data, &checksum)) {
> + /* Write the checksum to EDID checksum register */
> + ret = drm_dp_dpcd_write(&intel_dp->aux,
> +
> DP_TEST_EDID_CHECKSUM,
> +
> &edid_read->checksum, 1);
Way too many tabs above too.
> + /* Reponse is ACK and and checksum written */
> + test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
> + } else {
> + /* Invalid checksum - EDID corruption detection test */
> + goto failsafe;
> + }
> +
> + /* Update EDID modes */
> + mode_count = intel_connector_update_modes(connector, edid_r
Re: [Intel-gfx] [RFC] Move BDW workarounds to ring init fn
On 28/07/2014 18:26, Ville Syrjälä wrote: On Mon, Jul 28, 2014 at 05:31:45PM +0100, arun.siluv...@linux.intel.com wrote: From: Arun Siluvery This patch moves BDW workarounds from init_clock_gating() to render ring init fn otherwise they are lost when gpu is reset. In case of execlists, some of the workarounds modify registers that are part of register state context which doesn't get initialized until init_clock_gating(); this results in default context with incorrect values as it is restored and saved before updated by workarounds. I don't think it has to do with execlists. Many of the registers are part of the context image even in ring buffer mode AFAIK. Open issue: For Wa4x4STCOptimizationDisable, we set CACHE_MODE_1[6:6] = 1 At the time when HW contexts are enabled after rings are initialized with default context this workaround is valid but followed by a context switch this is getting reset, please see below log snippet. This is a bit weird. The default context should have restore inhibit==1 so it shouldn't clobber the CACHE_MODE_1 register. There was a specific magic dance you're supposed to do when accessing such registers with mmio, but here we do the write even before the first context switch. Apparently there was some kind of problem with CACHE_MODE_0 on snb too: commit 3a69ddd6f872180b6f61fda87152b37202118fbc Author: Kenneth Graunke Date: Fri Apr 27 12:44:41 2012 -0700 drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. but IIRC I wasn't able to reproduce it when I tried. Similar to this register I am also applying this in render ring init fn. Maybe we need to delay these register writes until we've switched to the default context? In its current state (WAs applied in init_clock_gating()) we are writing these registers after switching to default context. When a new hw context is created does all the registers part of context start with default values or they sample the current state? and at what point this sampling takes place? As a test I have updated CACHE_MODE_1 after mi_set_context() then the workaround was valid with every context switch but I think it may not be the right way otherwise we will have to update other WA registers also at this point with every context switch. regards Arun ... [5.978209] [drm:i915_pages_create_for_stolen] offset=0x0, size=8294400 [5.978213] [drm:intel_alloc_plane_obj] plane fb obj 8801472e [5.978215] [drm:i915_gem_setup_global_gtt] reserving preallocated space: 0 + 7e9000 [5.978216] [drm:i915_gem_setup_global_gtt] clearing unused GTT space: [7e9000, f000] [5.979613] [drm:i915_gem_init] CACHE_MODE_1: 0x0180 [5.981372] [drm:gen8_ppgtt_init] Allocated 4 pages for page directories (0 wasted) [5.981373] [drm:gen8_ppgtt_init] Allocated 2048 pages for page tables (0 wasted) [5.981376] [drm:i915_gem_context_init] HW context support initialized [5.981462] [drm:i915_gem_init_hw] CACHE_MODE_1: 0x0180 [5.981467] [drm:i915_gem_init_rings] CACHE_MODE_1: 0x0180 [5.981704] [drm:bdw_init_workarounds] CACHE_MODE_1: 0x01C0 [5.981716] [drm:init_status_page] bsd ring hws offset: 0x0081e000 [5.981792] [drm:init_status_page] blitter ring hws offset: 0x0083f000 [5.981910] [drm:init_status_page] video enhancement ring hws offset: 0x0086 [5.982001] [drm:i915_gem_init_hw] CACHE_MODE_1: 0x01C0 [5.982104] [drm:i915_gem_context_enable] Switch render ring to default_context [5.982106] [drm:i915_gem_render_state_init] render ring: Render state init [5.982120] [drm:do_switch] render ring, CACHE_MODE_1: 0x01C0, uninitialized: 1 [5.982121] [drm:i915_gem_context_enable] Switch bsd ring to default_context [5.982122] [drm:do_switch] bsd ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982123] [drm:i915_gem_context_enable] Switch blitter ring to default_context [5.982126] [drm:do_switch] blitter ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982126] [drm:i915_gem_context_enable] Switch video enhancement ring to default_context [5.982128] [drm:do_switch] video enhancement ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982133] [drm:i915_gem_init] CACHE_MODE_1: 0x01C0 [5.982258] [drm:intel_init_clock_gating] ... [ 10.037019] [drm:do_switch] blitter ring, CACHE_MODE_1: 0x0180, uninitialized: 0 ... [ 10.488145] [drm:do_switch] render ring, CACHE_MODE_1: 0x0180, uninitialized: 0 ... I am currently testing this with an igt which triggers a gpu reset and compares WA register contents before and after reset but the test fails because of this register hence not sending it now. Please let me know how to keep this WA valid after a context switch. Arun Siluvery (1): drm/i915/bdw: Initialize BDW workarounds in render ring init fn drivers/gpu/drm/i915/i915_debugfs.c | 46 ++ drivers/gpu/drm/i915/intel_pm.c | 59
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
Am 29.07.2014 23:35, schrieb Daniel Vetter: On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann wrote: Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with "git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915" This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi Cc: Ben Widawsky Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Hm, I'm not aware of this breaking any gm45 machines, mine here is still happy. Can you please make sure that you don't have any i915 module options set anywhere, either on the kernel cmdline, modeprobe config files in /etc or anywhere else? My kernel cmdline doesn't have anything, but /etc/modprobe.d/i915-kms.conf exists. Its content is this single line: options i915 modeset=1 Can't remember if I created that (it's from 2010) or if it's Debian default... grep -Ri i915 /etc/ doesn't show anything else. grep 915 config-3.15 CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set # CONFIG_DRM_I915_UMS is not set CONFIG_SND_HDA_I915=y Would it help if I included the driver instead of building a module? --jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: HDMI pixel replication modes now hactive of 720 for pixel replication
From: Clint Taylor
CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
to 1440. The current driver reports 1440 pixel to the OS and does not set pixel
replicated modes.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_edid.c| 68 ++---
drivers/gpu/drm/i915/intel_hdmi.c | 13 +++
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfa9769..5233f4c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,26 +632,26 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 6 - 1440x480i@60Hz */
- { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 6 - 720(1440)x480i@60Hz */
+ { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 7 - 1440x480i@60Hz */
- { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 7 - 720(1440)x480i@60Hz */
+ { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 8 - 1440x240@60Hz */
- { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 8 - 720(1440)x240@60Hz */
+ { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 9 - 1440x240@60Hz */
- { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 9 - 720(1440)x240@60Hz */
+ { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
@@ -714,26 +714,26 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 21 - 1440x576i@50Hz */
- { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 21 - 720(1440)x576i@50Hz */
+ { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 22 - 1440x576i@50Hz */
- { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 22 - 720(1440)x576i@50Hz */
+ { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 23 - 1440x288@50Hz */
- { DRM_MODE("1440x288", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 23 - 720(1440)x288@50Hz */
+ { DRM_MODE("720x288", DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 24 - 1440x288@50Hz */
- { DRM_MODE("1440x288", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 24 - 720(1440)x288@50Hz */
+ { DRM_MODE("720x288", DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
@@ -837,17 +837,17 @@ static const struct drm_display_mode edid_cea_modes[] = {
796, 864, 0, 576, 581, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
.vrefresh = 100, .pict
Re: [Intel-gfx] [PATCH v2] Displayport compliance testing
2014-07-22 18:11 GMT-03:00 Jesse Barnes : > On Tue, 22 Jul 2014 22:53:44 +0200 > Daniel Vetter wrote: > >> On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes >> wrote: >> > Are you saying >> > you'll reject this approach entirely? >> >> I'm saying that I don't see terrible lot of value in adding a bunch of >> code for a sticker, and that we should look into making it actually >> useful by testing the paths that end-users end up using. And we have >> to keep this working once it's merged. >> >> But if it doesn't make sense to make this sticker useful while still >> being able to get it then I'll reconsider. > > Yeah I think it depends on the test. We're supposed to go through > existing paths for testing e.g. link training with different params > (though with a fixed fb and mode), so getting coverage there is > something we want regardless. But getting something like probing > covered as part of the compliance testing may be something else > entirely... I was finally able to take some time to read the spec, and I agree that the hybrid approach looks like the way to go. Some tests require specifically-crafted FBs, while some other tests cause real hotplug events to be sent from the sink. If there's an unknown/unspecified user-space running when the tests are happening, who knows how it is going to react? Of course, for tests that can be implemented directly inside the Kernel still using the "standard" code paths, we should do it in the Kernel. One possible approach that I thought would be the following: - Each DP encoder provides its own debugfs file for DP test compiance (e.g., /sys/kernel/debug/dri/0/i915_ddi_b_dp_test_compliance). - If the file is not open, any requests for tests that require special actions from our driver - outside of the normal behavior - will be NACKed. - If the file is open, we ACK test requests and print special strings to the debugfs file telling the user-space app what it's supposed to do. We could use simple strings like "set the preferred mode", "set failsafe mode", "set mode using FB test pattern Y", etc. A stringly typed protocol :) - The user-space app needs to be the DRM master, open the debugfs file, parse the operations it prints and act accordingly, and listen to the hotplug events sent by the Kernel. - If some special corner quirky case needs to be done (e.g., train link with a specific number of lanes), the Kernel should store this information at struct intel_dp, and then when a modeset is done on this encoder, we check if the debugfs file is open (i.e., we're doing compliance testing) and then we use the specified configuration. With this, we can probably avoid special uevents or debug-only connector/encoder properties. - The user-space app could be part of intel-gpu-tools. Anyway, this is just an alternate idea to Daniel's suggestion, and many other possible implementation ideas would work for me. Todd, what is your opinion? I will continue the review of the patches we currently have, since it seems we didn't decide what we're gonna merge. > > -- > Jesse Barnes, Intel Open Source Technology Center > ___ > 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] i915 / 3.15 intermittently boots into blank screeen
On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann wrote: > Am 18.07.2014 18:25, schrieb Daniel Vetter: >> >> On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote: >> >>> >>> Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: > > > I'm experiencing an issue with 3.15.5 on my Lenovo T400: > Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but > the > first mode change doesn't occur, resulting in a black screen with > backlight > on. The system is entirely unresponsive and I can only press the power > button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. >>> >>> >>> thank you for the feedback. >>> I still have all my custom built kernels, I will test 3.14.0 through >>> 3.14.8 >>> to make sure those were OK and report back. >> >> >> You only need to test 3.14.0, since the backported fixes only contain >> a very small subset of all patches for 3.15. So it's more efficient to >> then switch to git bisect between 3.14 and 3.15 directly (after you've >> confirmed that 3.15.0 is indeed busted). > > I familiarized with git bisect, that was something I had never used before. > > I started it with "git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915" > > This lead me to this: > > cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit > commit cfa7c862982b431add7f2b362526bf31372fc7b0 > Author: Daniel Vetter > Date: Tue Apr 29 11:53:58 2014 +0200 > > drm/i915: Sanitize the enable_ppgtt module option once > > Otherwise we'll end up spamming dmesg on every context creation on snb > with vt-d enabled. This regression was introduced in > > commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 > Author: Ben Widawsky > Date: Fri Dec 6 14:11:14 2013 -0800 > > drm/i915: Reorganize intel_enable_ppgtt > > As the i915.enable_ppgtt is read-only it cannot be changed after the > module is loaded and so we can perform an early sanitization of the > values. > > v2: > - Add comment and pimp commit message (Chris) > - Use the param consistently (Jani) > > v3: > - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to > gtt_init. Fixes boot hangs on pre-gen6. > - Add a debug output for the sanitize ppgtt mode. > > References: https://lkml.org/lkml/2014/4/17/599 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 > Cc: Alessandro Suardi > Cc: Ben Widawsky > Cc: Chris Wilson > Reviewed-by: Chris Wilson > Signed-off-by: Daniel Vetter > Signed-off-by: Jani Nikula > > :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 > 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers > > I realized that the issue does always show, contrary to the subject > initially chosen. > > Unfortunately I can't say anything else, but maybe this will help you > experts spot the issue. > If I can help more, be it with testing or anything else, just let me know. Hm, I'm not aware of this breaking any gm45 machines, mine here is still happy. Can you please make sure that you don't have any i915 module options set anywhere, either on the kernel cmdline, modeprobe config files in /etc or anywhere else? -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 5/8] drm: trylock modest locking for fbdev panics
In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.
So add a trylock mode to the modeset locking code which attempts all
locks only with trylocks, if possible. We need to track this in the
locking functions themselves and can't restrict this to drivers since
driver-private w/w mutexes must be treated the same way.
There's still the issue that other driver private locks aren't handled
here at all, but well can't have everything. With this we will at
least not regress, even once atomic allows lots of concurrent kms
activity.
Aside: We should move the acquire context to stack-based allocation in
the callers to get rid of that awful WARN_ON(kmalloc_failed) control
flow which just blows up when memory is short. But that's material for
separate patches.
v2:
- Fix logic inversion fumble in the fb helper.
- Add proper kerneldoc.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 10 +++
drivers/gpu/drm/drm_modeset_lock.c | 56 ++
include/drm/drm_modeset_lock.h | 6
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9dc0f1..841e039ba028 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -419,11 +419,11 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
- /* NOTE: we use lockless flag below to avoid grabbing other
-* modeset locks. So just trylock the underlying mutex
-* directly:
+ /*
+* NOTE: Use trylock mode to avoid deadlocks and sleeping in
+* panic context.
*/
- if (!mutex_trylock(&dev->mode_config.mutex)) {
+ if (__drm_modeset_lock_all(dev, true) != 0) {
error = true;
continue;
}
@@ -432,7 +432,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (ret)
error = true;
- mutex_unlock(&dev->mode_config.mutex);
+ drm_modeset_unlock_all(dev);
}
return error;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 4d2aa549c614..acfe187609b0 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,26 +57,37 @@
/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
+ * __drm_modeset_lock_all - internal helper to grab all modeset locks
+ * @dev: DRM device
+ * @trylock: trylock mode for atomic contexts
*
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
+ * This is a special version of drm_modeset_lock_all() which can also be used
in
+ * atomic contexts. Then @trylock must be set to true.
+ *
+ * Returns:
+ * 0 on success or negative error code on failure.
*/
-void drm_modeset_lock_all(struct drm_device *dev)
+int __drm_modeset_lock_all(struct drm_device *dev,
+ bool trylock)
{
struct drm_mode_config *config = &dev->mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
+ ctx = kzalloc(sizeof(*ctx),
+ trylock ? GFP_ATOMIC : GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
- mutex_lock(&config->mutex);
+ if (trylock) {
+ if (!mutex_trylock(&config->mutex))
+ return -EBUSY;
+ } else {
+ mutex_lock(&config->mutex);
+ }
drm_modeset_acquire_init(ctx, 0);
+ ctx->trylock_only = trylock;
retry:
ret = drm_modeset_lock(&config->connection_mutex, ctx);
@@ -95,13 +106,29 @@ retry:
drm_warn_on_modeset_not_all_locked(dev);
- return;
+ return 0;
fail:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
goto retry;
}
+
+ return ret;
+}
+EXPORT_SYMBOL(__drm_modeset_lock_all);
+
+/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+ WARN_ON(__drm_modeset_lock_all(dev, false) != 0);
}
EXPORT_SYMBOL(drm_modeset_lock_all);
@@ -287,7 +314,12 @@ static inline int modeset_lock(struct drm_
[Intel-gfx] [PATCH 2/8] drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
Somehow we've forgotten about this little bit of OCD.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 95 --
drivers/gpu/drm/drm_modeset_lock.c | 95 ++
include/drm/drm_crtc.h | 4 --
include/drm/drm_modeset_lock.h | 5 ++
4 files changed, 100 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5a494caa8c9a..ff583bec31f9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -45,101 +45,6 @@ static struct drm_framebuffer
*add_framebuffer_internal(struct drm_device *dev,
struct drm_mode_fb_cmd2
*r,
struct drm_file
*file_priv);
-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx;
- int ret;
-
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
-
- mutex_lock(&config->mutex);
-
- drm_modeset_acquire_init(ctx, 0);
-
-retry:
- ret = drm_modeset_lock(&config->connection_mutex, ctx);
- if (ret)
- goto fail;
- ret = drm_modeset_lock_all_crtcs(dev, ctx);
- if (ret)
- goto fail;
-
- WARN_ON(config->acquire_ctx);
-
- /* now we hold the locks, so now that it is safe, stash the
-* ctx for drm_modeset_unlock_all():
-*/
- config->acquire_ctx = ctx;
-
- drm_warn_on_modeset_not_all_locked(dev);
-
- return;
-
-fail:
- if (ret == -EDEADLK) {
- drm_modeset_backoff(ctx);
- goto retry;
- }
-}
-EXPORT_SYMBOL(drm_modeset_lock_all);
-
-/**
- * drm_modeset_unlock_all - drop all modeset locks
- * @dev: device
- *
- * This function drop all modeset locks taken by drm_modeset_lock_all.
- */
-void drm_modeset_unlock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
-
- if (WARN_ON(!ctx))
- return;
-
- config->acquire_ctx = NULL;
- drm_modeset_drop_locks(ctx);
- drm_modeset_acquire_fini(ctx);
-
- kfree(ctx);
-
- mutex_unlock(&dev->mode_config.mutex);
-}
-EXPORT_SYMBOL(drm_modeset_unlock_all);
-
-/**
- * drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
- * @dev: device
- *
- * Useful as a debug assert.
- */
-void drm_warn_on_modeset_not_all_locked(struct drm_device *dev)
-{
- struct drm_crtc *crtc;
-
- /* Locking is currently fubar in the panic handler. */
- if (oops_in_progress)
- return;
-
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
-
- WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
- WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
-}
-EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
-
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 0dc57d5ecd10..73e6534fd0aa 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,6 +57,101 @@
/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ mutex_lock(&config->mutex);
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(&config->connection_mutex, ctx);
+ if (ret)
+ goto fail;
+ ret = drm_modeset_lock_all_crtcs(dev, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(config->acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_all():
+*/
+ config->acquire_ctx = ctx;
+
+ drm_warn_on_modeset_not_all_locked(dev);
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff
[Intel-gfx] [PATCH 3/8] drm: Handle legacy per-crtc locking with full acquire ctx
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those paths which grab all locks we already
have to keep around an acquire context in dev->mode_config. Helper
functions that implement legacy interfaces in terms of atomic support
can therefore grab this acquire contexts and reuse it.
The only interfaces left are the cursor and pageflip ioctls. So add
functions to grab the crtc lock these need using an acquire context
and preserve it for atomic drivers to reuse.
v2:
- Fixup comments&kerneldoc.
- Drop the WARNING from modeset_lock_all_crtcs since that can be used
in legacy paths with crtc locking.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 8 ++--
drivers/gpu/drm/drm_modeset_lock.c | 84 ++
include/drm/drm_crtc.h | 6 +++
include/drm/drm_modeset_lock.h | 5 +++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ff583bec31f9..c09374038f9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2714,7 +2714,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (crtc->cursor)
return drm_mode_cursor_universal(crtc, req, file_priv);
- drm_modeset_lock(&crtc->mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (req->flags & DRM_MODE_CURSOR_BO) {
if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
ret = -ENXIO;
@@ -2738,7 +2738,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
}
out:
- drm_modeset_unlock(&crtc->mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
@@ -4474,7 +4474,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!crtc)
return -ENOENT;
- drm_modeset_lock(&crtc->mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (crtc->primary->fb == NULL) {
/* The framebuffer is currently unbound, presumably
* due to a hotplug event, that userspace has not
@@ -4558,7 +4558,7 @@ out:
drm_framebuffer_unreference(fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
- drm_modeset_unlock(&crtc->mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 73e6534fd0aa..4d2aa549c614 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -130,6 +130,90 @@ void drm_modeset_unlock_all(struct drm_device *dev)
EXPORT_SYMBOL(drm_modeset_unlock_all);
/**
+ * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx
+ * @crtc: drm crtc
+ *
+ * This function locks the given crtc using a hidden acquire context. This is
+ * necessary so that drivers internally using the atomic interfaces can grab
+ * furether locks with the lock acquire context.
+ */
+void drm_modeset_lock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(&crtc->mutex, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(crtc->acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_crtc():
+*/
+ crtc->acquire_ctx = ctx;
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ctx);
+ goto retry;
+ }
+}
+EXPORT_SYMBOL(drm_modeset_lock_crtc);
+
+/**
+ * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
+ * crtc: drm crtc
+ *
+ * Legacy ioctl operations like cursor updates or page flips only have per-crtc
+ * locking, and store the acquire ctx in the corresponding crtc. All other
+ * legacy operations take all locks and use a global acquire context. This
+ * function grabs the right one.
+ */
+struct drm_modeset_acquire_ctx *
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
+{
+ if (crtc->acquire_ctx)
+ return crtc->acquire_ctx;
+
+ WARN_ON(!crtc->dev->mode_config.acquire_ctx);
+
+ return crtc->dev->mode_config.acquire_ctx;
+}
+EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
+
+/**
+ * drm_modeset_unlock_crtc - drop crtc lock
+ * @crtc: drm crtc
+ *
+ * This drops the crtc lock acquire with drm_modeset_lock_crtc() and all other
+ * locks acquired through the hidden context.
+ */
+void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx = crtc->ac
[Intel-gfx] [PATCH 8/8] drm/i915: Use generic vblank wait
This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 41 +---
1 file changed, 1 insertion(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1ae5b37..13bcf1348fc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -891,17 +891,6 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct
drm_i915_private *dev_priv,
return intel_crtc->config.cpu_transcoder;
}
-static void g4x_wait_for_vblank(struct drm_device *dev, int pipe)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u32 frame, frame_reg = PIPE_FRMCOUNT_GM45(pipe);
-
- frame = I915_READ(frame_reg);
-
- if (wait_for(I915_READ_NOTRACE(frame_reg) != frame, 50))
- WARN(1, "vblank wait timed out\n");
-}
-
/**
* intel_wait_for_vblank - wait for vblank on a given pipe
* @dev: drm device
@@ -912,35 +901,7 @@ static void g4x_wait_for_vblank(struct drm_device *dev,
int pipe)
*/
void intel_wait_for_vblank(struct drm_device *dev, int pipe)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- int pipestat_reg = PIPESTAT(pipe);
-
- if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
- g4x_wait_for_vblank(dev, pipe);
- return;
- }
-
- /* Clear existing vblank status. Note this will clear any other
-* sticky status fields as well.
-*
-* This races with i915_driver_irq_handler() with the result
-* that either function could miss a vblank event. Here it is not
-* fatal, as we will either wait upon the next vblank interrupt or
-* timeout. Generally speaking intel_wait_for_vblank() is only
-* called during modeset at which time the GPU should be idle and
-* should *not* be performing page flips and thus not waiting on
-* vblanks...
-* Currently, the result of us stealing a vblank from the irq
-* handler is that a single frame will be skipped during swapbuffers.
-*/
- I915_WRITE(pipestat_reg,
- I915_READ(pipestat_reg) | PIPE_VBLANK_INTERRUPT_STATUS);
-
- /* Wait for vblank interrupt bit to set */
- if (wait_for(I915_READ(pipestat_reg) &
-PIPE_VBLANK_INTERRUPT_STATUS,
-50))
- DRM_DEBUG_KMS("vblank wait timed out\n");
+ drm_vblank_wait(dev, pipe);
}
static bool pipe_dsl_stopped(struct drm_device *dev, enum pipe pipe)
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm: Move ->old_fb from crtc to plane
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 40
include/drm/drm_crtc.h | 8
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c09374038f9a..bacf565449d5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
*/
void drm_plane_force_disable(struct drm_plane *plane)
{
- struct drm_framebuffer *old_fb = plane->fb;
int ret;
- if (!old_fb)
+ if (!plane->fb)
return;
+ plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (ret) {
DRM_ERROR("failed to disable plane with busy fb\n");
+ plane->old_fb = NULL;
return;
}
/* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(old_fb);
+ __drm_framebuffer_unreference(plane->old_fb);
+ plane->old_fb = NULL;
plane->fb = NULL;
plane->crtc = NULL;
}
@@ -2188,7 +2190,7 @@ static int setplane_internal(struct drm_plane *plane,
uint32_t src_w, uint32_t src_h)
{
struct drm_device *dev = plane->dev;
- struct drm_framebuffer *old_fb = NULL;
+ struct drm_framebuffer *old_fb;
int ret = 0;
unsigned int fb_width, fb_height;
int i;
@@ -2196,14 +2198,16 @@ static int setplane_internal(struct drm_plane *plane,
/* No fb means shut it down */
if (!fb) {
drm_modeset_lock_all(dev);
- old_fb = plane->fb;
+ plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (!ret) {
plane->crtc = NULL;
plane->fb = NULL;
} else {
- old_fb = NULL;
+ plane->old_fb = NULL;
}
+ old_fb = plane->old_fb;
+ plane->old_fb = NULL;
drm_modeset_unlock_all(dev);
goto out;
}
@@ -2245,7 +2249,7 @@ static int setplane_internal(struct drm_plane *plane,
}
drm_modeset_lock_all(dev);
- old_fb = plane->fb;
+ plane->old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
@@ -2254,8 +2258,10 @@ static int setplane_internal(struct drm_plane *plane,
plane->fb = fb;
fb = NULL;
} else {
- old_fb = NULL;
+ plane->old_fb = NULL;
}
+ old_fb = plane->old_fb;
+ plane->old_fb = NULL;
drm_modeset_unlock_all(dev);
out:
@@ -2369,7 +2375,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
* crtcs. Atomic modeset will have saner semantics ...
*/
list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head)
- tmp->old_fb = tmp->primary->fb;
+ tmp->primary->old_fb = tmp->primary->fb;
fb = set->fb;
@@ -2382,8 +2388,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head) {
if (tmp->primary->fb)
drm_framebuffer_reference(tmp->primary->fb);
- if (tmp->old_fb)
- drm_framebuffer_unreference(tmp->old_fb);
+ if (tmp->primary->old_fb)
+ drm_framebuffer_unreference(tmp->primary->old_fb);
+ tmp->primary->old_fb = NULL;
}
return ret;
@@ -4458,7 +4465,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
{
struct drm_mode_crtc_page_flip *page_flip = data;
struct drm_crtc *crtc;
- struct drm_framebuffer *fb = NULL, *old_fb = NULL;
+ struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
int ret = -EINVAL;
@@ -4530,7 +4537,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
(void (*) (struct drm_pending_event *)) kfree;
}
- old_fb = crtc->primary->fb;
+ crtc->primary->old_fb = crtc->primary->fb;
ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->
[Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 45 +
include/drm/drmP.h| 2 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123afdb34..76024fdde452 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -999,6 +999,51 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
EXPORT_SYMBOL(drm_crtc_vblank_put);
/**
+ * drm_vblank_wait - wait for one vblank
+ * @dev: DRM device
+ * @crtc: crtc index
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_vblank_wait(struct drm_device *dev, int crtc)
+{
+ int ret;
+ u32 last;
+
+ ret = drm_vblank_get(dev, crtc);
+ if (WARN_ON(ret))
+ return;
+
+ last = drm_vblank_count(dev, crtc);
+
+#define C (last != drm_vblank_count(dev, crtc))
+ ret = wait_event_timeout(dev->vblank[crtc].queue,
+C, msecs_to_jiffies(100));
+
+ WARN_ON(ret == 0);
+#undef C
+
+ drm_vblank_put(dev, crtc);
+}
+EXPORT_SYMBOL(drm_vblank_wait);
+
+/**
+ * drm_crtc_vblank_wait - wait for one vblank
+ * @crtc: DRM crtc
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc->dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
* drm_vblank_off - disable vblank events on a CRTC
* @dev: DRM device
* @crtc: CRTC in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 06a673894c47..f72e5ef5f7b0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1355,6 +1355,8 @@ extern int drm_vblank_get(struct drm_device *dev, int
crtc);
extern void drm_vblank_put(struct drm_device *dev, int crtc);
extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
+extern void drm_vblank_wait(struct drm_device *dev, int crtc);
+extern void drm_crtc_vblank_wait(struct drm_crtc *crtc);
extern void drm_vblank_off(struct drm_device *dev, int crtc);
extern void drm_vblank_on(struct drm_device *dev, int crtc);
extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm: Add a plane->reset hook
In general having this can't hurt, and the atomic helpers will need
it to be able to reset the state objects properly. The overall idea
is to reset in the order pixels flow, so planes -> crtcs ->
encoders -> connectors.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 +
include/drm/drm_crtc.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bacf565449d5..ff705ea3f50e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4582,9 +4582,14 @@ out:
void drm_mode_config_reset(struct drm_device *dev)
{
struct drm_crtc *crtc;
+ struct drm_crtc *plane;
struct drm_encoder *encoder;
struct drm_connector *connector;
+ list_for_each_entry(plane, &dev->mode_config.plane_list, head)
+ if (plane->funcs->reset)
+ plane->funcs->reset(plane);
+
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
if (crtc->funcs->reset)
crtc->funcs->reset(crtc);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5fffb5c53ba6..0115b80a0632 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -580,6 +580,7 @@ struct drm_plane_funcs {
uint32_t src_w, uint32_t src_h);
int (*disable_plane)(struct drm_plane *plane);
void (*destroy)(struct drm_plane *plane);
+ void (*reset)(struct drm_plane *plane);
int (*set_property)(struct drm_plane *plane,
struct drm_property *property, uint64_t val);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] atomic prep work
Hi all, So I've split out every single hunk that touches existing code from my atomic series and this is it. It mostly touches error handling code and other more exceptional stuff. My idea is that if we get this in now we have a bit more leeway with the actual atomic infrastructure work since that won't touch any code any more which is used by current drivers. Comments, flames and reviews highly welcome. Cheers, Daniel Daniel Vetter (8): drm: Add drm_plane/connector_index drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc] drm: Handle legacy per-crtc locking with full acquire ctx drm: Move ->old_fb from crtc to plane drm: trylock modest locking for fbdev panics drm: Add a plane->reset hook drm/irq: Implement a generic vblank_wait function drm/i915: Use generic vblank wait drivers/gpu/drm/drm_crtc.c | 194 +-- drivers/gpu/drm/drm_fb_helper.c | 10 +- drivers/gpu/drm/drm_irq.c| 45 drivers/gpu/drm/drm_modeset_lock.c | 213 ++- drivers/gpu/drm/i915/intel_display.c | 41 +-- include/drm/drmP.h | 2 + include/drm/drm_crtc.h | 21 ++-- include/drm/drm_modeset_lock.h | 16 +++ 8 files changed, 373 insertions(+), 169 deletions(-) -- 2.0.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm: Add drm_plane/connector_index
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add the index to the relevant modeset objects.
Rob Clark doesn't like the loops too much, but we can always add an
obj->idx parameter later on. And for now reiterating is actually safer
since nowadays we have hotpluggable connectors (thanks to DP MST).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 46 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 805240b11229..5a494caa8c9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector *connector)
EXPORT_SYMBOL(drm_connector_cleanup);
/**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_connector_index(struct drm_connector *connector)
+{
+ unsigned int index = 0;
+ struct drm_connector *tmp;
+
+ list_for_each_entry(tmp, &connector->dev->mode_config.connector_list,
head) {
+ if (tmp == connector)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_connector_index);
+
+/**
* drm_connector_register - register a connector
* @connector: the connector to register
*
@@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
EXPORT_SYMBOL(drm_plane_cleanup);
/**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_plane_index(struct drm_plane *plane)
+{
+ unsigned int index = 0;
+ struct drm_plane *tmp;
+
+ list_for_each_entry(tmp, &plane->dev->mode_config.plane_list, head) {
+ if (tmp == plane)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_plane_index);
+
+/**
* drm_plane_force_disable - Forcibly disable a plane
* @plane: plane to disable
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0da059..4cae44611ab0 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -903,6 +903,7 @@ int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
extern void drm_connector_cleanup(struct drm_connector *connector);
+extern unsigned int drm_connector_index(struct drm_connector *crtc);
/* helper to unplug all connectors from sysfs for device */
extern void drm_connector_unplug_all(struct drm_device *dev);
@@ -942,6 +943,7 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, uint32_t format_count,
bool is_primary);
extern void drm_plane_cleanup(struct drm_plane *plane);
+extern unsigned int drm_plane_index(struct drm_plane *crtc);
extern void drm_plane_force_disable(struct drm_plane *plane);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with "git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915" This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi Cc: Ben Widawsky Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Regards jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: timespec_sub should already be normalized
So don't bother checking it again.
This was introduced:
commit b361237bcc7cea1d99f770490120d8bc2aed
Author: Chris Wilson
Date: Fri Aug 24 09:35:08 2012 +0100
drm/i915: Juggle code order to ease flow of the next patch
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ac349ff..17f7ac9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1243,8 +1243,6 @@ static int __wait_seqno(struct intel_engine_cs *ring, u32
seqno,
if (timeout) {
struct timespec sleep_time = timespec_sub(now, before);
*timeout = timespec_sub(*timeout, sleep_time);
- if (!timespec_valid(timeout)) /* i.e. negative time remains */
- set_normalized_timespec(timeout, 0, 0);
}
return ret;
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Embellish wait_end trace
This adds two new data points to the trace event, wait time, and whether
or not the event slept. Both of these should already be obtainable
through various means. This patch just makes the data more accessible.
Wait is obtainable with the current code by matching seqnos in
begin/end. In simple cases where begin/ends are always paired, this is
trivial. However, if you queue up multiple begins/ends, it can get
confusing. We're already calculating wait time, so it's trivially added
here. This patch also provides the slightly more accurate wait_time as
opposed to the timestamps from the tracepoint. It's observable, but just
noise.
The second bit of information, whether or not the operation slept is
helpful in determining where time went. This is probably also obtainable
through the scheduler events. However, we have the information easily at
our fingertips, we may as well give it out.
This results in an event which looks like:
gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: dev=0,
ring=3, seqno=4294963203, duration=0.000368225 (slept=yes)
While here, rename sleep_time to wait_time since the verb sleep hasn't
been true for a long time (several conditions exist where it won't
sleep).
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
drivers/gpu/drm/i915/i915_trace.h | 29 ++---
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 17f7ac9..bb7fed6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1161,6 +1161,8 @@ static int __wait_seqno(struct intel_engine_cs *ring, u32
seqno,
struct timespec before, now;
DEFINE_WAIT(wait);
unsigned long timeout_expire;
+ struct timespec wait_time;
+ bool slept = false;
int ret;
WARN(!intel_irqs_enabled(dev_priv), "IRQs disabled");
@@ -1216,6 +1218,7 @@ static int __wait_seqno(struct intel_engine_cs *ring, u32
seqno,
break;
}
+ slept = true;
timer.function = NULL;
if (timeout || missed_irq(dev_priv, ring)) {
unsigned long expire;
@@ -1233,17 +1236,16 @@ static int __wait_seqno(struct intel_engine_cs *ring,
u32 seqno,
}
}
getrawmonotonic(&now);
- trace_i915_gem_request_wait_end(ring, seqno);
if (!irq_test_in_progress)
ring->irq_put(ring);
finish_wait(&ring->irq_queue, &wait);
+ wait_time = timespec_sub(now, before);
+ trace_i915_gem_request_wait_end(ring, seqno, wait_time, slept);
- if (timeout) {
- struct timespec sleep_time = timespec_sub(now, before);
- *timeout = timespec_sub(*timeout, sleep_time);
- }
+ if (timeout)
+ *timeout = timespec_sub(*timeout, wait_time);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index f5aa006..0936066 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -476,9 +476,32 @@ TRACE_EVENT(i915_gem_request_wait_begin,
__entry->blocking ? "yes (NB)" : "no")
);
-DEFINE_EVENT(i915_gem_request, i915_gem_request_wait_end,
- TP_PROTO(struct intel_engine_cs *ring, u32 seqno),
- TP_ARGS(ring, seqno)
+TRACE_EVENT(i915_gem_request_wait_end,
+ TP_PROTO(struct intel_engine_cs *ring, u32 seqno, struct timespec
delta, bool slept),
+ TP_ARGS(ring, seqno, delta, slept),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u32, ring)
+__field(u32, seqno)
+__field(long long, s)
+__field(long, ns)
+__field(bool, slept)
+),
+
+ TP_fast_assign(
+ __entry->dev = ring->dev->primary->index;
+ __entry->ring = ring->id;
+ __entry->seqno = seqno;
+ __entry->s = (long long)delta.tv_sec;
+ __entry->ns = delta.tv_nsec;
+ __entry->slept = slept;
+ ),
+
+ TP_printk("dev=%u, ring=%u, seqno=%u, duration=%lld.%.9ld
(slept=%s)",
+ __entry->dev, __entry->ring, __entry->seqno,
+ __entry->s, __entry->ns,
+ __entry->slept ? "yes" : "no")
);
DECLARE_EVENT_CLASS(i915_ring,
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:44:51AM -0700, Ben Widawsky wrote:
> On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
> > On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> > > VMAs should take a reference of the address space they use.
> > >
> > > Now, when the fd is closed, it will release the ref that the context was
> > > holding, but it will still be referenced by any vmas that are still
> > > active.
> > >
> > > ppgtt_release() should then only be called when the last thing referencing
> > > it releases the ref, and it can just call the base cleanup and free the
> > > ppgtt.
> > >
> > > Signed-off-by: Michel Thierry
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > > drivers/gpu/drm/i915/i915_gem.c | 8
> > > drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
> > > drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
> > > 4 files changed, 18 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 2acc03f..a879a93 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
> > > drm_i915_gem_object *obj);
> > >
> > > /* i915_gem_context.c */
> > > #define ctx_to_ppgtt(ctx) container_of((ctx)->vm, struct i915_hw_ppgtt,
> > > base)
> > > +#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
> > > int __must_check i915_gem_context_init(struct drm_device *dev);
> > > +void ppgtt_release(struct kref *kref);
> > > void i915_gem_context_fini(struct drm_device *dev);
> > > void i915_gem_context_reset(struct drm_device *dev);
> > > int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index dcd8d7b..25a32b9 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
> > > drm_i915_gem_object *obj,
> > >
> > > void i915_gem_vma_destroy(struct i915_vma *vma)
> > > {
> > > + struct i915_address_space *vm = NULL;
> > > + struct i915_hw_ppgtt *ppgtt = NULL;
> > > WARN_ON(vma->node.allocated);
> > >
> > > /* Keep the vma as a placeholder in the execbuffer reservation lists */
> > > if (!list_empty(&vma->exec_list))
> > > return;
> > >
> > > + vm = vma->vm;
> > > + ppgtt = vm_to_ppgtt(vm);
> > > +
> > > + if (ppgtt)
> > > + kref_put(&ppgtt->ref, ppgtt_release);
> > > +
> > > list_del(&vma->vma_link);
> > >
> > > kfree(vma);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > > b/drivers/gpu/drm/i915/i915_gem_context.c
> > > index 5b5af6c..59272f9 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > > @@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
> > > *ppgtt)
> > > return;
> > > }
> > >
> > > - /*
> > > - * Make sure vmas are unbound before we take down the drm_mm
> > > - *
> > > - * FIXME: Proper refcounting should take care of this, this shouldn't be
> > > - * needed at all.
> > > - */
> > > - if (!list_empty(&vm->active_list)) {
> > > - struct i915_vma *vma;
> > > -
> > > - list_for_each_entry(vma, &vm->active_list, mm_list)
> > > - if (WARN_ON(list_empty(&vma->vma_link) ||
> > > - list_is_singular(&vma->vma_link)))
> > > - break;
> > > -
> > > - i915_gem_evict_vm(&ppgtt->base, true);
> > > - } else {
> > > - i915_gem_retire_requests(dev);
> > > - i915_gem_evict_vm(&ppgtt->base, false);
> > > - }
> > > + /* vmas should already be unbound */
> > > + WARN_ON(!list_empty(&vm->active_list));
> > >
> > > ppgtt->base.cleanup(&ppgtt->base);
> > > }
> > >
> > > -static void ppgtt_release(struct kref *kref)
> > > +void ppgtt_release(struct kref *kref)
> > > {
> > > struct i915_hw_ppgtt *ppgtt =
> > > container_of(kref, struct i915_hw_ppgtt, ref);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > index 1411613..90c3d0f 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > @@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
> > > drm_i915_gem_object *obj,
> > > struct i915_address_space *vm)
> > > {
> > > struct i915_vma *vma;
> > > + struct i915_hw_ppgtt *ppgtt = NULL;
> > >
> > > vma = i915_gem_obj_to_vma(obj, vm);
> > > if (!vma)
> > > vma = __i915_gem_vma_create(obj, vm);
> > >
> > > + ppgtt = vm_to_ppgtt(vm);
> > > + if (ppgtt)
> > > + kref_get(&ppgtt->ref);
> > > +
> > > return vma;
> > > }
> >
> > Seems like a reasonable fix to me, and it'
Re: [Intel-gfx] [PATCH 37/40] drm/i915: Fix eDP link training when switching pipes
On Tue, Jul 29, 2014 at 10:18:46PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 29, 2014 at 08:06:57PM +0200, Daniel Vetter wrote:
> > On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
> > > On Sat, 28 Jun 2014 02:04:28 +0300
> > > ville.syrj...@linux.intel.com wrote:
> > >
> > > > From: Ville Syrjälä
> > > >
> > > > When switching from one pipe to another, the power sequencer of the new
> > > > pipe seems to need a bit of kicking to lock into the port. Even the vdd
> > > > force bit doesn't work before the power sequencer has been sufficiently
> > > > kicked, so this must be done even before any AUX transactions.
> > > >
> > > > This sequence has been found to do the trick:
> > > > 1) enable port with idle pattern
> > > > 2) enable the power sequencer
> > > > 3) proceed with link training
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 34 --
> > > > 1 file changed, 32 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 65ab54c..07b0320 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -2010,6 +2010,37 @@ static void chv_post_disable_dp(struct
> > > > intel_encoder *encoder)
> > > > mutex_unlock(&dev_priv->dpio_lock);
> > > > }
> > > >
> > > > +static void intel_edp_init_train(struct intel_dp *intel_dp)
> > > > +{
> > > > + struct intel_digital_port *intel_dig_port =
> > > > dp_to_dig_port(intel_dp);
> > > > + struct drm_device *dev = intel_dig_port->base.base.dev;
> > > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > > +
> > > > + if (!is_edp(intel_dp))
> > > > + return;
> >
> > This changes the order of events as observed by the sink, so I really
> > wonder why this is edp specific?
>
> It's not really. I need to kick the power sequencer for regular DP ports
> too (in a later patch), and recently I started to wonder if we also need
> it for HDMI ports but I didn't test that theory yet.
>
> Based on my observations there are several problems intermingled here:
> 1. the power sequencer prevents the port from starting up until the
>power up sequence has finished
> 2. vdd force bit doesn't work until the power sequencer has finished
> 3. the power sequencer won't finish the power up sequence unless idle
>pattern is used
>
> So the fix is to enable the port with idle pattern and enable the power
> sequencer even before doing any aux transactions (including the sink
> dpms write).
>
> Once the power sequencer has finished powering up on to the port once.
> the vdd force bit will keep working on the port even if the port and
> power sequencer are later disabled. Also iirc the power sequencer will
> no longer prevent the port from starting up even if the power sequencer
> is left disabled when re-enabling the port later. But the same problem
> will reappear when we change the pipe->port mapping, and then we need
> to kick the power sequencer again.
>
> > We do have bug reports about external DP monitors not waking up from the
> > sink_dpms call properly ...
>
> On vlv or something else? I'm not quite sure if the same problems would
> be possible on other platforms since they only have one power sequencer.
> But maybe that too locks into the port and would need a similar kick.
>
> But IIRC on PCH platforms the spec says that we must enable the port
> with training pattern 1. So the use of idle pattern would at least go
> against the spec. Which is why I left that part as vlv/chv specific.
Hm ... tricky. And especially since it seems to be required only once. I'm
just concerned about the slight behavioural difference between the general
dp link enabling where we do the sink dpms aux transaction first, then
start with link training. But on vlv/chv here we first kick the port a bit
and enable the idle pattern. If now a few displays don't like this or
require this we have a problem.
In general I really want us to try as hard as possible to have 0
differences in sink-visible behaviour. DP is simply too fickle imo. But if
there's nothing we can do I guess good explanations in commit message and
comments is all I can ask for. I.e. something like the above should go
into the commit message and maybe we should make the comment a bit more
dangerously-sounding.
-Daniel
>
> > -Daniel
> >
> > > > +
> > > > + /*
> > > > +* Need to enable the port with idle pattern to allow the power
> > > > +* sequencer to lock into the port. Otherwise the power
> > > > sequencer
> > > > +* (including vdd force bit!) doesn't work on this port.
> > > > +*/
> > > > + if (IS_VALLEYVIEW(dev)) {
> > > > + intel_dp->DP |= DP_PORT_EN;
> > > > +
> > > > + if (IS_CHERRYVIEW(dev))
> > > > + intel_dp->DP &= ~DP_LINK_TRAIN_M
Re: [Intel-gfx] [PATCH 37/40] drm/i915: Fix eDP link training when switching pipes
On Tue, Jul 29, 2014 at 08:06:57PM +0200, Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:04:28 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > When switching from one pipe to another, the power sequencer of the new
> > > pipe seems to need a bit of kicking to lock into the port. Even the vdd
> > > force bit doesn't work before the power sequencer has been sufficiently
> > > kicked, so this must be done even before any AUX transactions.
> > >
> > > This sequence has been found to do the trick:
> > > 1) enable port with idle pattern
> > > 2) enable the power sequencer
> > > 3) proceed with link training
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 34 --
> > > 1 file changed, 32 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 65ab54c..07b0320 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -2010,6 +2010,37 @@ static void chv_post_disable_dp(struct
> > > intel_encoder *encoder)
> > > mutex_unlock(&dev_priv->dpio_lock);
> > > }
> > >
> > > +static void intel_edp_init_train(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > + struct drm_device *dev = intel_dig_port->base.base.dev;
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > +
> > > + if (!is_edp(intel_dp))
> > > + return;
>
> This changes the order of events as observed by the sink, so I really
> wonder why this is edp specific?
It's not really. I need to kick the power sequencer for regular DP ports
too (in a later patch), and recently I started to wonder if we also need
it for HDMI ports but I didn't test that theory yet.
Based on my observations there are several problems intermingled here:
1. the power sequencer prevents the port from starting up until the
power up sequence has finished
2. vdd force bit doesn't work until the power sequencer has finished
3. the power sequencer won't finish the power up sequence unless idle
pattern is used
So the fix is to enable the port with idle pattern and enable the power
sequencer even before doing any aux transactions (including the sink
dpms write).
Once the power sequencer has finished powering up on to the port once.
the vdd force bit will keep working on the port even if the port and
power sequencer are later disabled. Also iirc the power sequencer will
no longer prevent the port from starting up even if the power sequencer
is left disabled when re-enabling the port later. But the same problem
will reappear when we change the pipe->port mapping, and then we need
to kick the power sequencer again.
> We do have bug reports about external DP monitors not waking up from the
> sink_dpms call properly ...
On vlv or something else? I'm not quite sure if the same problems would
be possible on other platforms since they only have one power sequencer.
But maybe that too locks into the port and would need a similar kick.
But IIRC on PCH platforms the spec says that we must enable the port
with training pattern 1. So the use of idle pattern would at least go
against the spec. Which is why I left that part as vlv/chv specific.
> -Daniel
>
> > > +
> > > + /*
> > > + * Need to enable the port with idle pattern to allow the power
> > > + * sequencer to lock into the port. Otherwise the power sequencer
> > > + * (including vdd force bit!) doesn't work on this port.
> > > + */
> > > + if (IS_VALLEYVIEW(dev)) {
> > > + intel_dp->DP |= DP_PORT_EN;
> > > +
> > > + if (IS_CHERRYVIEW(dev))
> > > + intel_dp->DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > + else
> > > + intel_dp->DP &= ~DP_LINK_TRAIN_MASK;
> > > + intel_dp->DP |= DP_LINK_TRAIN_PAT_IDLE;
> > > +
> > > + I915_WRITE(intel_dp->output_reg, intel_dp->DP);
> > > + POSTING_READ(intel_dp->output_reg);
> > > + }
> > > +
> > > + intel_edp_panel_on(intel_dp);
> > > + edp_panel_vdd_off(intel_dp, true);
> > > +}
> > > +
> > > static void intel_enable_dp(struct intel_encoder *encoder)
> > > {
> > > struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> > > @@ -2021,10 +2052,9 @@ static void intel_enable_dp(struct intel_encoder
> > > *encoder)
> > > return;
> > >
> > > intel_edp_panel_vdd_on(intel_dp);
> > > + intel_edp_init_train(intel_dp);
> > > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > > intel_dp_start_link_train(intel_dp);
> > > - intel_edp_panel_on(intel_dp);
> > > - edp_panel_vdd_off(intel_dp, true);
> > > intel_dp_complete_link_train(intel_dp);
> > > intel_dp_stop_link_train(intel_dp);
> > > }
> >
> > Yeah I think this matches the doc too. I never pushed this change
> > because I could never find anything t
Re: [Intel-gfx] [PATCH 34/40] drm/i915: Add DP training pattern 3 for CHV
On Tue, Jul 29, 2014 at 09:34:34PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 29, 2014 at 08:04:59PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
> > > On Sat, 28 Jun 2014 02:04:25 +0300
> > > ville.syrj...@linux.intel.com wrote:
> > >
> > > > From: Ville Syrjälä
> > > >
> > > > CHV supports DP training pattern 3. Add the required stuff.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > > drivers/gpu/drm/i915/intel_dp.c | 18 ++
> > > > 2 files changed, 16 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 85b59c4..8debe61 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -3515,6 +3515,8 @@ enum punit_power_well {
> > > > #define DP_LINK_TRAIN_OFF(3 << 28)
> > > > #define DP_LINK_TRAIN_MASK (3 << 28)
> > > > #define DP_LINK_TRAIN_SHIFT 28
> > > > +#define DP_LINK_TRAIN_PAT_3_CHV (1 << 14)
> > > > +#define DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
> > > >
> > > > /* CPT Link training mode */
> > > > #define DP_LINK_TRAIN_PAT_1_CPT (0 << 8)
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 739dc43..a825ff1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp
> > > > *intel_dp,
> > > > }
> > > >
> > > > } else {
> > > > - *DP &= ~DP_LINK_TRAIN_MASK;
> > > > + if (IS_CHERRYVIEW(dev))
> > > > + *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > > + else
> > > > + *DP &= ~DP_LINK_TRAIN_MASK;
> > > >
> > > > switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > > > case DP_TRAINING_PATTERN_DISABLE:
> > > > @@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp
> > > > *intel_dp,
> > > > *DP |= DP_LINK_TRAIN_PAT_2;
> > > > break;
> > > > case DP_TRAINING_PATTERN_3:
> > > > - DRM_ERROR("DP training pattern 3 not
> > > > supported\n");
> > > > - *DP |= DP_LINK_TRAIN_PAT_2;
> > > > + if (IS_CHERRYVIEW(dev)) {
> > > > + *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > > > + } else {
> > > > + DRM_ERROR("DP training pattern 3 not
> > > > supported\n");
> > > > + *DP |= DP_LINK_TRAIN_PAT_2;
> > > > + }
> > > > break;
> > > > }
> > > > }
> > > > @@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
> > > > DP &= ~DP_LINK_TRAIN_MASK_CPT;
> > > > I915_WRITE(intel_dp->output_reg, DP |
> > > > DP_LINK_TRAIN_PAT_IDLE_CPT);
> > > > } else {
> > > > - DP &= ~DP_LINK_TRAIN_MASK;
> > > > + if (IS_CHERRYVIEW(dev))
> > > > + DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > > + else
> > > > + DP &= ~DP_LINK_TRAIN_MASK;
> > > > I915_WRITE(intel_dp->output_reg, DP |
> > > > DP_LINK_TRAIN_PAT_IDLE);
> > > > }
> > > > POSTING_READ(intel_dp->output_reg);
> > >
> > > I guess we could have a whole IS_CHV block, but that would probably add
> > > more code than it saved...
> > >
> > > Reviewed-by: Jesse Barnes
> >
> > This won't do a hole lot without adding HBR2 support ... Queued for
> > -next anyway, thanks for the patch.
>
> What else is missing for HBR2?
Adjusting the check in intel_dp_max_link_bw. At least I haven't seen a
patch for that yet. Maybe missed it.
-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
Re: [Intel-gfx] [PATCH 12/40] drm/i915: Clarify CHV swing margin/deemph bits
On Tue, Jul 29, 2014 at 09:55:39AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:03 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > CHV display PHY registes have two swing margin/deemph settings. Make it
> > clear which ones we're using.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 8 ++--
> > drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> > drivers/gpu/drm/i915/intel_hdmi.c | 4 ++--
> > 3 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e296312..ba90320 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -831,8 +831,8 @@ enum punit_power_well {
> >
> > #define _VLV_TX_DW2_CH00x8288
> > #define _VLV_TX_DW2_CH10x8488
> > -#define DPIO_SWING_MARGIN_SHIFT 16
> > -#define DPIO_SWING_MARGIN_MASK (0xff << DPIO_SWING_MARGIN_SHIFT)
> > +#define DPIO_SWING_MARGIN000_SHIFT 16
> > +#define DPIO_SWING_MARGIN000_MASK(0xff <<
> > DPIO_SWING_MARGIN000_SHIFT)
> > #define DPIO_UNIQ_TRANS_SCALE_SHIFT 8
> > #define VLV_TX_DW2(ch) _PORT(ch, _VLV_TX_DW2_CH0, _VLV_TX_DW2_CH1)
> >
> > @@ -840,12 +840,16 @@ enum punit_power_well {
> > #define _VLV_TX_DW3_CH10x848c
> > /* The following bit for CHV phy */
> > #define DPIO_TX_UNIQ_TRANS_SCALE_EN (1<<27)
> > +#define DPIO_SWING_MARGIN101_SHIFT 16
> > +#define DPIO_SWING_MARGIN101_MASK(0xff <<
> > DPIO_SWING_MARGIN101_SHIFT)
> > #define VLV_TX_DW3(ch) _PORT(ch, _VLV_TX_DW3_CH0, _VLV_TX_DW3_CH1)
> >
> > #define _VLV_TX_DW4_CH00x8290
> > #define _VLV_TX_DW4_CH10x8490
> > #define DPIO_SWING_DEEMPH9P5_SHIFT 24
> > #define DPIO_SWING_DEEMPH9P5_MASK(0xff <<
> > DPIO_SWING_DEEMPH9P5_SHIFT)
> > +#define DPIO_SWING_DEEMPH6P0_SHIFT 16
> > +#define DPIO_SWING_DEEMPH6P0_MASK(0xff <<
> > DPIO_SWING_DEEMPH6P0_SHIFT)
> > #define VLV_TX_DW4(ch) _PORT(ch, _VLV_TX_DW4_CH0, _VLV_TX_DW4_CH1)
> >
> > #define _VLV_TX3_DW4_CH0 0x690
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index e272f92..4457f8f 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2565,8 +2565,8 @@ static uint32_t intel_chv_signal_levels(struct
> > intel_dp *intel_dp)
> > /* Program swing margin */
> > for (i = 0; i < 4; i++) {
> > val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
> > - val &= ~DPIO_SWING_MARGIN_MASK;
> > - val |= margin_reg_value << DPIO_SWING_MARGIN_SHIFT;
> > + val &= ~DPIO_SWING_MARGIN000_MASK;
> > + val |= margin_reg_value << DPIO_SWING_MARGIN000_SHIFT;
> > vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index c9d77d3..c5c88127 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1411,8 +1411,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> > *encoder)
> >
> > for (i = 0; i < 4; i++) {
> > val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
> > - val &= ~DPIO_SWING_MARGIN_MASK;
> > - val |= 102 << DPIO_SWING_MARGIN_SHIFT;
> > + val &= ~DPIO_SWING_MARGIN000_MASK;
> > + val |= 102 << DPIO_SWING_MARGIN000_SHIFT;
> > vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
> > }
> >
>
> Reviewed-by: Jesse Barnes
Ok, pulled in the pile of patches Jesse just reviewed.
-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
Re: [Intel-gfx] [PATCH] drm/i915: freeze display before the interrupts and GT
On Tue, Jul 29, 2014 at 11:13:03AM -0700, Jesse Barnes wrote:
> On Thu, 17 Jul 2014 17:43:46 -0300
> Paulo Zanoni wrote:
>
> > From: Paulo Zanoni
> >
> > Since we started using intel_runtime_pm_disable_interrupts() at normal
> > (non-runtime) suspend/resume, we had to remove a WARN from
> > ironlake_disable_display_irq to avoid a case where we were doing the
> > correct thing and the WARN was not really needed. The problem is that
> > the WARN was useful in other cases, and its removal can hide some bugs
> > that we would catch automatically.
> >
> > To be able to add back the WARN, we have to call intel_crtc_control()
> > before interrupts are disabled, which is what this patch currently
> > does.
> >
> > Also notice that Ville's patch from the Watermarks series "drm/i915:
> > Leave interrupts enabled while disabling crtcs during suspend" also
> > did a change that's equivalent to the one we're doing on this patch,
> > with the exception that its original patch, when applied to the
> > current tree, procduces a WARN.
> >
> > Related commits:
> >
> > commit daa390e5ee45cc051d6bf37b296901f2f92b002d
> > Author: Jesse Barnes
> > drm/i915: don't warn if IRQs are disabled when shutting down display
> > IRQs
> >
> > commit e11aa362308f5de467ce355a2a2471321b15a35c
> > Author: Jesse Barnes
> > drm/i915: use runtime irq suspend/resume in freeze/thaw
> >
> > Cc: Ville Syrjälä
> > Cc: Jesse Barnes
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 11 +--
> > drivers/gpu/drm/i915/i915_irq.c | 2 +-
> > 2 files changed, 6 insertions(+), 7 deletions(-)
> >
> > No need to revert anything :)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 3315358..63675bf 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -520,12 +520,6 @@ static int i915_drm_freeze(struct drm_device *dev)
> > return error;
> > }
> >
> > - flush_delayed_work(&dev_priv->rps.delayed_resume_work);
> > -
> > - intel_runtime_pm_disable_interrupts(dev);
> > -
> > - intel_suspend_gt_powersave(dev);
> > -
> > /*
> > * Disable CRTCs directly since we want to preserve sw state
> > * for _thaw. Also, power gate the CRTC power wells.
> > @@ -535,6 +529,11 @@ static int i915_drm_freeze(struct drm_device *dev)
> > intel_crtc_control(crtc, false);
> > drm_modeset_unlock_all(dev);
> >
> > + flush_delayed_work(&dev_priv->rps.delayed_resume_work);
> > + intel_runtime_pm_disable_interrupts(dev);
> > +
> > + intel_suspend_gt_powersave(dev);
> > +
> > intel_modeset_suspend_hw(dev);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 20c777c..af231ba 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -151,7 +151,7 @@ ironlake_disable_display_irq(struct drm_i915_private
> > *dev_priv, u32 mask)
> > {
> > assert_spin_locked(&dev_priv->irq_lock);
> >
> > - if (!intel_irqs_enabled(dev_priv))
> > + if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> > return;
> >
> > if ((dev_priv->irq_mask & mask) != mask) {
>
> So with this added, we get the WARN back but don't need/want to revert
> any other patches?
>
> Did you check boot, suspend/resume, and runtime PM for warnings with
> this change applied? If so, looks fine:
>
> Reviewed-by: Jesse Barnes
There was a bit of conflict with one of Dave's fixes for the dp mst work,
but I think that was just partial of this patch here. But please
double-check.
Queued for -next, thanks for the patch.
-Daniel
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
> On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> > VMAs should take a reference of the address space they use.
> >
> > Now, when the fd is closed, it will release the ref that the context was
> > holding, but it will still be referenced by any vmas that are still
> > active.
> >
> > ppgtt_release() should then only be called when the last thing referencing
> > it releases the ref, and it can just call the base cleanup and free the
> > ppgtt.
> >
> > Signed-off-by: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/i915_gem.c | 8
> > drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
> > 4 files changed, 18 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 2acc03f..a879a93 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
> > drm_i915_gem_object *obj);
> >
> > /* i915_gem_context.c */
> > #define ctx_to_ppgtt(ctx) container_of((ctx)->vm, struct i915_hw_ppgtt,
> > base)
> > +#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
> > int __must_check i915_gem_context_init(struct drm_device *dev);
> > +void ppgtt_release(struct kref *kref);
> > void i915_gem_context_fini(struct drm_device *dev);
> > void i915_gem_context_reset(struct drm_device *dev);
> > int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index dcd8d7b..25a32b9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
> > drm_i915_gem_object *obj,
> >
> > void i915_gem_vma_destroy(struct i915_vma *vma)
> > {
> > + struct i915_address_space *vm = NULL;
> > + struct i915_hw_ppgtt *ppgtt = NULL;
> > WARN_ON(vma->node.allocated);
> >
> > /* Keep the vma as a placeholder in the execbuffer reservation lists */
> > if (!list_empty(&vma->exec_list))
> > return;
> >
> > + vm = vma->vm;
> > + ppgtt = vm_to_ppgtt(vm);
> > +
> > + if (ppgtt)
> > + kref_put(&ppgtt->ref, ppgtt_release);
> > +
> > list_del(&vma->vma_link);
> >
> > kfree(vma);
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 5b5af6c..59272f9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
> > *ppgtt)
> > return;
> > }
> >
> > - /*
> > -* Make sure vmas are unbound before we take down the drm_mm
> > -*
> > -* FIXME: Proper refcounting should take care of this, this shouldn't be
> > -* needed at all.
> > -*/
> > - if (!list_empty(&vm->active_list)) {
> > - struct i915_vma *vma;
> > -
> > - list_for_each_entry(vma, &vm->active_list, mm_list)
> > - if (WARN_ON(list_empty(&vma->vma_link) ||
> > - list_is_singular(&vma->vma_link)))
> > - break;
> > -
> > - i915_gem_evict_vm(&ppgtt->base, true);
> > - } else {
> > - i915_gem_retire_requests(dev);
> > - i915_gem_evict_vm(&ppgtt->base, false);
> > - }
> > + /* vmas should already be unbound */
> > + WARN_ON(!list_empty(&vm->active_list));
> >
> > ppgtt->base.cleanup(&ppgtt->base);
> > }
> >
> > -static void ppgtt_release(struct kref *kref)
> > +void ppgtt_release(struct kref *kref)
> > {
> > struct i915_hw_ppgtt *ppgtt =
> > container_of(kref, struct i915_hw_ppgtt, ref);
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 1411613..90c3d0f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
> > drm_i915_gem_object *obj,
> > struct i915_address_space *vm)
> > {
> > struct i915_vma *vma;
> > + struct i915_hw_ppgtt *ppgtt = NULL;
> >
> > vma = i915_gem_obj_to_vma(obj, vm);
> > if (!vma)
> > vma = __i915_gem_vma_create(obj, vm);
> >
> > + ppgtt = vm_to_ppgtt(vm);
> > + if (ppgtt)
> > + kref_get(&ppgtt->ref);
> > +
> > return vma;
> > }
>
> Seems like a reasonable fix to me, and it's simpler than Chris' request
> to ref when active. Logically his makes more sense, but it's not quite
> as simple to review. Actually active isn't the right thing to track IMO,
> bound is what you want to track.
I didn't mea
Re: [Intel-gfx] [PATCH 06/40] drm/i915: Add cdclk change support for chv
On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:03:57 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Looks like the Punit is supposed to support the 400MHz cdclk directly on
> > chv, so we don't need the vlv tricks.
> >
> > FIXME: Punit doesn't seem ready for this yet on current hw
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 4 +++
> > drivers/gpu/drm/i915/intel_display.c | 50
> > ++--
> > 2 files changed, 52 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f156591..e296312 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -491,6 +491,10 @@
> > #define BUNIT_REG_BISOC0x11
> >
> > #define PUNIT_REG_DSPFREQ 0x36
> > +#define DSPFREQSTAT_SHIFT_CHV24
> > +#define DSPFREQSTAT_MASK_CHV (0x1f <<
> > DSPFREQSTAT_SHIFT_CHV)
> > +#define DSPFREQGUAR_SHIFT_CHV8
> > +#define DSPFREQGUAR_MASK_CHV (0x1f <<
> > DSPFREQGUAR_SHIFT_CHV)
> > #define DSPFREQSTAT_SHIFT30
> > #define DSPFREQSTAT_MASK (0x3 << DSPFREQSTAT_SHIFT)
> > #define DSPFREQGUAR_SHIFT14
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 99c10d1..9af1d13 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
> > *dev, int cdclk)
> > vlv_update_cdclk(dev);
> > }
> >
> > +static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + u32 val, cmd;
> > +
> > + WARN_ON(dev_priv->display.get_display_clock_speed(dev) !=
> > dev_priv->vlv_cdclk_freq);
> > +
> > + switch (cdclk) {
> > + case 40:
> > + cmd = 3;
> > + break;
> > + case 33:
> > + case 32:
> > + cmd = 2;
> > + break;
> > + case 27:
> > + cmd = 1;
> > + break;
> > + case 20:
> > + cmd = 0;
> > + break;
> > + default:
> > + WARN_ON(1);
> > + return;
> > + }
> > +
> > + mutex_lock(&dev_priv->rps.hw_lock);
> > + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> > + val &= ~DSPFREQGUAR_MASK_CHV;
> > + val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> > + vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> > + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> > + DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
> > +50)) {
> > + DRM_ERROR("timed out waiting for CDclk change\n");
> > + }
> > + mutex_unlock(&dev_priv->rps.hw_lock);
> > +
> > + vlv_update_cdclk(dev);
> > +}
> > +
> > static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
> > int max_pixclk)
> > {
> > @@ -4597,8 +4638,13 @@ static void
> > valleyview_modeset_global_resources(struct drm_device *dev)
> > int max_pixclk = intel_mode_max_pixclk(dev_priv);
> > int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
> >
> > - if (req_cdclk != dev_priv->vlv_cdclk_freq)
> > - valleyview_set_cdclk(dev, req_cdclk);
> > + if (req_cdclk != dev_priv->vlv_cdclk_freq) {
> > + if (IS_CHERRYVIEW(dev))
> > + cherryview_set_cdclk(dev, req_cdclk);
> > + else
> > + valleyview_set_cdclk(dev, req_cdclk);
> > + }
> > +
> > modeset_update_crtc_power_domains(dev);
> > }
> >
>
> Which doc has these Punit commands? I'm assuming you have them
> correct, but a ref would be good if we don't already have one.
These were in the punit has. The display cluster has still had the old
vlv information last I looked.
>
> Reviewed-by: Jesse Barnes
>
> There should probably be a JIRA for this too so QA can verify once we
> have updated punit support.
>
> --
> Jesse Barnes, 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 34/40] drm/i915: Add DP training pattern 3 for CHV
On Tue, Jul 29, 2014 at 08:04:59PM +0200, Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:04:25 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > CHV supports DP training pattern 3. Add the required stuff.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > drivers/gpu/drm/i915/intel_dp.c | 18 ++
> > > 2 files changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 85b59c4..8debe61 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -3515,6 +3515,8 @@ enum punit_power_well {
> > > #define DP_LINK_TRAIN_OFF (3 << 28)
> > > #define DP_LINK_TRAIN_MASK (3 << 28)
> > > #define DP_LINK_TRAIN_SHIFT28
> > > +#define DP_LINK_TRAIN_PAT_3_CHV(1 << 14)
> > > +#define DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
> > >
> > > /* CPT Link training mode */
> > > #define DP_LINK_TRAIN_PAT_1_CPT(0 << 8)
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 739dc43..a825ff1 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > > }
> > >
> > > } else {
> > > - *DP &= ~DP_LINK_TRAIN_MASK;
> > > + if (IS_CHERRYVIEW(dev))
> > > + *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > + else
> > > + *DP &= ~DP_LINK_TRAIN_MASK;
> > >
> > > switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > > case DP_TRAINING_PATTERN_DISABLE:
> > > @@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > > *DP |= DP_LINK_TRAIN_PAT_2;
> > > break;
> > > case DP_TRAINING_PATTERN_3:
> > > - DRM_ERROR("DP training pattern 3 not supported\n");
> > > - *DP |= DP_LINK_TRAIN_PAT_2;
> > > + if (IS_CHERRYVIEW(dev)) {
> > > + *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > > + } else {
> > > + DRM_ERROR("DP training pattern 3 not
> > > supported\n");
> > > + *DP |= DP_LINK_TRAIN_PAT_2;
> > > + }
> > > break;
> > > }
> > > }
> > > @@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
> > > DP &= ~DP_LINK_TRAIN_MASK_CPT;
> > > I915_WRITE(intel_dp->output_reg, DP |
> > > DP_LINK_TRAIN_PAT_IDLE_CPT);
> > > } else {
> > > - DP &= ~DP_LINK_TRAIN_MASK;
> > > + if (IS_CHERRYVIEW(dev))
> > > + DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > > + else
> > > + DP &= ~DP_LINK_TRAIN_MASK;
> > > I915_WRITE(intel_dp->output_reg, DP | DP_LINK_TRAIN_PAT_IDLE);
> > > }
> > > POSTING_READ(intel_dp->output_reg);
> >
> > I guess we could have a whole IS_CHV block, but that would probably add
> > more code than it saved...
> >
> > Reviewed-by: Jesse Barnes
>
> This won't do a hole lot without adding HBR2 support ... Queued for
> -next anyway, thanks for the patch.
What else is missing for HBR2?
--
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: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> VMAs should take a reference of the address space they use.
>
> Now, when the fd is closed, it will release the ref that the context was
> holding, but it will still be referenced by any vmas that are still
> active.
>
> ppgtt_release() should then only be called when the last thing referencing
> it releases the ref, and it can just call the base cleanup and free the
> ppgtt.
>
> Signed-off-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gem.c | 8
> drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
> drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
> 4 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2acc03f..a879a93 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
> drm_i915_gem_object *obj);
>
> /* i915_gem_context.c */
> #define ctx_to_ppgtt(ctx) container_of((ctx)->vm, struct i915_hw_ppgtt, base)
> +#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
> int __must_check i915_gem_context_init(struct drm_device *dev);
> +void ppgtt_release(struct kref *kref);
> void i915_gem_context_fini(struct drm_device *dev);
> void i915_gem_context_reset(struct drm_device *dev);
> int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dcd8d7b..25a32b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
> drm_i915_gem_object *obj,
>
> void i915_gem_vma_destroy(struct i915_vma *vma)
> {
> + struct i915_address_space *vm = NULL;
> + struct i915_hw_ppgtt *ppgtt = NULL;
> WARN_ON(vma->node.allocated);
>
> /* Keep the vma as a placeholder in the execbuffer reservation lists */
> if (!list_empty(&vma->exec_list))
> return;
>
> + vm = vma->vm;
> + ppgtt = vm_to_ppgtt(vm);
> +
> + if (ppgtt)
> + kref_put(&ppgtt->ref, ppgtt_release);
> +
> list_del(&vma->vma_link);
>
> kfree(vma);
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5b5af6c..59272f9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
> *ppgtt)
> return;
> }
>
> - /*
> - * Make sure vmas are unbound before we take down the drm_mm
> - *
> - * FIXME: Proper refcounting should take care of this, this shouldn't be
> - * needed at all.
> - */
> - if (!list_empty(&vm->active_list)) {
> - struct i915_vma *vma;
> -
> - list_for_each_entry(vma, &vm->active_list, mm_list)
> - if (WARN_ON(list_empty(&vma->vma_link) ||
> - list_is_singular(&vma->vma_link)))
> - break;
> -
> - i915_gem_evict_vm(&ppgtt->base, true);
> - } else {
> - i915_gem_retire_requests(dev);
> - i915_gem_evict_vm(&ppgtt->base, false);
> - }
> + /* vmas should already be unbound */
> + WARN_ON(!list_empty(&vm->active_list));
>
> ppgtt->base.cleanup(&ppgtt->base);
> }
>
> -static void ppgtt_release(struct kref *kref)
> +void ppgtt_release(struct kref *kref)
> {
> struct i915_hw_ppgtt *ppgtt =
> container_of(kref, struct i915_hw_ppgtt, ref);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 1411613..90c3d0f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
> drm_i915_gem_object *obj,
> struct i915_address_space *vm)
> {
> struct i915_vma *vma;
> + struct i915_hw_ppgtt *ppgtt = NULL;
>
> vma = i915_gem_obj_to_vma(obj, vm);
> if (!vma)
> vma = __i915_gem_vma_create(obj, vm);
>
> + ppgtt = vm_to_ppgtt(vm);
> + if (ppgtt)
> + kref_get(&ppgtt->ref);
> +
> return vma;
> }
Seems like a reasonable fix to me, and it's simpler than Chris' request
to ref when active. Logically his makes more sense, but it's not quite
as simple to review. Actually active isn't the right thing to track IMO,
bound is what you want to track. I think if anything, do that one as a
patch on top, it does address the problem mentioned below. I also wonder
given the recent reset lolz how this behaves there; and I'd make sure to
thoroughly test the various reset/hang conditions.
Also, this puts
Re: [Intel-gfx] [PATCH 00/10] Split the HSW/BDW PLL code a bit more
On Tue, Jul 29, 2014 at 06:06:15PM +0100, Damien Lespiau wrote: > Turns out we were optimistic. intel_ prefixes don't tend to last and this is > one of those times. Pulled in the entire series to dinq, thanks. -Daniel > > -- > Damien > > Damien Lespiau (10): > drm/i915: Specify when the PLL hw state fields are valid > drm/i915: Add a space to the shared DPLL debug message > drm/i915: Extract the HSW DDI selection code into its own function > drm/i915: Extract the HSW/BDW shared dpll init code > drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW > drm/i915: Fix stale comment for intel_ddi_pll_select() > drm/i915: Split the BDW/HSW specific shared pll selection > drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific > drm/i915: Split the CDCLK retrieval per-platform > drm/i915: Make ddi_clock_gate() HSW/BDW specific > > drivers/gpu/drm/i915/i915_drv.h | 3 + > drivers/gpu/drm/i915/intel_ddi.c | 124 > +++ > drivers/gpu/drm/i915/intel_display.c | 29 > drivers/gpu/drm/i915/intel_dp.c | 2 +- > 4 files changed, 105 insertions(+), 53 deletions(-) > > -- > 1.8.3.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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
Re: [Intel-gfx] [PATCH 37/40] drm/i915: Fix eDP link training when switching pipes
On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:28 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > When switching from one pipe to another, the power sequencer of the new
> > pipe seems to need a bit of kicking to lock into the port. Even the vdd
> > force bit doesn't work before the power sequencer has been sufficiently
> > kicked, so this must be done even before any AUX transactions.
> >
> > This sequence has been found to do the trick:
> > 1) enable port with idle pattern
> > 2) enable the power sequencer
> > 3) proceed with link training
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 34 --
> > 1 file changed, 32 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 65ab54c..07b0320 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2010,6 +2010,37 @@ static void chv_post_disable_dp(struct intel_encoder
> > *encoder)
> > mutex_unlock(&dev_priv->dpio_lock);
> > }
> >
> > +static void intel_edp_init_train(struct intel_dp *intel_dp)
> > +{
> > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > + struct drm_device *dev = intel_dig_port->base.base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > +
> > + if (!is_edp(intel_dp))
> > + return;
This changes the order of events as observed by the sink, so I really
wonder why this is edp specific?
We do have bug reports about external DP monitors not waking up from the
sink_dpms call properly ...
-Daniel
> > +
> > + /*
> > +* Need to enable the port with idle pattern to allow the power
> > +* sequencer to lock into the port. Otherwise the power sequencer
> > +* (including vdd force bit!) doesn't work on this port.
> > +*/
> > + if (IS_VALLEYVIEW(dev)) {
> > + intel_dp->DP |= DP_PORT_EN;
> > +
> > + if (IS_CHERRYVIEW(dev))
> > + intel_dp->DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > + else
> > + intel_dp->DP &= ~DP_LINK_TRAIN_MASK;
> > + intel_dp->DP |= DP_LINK_TRAIN_PAT_IDLE;
> > +
> > + I915_WRITE(intel_dp->output_reg, intel_dp->DP);
> > + POSTING_READ(intel_dp->output_reg);
> > + }
> > +
> > + intel_edp_panel_on(intel_dp);
> > + edp_panel_vdd_off(intel_dp, true);
> > +}
> > +
> > static void intel_enable_dp(struct intel_encoder *encoder)
> > {
> > struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> > @@ -2021,10 +2052,9 @@ static void intel_enable_dp(struct intel_encoder
> > *encoder)
> > return;
> >
> > intel_edp_panel_vdd_on(intel_dp);
> > + intel_edp_init_train(intel_dp);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > intel_dp_start_link_train(intel_dp);
> > - intel_edp_panel_on(intel_dp);
> > - edp_panel_vdd_off(intel_dp, true);
> > intel_dp_complete_link_train(intel_dp);
> > intel_dp_stop_link_train(intel_dp);
> > }
>
> Yeah I think this matches the doc too. I never pushed this change
> because I could never find anything that it actually fixed.
>
> I guess you have something now though!
>
> Reviewed-by: Jesse Barnes
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW
On Tue, Jul 29, 2014 at 06:06:20PM +0100, Damien Lespiau wrote: > Future platform will use config->ddi_pll_sel in a different way. > > Signed-off-by: Damien Lespiau > --- > drivers/gpu/drm/i915/intel_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index ea6ff71..bdbe8f7 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -976,7 +976,7 @@ found: > &pipe_config->dp_m2_n2); > } > > - if (HAS_DDI(dev)) > + if (IS_HASWELL(dev) || IS_BROADWELL(dev)) > hsw_dp_set_ddi_pll_sel(pipe_config, intel_dp->link_bw); > else > intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw); We could do an s/intel/gmch/ here too ... Or g4x. -Daniel > -- > 1.8.3.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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] tests/gem_ringfill: add interruptible mode
Should be useful to test intel_ring_begin restart behaviour a bit.
Signed-off-by: Daniel Vetter
---
tests/gem_ringfill.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tests/gem_ringfill.c b/tests/gem_ringfill.c
index 5700a74d260b..750537a9bbab 100644
--- a/tests/gem_ringfill.c
+++ b/tests/gem_ringfill.c
@@ -226,6 +226,23 @@ igt_main
check_ring(bufmgr, batch, "render", copy);
}
+ igt_fork_signal_helper();
+ igt_subtest("blitter-interruptible")
+ check_ring(bufmgr, batch, "blt", blt_copy);
+
+ /* Strictly only required on architectures with a separate BLT ring,
+* but lets stress everybody.
+*/
+ igt_subtest("render-interruptible") {
+ igt_render_copyfunc_t copy;
+
+ copy = igt_get_render_copyfunc(batch->devid);
+ igt_require(copy);
+
+ check_ring(bufmgr, batch, "render", copy);
+ }
+ igt_stop_signal_helper();
+
igt_fixture {
intel_batchbuffer_free(batch);
drm_intel_bufmgr_destroy(bufmgr);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load & thaw
On Tue, Jul 29, 2014 at 05:25:48PM +, Mcaulay, Alistair wrote: > > drv_suspend, gem_hangcheck_forcewake are working fine now with PPGTT > enabled. Both with and without my patch. > > The results are the same with and without my patch for: > > $ sudo ~/drm_nightly/intel-gpu-tools/tests/drv_hangman > IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64) > Subtest error-state-debugfs-entry: SUCCESS > Subtest error-state-sysfs-entry: SUCCESS > Subtest ring-stop-sysfs-entry: SUCCESS > Subtest error-state-basic: SUCCESS > Subtest error-state-capture-render: SUCCESS > Test assertion failure function check_error_state, file drv_hangman.c:303: > Failed assertion: gtt_offset == expected_offset > Subtest error-state-capture-bsd: FAIL > Test assertion failure function check_error_state, file drv_hangman.c:303: > Failed assertion: gtt_offset == expected_offset > Subtest error-state-capture-blt: FAIL > Test assertion failure function check_error_state, file drv_hangman.c:303: > Failed assertion: gtt_offset == expected_offset > Subtest error-state-capture-vebox: FAIL > > $ sudo ~/drm_nightly/intel-gpu-tools/tests/gem_reset_stats > IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64) > Subtest params: SUCCESS > Subtest params-ctx-render: SUCCESS > Subtest reset-stats-render: SUCCESS > Subtest reset-stats-ctx-render: SUCCESS > Subtest ban-render: SUCCESS > Subtest ban-ctx-render: SUCCESS > Subtest reset-count-render: SUCCESS > Subtest reset-count-ctx-render: SUCCESS > Subtest unrelated-ctx-render: SUCCESS > Subtest close-pending-render: SUCCESS > Subtest close-pending-ctx-render: SUCCESS > > > > Both good without PPGTT. > I haven't yet seen a regression with the patch. gem_ringfill might be able to hit the -EAGAIN issue. But that testcase is missing subtest with signals to interrupt the ioctls. I'll add that. -Daniel > > -Original Message- > From: Ben Widawsky [mailto:b...@bwidawsk.net] > Sent: Tuesday, July 29, 2014 1:17 AM > To: Mcaulay, Alistair > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match > driver load & thaw > > On Mon, Jul 28, 2014 at 05:12:59PM +, Mcaulay, Alistair wrote: > > Hi Ben / Daniel, > > I agree that this needs to be properly tested. Are there any particular igt > > tests you would suggest I use? > > I've been running: > > drv_hangman, drv_suspend, gem_hangcheck_forcewake. > > I thought IGT had added some random reset stuff in the way that we have for > signals. However, it looks like I imagined it. I guess you can add gem_hang, > gem_reset_stats, and tests/debugfs_wedged to that list. Daniel can probably > provide any I might have missed. > > The way that igt quiesces everything these days really hurts the ability to > test multi-process. If every tests starts off with no work, and running the > default context, things are pretty trivial. Similarly, running these tests in > isolation, even if it isn't quiescing doesn't help the situation. The way I > wrote the code originally was through debugging hangs on a desktop as I > developed patches, and not with IGT (though drv_hangman could catch many > issues). I'd definitely recommend trying to invoke hangs on a running > desktop. I'd advise doing this by modifying mesa to submit a crap batch, I > can provide you more details on how to do this if you need it. Also try to > disable the quiescing in IGT and run more than these tests in isolation. > > > > > Also do you have a set of PPGTT Patches that should work with these > > tests. Michel sent me a set of patches to enable PPGTT, but these 3 tests > > fail with the patches. > > I will try to reproduce this on my patch series when I have some time and if > nothing else, that should be a good preparation/refresher for the patch > review anyway. The patches I wrote shouldn't have touched much on these paths > - not sure if Michel changed anything there. > > With patch on top of what Michel sent you, everything passes? > > > > > Thanks, > > Alistair. > > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > > Daniel Vetter > > Sent: Monday, July 28, 2014 10:27 AM > > To: Ben Widawsky > > Cc: Mcaulay, Alistair; intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence > > to match driver load & thaw > > > > On Fri, Jul 25, 2014 at 06:05:29PM -0700, Ben Widawsky wrote: > > > On Wed, Jul 16, 2014 at 04:05:59PM +0100, alistair.mcau...@intel.com > > > wrote: > > > > From: "McAulay, Alistair" > > > > > > > > This patch is to address Daniels concerns over different code during > > > > reset: > > > > > > > > http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.h > > > > tm > > > > l > > > > > > > > "The reason for aiming as hard as possible to use the exact same > > > > code for driver load, gpu reset and runtime pm/system resume is > > > > tha
Re: [Intel-gfx] [PATCH] drm/i915: freeze display before the interrupts and GT
On Thu, 17 Jul 2014 17:43:46 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Since we started using intel_runtime_pm_disable_interrupts() at normal
> (non-runtime) suspend/resume, we had to remove a WARN from
> ironlake_disable_display_irq to avoid a case where we were doing the
> correct thing and the WARN was not really needed. The problem is that
> the WARN was useful in other cases, and its removal can hide some bugs
> that we would catch automatically.
>
> To be able to add back the WARN, we have to call intel_crtc_control()
> before interrupts are disabled, which is what this patch currently
> does.
>
> Also notice that Ville's patch from the Watermarks series "drm/i915:
> Leave interrupts enabled while disabling crtcs during suspend" also
> did a change that's equivalent to the one we're doing on this patch,
> with the exception that its original patch, when applied to the
> current tree, procduces a WARN.
>
> Related commits:
>
> commit daa390e5ee45cc051d6bf37b296901f2f92b002d
> Author: Jesse Barnes
> drm/i915: don't warn if IRQs are disabled when shutting down display IRQs
>
> commit e11aa362308f5de467ce355a2a2471321b15a35c
> Author: Jesse Barnes
> drm/i915: use runtime irq suspend/resume in freeze/thaw
>
> Cc: Ville Syrjälä
> Cc: Jesse Barnes
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.c | 11 +--
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> No need to revert anything :)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3315358..63675bf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -520,12 +520,6 @@ static int i915_drm_freeze(struct drm_device *dev)
> return error;
> }
>
> - flush_delayed_work(&dev_priv->rps.delayed_resume_work);
> -
> - intel_runtime_pm_disable_interrupts(dev);
> -
> - intel_suspend_gt_powersave(dev);
> -
> /*
>* Disable CRTCs directly since we want to preserve sw state
>* for _thaw. Also, power gate the CRTC power wells.
> @@ -535,6 +529,11 @@ static int i915_drm_freeze(struct drm_device *dev)
> intel_crtc_control(crtc, false);
> drm_modeset_unlock_all(dev);
>
> + flush_delayed_work(&dev_priv->rps.delayed_resume_work);
> + intel_runtime_pm_disable_interrupts(dev);
> +
> + intel_suspend_gt_powersave(dev);
> +
> intel_modeset_suspend_hw(dev);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 20c777c..af231ba 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -151,7 +151,7 @@ ironlake_disable_display_irq(struct drm_i915_private
> *dev_priv, u32 mask)
> {
> assert_spin_locked(&dev_priv->irq_lock);
>
> - if (!intel_irqs_enabled(dev_priv))
> + if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> return;
>
> if ((dev_priv->irq_mask & mask) != mask) {
So with this added, we get the WARN back but don't need/want to revert
any other patches?
Did you check boot, suspend/resume, and runtime PM for warnings with
this change applied? If so, looks fine:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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/40] drm/i915: Add cdclk change support for chv
On Tue, 29 Jul 2014 19:59:26 +0200
Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:03:57 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Looks like the Punit is supposed to support the 400MHz cdclk directly on
> > > chv, so we don't need the vlv tricks.
> > >
> > > FIXME: Punit doesn't seem ready for this yet on current hw
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 4 +++
> > > drivers/gpu/drm/i915/intel_display.c | 50
> > > ++--
> > > 2 files changed, 52 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index f156591..e296312 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -491,6 +491,10 @@
> > > #define BUNIT_REG_BISOC 0x11
> > >
> > > #define PUNIT_REG_DSPFREQ0x36
> > > +#define DSPFREQSTAT_SHIFT_CHV 24
> > > +#define DSPFREQSTAT_MASK_CHV (0x1f <<
> > > DSPFREQSTAT_SHIFT_CHV)
> > > +#define DSPFREQGUAR_SHIFT_CHV 8
> > > +#define DSPFREQGUAR_MASK_CHV (0x1f <<
> > > DSPFREQGUAR_SHIFT_CHV)
> > > #define DSPFREQSTAT_SHIFT 30
> > > #define DSPFREQSTAT_MASK (0x3 <<
> > > DSPFREQSTAT_SHIFT)
> > > #define DSPFREQGUAR_SHIFT 14
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 99c10d1..9af1d13 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
> > > *dev, int cdclk)
> > > vlv_update_cdclk(dev);
> > > }
> > >
> > > +static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > + u32 val, cmd;
> > > +
> > > + WARN_ON(dev_priv->display.get_display_clock_speed(dev) !=
> > > dev_priv->vlv_cdclk_freq);
> > > +
> > > + switch (cdclk) {
> > > + case 40:
> > > + cmd = 3;
> > > + break;
> > > + case 33:
> > > + case 32:
> > > + cmd = 2;
> > > + break;
> > > + case 27:
> > > + cmd = 1;
> > > + break;
> > > + case 20:
> > > + cmd = 0;
> > > + break;
> > > + default:
> > > + WARN_ON(1);
> > > + return;
> > > + }
> > > +
> > > + mutex_lock(&dev_priv->rps.hw_lock);
> > > + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> > > + val &= ~DSPFREQGUAR_MASK_CHV;
> > > + val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> > > + vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> > > + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> > > + DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
> > > + 50)) {
> > > + DRM_ERROR("timed out waiting for CDclk change\n");
> > > + }
> > > + mutex_unlock(&dev_priv->rps.hw_lock);
> > > +
> > > + vlv_update_cdclk(dev);
> > > +}
> > > +
> > > static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
> > >int max_pixclk)
> > > {
> > > @@ -4597,8 +4638,13 @@ static void
> > > valleyview_modeset_global_resources(struct drm_device *dev)
> > > int max_pixclk = intel_mode_max_pixclk(dev_priv);
> > > int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
> > >
> > > - if (req_cdclk != dev_priv->vlv_cdclk_freq)
> > > - valleyview_set_cdclk(dev, req_cdclk);
> > > + if (req_cdclk != dev_priv->vlv_cdclk_freq) {
> > > + if (IS_CHERRYVIEW(dev))
> > > + cherryview_set_cdclk(dev, req_cdclk);
> > > + else
> > > + valleyview_set_cdclk(dev, req_cdclk);
> > > + }
> > > +
> > > modeset_update_crtc_power_domains(dev);
> > > }
> > >
> >
> > Which doc has these Punit commands? I'm assuming you have them
> > correct, but a ref would be good if we don't already have one.
>
> Yeah I think I'll hold off on this until the doc has diffused better. For
> byt this was too much fun with jumping back&forth a few times ...
Well, the next patch disables this until we can test anyway, so it
should be fine to add and fixup/add the doc link later.
--
Jesse Barnes, 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 34/40] drm/i915: Add DP training pattern 3 for CHV
On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:25 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > CHV supports DP training pattern 3. Add the required stuff.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > drivers/gpu/drm/i915/intel_dp.c | 18 ++
> > 2 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 85b59c4..8debe61 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3515,6 +3515,8 @@ enum punit_power_well {
> > #define DP_LINK_TRAIN_OFF(3 << 28)
> > #define DP_LINK_TRAIN_MASK (3 << 28)
> > #define DP_LINK_TRAIN_SHIFT 28
> > +#define DP_LINK_TRAIN_PAT_3_CHV (1 << 14)
> > +#define DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
> >
> > /* CPT Link training mode */
> > #define DP_LINK_TRAIN_PAT_1_CPT (0 << 8)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 739dc43..a825ff1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > }
> >
> > } else {
> > - *DP &= ~DP_LINK_TRAIN_MASK;
> > + if (IS_CHERRYVIEW(dev))
> > + *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > + else
> > + *DP &= ~DP_LINK_TRAIN_MASK;
> >
> > switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > case DP_TRAINING_PATTERN_DISABLE:
> > @@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > *DP |= DP_LINK_TRAIN_PAT_2;
> > break;
> > case DP_TRAINING_PATTERN_3:
> > - DRM_ERROR("DP training pattern 3 not supported\n");
> > - *DP |= DP_LINK_TRAIN_PAT_2;
> > + if (IS_CHERRYVIEW(dev)) {
> > + *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > + } else {
> > + DRM_ERROR("DP training pattern 3 not
> > supported\n");
> > + *DP |= DP_LINK_TRAIN_PAT_2;
> > + }
> > break;
> > }
> > }
> > @@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
> > DP &= ~DP_LINK_TRAIN_MASK_CPT;
> > I915_WRITE(intel_dp->output_reg, DP |
> > DP_LINK_TRAIN_PAT_IDLE_CPT);
> > } else {
> > - DP &= ~DP_LINK_TRAIN_MASK;
> > + if (IS_CHERRYVIEW(dev))
> > + DP &= ~DP_LINK_TRAIN_MASK_CHV;
> > + else
> > + DP &= ~DP_LINK_TRAIN_MASK;
> > I915_WRITE(intel_dp->output_reg, DP | DP_LINK_TRAIN_PAT_IDLE);
> > }
> > POSTING_READ(intel_dp->output_reg);
>
> I guess we could have a whole IS_CHV block, but that would probably add
> more code than it saved...
>
> Reviewed-by: Jesse Barnes
This won't do a hole lot without adding HBR2 support ... Queued for
-next anyway, thanks for the patch.
-Daniel
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
Re: [Intel-gfx] [PATCH 29/40] drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
On Tue, Jul 29, 2014 at 09:59:53AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:04:20 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Kenneth Graunke
> >
> > We'll want to reuse this for a workaround.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 36
> > -
> > 1 file changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 2faef26..97796b1 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -381,6 +381,27 @@ gen7_render_ring_flush(struct intel_engine_cs *ring,
> > }
> >
> > static int
> > +gen8_emit_pipe_control(struct intel_engine_cs *ring,
> > + u32 flags, u32 scratch_addr)
> > +{
> > + int ret;
> > +
> > + ret = intel_ring_begin(ring, 6);
> > + if (ret)
> > + return ret;
> > +
> > + intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
> > + intel_ring_emit(ring, flags);
> > + intel_ring_emit(ring, scratch_addr);
> > + intel_ring_emit(ring, 0);
> > + intel_ring_emit(ring, 0);
> > + intel_ring_emit(ring, 0);
> > + intel_ring_advance(ring);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > gen8_render_ring_flush(struct intel_engine_cs *ring,
> >u32 invalidate_domains, u32 flush_domains)
> > {
> > @@ -405,20 +426,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
> > flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
> > }
> >
> > - ret = intel_ring_begin(ring, 6);
> > - if (ret)
> > - return ret;
> > -
> > - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
> > - intel_ring_emit(ring, flags);
> > - intel_ring_emit(ring, scratch_addr);
> > - intel_ring_emit(ring, 0);
> > - intel_ring_emit(ring, 0);
> > - intel_ring_emit(ring, 0);
> > - intel_ring_advance(ring);
> > -
> > - return 0;
> > -
> > + return gen8_emit_pipe_control(ring, flags, scratch_addr);
> > }
> >
> > static void ring_write_tail(struct intel_engine_cs *ring,
>
> Reviewed-by: Jesse Barnes
Aside: checkpatch complains about this since it makes it harder to grep
for dmesg noise. But I guess if 3 people here like it I should merge it
;-)
Queued for -next, thanks for the patch.
-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
Re: [Intel-gfx] [PATCH 06/40] drm/i915: Add cdclk change support for chv
On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
> On Sat, 28 Jun 2014 02:03:57 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Looks like the Punit is supposed to support the 400MHz cdclk directly on
> > chv, so we don't need the vlv tricks.
> >
> > FIXME: Punit doesn't seem ready for this yet on current hw
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 4 +++
> > drivers/gpu/drm/i915/intel_display.c | 50
> > ++--
> > 2 files changed, 52 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f156591..e296312 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -491,6 +491,10 @@
> > #define BUNIT_REG_BISOC0x11
> >
> > #define PUNIT_REG_DSPFREQ 0x36
> > +#define DSPFREQSTAT_SHIFT_CHV24
> > +#define DSPFREQSTAT_MASK_CHV (0x1f <<
> > DSPFREQSTAT_SHIFT_CHV)
> > +#define DSPFREQGUAR_SHIFT_CHV8
> > +#define DSPFREQGUAR_MASK_CHV (0x1f <<
> > DSPFREQGUAR_SHIFT_CHV)
> > #define DSPFREQSTAT_SHIFT30
> > #define DSPFREQSTAT_MASK (0x3 << DSPFREQSTAT_SHIFT)
> > #define DSPFREQGUAR_SHIFT14
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 99c10d1..9af1d13 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
> > *dev, int cdclk)
> > vlv_update_cdclk(dev);
> > }
> >
> > +static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + u32 val, cmd;
> > +
> > + WARN_ON(dev_priv->display.get_display_clock_speed(dev) !=
> > dev_priv->vlv_cdclk_freq);
> > +
> > + switch (cdclk) {
> > + case 40:
> > + cmd = 3;
> > + break;
> > + case 33:
> > + case 32:
> > + cmd = 2;
> > + break;
> > + case 27:
> > + cmd = 1;
> > + break;
> > + case 20:
> > + cmd = 0;
> > + break;
> > + default:
> > + WARN_ON(1);
> > + return;
> > + }
> > +
> > + mutex_lock(&dev_priv->rps.hw_lock);
> > + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> > + val &= ~DSPFREQGUAR_MASK_CHV;
> > + val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> > + vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> > + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> > + DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
> > +50)) {
> > + DRM_ERROR("timed out waiting for CDclk change\n");
> > + }
> > + mutex_unlock(&dev_priv->rps.hw_lock);
> > +
> > + vlv_update_cdclk(dev);
> > +}
> > +
> > static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
> > int max_pixclk)
> > {
> > @@ -4597,8 +4638,13 @@ static void
> > valleyview_modeset_global_resources(struct drm_device *dev)
> > int max_pixclk = intel_mode_max_pixclk(dev_priv);
> > int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
> >
> > - if (req_cdclk != dev_priv->vlv_cdclk_freq)
> > - valleyview_set_cdclk(dev, req_cdclk);
> > + if (req_cdclk != dev_priv->vlv_cdclk_freq) {
> > + if (IS_CHERRYVIEW(dev))
> > + cherryview_set_cdclk(dev, req_cdclk);
> > + else
> > + valleyview_set_cdclk(dev, req_cdclk);
> > + }
> > +
> > modeset_update_crtc_power_domains(dev);
> > }
> >
>
> Which doc has these Punit commands? I'm assuming you have them
> correct, but a ref would be good if we don't already have one.
Yeah I think I'll hold off on this until the doc has diffused better. For
byt this was too much fun with jumping back&forth a few times ...
-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
Re: [Intel-gfx] [PATCH 10/9] drm: Add dev->vblank_disable_immediate flag
On Tue, Jul 29, 2014 at 08:31:55PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
> > On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a flag to drm_device which will cause the vblank code to bypass the
> > > disable timer and always disable the vblank interrupt immediately when
> > > the last reference is dropped.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_irq.c | 6 +++---
> > > include/drm/drmP.h| 10 ++
> > > 2 files changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index 20a4855..b008803 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -994,11 +994,11 @@ void drm_vblank_put(struct drm_device *dev, int
> > > crtc)
> > >
> > > /* Last user schedules interrupt disable */
> > > if (atomic_dec_and_test(&vblank->refcount)) {
> > > - if (drm_vblank_offdelay > 0)
> > > + if (dev->vblank_disable_immediate || drm_vblank_offdelay == 0)
> > > + vblank_disable_fn((unsigned long)vblank);
> > > + else if (drm_vblank_offdelay > 0)
> > > mod_timer(&vblank->disable_timer,
> > > jiffies + ((drm_vblank_offdelay * HZ)/1000));
> > > - else if (drm_vblank_offdelay == 0)
> > > - vblank_disable_fn((unsigned long)vblank);
> > > }
> > > }
> > > EXPORT_SYMBOL(drm_vblank_put);
> >
> > Would it be better if we just squashed this device flag logic back into
> > patch 7, but kept the drm_vblank_offdelay == 0 meaning of "never
> > disable?" I can see there being people who might already use this when
> > debugging new and potentially flaky hardware platforms who would be
> > surprised by the change in behavior. So basically something like:
> >
> > if (drm_vblank_offdelay == 0)
> > return
> > else if (dev->vblank_disable_immediate)
> > vblank_disable_fn((unsigned long)vblank);
> > else
> > mod_timer(...);
>
> I'm not sure I want drm_vblank_offdelay affecting drivers that have
> vblank_disable_immediate set since it's a global variable. If there
> are two devices on the system where one has
> vblank_disable_immediate==true and the other doesn't, the user
> might want to keep vblank interrupts enabled on the crappy device
> all time by frobbing drm_vblank_offdelay.
>
> I agree that changing the meaning of drm_vblank_offdelay=0 is a bit
> questionable, but reversing the meaning so that '==0' meas 'never disable'
> and '<0' means 'disable immediately' seemed a bit weird for my taste. But
> I suppose I could make that change if people think it's better. Or maybe
> just forget about the 'disable immediately' behaviour when
> vblank_disable_immediate==false?
>
> > I'd also suggest adding a comment in drm_stub.c to indicate that
> > drm_vblank_offdelay gets ignored for drivers that set
> > vblank_disable_immediate.
>
> Good idea.
Yeah, I think that's good enough. There really shouldn't be any need for
drivers which support immediate vblank disabling to ever keep it on for a
while. Presuming the immediate disable actually works ofc.
-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
Re: [Intel-gfx] [PATCH 10/9] drm: Add dev->vblank_disable_immediate flag
On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
> On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add a flag to drm_device which will cause the vblank code to bypass the
> > disable timer and always disable the vblank interrupt immediately when
> > the last reference is dropped.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_irq.c | 6 +++---
> > include/drm/drmP.h| 10 ++
> > 2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 20a4855..b008803 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -994,11 +994,11 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> >
> > /* Last user schedules interrupt disable */
> > if (atomic_dec_and_test(&vblank->refcount)) {
> > - if (drm_vblank_offdelay > 0)
> > + if (dev->vblank_disable_immediate || drm_vblank_offdelay == 0)
> > + vblank_disable_fn((unsigned long)vblank);
> > + else if (drm_vblank_offdelay > 0)
> > mod_timer(&vblank->disable_timer,
> > jiffies + ((drm_vblank_offdelay * HZ)/1000));
> > - else if (drm_vblank_offdelay == 0)
> > - vblank_disable_fn((unsigned long)vblank);
> > }
> > }
> > EXPORT_SYMBOL(drm_vblank_put);
>
> Would it be better if we just squashed this device flag logic back into
> patch 7, but kept the drm_vblank_offdelay == 0 meaning of "never
> disable?" I can see there being people who might already use this when
> debugging new and potentially flaky hardware platforms who would be
> surprised by the change in behavior. So basically something like:
>
> if (drm_vblank_offdelay == 0)
> return
> else if (dev->vblank_disable_immediate)
> vblank_disable_fn((unsigned long)vblank);
> else
> mod_timer(...);
I'm not sure I want drm_vblank_offdelay affecting drivers that have
vblank_disable_immediate set since it's a global variable. If there
are two devices on the system where one has
vblank_disable_immediate==true and the other doesn't, the user
might want to keep vblank interrupts enabled on the crappy device
all time by frobbing drm_vblank_offdelay.
I agree that changing the meaning of drm_vblank_offdelay=0 is a bit
questionable, but reversing the meaning so that '==0' meas 'never disable'
and '<0' means 'disable immediately' seemed a bit weird for my taste. But
I suppose I could make that change if people think it's better. Or maybe
just forget about the 'disable immediately' behaviour when
vblank_disable_immediate==false?
> I'd also suggest adding a comment in drm_stub.c to indicate that
> drm_vblank_offdelay gets ignored for drivers that set
> vblank_disable_immediate.
Good idea.
>
> Other than that, patches 1-8, 10, and 11 are
> Reviewed-by: Matt Roper
>
> I'll finish up reviewing #9 and 12-14 tomorrow when I have some more
> time.
>
>
>
> Matt
>
>
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 979a498..0944544 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1117,6 +1117,16 @@ struct drm_device {
> > */
> > bool vblank_disable_allowed;
> >
> > + /*
> > +* If true, vblank interrupt will be disabled immediately when the
> > +* refcount drops to zero, as opposed to via the vblank disable
> > +* timer.
> > +* This can be set to true it the hardware has a working vblank
> > +* counter and the driver uses drm_vblank_on() and drm_vblank_off()
> > +* appropriately.
> > +*/
> > + bool vblank_disable_immediate;
> > +
> > /* array of size num_crtcs */
> > struct drm_vblank_crtc *vblank;
> >
> > --
> > 1.8.5.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
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: Rework GPU reset sequence to match driver load & thaw
drv_suspend, gem_hangcheck_forcewake are working fine now with PPGTT enabled. Both with and without my patch. The results are the same with and without my patch for: $ sudo ~/drm_nightly/intel-gpu-tools/tests/drv_hangman IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64) Subtest error-state-debugfs-entry: SUCCESS Subtest error-state-sysfs-entry: SUCCESS Subtest ring-stop-sysfs-entry: SUCCESS Subtest error-state-basic: SUCCESS Subtest error-state-capture-render: SUCCESS Test assertion failure function check_error_state, file drv_hangman.c:303: Failed assertion: gtt_offset == expected_offset Subtest error-state-capture-bsd: FAIL Test assertion failure function check_error_state, file drv_hangman.c:303: Failed assertion: gtt_offset == expected_offset Subtest error-state-capture-blt: FAIL Test assertion failure function check_error_state, file drv_hangman.c:303: Failed assertion: gtt_offset == expected_offset Subtest error-state-capture-vebox: FAIL $ sudo ~/drm_nightly/intel-gpu-tools/tests/gem_reset_stats IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64) Subtest params: SUCCESS Subtest params-ctx-render: SUCCESS Subtest reset-stats-render: SUCCESS Subtest reset-stats-ctx-render: SUCCESS Subtest ban-render: SUCCESS Subtest ban-ctx-render: SUCCESS Subtest reset-count-render: SUCCESS Subtest reset-count-ctx-render: SUCCESS Subtest unrelated-ctx-render: SUCCESS Subtest close-pending-render: SUCCESS Subtest close-pending-ctx-render: SUCCESS Both good without PPGTT. I haven't yet seen a regression with the patch. -Original Message- From: Ben Widawsky [mailto:b...@bwidawsk.net] Sent: Tuesday, July 29, 2014 1:17 AM To: Mcaulay, Alistair Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load & thaw On Mon, Jul 28, 2014 at 05:12:59PM +, Mcaulay, Alistair wrote: > Hi Ben / Daniel, > I agree that this needs to be properly tested. Are there any particular igt > tests you would suggest I use? > I've been running: > drv_hangman, drv_suspend, gem_hangcheck_forcewake. I thought IGT had added some random reset stuff in the way that we have for signals. However, it looks like I imagined it. I guess you can add gem_hang, gem_reset_stats, and tests/debugfs_wedged to that list. Daniel can probably provide any I might have missed. The way that igt quiesces everything these days really hurts the ability to test multi-process. If every tests starts off with no work, and running the default context, things are pretty trivial. Similarly, running these tests in isolation, even if it isn't quiescing doesn't help the situation. The way I wrote the code originally was through debugging hangs on a desktop as I developed patches, and not with IGT (though drv_hangman could catch many issues). I'd definitely recommend trying to invoke hangs on a running desktop. I'd advise doing this by modifying mesa to submit a crap batch, I can provide you more details on how to do this if you need it. Also try to disable the quiescing in IGT and run more than these tests in isolation. > > Also do you have a set of PPGTT Patches that should work with these > tests. Michel sent me a set of patches to enable PPGTT, but these 3 tests > fail with the patches. I will try to reproduce this on my patch series when I have some time and if nothing else, that should be a good preparation/refresher for the patch review anyway. The patches I wrote shouldn't have touched much on these paths - not sure if Michel changed anything there. With patch on top of what Michel sent you, everything passes? > > Thanks, > Alistair. > > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Monday, July 28, 2014 10:27 AM > To: Ben Widawsky > Cc: Mcaulay, Alistair; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence > to match driver load & thaw > > On Fri, Jul 25, 2014 at 06:05:29PM -0700, Ben Widawsky wrote: > > On Wed, Jul 16, 2014 at 04:05:59PM +0100, alistair.mcau...@intel.com wrote: > > > From: "McAulay, Alistair" > > > > > > This patch is to address Daniels concerns over different code during > > > reset: > > > > > > http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.h > > > tm > > > l > > > > > > "The reason for aiming as hard as possible to use the exact same > > > code for driver load, gpu reset and runtime pm/system resume is > > > that we've simply seen too many bugs due to slight variations and > > > unintended omissions." > > > > > > Tested using igt drv_hangman. > > > > > > Signed-off-by: McAulay, Alistair > > > > 2 quick comments before I actually do a real review. > > 1. Did you actually run this with and without full ppgtt? > > 2. I don't think this is actually fulfilling what Daniel is > > requesting, though we can let him comment. > > Mostly looks like what I th
[Intel-gfx] [PATCH 09/10] drm/i915: Split the CDCLK retrieval per-platform
This is only going to get worse, so split it now to avoid adding more
cases to the if/else ladder.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 55 +++-
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 69dc54c..2aad888 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1192,31 +1192,52 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
}
}
-int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
+static int bdw_get_cdclk_freq(struct drm_i915_private *dev_priv)
+{
+ uint32_t lcpll = I915_READ(LCPLL_CTL);
+ uint32_t freq = lcpll & LCPLL_CLK_FREQ_MASK;
+
+ if (lcpll & LCPLL_CD_SOURCE_FCLK)
+ return 80;
+ else if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT)
+ return 45;
+ else if (freq == LCPLL_CLK_FREQ_450)
+ return 45;
+ else if (freq == LCPLL_CLK_FREQ_54O_BDW)
+ return 54;
+ else if (freq == LCPLL_CLK_FREQ_337_5_BDW)
+ return 337500;
+ else
+ return 675000;
+}
+
+static int hsw_get_cdclk_freq(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
uint32_t lcpll = I915_READ(LCPLL_CTL);
uint32_t freq = lcpll & LCPLL_CLK_FREQ_MASK;
- if (lcpll & LCPLL_CD_SOURCE_FCLK) {
+ if (lcpll & LCPLL_CD_SOURCE_FCLK)
return 80;
- } else if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT) {
+ else if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT)
return 45;
- } else if (freq == LCPLL_CLK_FREQ_450) {
+ else if (freq == LCPLL_CLK_FREQ_450)
return 45;
- } else if (IS_HASWELL(dev)) {
- if (IS_ULT(dev))
- return 337500;
- else
- return 54;
- } else {
- if (freq == LCPLL_CLK_FREQ_54O_BDW)
- return 54;
- else if (freq == LCPLL_CLK_FREQ_337_5_BDW)
- return 337500;
- else
- return 675000;
- }
+ else if (IS_ULT(dev))
+ return 337500;
+ else
+ return 54;
+}
+
+int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv->dev;
+
+ if (IS_BROADWELL(dev))
+ return bdw_get_cdclk_freq(dev_priv);
+
+ /* Haswell */
+ return hsw_get_cdclk_freq(dev_priv);
}
static void hsw_ddi_pll_enable(struct drm_i915_private *dev_priv,
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Make ddi_clock_gate() HSW/BDW specific
Turns out we were again way too naive and optimistic, of course things
will change.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2aad888..a6024de 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -587,8 +587,8 @@ static int intel_ddi_calc_wrpll_link(struct
drm_i915_private *dev_priv,
return (refclk * n * 100) / (p * r);
}
-void intel_ddi_clock_get(struct intel_encoder *encoder,
-struct intel_crtc_config *pipe_config)
+static void hsw_ddi_clock_get(struct intel_encoder *encoder,
+ struct intel_crtc_config *pipe_config)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
int link_clock = 0;
@@ -643,6 +643,12 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
pipe_config->adjusted_mode.crtc_clock = pipe_config->port_clock;
}
+void intel_ddi_clock_get(struct intel_encoder *encoder,
+struct intel_crtc_config *pipe_config)
+{
+ hsw_ddi_clock_get(encoder, pipe_config);
+}
+
static void
hsw_ddi_calculate_wrpll(int clock /* in Hz */,
unsigned *r2_out, unsigned *n2_out, unsigned *p_out)
@@ -1480,7 +1486,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
dev_priv->vbt.edp_bpp = pipe_config->pipe_bpp;
}
- intel_ddi_clock_get(encoder, pipe_config);
+ hsw_ddi_clock_get(encoder, pipe_config);
}
static void intel_ddi_destroy(struct drm_encoder *encoder)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 98e2fd5..69dc54c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -644,8 +644,8 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
}
static void
-intel_ddi_calculate_wrpll(int clock /* in Hz */,
- unsigned *r2_out, unsigned *n2_out, unsigned *p_out)
+hsw_ddi_calculate_wrpll(int clock /* in Hz */,
+ unsigned *r2_out, unsigned *n2_out, unsigned *p_out)
{
uint64_t freq2k;
unsigned p, n2, r2;
@@ -709,14 +709,16 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
}
static bool
-hsw_ddi_pll_select(struct intel_crtc *intel_crtc, int output, int clock)
+hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
+ struct intel_encoder *intel_encoder,
+ int clock)
{
- if (output == INTEL_OUTPUT_HDMI) {
+ if (intel_encoder->type == INTEL_OUTPUT_HDMI) {
struct intel_shared_dpll *pll;
uint32_t val;
unsigned p, n2, r2;
- intel_ddi_calculate_wrpll(clock * 1000, &r2, &n2, &p);
+ hsw_ddi_calculate_wrpll(clock * 1000, &r2, &n2, &p);
val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
@@ -749,12 +751,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
{
struct drm_crtc *crtc = &intel_crtc->base;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- int type = intel_encoder->type;
int clock = intel_crtc->config.port_clock;
intel_put_shared_dpll(intel_crtc);
- return hsw_ddi_pll_select(intel_crtc, type, clock);
+ return hsw_ddi_pll_select(intel_crtc, intel_encoder, clock);
}
void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Extract the HSW DDI selection code into its own function
Future platform will slightly change that.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0147652..5678c68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7573,6 +7573,22 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
return 0;
}
+static void haswell_get_ddi_pll(struct drm_i915_private *dev_priv,
+ enum port port,
+ struct intel_crtc_config *pipe_config)
+{
+ pipe_config->ddi_pll_sel = I915_READ(PORT_CLK_SEL(port));
+
+ switch (pipe_config->ddi_pll_sel) {
+ case PORT_CLK_SEL_WRPLL1:
+ pipe_config->shared_dpll = DPLL_ID_WRPLL1;
+ break;
+ case PORT_CLK_SEL_WRPLL2:
+ pipe_config->shared_dpll = DPLL_ID_WRPLL2;
+ break;
+ }
+}
+
static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
{
@@ -7586,16 +7602,7 @@ static void haswell_get_ddi_port_state(struct intel_crtc
*crtc,
port = (tmp & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT;
- pipe_config->ddi_pll_sel = I915_READ(PORT_CLK_SEL(port));
-
- switch (pipe_config->ddi_pll_sel) {
- case PORT_CLK_SEL_WRPLL1:
- pipe_config->shared_dpll = DPLL_ID_WRPLL1;
- break;
- case PORT_CLK_SEL_WRPLL2:
- pipe_config->shared_dpll = DPLL_ID_WRPLL2;
- break;
- }
+ haswell_get_ddi_pll(dev_priv, port, pipe_config);
if (pipe_config->shared_dpll >= 0) {
pll = &dev_priv->shared_dplls[pipe_config->shared_dpll];
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Split the BDW/HSW specific shared pll selection
We'll need a different algorithm to select the shared DPLL.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4012a7b..98e2fd5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -708,23 +708,10 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
*r2_out = best.r2;
}
-/*
- * Tries to find a *shared* PLL for the CRTC and store it in
- * intel_crtc->ddi_pll_sel.
- *
- * For private DPLLs, compute_config() should do the selection for us. This
- * function should be folded into compute_config() eventually.
- */
-bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
+static bool
+hsw_ddi_pll_select(struct intel_crtc *intel_crtc, int output, int clock)
{
- struct drm_crtc *crtc = &intel_crtc->base;
- struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- int type = intel_encoder->type;
- int clock = intel_crtc->config.port_clock;
-
- intel_put_shared_dpll(intel_crtc);
-
- if (type == INTEL_OUTPUT_HDMI) {
+ if (output == INTEL_OUTPUT_HDMI) {
struct intel_shared_dpll *pll;
uint32_t val;
unsigned p, n2, r2;
@@ -750,6 +737,26 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
return true;
}
+
+/*
+ * Tries to find a *shared* PLL for the CRTC and store it in
+ * intel_crtc->ddi_pll_sel.
+ *
+ * For private DPLLs, compute_config() should do the selection for us. This
+ * function should be folded into compute_config() eventually.
+ */
+bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
+{
+ struct drm_crtc *crtc = &intel_crtc->base;
+ struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
+ int type = intel_encoder->type;
+ int clock = intel_crtc->config.port_clock;
+
+ intel_put_shared_dpll(intel_crtc);
+
+ return hsw_ddi_pll_select(intel_crtc, type, clock);
+}
+
void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = crtc->dev->dev_private;
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/10] Split the HSW/BDW PLL code a bit more
Turns out we were optimistic. intel_ prefixes don't tend to last and this is one of those times. -- Damien Damien Lespiau (10): drm/i915: Specify when the PLL hw state fields are valid drm/i915: Add a space to the shared DPLL debug message drm/i915: Extract the HSW DDI selection code into its own function drm/i915: Extract the HSW/BDW shared dpll init code drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW drm/i915: Fix stale comment for intel_ddi_pll_select() drm/i915: Split the BDW/HSW specific shared pll selection drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific drm/i915: Split the CDCLK retrieval per-platform drm/i915: Make ddi_clock_gate() HSW/BDW specific drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/intel_ddi.c | 124 +++ drivers/gpu/drm/i915/intel_display.c | 29 drivers/gpu/drm/i915/intel_dp.c | 2 +- 4 files changed, 105 insertions(+), 53 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Add a space to the shared DPLL debug message
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1a..0147652 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1778,7 +1778,7 @@ static void intel_enable_shared_dpll(struct intel_crtc
*crtc)
if (WARN_ON(pll->refcount == 0))
return;
- DRM_DEBUG_KMS("enable %s (active %d, on? %d)for crtc %d\n",
+ DRM_DEBUG_KMS("enable %s (active %d, on? %d) for crtc %d\n",
pll->name, pll->active, pll->on,
crtc->base.base.id);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Extract the HSW/BDW shared dpll init code
So we can easily provide an alternate implementation in the future.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1848906..55d7dad 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1248,10 +1248,8 @@ static const char * const hsw_ddi_pll_names[] = {
"WRPLL 2",
};
-void intel_ddi_pll_init(struct drm_device *dev)
+static void hsw_shared_dplls_init(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- uint32_t val = I915_READ(LCPLL_CTL);
int i;
dev_priv->num_shared_dpll = 2;
@@ -1264,6 +1262,14 @@ void intel_ddi_pll_init(struct drm_device *dev)
dev_priv->shared_dplls[i].get_hw_state =
hsw_ddi_pll_get_hw_state;
}
+}
+
+void intel_ddi_pll_init(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t val = I915_READ(LCPLL_CTL);
+
+ hsw_shared_dplls_init(dev_priv);
/* The LCPLL register should be turned on by the BIOS. For now let's
* just check its state and print errors in case something is wrong.
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW
Future platform will use config->ddi_pll_sel in a different way. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index ea6ff71..bdbe8f7 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -976,7 +976,7 @@ found: &pipe_config->dp_m2_n2); } - if (HAS_DDI(dev)) + if (IS_HASWELL(dev) || IS_BROADWELL(dev)) hsw_dp_set_ddi_pll_sel(pipe_config, intel_dp->link_bw); else intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw); -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Fix stale comment for intel_ddi_pll_select()
Since the run-time PM on DPMS series, this function has an outdated
comment. Refresh it a bit.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 55d7dad..4012a7b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -709,10 +709,11 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
}
/*
- * Tries to find a PLL for the CRTC. If it finds, it increases the refcount and
- * stores it in intel_crtc->ddi_pll_sel, so other mode sets won't be able to
- * steal the selected PLL. You need to call intel_ddi_pll_enable to actually
- * enable the PLL.
+ * Tries to find a *shared* PLL for the CRTC and store it in
+ * intel_crtc->ddi_pll_sel.
+ *
+ * For private DPLLs, compute_config() should do the selection for us. This
+ * function should be folded into compute_config() eventually.
*/
bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
{
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: Specify when the PLL hw state fields are valid
Not all those fields are valid on a given platform. Make it explicit.
Unions could also be used, but were cluttering some code paths with
if/else ladders.
v2: Don't use anonymous unions (Daniel)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..d604f4f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -197,10 +197,13 @@ enum intel_dpll_id {
#define I915_NUM_PLLS 2
struct intel_dpll_hw_state {
+ /* i9xx, pch plls */
uint32_t dpll;
uint32_t dpll_md;
uint32_t fp0;
uint32_t fp1;
+
+ /* hsw, bdw */
uint32_t wrpll;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 34/40] drm/i915: Add DP training pattern 3 for CHV
On Sat, 28 Jun 2014 02:04:25 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CHV supports DP training pattern 3. Add the required stuff.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_dp.c | 18 ++
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 85b59c4..8debe61 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3515,6 +3515,8 @@ enum punit_power_well {
> #define DP_LINK_TRAIN_OFF (3 << 28)
> #define DP_LINK_TRAIN_MASK (3 << 28)
> #define DP_LINK_TRAIN_SHIFT28
> +#define DP_LINK_TRAIN_PAT_3_CHV(1 << 14)
> +#define DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
>
> /* CPT Link training mode */
> #define DP_LINK_TRAIN_PAT_1_CPT(0 << 8)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 739dc43..a825ff1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> }
>
> } else {
> - *DP &= ~DP_LINK_TRAIN_MASK;
> + if (IS_CHERRYVIEW(dev))
> + *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> + else
> + *DP &= ~DP_LINK_TRAIN_MASK;
>
> switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> case DP_TRAINING_PATTERN_DISABLE:
> @@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> *DP |= DP_LINK_TRAIN_PAT_2;
> break;
> case DP_TRAINING_PATTERN_3:
> - DRM_ERROR("DP training pattern 3 not supported\n");
> - *DP |= DP_LINK_TRAIN_PAT_2;
> + if (IS_CHERRYVIEW(dev)) {
> + *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> + } else {
> + DRM_ERROR("DP training pattern 3 not
> supported\n");
> + *DP |= DP_LINK_TRAIN_PAT_2;
> + }
> break;
> }
> }
> @@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
> DP &= ~DP_LINK_TRAIN_MASK_CPT;
> I915_WRITE(intel_dp->output_reg, DP |
> DP_LINK_TRAIN_PAT_IDLE_CPT);
> } else {
> - DP &= ~DP_LINK_TRAIN_MASK;
> + if (IS_CHERRYVIEW(dev))
> + DP &= ~DP_LINK_TRAIN_MASK_CHV;
> + else
> + DP &= ~DP_LINK_TRAIN_MASK;
> I915_WRITE(intel_dp->output_reg, DP | DP_LINK_TRAIN_PAT_IDLE);
> }
> POSTING_READ(intel_dp->output_reg);
I guess we could have a whole IS_CHV block, but that would probably add
more code than it saved...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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 29/40] drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
On Sat, 28 Jun 2014 02:04:20 +0300
ville.syrj...@linux.intel.com wrote:
> From: Kenneth Graunke
>
> We'll want to reuse this for a workaround.
>
> Signed-off-by: Kenneth Graunke
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 36
> -
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 2faef26..97796b1 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -381,6 +381,27 @@ gen7_render_ring_flush(struct intel_engine_cs *ring,
> }
>
> static int
> +gen8_emit_pipe_control(struct intel_engine_cs *ring,
> +u32 flags, u32 scratch_addr)
> +{
> + int ret;
> +
> + ret = intel_ring_begin(ring, 6);
> + if (ret)
> + return ret;
> +
> + intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
> + intel_ring_emit(ring, flags);
> + intel_ring_emit(ring, scratch_addr);
> + intel_ring_emit(ring, 0);
> + intel_ring_emit(ring, 0);
> + intel_ring_emit(ring, 0);
> + intel_ring_advance(ring);
> +
> + return 0;
> +}
> +
> +static int
> gen8_render_ring_flush(struct intel_engine_cs *ring,
> u32 invalidate_domains, u32 flush_domains)
> {
> @@ -405,20 +426,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
> flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
> }
>
> - ret = intel_ring_begin(ring, 6);
> - if (ret)
> - return ret;
> -
> - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
> - intel_ring_emit(ring, flags);
> - intel_ring_emit(ring, scratch_addr);
> - intel_ring_emit(ring, 0);
> - intel_ring_emit(ring, 0);
> - intel_ring_emit(ring, 0);
> - intel_ring_advance(ring);
> -
> - return 0;
> -
> + return gen8_emit_pipe_control(ring, flags, scratch_addr);
> }
>
> static void ring_write_tail(struct intel_engine_cs *ring,
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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 27/40] drm/i915: Split a few long debug prints
On Sat, 28 Jun 2014 02:04:18 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Split some WM debug prints to multiple lines. This shouldn't hurt
> grappability since the important part is at the start and the rest
> is just repeated stuff for each pipe.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f0516a7..cb0b4b4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1345,7 +1345,8 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
> plane_sr = cursor_sr = 0;
> }
>
> - DRM_DEBUG_KMS("Setting FIFO watermarks - A: plane=%d, cursor=%d, B:
> plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n",
> + DRM_DEBUG_KMS("Setting FIFO watermarks - A: plane=%d, cursor=%d, "
> + "B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n",
> planea_wm, cursora_wm,
> planeb_wm, cursorb_wm,
> plane_sr, cursor_sr);
> @@ -1397,7 +1398,8 @@ static void g4x_update_wm(struct drm_crtc *crtc)
> plane_sr = cursor_sr = 0;
> }
>
> - DRM_DEBUG_KMS("Setting FIFO watermarks - A: plane=%d, cursor=%d, B:
> plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n",
> + DRM_DEBUG_KMS("Setting FIFO watermarks - A: plane=%d, cursor=%d, "
> + "B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n",
> planea_wm, cursora_wm,
> planeb_wm, cursorb_wm,
> plane_sr, cursor_sr);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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/40] drm/i915: Override display PHY TX FIFO reset master on chv
On Sat, 28 Jun 2014 02:04:05 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Just an attempt to frob these bits. Apparently we should not need to
> touch them (apart from maybe making sure the override is disabled so
> that the hardware automagically does the right thing).
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 12
> drivers/gpu/drm/i915/intel_dp.c | 23 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 23 +++
> 3 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2a7bc22..d246609 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -758,6 +758,8 @@ enum punit_power_well {
> #define _VLV_PCS_DW0_CH1 0x8400
> #define DPIO_PCS_TX_LANE2_RESET(1<<16)
> #define DPIO_PCS_TX_LANE1_RESET(1<<7)
> +#define DPIO_LEFT_TXFIFO_RST_MASTER2 (1<<4)
> +#define DPIO_RIGHT_TXFIFO_RST_MASTER2 (1<<3)
> #define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
>
> #define _VLV_PCS01_DW0_CH0 0x200
> @@ -834,8 +836,18 @@ enum punit_power_well {
>
> #define _VLV_PCS_DW11_CH00x822c
> #define _VLV_PCS_DW11_CH10x842c
> +#define DPIO_LANEDESKEW_STRAP_OVRD (1<<3)
> +#define DPIO_LEFT_TXFIFO_RST_MASTER(1<<1)
> +#define DPIO_RIGHT_TXFIFO_RST_MASTER (1<<0)
> #define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
>
> +#define _VLV_PCS01_DW11_CH0 0x022c
> +#define _VLV_PCS23_DW11_CH0 0x042c
> +#define _VLV_PCS01_DW11_CH1 0x262c
> +#define _VLV_PCS23_DW11_CH1 0x282c
> +#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW0_CH0, _VLV_PCS01_DW0_CH1)
> +#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW0_CH0, _VLV_PCS23_DW0_CH1)
> +
> #define _VLV_PCS_DW12_CH00x8230
> #define _VLV_PCS_DW12_CH10x8430
> #define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c59e8fc..814a950 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2139,6 +2139,29 @@ static void chv_pre_enable_dp(struct intel_encoder
> *encoder)
>
> mutex_lock(&dev_priv->dpio_lock);
>
> + /* TX FIFO reset source */
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> + val |= DPIO_LEFT_TXFIFO_RST_MASTER2;
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER2;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER;
> + val &= ~DPIO_RIGHT_TXFIFO_RST_MASTER;
> + val |= DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER2;
> + val &= ~DPIO_RIGHT_TXFIFO_RST_MASTER2;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER;
> + val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
> + val |= DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> +
> /* Deassert soft data lane reset*/
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> val |= CHV_PCS_REQ_SOFTRESET_EN;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index cda6506..47430d5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1358,6 +1358,29 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder)
>
> mutex_lock(&dev_priv->dpio_lock);
>
> + /* TX FIFO reset source */
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> + val |= DPIO_LEFT_TXFIFO_RST_MASTER2;
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER2;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER;
> + val &= ~DPIO_RIGHT_TXFIFO_RST_MASTER;
> + val |= DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER2;
> + val &= ~DPIO_RIGHT_TXFIFO_RST_MASTER2;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> +
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> + val &= ~DPIO_LEFT_TXFIFO_RST_MASTER;
> + val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
> + val |= DPIO_LANEDESKEW_STRAP_OVRD;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> +
> /* Deassert soft data lane reset*/
> val
Re: [Intel-gfx] [PATCH 12/40] drm/i915: Clarify CHV swing margin/deemph bits
On Sat, 28 Jun 2014 02:04:03 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CHV display PHY registes have two swing margin/deemph settings. Make it
> clear which ones we're using.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8 ++--
> drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/intel_hdmi.c | 4 ++--
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e296312..ba90320 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -831,8 +831,8 @@ enum punit_power_well {
>
> #define _VLV_TX_DW2_CH0 0x8288
> #define _VLV_TX_DW2_CH1 0x8488
> -#define DPIO_SWING_MARGIN_SHIFT16
> -#define DPIO_SWING_MARGIN_MASK (0xff << DPIO_SWING_MARGIN_SHIFT)
> +#define DPIO_SWING_MARGIN000_SHIFT 16
> +#define DPIO_SWING_MARGIN000_MASK (0xff << DPIO_SWING_MARGIN000_SHIFT)
> #define DPIO_UNIQ_TRANS_SCALE_SHIFT8
> #define VLV_TX_DW2(ch) _PORT(ch, _VLV_TX_DW2_CH0, _VLV_TX_DW2_CH1)
>
> @@ -840,12 +840,16 @@ enum punit_power_well {
> #define _VLV_TX_DW3_CH1 0x848c
> /* The following bit for CHV phy */
> #define DPIO_TX_UNIQ_TRANS_SCALE_EN(1<<27)
> +#define DPIO_SWING_MARGIN101_SHIFT 16
> +#define DPIO_SWING_MARGIN101_MASK (0xff << DPIO_SWING_MARGIN101_SHIFT)
> #define VLV_TX_DW3(ch) _PORT(ch, _VLV_TX_DW3_CH0, _VLV_TX_DW3_CH1)
>
> #define _VLV_TX_DW4_CH0 0x8290
> #define _VLV_TX_DW4_CH1 0x8490
> #define DPIO_SWING_DEEMPH9P5_SHIFT 24
> #define DPIO_SWING_DEEMPH9P5_MASK (0xff << DPIO_SWING_DEEMPH9P5_SHIFT)
> +#define DPIO_SWING_DEEMPH6P0_SHIFT 16
> +#define DPIO_SWING_DEEMPH6P0_MASK (0xff << DPIO_SWING_DEEMPH6P0_SHIFT)
> #define VLV_TX_DW4(ch) _PORT(ch, _VLV_TX_DW4_CH0, _VLV_TX_DW4_CH1)
>
> #define _VLV_TX3_DW4_CH0 0x690
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e272f92..4457f8f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2565,8 +2565,8 @@ static uint32_t intel_chv_signal_levels(struct intel_dp
> *intel_dp)
> /* Program swing margin */
> for (i = 0; i < 4; i++) {
> val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
> - val &= ~DPIO_SWING_MARGIN_MASK;
> - val |= margin_reg_value << DPIO_SWING_MARGIN_SHIFT;
> + val &= ~DPIO_SWING_MARGIN000_MASK;
> + val |= margin_reg_value << DPIO_SWING_MARGIN000_SHIFT;
> vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index c9d77d3..c5c88127 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1411,8 +1411,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder)
>
> for (i = 0; i < 4; i++) {
> val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
> - val &= ~DPIO_SWING_MARGIN_MASK;
> - val |= 102 << DPIO_SWING_MARGIN_SHIFT;
> + val &= ~DPIO_SWING_MARGIN000_MASK;
> + val |= 102 << DPIO_SWING_MARGIN000_SHIFT;
> vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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 11/40] drm/i915: Call intel_{dp, hdmi}_prepare for chv
On Sat, 28 Jun 2014 02:04:02 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CHV was forgotten the intel_{dp,hdmi}_prepare() were introduced (or the
> chv patches were still in flight?). Call these when enabling the ports.
>
> Things tend to work much better when we actually write something
> to the port registers :)
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b5ec489..e272f92 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2197,6 +2197,8 @@ static void chv_dp_pre_pll_enable(struct intel_encoder
> *encoder)
> enum pipe pipe = intel_crtc->pipe;
> u32 val;
>
> + intel_dp_prepare(encoder);
> +
> mutex_lock(&dev_priv->dpio_lock);
>
> /* program left/right clock distribution */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 2422413..c9d77d3 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1240,6 +1240,8 @@ static void chv_hdmi_pre_pll_enable(struct
> intel_encoder *encoder)
> enum pipe pipe = intel_crtc->pipe;
> u32 val;
>
> + intel_hdmi_prepare(encoder);
> +
> mutex_lock(&dev_priv->dpio_lock);
>
> /* program left/right clock distribution */
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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 09/40] drm/i915: Split chv_update_pll() apart
On Sat, 28 Jun 2014 02:04:00 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Split chv_update_pll() into two parts ala:
> commit bdd4b6a655749970cc632aafc5fd596c07b60b1c
> Author: Daniel Vetter
> Date: Thu Apr 24 23:55:11 2014 +0200
>
> drm/i915: Extract vlv_prepare_pll
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a430699f..3e4d570 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -100,6 +100,7 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc);
> static void haswell_set_pipeconf(struct drm_crtc *crtc);
> static void intel_set_pipe_csc(struct drm_crtc *crtc);
> static void vlv_prepare_pll(struct intel_crtc *crtc);
> +static void chv_prepare_pll(struct intel_crtc *crtc);
>
> typedef struct {
> int min, max;
> @@ -4670,8 +4671,12 @@ static void valleyview_crtc_enable(struct drm_crtc
> *crtc)
>
> is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
>
> - if (!is_dsi && !IS_CHERRYVIEW(dev))
> - vlv_prepare_pll(intel_crtc);
> + if (!is_dsi) {
> + if (IS_CHERRYVIEW(dev))
> + chv_prepare_pll(intel_crtc);
> + else
> + vlv_prepare_pll(intel_crtc);
> + }
>
> /* Set up the display plane register */
> dspcntr = DISPPLANE_GAMMA_ENABLE;
> @@ -5692,6 +5697,18 @@ static void vlv_prepare_pll(struct intel_crtc *crtc)
>
> static void chv_update_pll(struct intel_crtc *crtc)
> {
> + crtc->config.dpll_hw_state.dpll = DPLL_SSC_REF_CLOCK_CHV |
> + DPLL_REFA_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
> + DPLL_VCO_ENABLE;
> + if (crtc->pipe != PIPE_A)
> + crtc->config.dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
> +
> + crtc->config.dpll_hw_state.dpll_md =
> + (crtc->config.pixel_multiplier - 1) <<
> DPLL_MD_UDI_MULTIPLIER_SHIFT;
> +}
> +
> +static void chv_prepare_pll(struct intel_crtc *crtc)
> +{
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int pipe = crtc->pipe;
> @@ -5701,15 +5718,6 @@ static void chv_update_pll(struct intel_crtc *crtc)
> u32 bestn, bestm1, bestm2, bestp1, bestp2, bestm2_frac;
> int refclk;
>
> - crtc->config.dpll_hw_state.dpll = DPLL_SSC_REF_CLOCK_CHV |
> - DPLL_REFA_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
> - DPLL_VCO_ENABLE;
> - if (pipe != PIPE_A)
> - crtc->config.dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
> -
> - crtc->config.dpll_hw_state.dpll_md =
> - (crtc->config.pixel_multiplier - 1) <<
> DPLL_MD_UDI_MULTIPLIER_SHIFT;
> -
> bestn = crtc->config.dpll.n;
> bestm2_frac = crtc->config.dpll.m2 & 0x3f;
> bestm1 = crtc->config.dpll.m1;
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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 08/40] drm/i915: Leave DPLL ref clocks on
On Sat, 28 Jun 2014 02:03:59 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We enable the DPLL refclock already when bringing up the cmnlane power > well, so also leave it on when otherwise disabling the DPLL. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 4abf8b6f..a430699f 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1709,7 +1709,7 @@ static void chv_disable_pll(struct drm_i915_private > *dev_priv, enum pipe pipe) > assert_pipe_disabled(dev_priv, pipe); > > /* Set PLL en = 0 */ > - val = DPLL_SSC_REF_CLOCK_CHV; > + val = DPLL_SSC_REF_CLOCK_CHV | DPLL_REFA_CLK_ENABLE_VLV; > if (pipe != PIPE_A) > val |= DPLL_INTEGRATED_CRI_CLK_VLV; > I915_WRITE(DPLL(pipe), val); Reviewed-by: Jesse Barnes -- Jesse Barnes, 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 07/40] drm/i915: Disable cdclk changes for chv until Punit is ready
On Sat, 28 Jun 2014 02:03:58 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Punit seems a bit WIP still. Disable cdclk changes until we have > hardware where it works. > > 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 9af1d13..4abf8b6f 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -4576,6 +4576,10 @@ static int valleyview_calc_cdclk(struct > drm_i915_private *dev_priv, > int vco = valleyview_get_vco(dev_priv); > int freq_320 = (vco << 1) % 32 != 0 ? 33 : 32; > > + /* FIXME: Punit isn't quite ready yet */ > + if (IS_CHERRYVIEW(dev_priv->dev)) > + return 40; > + > /* >* Really only a few cases to deal with, as only 4 CDclks are supported: >* 200MHz > @@ -5297,6 +5301,10 @@ static int valleyview_get_display_clock_speed(struct > drm_device *dev) > u32 val; > int divider; > > + /* FIXME: Punit isn't quite ready yet */ > + if (IS_CHERRYVIEW(dev)) > + return 40; > + > mutex_lock(&dev_priv->dpio_lock); > val = vlv_cck_read(dev_priv, CCK_DISPLAY_CLOCK_CONTROL); > mutex_unlock(&dev_priv->dpio_lock); Reviewed-by: Jesse Barnes -- Jesse Barnes, 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/40] drm/i915: Add cdclk change support for chv
On Sat, 28 Jun 2014 02:03:57 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Looks like the Punit is supposed to support the 400MHz cdclk directly on
> chv, so we don't need the vlv tricks.
>
> FIXME: Punit doesn't seem ready for this yet on current hw
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +++
> drivers/gpu/drm/i915/intel_display.c | 50
> ++--
> 2 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f156591..e296312 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -491,6 +491,10 @@
> #define BUNIT_REG_BISOC 0x11
>
> #define PUNIT_REG_DSPFREQ0x36
> +#define DSPFREQSTAT_SHIFT_CHV 24
> +#define DSPFREQSTAT_MASK_CHV (0x1f <<
> DSPFREQSTAT_SHIFT_CHV)
> +#define DSPFREQGUAR_SHIFT_CHV 8
> +#define DSPFREQGUAR_MASK_CHV (0x1f <<
> DSPFREQGUAR_SHIFT_CHV)
> #define DSPFREQSTAT_SHIFT 30
> #define DSPFREQSTAT_MASK (0x3 << DSPFREQSTAT_SHIFT)
> #define DSPFREQGUAR_SHIFT 14
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 99c10d1..9af1d13 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
> *dev, int cdclk)
> vlv_update_cdclk(dev);
> }
>
> +static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 val, cmd;
> +
> + WARN_ON(dev_priv->display.get_display_clock_speed(dev) !=
> dev_priv->vlv_cdclk_freq);
> +
> + switch (cdclk) {
> + case 40:
> + cmd = 3;
> + break;
> + case 33:
> + case 32:
> + cmd = 2;
> + break;
> + case 27:
> + cmd = 1;
> + break;
> + case 20:
> + cmd = 0;
> + break;
> + default:
> + WARN_ON(1);
> + return;
> + }
> +
> + mutex_lock(&dev_priv->rps.hw_lock);
> + val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> + val &= ~DSPFREQGUAR_MASK_CHV;
> + val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> + vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> + DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
> + 50)) {
> + DRM_ERROR("timed out waiting for CDclk change\n");
> + }
> + mutex_unlock(&dev_priv->rps.hw_lock);
> +
> + vlv_update_cdclk(dev);
> +}
> +
> static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
>int max_pixclk)
> {
> @@ -4597,8 +4638,13 @@ static void valleyview_modeset_global_resources(struct
> drm_device *dev)
> int max_pixclk = intel_mode_max_pixclk(dev_priv);
> int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
>
> - if (req_cdclk != dev_priv->vlv_cdclk_freq)
> - valleyview_set_cdclk(dev, req_cdclk);
> + if (req_cdclk != dev_priv->vlv_cdclk_freq) {
> + if (IS_CHERRYVIEW(dev))
> + cherryview_set_cdclk(dev, req_cdclk);
> + else
> + valleyview_set_cdclk(dev, req_cdclk);
> + }
> +
> modeset_update_crtc_power_domains(dev);
> }
>
Which doc has these Punit commands? I'm assuming you have them
correct, but a ref would be good if we don't already have one.
Reviewed-by: Jesse Barnes
There should probably be a JIRA for this too so QA can verify once we
have updated punit support.
--
Jesse Barnes, 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] drm/i915: s/seqno/request/ tracking inside objects
On Tue, 29 Jul 2014 12:41:26 +0200
Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 08:29:53AM +0100, Chris Wilson wrote:
> > On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
> > > > @@ -3038,44 +3203,35 @@ out:
> > > > */
> > > > int
> > > > i915_gem_object_sync(struct drm_i915_gem_object *obj,
> > > > -struct intel_engine_cs *to)
> > > > +struct intel_engine_cs *to,
> > > > +bool readonly)
> > > > {
> > >
> > > It might be nice to have sync_read/sync_write functions instead, since
> > > looking up bool args or unnamed enums is a pain.
> >
> > Not convinced since it is used in a single location and two function
> > calls would look unelegant - but we could switch to PROT_READ |
> > PROT_WRITE throughout.
>
> Switching to PROT_READ/WRITE might be nice as a general cleanup (or some
> other named thing) since read_only/write booleans are all over the place.
> So I like this, but definitely something for a separate patch.
Agreed, that's a good idea.
--
Jesse Barnes, 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 1/2] drm/i915: factor out intel_edp_panel_vdd_sanitize
On Fri, Jun 27, 2014 at 09:35:13PM +0300, Imre Deak wrote:
> This will be needed by an upcoming patch too that needs to sanitize the
> VDD state during resume. The additional async disabling is only needed
> for the resume path, here it doesn't make a difference since we enable
> VDD right after the sanitize call.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dp.c | 59
>
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 43 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b5ec489..a40d914 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1234,6 +1234,19 @@ static void edp_panel_vdd_work(struct work_struct
> *__work)
> drm_modeset_unlock(&dev->mode_config.connection_mutex);
> }
>
> +static void edp_panel_vdd_schedule_off(struct intel_dp *intel_dp)
> +{
> + unsigned long delay;
> +
> + /*
> + * Queue the timer to fire a long time from now (relative to the power
> + * down delay) to keep the panel power up across a sequence of
> + * operations.
> + */
> + delay = msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5);
> + schedule_delayed_work(&intel_dp->panel_vdd_work, delay);
> +}
> +
> static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
> {
> if (!is_edp(intel_dp))
> @@ -1243,17 +1256,10 @@ static void edp_panel_vdd_off(struct intel_dp
> *intel_dp, bool sync)
>
> intel_dp->want_panel_vdd = false;
>
> - if (sync) {
> + if (sync)
> edp_panel_vdd_off_sync(intel_dp);
> - } else {
> - /*
> - * Queue the timer to fire a long
> - * time from now (relative to the power down delay)
> - * to keep the panel power up across a sequence of operations
> - */
> - schedule_delayed_work(&intel_dp->panel_vdd_work,
> -
> msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> - }
> + else
> + edp_panel_vdd_schedule_off(intel_dp);
> }
>
> void intel_edp_panel_on(struct intel_dp *intel_dp)
> @@ -4179,6 +4185,31 @@ intel_dp_drrs_init(struct intel_digital_port
> *intel_dig_port,
> return downclock_mode;
> }
>
> +void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
> + struct drm_device *dev = intel_encoder->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + enum intel_display_power_domain power_domain;
> +
> + if (intel_encoder->type != INTEL_OUTPUT_EDP)
> + return;
I'd move the intel_dp assignment after the encoder type check to avoid
anyone thinking that they're allowed to dereference it before we're
sure about the type.
Apart from that both patches are:
Reviewed-by: Ville Syrjälä
> +
> + if (!edp_have_panel_vdd(intel_dp))
> + return;
> + /*
> + * The VDD bit needs a power domain reference, so if the bit is
> + * already enabled when we boot or resume, grab this reference and
> + * schedule a vdd off, so we don't hold on to the reference
> + * indefinitely.
> + */
> + DRM_DEBUG_KMS("VDD left on by BIOS, adjusting state tracking\n");
> + power_domain = intel_display_port_power_domain(intel_encoder);
> + intel_display_power_get(dev_priv, power_domain);
> +
> + edp_panel_vdd_schedule_off(intel_dp);
> +}
> +
> static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>struct intel_connector *intel_connector,
>struct edp_power_seq *power_seq)
> @@ -4199,13 +4230,7 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> if (!is_edp(intel_dp))
> return true;
>
> - /* The VDD bit needs a power domain reference, so if the bit is already
> - * enabled when we boot, grab this reference. */
> - if (edp_have_panel_vdd(intel_dp)) {
> - enum intel_display_power_domain power_domain;
> - power_domain = intel_display_port_power_domain(intel_encoder);
> - intel_display_power_get(dev_priv, power_domain);
> - }
> + intel_edp_panel_vdd_sanitize(intel_encoder);
>
> /* Cache DPCD and EDID for edp. */
> intel_edp_panel_vdd_on(intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5f7c7bd..150c09b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -855,6 +855,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port
> port);
> void intel_edp_backlight_on(struct intel_dp *intel_dp);
> void intel_edp_backlight_off(struct intel_dp *intel_dp);
> void intel_edp_panel_vdd_on(struct intel_dp *intel_dp);
> +void intel_edp_panel_vd
Re: [Intel-gfx] [PATCH 1/3] drm/i915: fix cursor handling when runtime suspended
2014-07-29 7:22 GMT-03:00 Ville Syrjälä :
> On Mon, Jul 28, 2014 at 03:37:12PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If we're runtime suspended and try to use the cursor interfaces, we
>> will get a lot of WARNs saying we did the wrong thing.
>>
>> For intel_crtc_update_cursor(), all we need to do is return if the
>> CRTC is not active, since writing the registers won't really have any
>> effect if the screen is not visible, and we will write the registers
>> later when enabling the screen.
>>
>> For intel_crtc_cursor_set_obj(), we just need to wake up the hardware
>> then pinning the display plane.
>>
>> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
>>
>> Testcase: igt/pm_rpm/cursor
>> Testcase: igt/pm_rpm/cursor-dpms
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1edfd1a..f1a9b5c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -8144,6 +8144,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
>> *crtc,
>> if (base == 0 && intel_crtc->cursor_base == 0)
>> return;
>>
>> + if (!intel_crtc->active)
>> + return;
>> +
>> I915_WRITE(CURPOS(pipe), pos);
>>
>> if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
>> @@ -8217,7 +8220,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
>> *crtc,
>> if (need_vtd_wa(dev))
>> alignment = 64*1024;
>>
>> + intel_runtime_pm_get(dev_priv);
>> ret = i915_gem_object_pin_to_display_plane(obj, alignment,
>> NULL);
>> + intel_runtime_pm_put(dev_priv);
>
> put_fence() would need runtime pm too I think.
This is exactly why I wanted the get/put calls around everything on
those functions... I'll see if I can reproduce this on the test suite
too.
>
>> if (ret) {
>> DRM_DEBUG_KMS("failed to move cursor bo into the
>> GTT\n");
>> goto fail_locked;
>> --
>> 2.0.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Barbalho, Rafael
> Sent: Tuesday, July 29, 2014 2:38 PM
> To: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for
> pipe B on vlv/chv
> Importance: High
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, July 29, 2014 2:13 PM
> > To: Barbalho, Rafael
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH] drm/i915: Correctly read backlight PWM for pipe B on
> > vlv/chv
> >
> > On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com
> wrote:
> > > From: Rafael Barbalho
> > >
> > > Make the vlv/chv backlight setup more generic by actually looking at
> which
> > > pipe the panel is attached to and read the backlight PWM registers that
> > were
> > > setup by the bios from that pipe.
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Rafael Barbalho
> > > ---
> > > drivers/gpu/drm/i915/intel_panel.c | 24 ++--
> > > 1 file changed, 10 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > b/drivers/gpu/drm/i915/intel_panel.c
> > > index 59b028f..be75d76 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct
> > intel_connector *connector)
> > > struct drm_device *dev = connector->base.dev;
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > struct intel_panel *panel = &connector->panel;
> > > - enum pipe pipe;
> > > + enum pipe pipe = intel_get_pipe_from_connector(connector);
> >
> > This won't work unless the connector is already enabled.
> >
> > The power sequencer has a similar problem where we have to somehow
> > deduce
> > the correct pipe. vlv_power_sequencer_pipe() tries to guess the correct
> > pipe
> > there.
> >
> > We could start with intel_get_pipe_from_connector() and if that fails we'd
> > do something like vlv_power_sequencer_pipe(). Hmm, except the
> backlight
> > registers don't have the port information, so I guess we'd need to pick the
> > pipe simply based on the DP port control register.
> >
>
> Fair point, I didn't realise that intel_get_pipe_from_connector could return
> INVALID_PIPE.
>
> How about if I add:
> + enum pipe pipe = intel_get_pipe_from_connector(connector);
> +
> + if (pipe == INVALID_PIPE)
> + pipe = PIPE_A;
>
> It would return the driver to the current behaviour but still enable pipe B
> when that is present
> at start up.
>
Thinking about it I need to still keep the initial for_each_pipe loop to very
subtly
initialise both pipe A & B to a known PWM modulation frequency, which would
explain
why setting the backlight brightness works on pipe B. However, inheriting it
from the
bios is not working, which is what I am seeing. Let me rejig the patch and I'll
send out
a new version.
> > > u32 ctl, ctl2, val;
> > >
> > > - for_each_pipe(pipe) {
> > > - u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
> > > + ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
> > > + panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> > >
> > > - /* Skip if the modulation freq is already set */
> > > - if (cur_val & ~BACKLIGHT_DUTY_CYCLE_MASK)
> > > - continue;
> > > + ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
> > >
> > > - cur_val &= BACKLIGHT_DUTY_CYCLE_MASK;
> > > - I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 << 16) |
> > > -cur_val);
> > > + /* Skip if the modulation freq is already set */
> > > + if ((ctl & ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
> > > + ctl &= BACKLIGHT_DUTY_CYCLE_MASK;
> > > + ctl |= (0xf42 << 16);
> > > + I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
> > > }
> > >
> > > - ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
> > > - panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> > > -
> > > - ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
> > > panel->backlight.max = ctl >> 16;
> > > if (!panel->backlight.max)
> > > return -ENODEV;
> > >
> > > panel->backlight.min = get_backlight_min_vbt(connector);
> > >
> > > - val = _vlv_get_backlight(dev, PIPE_A);
> > > + val = _vlv_get_backlight(dev, pipe);
> > > panel->backlight.level =
> > intel_panel_compute_brightness(connector, val);
> > >
> > > panel->backlight.enabled = (ctl2 & BLM_PWM_ENABLE) &&
> > > --
> > > 2.0.3
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, July 29, 2014 2:13 PM
> To: Barbalho, Rafael
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915: Correctly read backlight PWM for pipe B on
> vlv/chv
>
> On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com wrote:
> > From: Rafael Barbalho
> >
> > Make the vlv/chv backlight setup more generic by actually looking at which
> > pipe the panel is attached to and read the backlight PWM registers that
> were
> > setup by the bios from that pipe.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Rafael Barbalho
> > ---
> > drivers/gpu/drm/i915/intel_panel.c | 24 ++--
> > 1 file changed, 10 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> > index 59b028f..be75d76 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct
> intel_connector *connector)
> > struct drm_device *dev = connector->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_panel *panel = &connector->panel;
> > - enum pipe pipe;
> > + enum pipe pipe = intel_get_pipe_from_connector(connector);
>
> This won't work unless the connector is already enabled.
>
> The power sequencer has a similar problem where we have to somehow
> deduce
> the correct pipe. vlv_power_sequencer_pipe() tries to guess the correct
> pipe
> there.
>
> We could start with intel_get_pipe_from_connector() and if that fails we'd
> do something like vlv_power_sequencer_pipe(). Hmm, except the backlight
> registers don't have the port information, so I guess we'd need to pick the
> pipe simply based on the DP port control register.
>
Fair point, I didn't realise that intel_get_pipe_from_connector could return
INVALID_PIPE.
How about if I add:
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
+
+ if (pipe == INVALID_PIPE)
+ pipe = PIPE_A;
It would return the driver to the current behaviour but still enable pipe B
when that is present
at start up.
> > u32 ctl, ctl2, val;
> >
> > - for_each_pipe(pipe) {
> > - u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
> > + ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
> > + panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> >
> > - /* Skip if the modulation freq is already set */
> > - if (cur_val & ~BACKLIGHT_DUTY_CYCLE_MASK)
> > - continue;
> > + ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
> >
> > - cur_val &= BACKLIGHT_DUTY_CYCLE_MASK;
> > - I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 << 16) |
> > - cur_val);
> > + /* Skip if the modulation freq is already set */
> > + if ((ctl & ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
> > + ctl &= BACKLIGHT_DUTY_CYCLE_MASK;
> > + ctl |= (0xf42 << 16);
> > + I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
> > }
> >
> > - ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
> > - panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> > -
> > - ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
> > panel->backlight.max = ctl >> 16;
> > if (!panel->backlight.max)
> > return -ENODEV;
> >
> > panel->backlight.min = get_backlight_min_vbt(connector);
> >
> > - val = _vlv_get_backlight(dev, PIPE_A);
> > + val = _vlv_get_backlight(dev, pipe);
> > panel->backlight.level =
> intel_panel_compute_brightness(connector, val);
> >
> > panel->backlight.enabled = (ctl2 & BLM_PWM_ENABLE) &&
> > --
> > 2.0.3
>
> --
> 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: Correctly read backlight PWM for pipe B on vlv/chv
On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> Make the vlv/chv backlight setup more generic by actually looking at which
> pipe the panel is attached to and read the backlight PWM registers that were
> setup by the bios from that pipe.
>
> Cc: Ville Syrjälä
> Signed-off-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/intel_panel.c | 24 ++--
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 59b028f..be75d76 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct intel_connector
> *connector)
> struct drm_device *dev = connector->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_panel *panel = &connector->panel;
> - enum pipe pipe;
> + enum pipe pipe = intel_get_pipe_from_connector(connector);
This won't work unless the connector is already enabled.
The power sequencer has a similar problem where we have to somehow deduce
the correct pipe. vlv_power_sequencer_pipe() tries to guess the correct pipe
there.
We could start with intel_get_pipe_from_connector() and if that fails we'd
do something like vlv_power_sequencer_pipe(). Hmm, except the backlight
registers don't have the port information, so I guess we'd need to pick the
pipe simply based on the DP port control register.
> u32 ctl, ctl2, val;
>
> - for_each_pipe(pipe) {
> - u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
> + ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
> + panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
>
> - /* Skip if the modulation freq is already set */
> - if (cur_val & ~BACKLIGHT_DUTY_CYCLE_MASK)
> - continue;
> + ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
>
> - cur_val &= BACKLIGHT_DUTY_CYCLE_MASK;
> - I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 << 16) |
> -cur_val);
> + /* Skip if the modulation freq is already set */
> + if ((ctl & ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
> + ctl &= BACKLIGHT_DUTY_CYCLE_MASK;
> + ctl |= (0xf42 << 16);
> + I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
> }
>
> - ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
> - panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> -
> - ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
> panel->backlight.max = ctl >> 16;
> if (!panel->backlight.max)
> return -ENODEV;
>
> panel->backlight.min = get_backlight_min_vbt(connector);
>
> - val = _vlv_get_backlight(dev, PIPE_A);
> + val = _vlv_get_backlight(dev, pipe);
> panel->backlight.level = intel_panel_compute_brightness(connector, val);
>
> panel->backlight.enabled = (ctl2 & BLM_PWM_ENABLE) &&
> --
> 2.0.3
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
From: Rafael Barbalho
Make the vlv/chv backlight setup more generic by actually looking at which
pipe the panel is attached to and read the backlight PWM registers that were
setup by the bios from that pipe.
Cc: Ville Syrjälä
Signed-off-by: Rafael Barbalho
---
drivers/gpu/drm/i915/intel_panel.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..be75d76 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct intel_connector
*connector)
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_panel *panel = &connector->panel;
- enum pipe pipe;
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 ctl, ctl2, val;
- for_each_pipe(pipe) {
- u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+ ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
+ panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
- /* Skip if the modulation freq is already set */
- if (cur_val & ~BACKLIGHT_DUTY_CYCLE_MASK)
- continue;
+ ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
- cur_val &= BACKLIGHT_DUTY_CYCLE_MASK;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 << 16) |
- cur_val);
+ /* Skip if the modulation freq is already set */
+ if ((ctl & ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
+ ctl &= BACKLIGHT_DUTY_CYCLE_MASK;
+ ctl |= (0xf42 << 16);
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
}
- ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
- panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
-
- ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
panel->backlight.max = ctl >> 16;
if (!panel->backlight.max)
return -ENODEV;
panel->backlight.min = get_backlight_min_vbt(connector);
- val = _vlv_get_backlight(dev, PIPE_A);
+ val = _vlv_get_backlight(dev, pipe);
panel->backlight.level = intel_panel_compute_brightness(connector, val);
panel->backlight.enabled = (ctl2 & BLM_PWM_ENABLE) &&
--
2.0.3
___
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: wait for all DSI FIFOs to be empty
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> Ensure that the DSI packets for a particular sequence are completely
> sent before going ahead in the enabling or disabling of the panel
>
> Signed-off-by: Shobhit Kumar
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 8
> drivers/gpu/drm/i915/intel_dsi_cmd.c | 16
> drivers/gpu/drm/i915/intel_dsi_cmd.h | 1 +
> 3 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 61da0e5..98c78ab 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -152,6 +152,8 @@ static void intel_dsi_enable(struct intel_encoder
> *encoder)
> if (intel_dsi->dev.dev_ops->enable)
> intel_dsi->dev.dev_ops->enable(&intel_dsi->dev);
>
> + wait_for_dsi_fifo_empty(intel_dsi);
> +
> /* assert ip_tg_enable signal */
> temp = I915_READ(MIPI_PORT_CTRL(pipe)) &
> ~LANE_CONFIGURATION_MASK;
> temp = temp | intel_dsi->port_bits;
> @@ -192,6 +194,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
> *encoder)
> if (intel_dsi->dev.dev_ops->send_otp_cmds)
> intel_dsi->dev.dev_ops->send_otp_cmds(&intel_dsi->dev);
>
> + wait_for_dsi_fifo_empty(intel_dsi);
> +
> /* Enable port in pre-enable phase itself because as per hw team
>* recommendation, port should be enabled befor plane & pipe */
> intel_dsi_enable(encoder);
> @@ -232,6 +236,8 @@ static void intel_dsi_disable(struct intel_encoder
> *encoder)
> DRM_DEBUG_KMS("\n");
>
> if (is_vid_mode(intel_dsi)) {
> + wait_for_dsi_fifo_empty(intel_dsi);
> +
> /* de-assert ip_tg_enable signal */
> temp = I915_READ(MIPI_PORT_CTRL(pipe));
> I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
> @@ -261,6 +267,8 @@ static void intel_dsi_disable(struct intel_encoder
> *encoder)
>* some next enable sequence send turn on packet error is observed */
> if (intel_dsi->dev.dev_ops->disable)
> intel_dsi->dev.dev_ops->disable(&intel_dsi->dev);
> +
> + wait_for_dsi_fifo_empty(intel_dsi);
> }
>
> static void intel_dsi_clear_device_ready(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> index 933c863..7f1430a 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> @@ -419,3 +419,19 @@ int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd,
> bool hs)
>
> return 0;
> }
> +
> +void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi)
> +{
> + struct drm_encoder *encoder = &intel_dsi->base.base;
> + struct drm_device *dev = encoder->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> + enum pipe pipe = intel_crtc->pipe;
> + u32 mask;
> +
> + mask = LP_CTRL_FIFO_EMPTY | HS_CTRL_FIFO_EMPTY |
> + LP_DATA_FIFO_EMPTY | HS_DATA_FIFO_EMPTY;
> +
> + if (wait_for((I915_READ(MIPI_GEN_FIFO_STAT(pipe)) & mask) == mask, 100))
> + DRM_ERROR("DPI FIFOs are not empty\n");
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.h
> b/drivers/gpu/drm/i915/intel_dsi_cmd.h
> index 9a18cbf..46aa1ac 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.h
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.h
> @@ -51,6 +51,7 @@ int dsi_vc_generic_read(struct intel_dsi *intel_dsi, int
> channel,
> u8 *reqdata, int reqlen, u8 *buf, int buflen);
>
> int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd, bool hs);
> +void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi);
>
> /* XXX: questionable write helpers */
> static inline int dsi_vc_dcs_write_0(struct intel_dsi *intel_dsi,
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2] drm/i915: Add correct hw/sw config check for DSI encoder
On Tue, 2014-07-15 at 18:15 +0530, Shobhit Kumar wrote:
> Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
> It will not be enabled for DSI and avoid dpio read WARN dumps.
>
> Absence of ->get_config was causing other WARN dumps as well. Update
> dpll_hw_state as well correctly
>
> v2: Address review comments by Daniel
> - Check if DPLL is enabled rather than checking pipe output type
> - set adjusted_mode->flags to 0 in compute_config rather than using
> pipe_config->quirks
> - Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
> - updated dpll_hw_state correctly
> - Updated commit message and title
>
> Signed-off-by: Shobhit Kumar
Ok, reviewing now the latest version after Daniel pointed me to it.
> ---
> drivers/gpu/drm/i915/intel_display.c | 4
> drivers/gpu/drm/i915/intel_dsi.c | 21 +++-
> drivers/gpu/drm/i915/intel_dsi.h | 1 +
> drivers/gpu/drm/i915/intel_dsi_pll.c | 46
>
> 4 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c89b4ac..d9c34e4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6132,6 +6132,10 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
> u32 mdiv;
> int refclk = 10;
>
> + /* In case of MIPI DPLL will not even be used */
> + if (!(pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE))
> + return;
> +
> mutex_lock(&dev_priv->dpio_lock);
> mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
> mutex_unlock(&dev_priv->dpio_lock);
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index bfcefbf..43be71bf 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -92,6 +92,9 @@ static bool intel_dsi_compute_config(struct intel_encoder
> *encoder,
> if (fixed_mode)
> intel_fixed_panel_mode(fixed_mode, adjusted_mode);
>
> + /* DSI uses short packets for sync events, so clear mode flags for DSI
> */
> + adjusted_mode->flags = 0;
> +
> if (intel_dsi->dev.dev_ops->mode_fixup)
> return intel_dsi->dev.dev_ops->mode_fixup(&intel_dsi->dev,
> mode, adjusted_mode);
> @@ -177,6 +180,10 @@ static void intel_dsi_pre_enable(struct intel_encoder
> *encoder)
> tmp |= DPLL_REFA_CLK_ENABLE_VLV;
> I915_WRITE(DPLL(pipe), tmp);
>
> + /* update the hw state for DPLL */
> + intel_crtc->config.dpll_hw_state.dpll = DPLL_INTEGRATED_CLOCK_VLV |
> + DPLL_REFA_CLK_ENABLE_VLV;
> +
> tmp = I915_READ(DSPCLK_GATE_D);
> tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
> I915_WRITE(DSPCLK_GATE_D, tmp);
> @@ -351,9 +358,21 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> static void intel_dsi_get_config(struct intel_encoder *encoder,
>struct intel_crtc_config *pipe_config)
> {
> + u32 pclk;
> DRM_DEBUG_KMS("\n");
>
> - /* XXX: read flags, set to adjusted_mode */
> + /*
> + * DPLL_MD is not used in case of DSI, reading will get some default
> value
> + * set dpll_md = 0
> + */
> + pipe_config->dpll_hw_state.dpll_md = 0;
> +
> + pclk = vlv_get_dsi_pclk(encoder, pipe_config->pipe_bpp);
> + if (!pclk)
> + return;
> +
> + pipe_config->adjusted_mode.crtc_clock = pclk;
> + pipe_config->port_clock = pclk;
> }
>
> static enum drm_mode_status
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 31db33d..fd51867 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -132,6 +132,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
> drm_encoder *encoder)
>
> extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
> extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
> +extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
>
> extern struct intel_dsi_dev_ops vbt_generic_dsi_display_ops;
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index ba79ec1..8085afe 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -50,6 +50,8 @@ static const u32 lfsr_converts[] = {
> 71, 35 /* 91 - 92 */
> };
>
> +static const int num_lfsr_converts = sizeof(lfsr_converts) /
> sizeof(lfsr_converts[0]);
> +
This could be just inlined using ARRAY_SIZE.
> #ifdef DSI_CLK_FROM_RR
>
> static u32 dsi_rr_formula(const struct drm_display_mode *mode,
> @@ -298,3 +300,47 @@ void vlv_disable_dsi_pll(struct intel_encoder *encoder)
>
> mute
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add get_config implementation for DSI encoder
On Tue, Jul 29, 2014 at 02:38:36PM +0300, Imre Deak wrote:
> On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> > Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
> > read WARN dumps as well. Absence of ->get_config was casuing othet WARN
> > dumps as well. With this the last of the known WARN dumps for DSI should
> > be fixed.
> >
> > Signed-off-by: Shobhit Kumar
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 7 +++---
> > drivers/gpu/drm/i915/intel_dsi.c | 45
> >
> > drivers/gpu/drm/i915/intel_dsi.h | 3 +++
> > drivers/gpu/drm/i915/intel_dsi_pll.c | 4 +++-
> > 4 files changed, 55 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fe6f1db..3d0ea7c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6309,9 +6309,10 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> > *crtc,
> >
> > if (IS_CHERRYVIEW(dev))
> > chv_crtc_clock_get(crtc, pipe_config);
> > - else if (IS_VALLEYVIEW(dev))
> > - vlv_crtc_clock_get(crtc, pipe_config);
> > - else
> > + else if (IS_VALLEYVIEW(dev)) {
> > + if (!intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_DSI))
> > + vlv_crtc_clock_get(crtc, pipe_config);
> > + } else
> > i9xx_crtc_clock_get(crtc, pipe_config);
> >
> > return true;
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index bfcefbf..61da0e5 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -351,9 +351,54 @@ static bool intel_dsi_get_hw_state(struct
> > intel_encoder *encoder,
> > static void intel_dsi_get_config(struct intel_encoder *encoder,
> > struct intel_crtc_config *pipe_config)
> > {
> > + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> > + u32 dsi_clock, pclk;
> > + u32 pll_ctl, pll_div;
> > + u32 m = 0, p = 0;
> > + int refclk = 25000;
> > + int i;
> > +
> > DRM_DEBUG_KMS("\n");
> >
> > /* XXX: read flags, set to adjusted_mode */
>
> This comment can be removed.
There's a v2 with a lot of this addressed already.
-Daniel
>
> > + pipe_config->quirks = 1;
>
> The proper macro should be used.
>
> > +
> > + memset(&pipe_config->dpll_hw_state, 0,
> > + sizeof(pipe_config->dpll_hw_state));
> > +
> > + mutex_lock(&dev_priv->dpio_lock);
> > + pll_ctl = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_CONTROL);
> > + pll_div = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_DIVIDER);
> > + mutex_unlock(&dev_priv->dpio_lock);
> > +
> > + pll_ctl &= ~(DSI_PLL_CLK_GATE_DSI0_DSIPLL | DSI_PLL_VCO_EN);
> > + pll_ctl = pll_ctl >> (DSI_PLL_P1_POST_DIV_SHIFT - 2);
>
> I'd prefer a proper masking of the P1 field instead of depending on
> other register fields being 0. The same goes for pll_div[M1].
>
> > +
> > + while (pll_ctl) {
> > + pll_ctl = pll_ctl >> 1;
> > + p++;
> > + }
> > + p--;
> > +
> > + for (i = 0; i < num_lfsr_converts; i++) {
> > + if (lfsr_converts[i] == pll_div)
> > + break;
> > + }
> > +
> > + if (i == num_lfsr_converts) {
> > + DRM_ERROR("wrong m_seed programmed\n");
> > + return;
> > + }
> > +
> > + m = i + 62;
> > +
> > + dsi_clock = (m * refclk) / p;
>
> Should guard against div-by-zero.
>
> > + pclk = DIV_ROUND_CLOSEST(dsi_clock * intel_dsi->lane_count,
> > +pipe_config->pipe_bpp);
>
> dsi_clk_from_pclk() uses dsi->pixel_format in place of pipe_bpp, so an
> assert here that the two values agree would be nice.
>
> > +
> > + pipe_config->adjusted_mode.crtc_clock = pclk;
> > + pipe_config->port_clock = pclk;
> > }
> >
> > static enum drm_mode_status
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> > b/drivers/gpu/drm/i915/intel_dsi.h
> > index 31db33d..e0c16b0 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.h
> > +++ b/drivers/gpu/drm/i915/intel_dsi.h
> > @@ -130,6 +130,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
> > drm_encoder *encoder)
> > return container_of(encoder, struct intel_dsi, base.base);
> > }
> >
> > +extern const u32 lfsr_converts[];
> > +extern const int num_lfsr_converts;
> > +
> > extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
> > extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> > b/drivers/gpu/drm/i915/intel_dsi_pll.c
> > index ba79ec1..78449ea 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> > @@ -43,13 +43,15 @@ struct dsi_mnp {
> > u32 dsi_pll_div;
> > };
> >
> > -static const u32 lfsr_converts[
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add get_config implementation for DSI encoder
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
> read WARN dumps as well. Absence of ->get_config was casuing othet WARN
> dumps as well. With this the last of the known WARN dumps for DSI should
> be fixed.
>
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 +++---
> drivers/gpu/drm/i915/intel_dsi.c | 45
>
> drivers/gpu/drm/i915/intel_dsi.h | 3 +++
> drivers/gpu/drm/i915/intel_dsi_pll.c | 4 +++-
> 4 files changed, 55 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fe6f1db..3d0ea7c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6309,9 +6309,10 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
>
> if (IS_CHERRYVIEW(dev))
> chv_crtc_clock_get(crtc, pipe_config);
> - else if (IS_VALLEYVIEW(dev))
> - vlv_crtc_clock_get(crtc, pipe_config);
> - else
> + else if (IS_VALLEYVIEW(dev)) {
> + if (!intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_DSI))
> + vlv_crtc_clock_get(crtc, pipe_config);
> + } else
> i9xx_crtc_clock_get(crtc, pipe_config);
>
> return true;
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index bfcefbf..61da0e5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -351,9 +351,54 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> static void intel_dsi_get_config(struct intel_encoder *encoder,
>struct intel_crtc_config *pipe_config)
> {
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> + u32 dsi_clock, pclk;
> + u32 pll_ctl, pll_div;
> + u32 m = 0, p = 0;
> + int refclk = 25000;
> + int i;
> +
> DRM_DEBUG_KMS("\n");
>
> /* XXX: read flags, set to adjusted_mode */
This comment can be removed.
> + pipe_config->quirks = 1;
The proper macro should be used.
> +
> + memset(&pipe_config->dpll_hw_state, 0,
> + sizeof(pipe_config->dpll_hw_state));
> +
> + mutex_lock(&dev_priv->dpio_lock);
> + pll_ctl = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_CONTROL);
> + pll_div = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_DIVIDER);
> + mutex_unlock(&dev_priv->dpio_lock);
> +
> + pll_ctl &= ~(DSI_PLL_CLK_GATE_DSI0_DSIPLL | DSI_PLL_VCO_EN);
> + pll_ctl = pll_ctl >> (DSI_PLL_P1_POST_DIV_SHIFT - 2);
I'd prefer a proper masking of the P1 field instead of depending on
other register fields being 0. The same goes for pll_div[M1].
> +
> + while (pll_ctl) {
> + pll_ctl = pll_ctl >> 1;
> + p++;
> + }
> + p--;
> +
> + for (i = 0; i < num_lfsr_converts; i++) {
> + if (lfsr_converts[i] == pll_div)
> + break;
> + }
> +
> + if (i == num_lfsr_converts) {
> + DRM_ERROR("wrong m_seed programmed\n");
> + return;
> + }
> +
> + m = i + 62;
> +
> + dsi_clock = (m * refclk) / p;
Should guard against div-by-zero.
> + pclk = DIV_ROUND_CLOSEST(dsi_clock * intel_dsi->lane_count,
> + pipe_config->pipe_bpp);
dsi_clk_from_pclk() uses dsi->pixel_format in place of pipe_bpp, so an
assert here that the two values agree would be nice.
> +
> + pipe_config->adjusted_mode.crtc_clock = pclk;
> + pipe_config->port_clock = pclk;
> }
>
> static enum drm_mode_status
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 31db33d..e0c16b0 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -130,6 +130,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
> drm_encoder *encoder)
> return container_of(encoder, struct intel_dsi, base.base);
> }
>
> +extern const u32 lfsr_converts[];
> +extern const int num_lfsr_converts;
> +
> extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
> extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index ba79ec1..78449ea 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -43,13 +43,15 @@ struct dsi_mnp {
> u32 dsi_pll_div;
> };
>
> -static const u32 lfsr_converts[] = {
> +const u32 lfsr_converts[] = {
> 426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
> 461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
> 106, 53, 282, 397, 354, 227, 113, 56, 284, 142, /* 81 - 90 */
> 71, 35
Re: [Intel-gfx] [PATCH i-g-t] lib: don't abort if forcing the connector state fails
On Mon, Jul 28, 2014 at 05:34:55PM +0200, Daniel Vetter wrote:
> On Mon, Jul 28, 2014 at 04:24:49PM +0100, Thomas Wood wrote:
> > Ensure tests using igt_enable_connectors can still run even if the
> > relevant debugfs files are not available.
> >
> > Signed-off-by: Thomas Wood
> > ---
> > lib/igt_kms.c | 19 ++-
> > lib/igt_kms.h | 2 +-
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > index 20370a9..740b5dd 100644
> > --- a/lib/igt_kms.c
> > +++ b/lib/igt_kms.c
> > @@ -429,9 +429,11 @@ static char* get_debugfs_connector_path(int drm_fd,
> > drmModeConnector *connector,
> > * @state: state to force on @connector
> > *
> > * Force the specified state on the specified connector.
> > + *
> > + * Returns: true on success
> > */
> > -void kmstest_force_connector(int drm_fd, drmModeConnector *connector, enum
> > -kmstest_force_connector_state state)
> > +bool kmstest_force_connector(int drm_fd, drmModeConnector *connector,
> > +enum kmstest_force_connector_state state)
> > {
> > char *path;
> > const char *value;
> > @@ -458,12 +460,15 @@ void kmstest_force_connector(int drm_fd,
> > drmModeConnector *connector, enum
> > debugfs_fd = open(path, O_WRONLY | O_TRUNC);
> > free(path);
> >
> > - igt_assert(debugfs_fd != -1);
> > + if (debugfs_fd == -1) {
> > + return false;
> > + }
>
> Aside: We have some neat debugfs helpers in igt_debugfs.c. Might convert
> over to them while at it.
Aside: they are not that neat... :p I felt restricted that I couldn't open
the right debugfs for an fd I had - the assumption of the singleton is
too prescriptive.
-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/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 01:06:40PM +0200, Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> > VMAs should take a reference of the address space they use.
> >
> > Now, when the fd is closed, it will release the ref that the context was
> > holding, but it will still be referenced by any vmas that are still
> > active.
> >
> > ppgtt_release() should then only be called when the last thing referencing
> > it releases the ref, and it can just call the base cleanup and free the
> > ppgtt.
> >
> > Signed-off-by: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/i915_gem.c | 8
> > drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
> > 4 files changed, 18 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 2acc03f..a879a93 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
> > drm_i915_gem_object *obj);
> >
> > /* i915_gem_context.c */
> > #define ctx_to_ppgtt(ctx) container_of((ctx)->vm, struct i915_hw_ppgtt,
> > base)
> > +#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
> > int __must_check i915_gem_context_init(struct drm_device *dev);
> > +void ppgtt_release(struct kref *kref);
> > void i915_gem_context_fini(struct drm_device *dev);
> > void i915_gem_context_reset(struct drm_device *dev);
> > int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index dcd8d7b..25a32b9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
> > drm_i915_gem_object *obj,
> >
> > void i915_gem_vma_destroy(struct i915_vma *vma)
> > {
> > + struct i915_address_space *vm = NULL;
> > + struct i915_hw_ppgtt *ppgtt = NULL;
> > WARN_ON(vma->node.allocated);
> >
> > /* Keep the vma as a placeholder in the execbuffer reservation lists */
> > if (!list_empty(&vma->exec_list))
> > return;
> >
> > + vm = vma->vm;
> > + ppgtt = vm_to_ppgtt(vm);
> > +
> > + if (ppgtt)
> > + kref_put(&ppgtt->ref, ppgtt_release);
>
> Hm, this has the risk that we leave unwanted vmas around for a bit longer.
> They will get cleaned up though when the final object references goes
> away, so the leak is fairly restricted. And currently we don't have a
> shrinker to just whack out vma objects even ...
>
> It's definitely a much neater solution than what I had in mind with moving
> vmas to full-blown active tracking like we do objects. So I'm tempted to
> go with, but have a bit a lurking feeling that I'm missing something.
>
> Chris?
I don't think that only taking the reference for whilst the vma is
active would add much extra code or complexity and being consistent
with the existing active tracking has the advantages you mention.
If we could clean up the vma handling in move_to_inactive that would
remove a major wart all by itself.
-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 i-g-t 1/5] lib: Remove unused field from struct igt_fb
Pushed those, before I forget.
--
Damien
On Fri, Jul 11, 2014 at 03:09:01PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> lib/igt_fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index 6d030e6..f5110d4 100644
> --- a/lib/igt_fb.h
> +++ b/lib/igt_fb.h
> @@ -48,7 +48,6 @@ struct igt_fb {
> uint32_t drm_format;
> int width;
> int height;
> - int depth;
> unsigned stride;
> unsigned tiling;
> unsigned size;
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
> VMAs should take a reference of the address space they use.
>
> Now, when the fd is closed, it will release the ref that the context was
> holding, but it will still be referenced by any vmas that are still
> active.
>
> ppgtt_release() should then only be called when the last thing referencing
> it releases the ref, and it can just call the base cleanup and free the
> ppgtt.
>
> Signed-off-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gem.c | 8
> drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
> drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
> 4 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2acc03f..a879a93 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
> drm_i915_gem_object *obj);
>
> /* i915_gem_context.c */
> #define ctx_to_ppgtt(ctx) container_of((ctx)->vm, struct i915_hw_ppgtt, base)
> +#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
> int __must_check i915_gem_context_init(struct drm_device *dev);
> +void ppgtt_release(struct kref *kref);
> void i915_gem_context_fini(struct drm_device *dev);
> void i915_gem_context_reset(struct drm_device *dev);
> int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dcd8d7b..25a32b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
> drm_i915_gem_object *obj,
>
> void i915_gem_vma_destroy(struct i915_vma *vma)
> {
> + struct i915_address_space *vm = NULL;
> + struct i915_hw_ppgtt *ppgtt = NULL;
> WARN_ON(vma->node.allocated);
>
> /* Keep the vma as a placeholder in the execbuffer reservation lists */
> if (!list_empty(&vma->exec_list))
> return;
>
> + vm = vma->vm;
> + ppgtt = vm_to_ppgtt(vm);
> +
> + if (ppgtt)
> + kref_put(&ppgtt->ref, ppgtt_release);
Hm, this has the risk that we leave unwanted vmas around for a bit longer.
They will get cleaned up though when the final object references goes
away, so the leak is fairly restricted. And currently we don't have a
shrinker to just whack out vma objects even ...
It's definitely a much neater solution than what I had in mind with moving
vmas to full-blown active tracking like we do objects. So I'm tempted to
go with, but have a bit a lurking feeling that I'm missing something.
Chris?
Cheers, Daniel
> +
> list_del(&vma->vma_link);
>
> kfree(vma);
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5b5af6c..59272f9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
> *ppgtt)
> return;
> }
>
> - /*
> - * Make sure vmas are unbound before we take down the drm_mm
> - *
> - * FIXME: Proper refcounting should take care of this, this shouldn't be
> - * needed at all.
> - */
> - if (!list_empty(&vm->active_list)) {
> - struct i915_vma *vma;
> -
> - list_for_each_entry(vma, &vm->active_list, mm_list)
> - if (WARN_ON(list_empty(&vma->vma_link) ||
> - list_is_singular(&vma->vma_link)))
> - break;
> -
> - i915_gem_evict_vm(&ppgtt->base, true);
> - } else {
> - i915_gem_retire_requests(dev);
> - i915_gem_evict_vm(&ppgtt->base, false);
> - }
> + /* vmas should already be unbound */
> + WARN_ON(!list_empty(&vm->active_list));
>
> ppgtt->base.cleanup(&ppgtt->base);
> }
>
> -static void ppgtt_release(struct kref *kref)
> +void ppgtt_release(struct kref *kref)
> {
> struct i915_hw_ppgtt *ppgtt =
> container_of(kref, struct i915_hw_ppgtt, ref);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 1411613..90c3d0f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
> drm_i915_gem_object *obj,
> struct i915_address_space *vm)
> {
> struct i915_vma *vma;
> + struct i915_hw_ppgtt *ppgtt = NULL;
>
> vma = i915_gem_obj_to_vma(obj, vm);
> if (!vma)
> vma = __i915_gem_vma_create(obj, vm);
>
> + ppgtt = vm_to_ppgtt(vm);
> + if (ppgtt)
> + kref_get(&ppgtt->ref);
> +
> return vma;
Re: [Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On Tue, Jul 29, 2014 at 12:50 PM, Dave Airlie wrote: > On 29 July 2014 20:46, Daniel Vetter wrote: >> On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote: >>> On 23 July 2014 06:02, Paulo Zanoni wrote: 2014-06-05 1:01 GMT-03:00 Dave Airlie : > From: Dave Airlie > > This adds DP 1.2 MST support on Haswell systems. Hi It looks like drm-intel-nightly now includes this patch. It actually includes v7, but I couldn't find it on my mail dirs. Just by booting the machine with this patch, I get: >>> >>> There are two patches in my drm-i915-next branch >>> >>> They should remove the offending bits for the fbdev and powersave warning. >> >> Paulo, can you please test these two patches? >> > Oh he did already, didn't I push them? I must have forgotten. Oh, I guess I've missed that since it didn't go over the m-l ;-) It's there already. -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
Re: [Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On 29 July 2014 20:46, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote: >> On 23 July 2014 06:02, Paulo Zanoni wrote: >>> 2014-06-05 1:01 GMT-03:00 Dave Airlie : From: Dave Airlie This adds DP 1.2 MST support on Haswell systems. >>> >>> Hi >>> >>> It looks like drm-intel-nightly now includes this patch. It actually >>> includes v7, but I couldn't find it on my mail dirs. >>> >>> Just by booting the machine with this patch, I get: >>> >> >> There are two patches in my drm-i915-next branch >> >> They should remove the offending bits for the fbdev and powersave warning. > > Paulo, can you please test these two patches? > Oh he did already, didn't I push them? I must have forgotten. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote: > On 23 July 2014 06:02, Paulo Zanoni wrote: >> 2014-06-05 1:01 GMT-03:00 Dave Airlie : >>> From: Dave Airlie >>> >>> This adds DP 1.2 MST support on Haswell systems. >> >> Hi >> >> It looks like drm-intel-nightly now includes this patch. It actually >> includes v7, but I couldn't find it on my mail dirs. >> >> Just by booting the machine with this patch, I get: >> > > There are two patches in my drm-i915-next branch > > They should remove the offending bits for the fbdev and powersave warning. Paulo, can you please test these two patches? -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
Re: [Intel-gfx] [PATCH] drm/i915: s/seqno/request/ tracking inside objects
On Tue, Jul 29, 2014 at 08:29:53AM +0100, Chris Wilson wrote:
> On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
> > > @@ -3038,44 +3203,35 @@ out:
> > > */
> > > int
> > > i915_gem_object_sync(struct drm_i915_gem_object *obj,
> > > - struct intel_engine_cs *to)
> > > + struct intel_engine_cs *to,
> > > + bool readonly)
> > > {
> >
> > It might be nice to have sync_read/sync_write functions instead, since
> > looking up bool args or unnamed enums is a pain.
>
> Not convinced since it is used in a single location and two function
> calls would look unelegant - but we could switch to PROT_READ |
> PROT_WRITE throughout.
Switching to PROT_READ/WRITE might be nice as a general cleanup (or some
other named thing) since read_only/write booleans are all over the place.
So I like this, but definitely something for a separate patch.
-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
Re: [Intel-gfx] PROBLEM: Native backlight regressed from logarithmic to linear scale
On Tue, Jul 29, 2014 at 06:14:16AM -0400, Anders Kaseorg wrote: > On Tue, 29 Jul 2014, Hans de Goede wrote: > > I've been thinking a bit about this, and I believe that the right answer > > here is to do the linear to logarithmic mapping in user-space. The intel > > backlight interface has a type of raw, clearly signalling to userspace > > that it is a raw "untranslated" interface, as such any fanciness such as > > creating a logarithmic scale should be done in userspace IMHO. > > I was going to respond that the kernel does its own brightness stepping > when userspace isn’t paying attention. But apparently only acpi_video > does that, and intel_backlight does not; my brightness keys now have no > effect outside of the X server. Is that the expected behavior? Userspace on linux is supposed to catch brightness keys and update the backlight. Some acpi drivers do funny stuff behind everyone's back, but generally that's the expected behavior. You'd need a deamon for the backlight to work on the console. > In any case, if you think punting part of the problem to userspace is the > right answer, then to flesh out the details: do you think it’s right for > userspace to assume that any backlight with type ‘raw’ is a linear scale > that needs to be converted, and one with type ‘firmware’ or ‘platform’ has > already been converted appropriately? I don't think you can generally assume anything - what we do is send the pwm signal, how linearly that translates into brightness is totally panel and driver dependent. So no matter what you pick someone will complain I think. -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
Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load & thaw
On Tue, Jul 29, 2014 at 08:36:33AM +0100, Chris Wilson wrote: > On Mon, Jul 28, 2014 at 11:26:38AM +0200, Daniel Vetter wrote: > > Oh, I guess that's the tricky bit why the old approach never worked - > > because reset_in_progress is set we failed the context/ppgtt loading > > through the rings and screwed up. > > > > Problem with your approach is that we want to bail out here if a reset is > > in progress, so we can't just eat the EAGAIN. If we do that we potentially > > deadlock or overflow the ring. > > > > I think we need a different hack here, and a few layers down (i.e. at the > > place where we actually generate that offending -EAGAIN). > > > > - Around the re-init sequence in the reset function we set > > dev_priv->mm.reload_in_reset or similar. Since we hold dev->struct_mutex > > no one will see that, as long as we never leak it out of the critical > > section. > > > > - In the ring_begin code that checks for gpu hangs we ignore > > reset_in_progress if this bit is set. > > > > - Both places need fairly big comments to explain what exactly is going > > on. > > This is going from bad to worse. I think you can do better if you looked > at the problem afresh. Well we can't really reset reset_in_progress at that point, since not all reset is done yet. Especially the modeset stuff. So I don't think that reordering the reset sequence would get us out of this ugly spot. And I don't see any other solution really. Do you? -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
Re: [Intel-gfx] [PATCH] drm: Add rotation_property to mode_config and creating it
On Tue, Jul 29, 2014 at 12:40:29PM +0300, Ville Syrjälä wrote: > On Mon, Jul 28, 2014 at 08:47:22PM +0200, Daniel Vetter wrote: > > On Mon, Jul 28, 2014 at 06:29:41PM +0300, Ville Syrjälä wrote: > > > On Tue, Jul 15, 2014 at 05:43:37PM +0530, sonika.jin...@intel.com wrote: > > > > From: Sonika Jindal > > > > > > > > v2: Adding creation of rotation_property here. > > > > > > > > Signed-off-by: Sonika Jindal > > > > --- > > > > drivers/gpu/drm/drm_crtc.c |3 ++- > > > > include/drm/drm_crtc.h |1 + > > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > > > index 787631e..49c0747 100644 > > > > --- a/drivers/gpu/drm/drm_crtc.c > > > > +++ b/drivers/gpu/drm/drm_crtc.c > > > > @@ -1299,7 +1299,8 @@ static int > > > > drm_mode_create_standard_plane_properties(struct drm_device *dev) > > > > "type", > > > > drm_plane_type_enum_list, > > > > > > > > ARRAY_SIZE(drm_plane_type_enum_list)); > > > > dev->mode_config.plane_type_property = type; > > > > - > > > > + dev->mode_config.rotation_property = > > > > drm_mode_create_rotation_property(dev, > > > > + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)); > > > > > > This might not make sense for other (!i915) hardware. And that's the > > > reason why I had the driver create the property in the first place. > > > > > > I think Daniel was thinking that we might want to expose all the bits > > > regardless of what the hardware supports, but I don't like that idea. > > > There are other properties (eg. alpha blending, csc stuff, etc.) that > > > have the same problem of hardware supporting only a (potentially small) > > > subset of the possible values. I'd rather we didn't make life harder > > > for userspace when the kernel can already report that certain values > > > will never work. > > > > Well I'd like the property to be in some generic place so that fbcon can > > unroate and that with the atomic stuff we can have rotation support in the > > core structures. Which should help with argument checking. > > > > But for rotation I don't think we should set it up in generic code, but in > > i915. So the place where we keep it would be generic, the values would be > > the sames, but the allowed set would differ depending upon platform or > > driver. > > That would still fail if all the planes on the same device don't support > the same rotation flags. Eg. on i915 we would have this problem if we > exposed the old video overlay as a drm plane. And it wouldn't be the > first piece of hardware where I've seen this kind of thing. Problem is still that I'd like to have a somewhat generic internal representation available. We could punt this to atomic though by adding a rotation field to the drm_plane_state structure. Which is more-or-less my plan, but wouldn't work with Rob's approach. Or we keep the property link only in drm_plane (and give drivers the freedom to set up the underlying enum however they want to), but I'm not sure whether our interfaces can cope with that. -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
Re: [Intel-gfx] [PATCH 22/40] drm/i915: Add chv port D TX wells
On Tue, Jul 29, 2014 at 12:54:36PM +0300, Imre Deak wrote:
> On Mon, 2014-07-28 at 18:19 +0300, Ville Syrjälä wrote:
> > On Fri, Jul 25, 2014 at 04:30:29PM +0300, Imre Deak wrote:
> > > On Sat, 2014-06-28 at 02:04 +0300, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Add the TX wells for port D. The Punit subsystem numbers are a total
> > > > guess at this time. Also I'm not sure these even exist. Certainly the
> > > > Punit in current hardware doesn't deal with these.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 4
> > > > drivers/gpu/drm/i915/intel_pm.c | 23 +++
> > > > 2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 3d1fef4..191df9e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -525,6 +525,10 @@ enum punit_power_well {
> > > > PUNIT_POWER_WELL_DPIO_RX0 = 10,
> > > > PUNIT_POWER_WELL_DPIO_RX1 = 11,
> > > > PUNIT_POWER_WELL_DPIO_CMN_D = 12,
> > > > + /* FIXME: guesswork below */
> > > > + PUNIT_POWER_WELL_DPIO_TX_D_LANES_01 = 13,
> > > > + PUNIT_POWER_WELL_DPIO_TX_D_LANES_23 = 14,
> > > > + PUNIT_POWER_WELL_DPIO_RX2 = 15,
> > > >
> > > > PUNIT_POWER_WELL_NUM,
> > > > };
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index cae936c..55f3e6b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -6540,6 +6540,15 @@ EXPORT_SYMBOL_GPL(i915_release_power_well);
> > > > BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
> > > > BIT(POWER_DOMAIN_INIT))
> > > >
> > > > +#define CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS ( \
> > > > + BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) | \
> > > > + BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
> > > > + BIT(POWER_DOMAIN_INIT))
> > > > +
> > > > +#define CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS ( \
> > > > + BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
> > >
> > > Atm, for all other ports we power up all lanes regardless of the actual
> > > configuration (until the PHY side setup is proved to work fine). So for
> > > consistency I'd do the same here too. With that change:
> >
> > We do that here too. '.domains = 01 | 23' for both tx-d wells. Or am I
> > missing something?
>
> Ah, right I should've read a couple of lines below. So my above comment
> can be ignored and my r-b applies as-is.
>
> > > Reviewed-by: Imre Deak
Queued for -next, thanks for the patch.
-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
Re: [Intel-gfx] [PATCH 45/53] drm/i915/bdw: Do not call intel_runtime_pm_get() in an interrupt
On Tue, Jul 29, 2014 at 08:37:48AM +0100, Chris Wilson wrote: > On Mon, Jul 28, 2014 at 10:54:06AM +0200, Daniel Vetter wrote: > > On Sat, Jul 26, 2014 at 11:27:38AM +0100, Chris Wilson wrote: > > > On Wed, Jun 18, 2014 at 10:54:13PM +0200, Daniel Vetter wrote: > > > > On Fri, Jun 13, 2014 at 04:38:03PM +0100, oscar.ma...@intel.com wrote: > > > > > From: Oscar Mateo > > > > > > > > > > Or with a spinlock grabbed, because it might sleep, which is not > > > > > a nice thing to do. Instead, do the runtime_pm get/put together > > > > > with the create/destroy request, and handle the forcewake get/put > > > > > directly. > > > > > > > > > > Signed-off-by: Oscar Mateo > > > > > > > > Looks like a fixup that should be squashed into relevant earlier > > > > patches. > > > > > > The whole gen6_gt_force_wake_get() calling intel_runtime_pm_get() is > > > broken due to this - we must be able to read registers in atomic > > > context! > > > > > > Please revert c8c8fb33b37766acf6474784b0d5245dab9a1690 > > > > force_wake_get can't call runtime_pm_get becuase pm_get can sleep. So if > > you want to read registers from atomic context you have to have a runtime > > pm reference from someone else. > > Nope. That cannot work. Well it works currently. So where do you see the problem? -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
Re: [Intel-gfx] [PATCH 1/3] drm/i915: fix cursor handling when runtime suspended
On Mon, Jul 28, 2014 at 03:37:12PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we're runtime suspended and try to use the cursor interfaces, we
> will get a lot of WARNs saying we did the wrong thing.
>
> For intel_crtc_update_cursor(), all we need to do is return if the
> CRTC is not active, since writing the registers won't really have any
> effect if the screen is not visible, and we will write the registers
> later when enabling the screen.
>
> For intel_crtc_cursor_set_obj(), we just need to wake up the hardware
> then pinning the display plane.
>
> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
>
> Testcase: igt/pm_rpm/cursor
> Testcase: igt/pm_rpm/cursor-dpms
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1edfd1a..f1a9b5c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8144,6 +8144,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
> *crtc,
> if (base == 0 && intel_crtc->cursor_base == 0)
> return;
>
> + if (!intel_crtc->active)
> + return;
> +
> I915_WRITE(CURPOS(pipe), pos);
>
> if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
> @@ -8217,7 +8220,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
> *crtc,
> if (need_vtd_wa(dev))
> alignment = 64*1024;
>
> + intel_runtime_pm_get(dev_priv);
> ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> NULL);
> + intel_runtime_pm_put(dev_priv);
put_fence() would need runtime pm too I think.
> if (ret) {
> DRM_DEBUG_KMS("failed to move cursor bo into the
> GTT\n");
> goto fail_locked;
> --
> 2.0.1
>
> ___
> 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] PROBLEM: Native backlight regressed from logarithmic to linear scale
On Tue, 29 Jul 2014, Hans de Goede wrote: > I've been thinking a bit about this, and I believe that the right answer > here is to do the linear to logarithmic mapping in user-space. The intel > backlight interface has a type of raw, clearly signalling to userspace > that it is a raw "untranslated" interface, as such any fanciness such as > creating a logarithmic scale should be done in userspace IMHO. I was going to respond that the kernel does its own brightness stepping when userspace isn’t paying attention. But apparently only acpi_video does that, and intel_backlight does not; my brightness keys now have no effect outside of the X server. Is that the expected behavior? In any case, if you think punting part of the problem to userspace is the right answer, then to flesh out the details: do you think it’s right for userspace to assume that any backlight with type ‘raw’ is a linear scale that needs to be converted, and one with type ‘firmware’ or ‘platform’ has already been converted appropriately? Anders ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
