Re: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

2015-10-20 Thread Daniel Vetter
On Mon, Oct 19, 2015 at 10:27:17PM +, Smith, Gary K wrote:
> Unless legacy mode enables it of course.

I thought we decided to ignore legacy gamma stuff (at least for now, until
someone complains about the inconsistency). So yeah, I think we're fine.
-Daniel

> 
> Thanks
> Gary
> 
> 
> "Smith, Gary K"  wrote:
> 
> Bear in mind that it will only happen after the property has been set. 
> Initially there will be no clients setting the property - so I think it 
> should be OK.
> 
> Thanks
> Gary
> 
> 
> Daniel Vetter  wrote:
> 
> On Mon, Oct 19, 2015 at 08:39:54PM +, Bish, Jim wrote:
> >
> >
> > On 10/19/2015 11:54 AM, Daniel Vetter wrote:
> > > On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote:
> > >> FYI - this shouldn't block the commits, but should be optimized later 
> > >> (fairly soon).
> > >>
> > >> I believe the current implementation ends up executing
> > >> while (count < CHV_DEGAMMA_MAX_VALS) {
> > >> // Do lots of caclulation
> > >> I915_WRITE(cgm_degamma_reg, word);
> > >> Every frame after you set the property, whether you change the contents 
> > >> of the blob or not. Clearly this is really inefficient when there are 
> > >> 100s of gamma values to write.
> > >> Same with the Gamma and CTM. CTM is less of an issue with only 9 entries.
> > >>
> > >> My suggestion here is to set a boolean when the property has been set as
> > >> part of a flip and only apply it on the atomic commit after the update
> > >> was received.
> > >
> > > Yeah the usual design is to add a foo_changed boolean (or bitmask, e.g.
> > > for changed planes tracked in the crtc_state) in the state where we need
> > > to commit the update. That /should/ be there really, didn't ever realize
> > > it's not done. Note that that for legacy cursors we update them without
> > > waiting for vblanks and legacy userspace does that a _lot_ (*cough* X
> > > server *cough*), if the overhead is severe this might be a problem and
> > > needs to be fixed before merging.
> > >
> > > -Daniel
> > Severe enough to block? I wanted to get this closed out this week but...
> > I see your point Gary but need a reading on Daniel's last sentence.
> 
> X server doing silly amounts of setcursor calls is a known issue that has
> bitten us in the past (with people complaining about seriously sluggish
> desktops). Just needs to be tested, and depending upon results either
> fixed before or after merging. I hope we can get away with fixing up
> post-merge. But writing a few kb through mmio for each cursor is a lot, so
> it might show up in real world.
> -Daniel
> 
> >
> > Jim
> > >
> > >>
> > >> Thanks
> > >> Gary
> > >>
> > >> -Original Message-
> > >> From: Sharma, Shashank
> > >> Sent: Friday, October 16, 2015 3:29 PM
> > >> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; 
> > >> emil.l.veli...@gmail.com; Roper, Matthew D; Bradford, Robert; Bish, Jim
> > >> Cc: Matheson, Annie J; kausalmall...@gmail.com; Kumar, Kiran S; Smith, 
> > >> Gary K; Vetter, Daniel; Mukherjee, Indranil; Palleti, Avinash Reddy; 
> > >> Sharma, Shashank
> > >> Subject: [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction
> > >>
> > >> CHV/BSW supports Degamma color correction, which linearizes all the 
> > >> non-linear color values. This will be applied before Color 
> > >> Transformation.
> > >>
> > >> This patch does the following:
> > >> 1. Attach deGamma property to CRTC
> > >> 2. Add the core function to program DeGamma correction values for
> > >>CHV/BSW platform
> > >> 2. Add DeGamma correction macros/defines
> > >>
> > >> Signed-off-by: Shashank Sharma 
> > >> Signed-off-by: Kausal Malladi 
> > >> ---
> > >>  drivers/gpu/drm/i915/i915_reg.h|  6 ++
> > >>  drivers/gpu/drm/i915/intel_color_manager.c | 92 
> > >> ++  
> > >> drivers/gpu/drm/i915/intel_color_manager.h |  5 ++
> > >>  3 files changed, 103 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > >> b/drivers/gpu/drm/i915/i915_reg.h index 45ddd84..1e46562 100644
> > >> --- a/drivers/gpu/drm/i915/i915_reg.h
> > >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> > >> @@ -8160,4 +8160,10 @@ enum skl_disp_power_wells {  #define 
> > >> _PIPE_GAMMA_BASE(pipe) \
> > >> (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
> > >>
> > >> +#define PIPEA_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 
> > >> 0x66000)
> > >> +#define PIPEB_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 
> > >> 0x68000)
> > >> +#define PIPEC_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 
> > >> 0x6A000)
> > >> +#define _PIPE_DEGAMMA_BASE(pipe) \
> > >> +  (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
> > >> +PIPEC_CGM_DEGAMMA))
> > >> +
> > >>  #endif /* _I915_REG_H_ */
> > >> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
> > >> b/drivers/gpu/drm/i915/intel_color_manager.c
> > >> index acb9647..1bbad79 100644
> > >> --- a/driv

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Make wait_for_flips interruptible.

2015-10-20 Thread Ander Conselvan De Oliveira
On Mon, 2015-10-19 at 15:30 +0200, Daniel Vetter wrote:
> On Mon, Oct 19, 2015 at 04:16:53PM +0300, Ander Conselvan De Oliveira wrote:
> > On Wed, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> > > @@ -13306,6 +13299,29 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > >   if (ret)
> > >   return ret;
> > >  
> > > + if (old_obj) {
> > > + struct drm_crtc_state *crtc_state =
> > > + drm_atomic_get_existing_crtc_state(new_state
> > > ->state,
> > > plane->state->crtc);
> > > +
> > > + /* Big Hammer, we also need to ensure that any pending
> > > +  * MI_WAIT_FOR_EVENT inside a user batch buffer on the
> > > +  * current scanout is retired before unpinning the old
> > > +  * framebuffer. Note that we rely on userspace rendering
> > > +  * into the buffer attached to the pipe they are waiting
> > > +  * on. If not, userspace generates a GPU hang with IPEHR
> > > +  * point to the MI_WAIT_FOR_EVENT.
> > > +  *
> > > +  * This should only fail upon a hung GPU, in which case
> > > we
> > > +  * can safely continue.
> > > +  */
> > > + if (needs_modeset(crtc_state))
> > > + ret = i915_gem_object_wait_rendering(old_obj,
> > > true);
> > > +
> > > + /* Swallow -EIO errors to allow updates during hw lockup.
> > > */
> > > + if (ret && ret != -EIO)
> > > + goto out;
> > 
> > Doesn't this change the behavior of a modeset after a GPU hang? Since
> > mm.interruptible is true, i915_gem_check_wedge() might return -EAGAIN
> > instead of
> > -EIO. Previously the modeset would continue in that scenario, but now,
> > somewhat
> > contrary to the comment above, we don't continue and instead pass the 
> > -EAGAIN to
> > user space.
> 
> It's "while the gpu hang is pending" not "after", but this change is the
> hole point of making pinning interruptible. With current modeset code the
> only thing we could hope for is that the reset would go through, and
> otherwise we'd have to fail the modeset. Now we can correctly retry the
> operation if it has run into a concurrent gpu hang/reset.

So in that case should user space retry the modeset? I don't think it does that
at moment, at least weston and xf86-video-intel don't. I'm not sure how big of a
deal that is, though, since it is an unlikely corner case.

Ander

> Note that we still should eat any -EIO, since modesets must continue even
> if the render side is completely dead.
> -Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Retry on every aux read.

2015-10-20 Thread Daniel Vetter
On Tue, Oct 20, 2015 at 10:02:21AM +0300, Jani Nikula wrote:
> On Tue, 20 Oct 2015, Rodrigo Vivi  wrote:
> > We have an inconsistency on our code on using intel_dp_dpcd_read_wake with
> > retries and when using drm_dp_dpcd_read helper without retry.
> 
> We're supposed to do the retries when the sink may be in a power down
> state. We're not very good at tracking that, and we've cargo culted the
> retry variants all over the place without thinking. This is why we're
> inconsistent.
> 
> > Since the retries help in many cases let's be consistent and be on
> > the safe side retrying on every aux read, including i2c ones.
> 
> Please let's not add superfluous retries at different levels of the
> stack just to be safe. It's like a variant of the C programmer's
> disease.
> 
> If the retries really help [citation needed] we need to figure out what
> we're doing wrong and where, and preferrably fix this at the DP helper
> level for all drivers, if possible.

Yeah, same comment as I've done last time around. If we need this, we need
to do this in core dp helpers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Daniel Vetter
On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > 
> > Previously rotation was ignored and wrong stride programmed
> > into the plane registers resulting in a corrupt image on screen.
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > Cc: Sonika Jindal 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 539c3737e823..6328788193e4 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
> > *intel_crtc)
> >  {
> > struct drm_device *dev = intel_crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > +   struct drm_plane *plane = intel_crtc->base.primary;
> > struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
> > const enum pipe pipe = intel_crtc->pipe;
> > -   u32 ctl, stride;
> > +   u32 ctl, stride, tile_height;
> >  
> > ctl = I915_READ(PLANE_CTL(pipe, 0));
> > ctl &= ~PLANE_CTL_TILED_MASK;
> > @@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
> > *intel_crtc)
> >  * The stride is either expressed as a multiple of 64 bytes chunks for
> >  * linear buffers or in number of tiles for tiled buffers.
> >  */
> > -   stride = fb->pitches[0] /
> > -intel_fb_stride_alignment(dev, fb->modifier[0],
> > -  fb->pixel_format);
> > +   if (intel_rotation_90_or_270(plane->state->rotation)) {
> > +   /* stride = Surface height in tiles */
> > +   tile_height = intel_tile_height(dev, fb->pixel_format,
> > +   fb->modifier[0], 0);
> > +   stride = DIV_ROUND_UP(fb->height, tile_height);
> > +   } else {
> > +   stride = fb->pitches[0] /
> > +   intel_fb_stride_alignment(dev, fb->modifier[0],
> > + fb->pixel_format);
> > +   }
> 
> I was wondering why we are allowing stride changes during page flip, but
> after looking at the history it seems we are not. The reason for
> updating the stride register is the fact that the units we specify it
> in change between different tiling modes on SKL+. We still reject actual
> stride changes during page flip, which is good because allowing it would
> cause problems for my fb->offsets[] stuff since the interpretation of the
> linear offset would change with the stride.
> 
> We do allow changes to the rotated stride though since we don't reject
> changes to the fb height. I think I need to draw some pictures before I
> can say for sure whether that can cause problems or not. But we ca
> leave that for another patch if it turns out to need handling.
> 
> One thing that's dodgy here is the plane->state->rotation check. I
> think currently we wait for pending flips during the atomic commit
> phase after we've swapped the state. So this may end up using the
> wrong rotation setting. It would be an even bigger problem if we
> already allowed queueing up or replaceing pending plane updates. I
> suppose the primary->fb thing doesn't suffer from this problem because
> we swap that pointer only after we've waited for pending flips.

Current rule is that pageflip doesn't allow any change in any metadata.
There's some minor exception that on some platforms we can change the
tiling because someone asked for that specifically and it's possible.

atomic flips will be able to cope with this. But for legacy pageflips imo
reject everything aggressively that changes metadata (stride, tiling,
rotation).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix a false alert of memory leak when free LRC

2015-10-20 Thread Daniel Vetter
On Mon, Oct 19, 2015 at 03:05:46PM -0700, yu@intel.com wrote:
> From: Alex Dai 
> 
> There is a memory leak warning message from i915_gem_context_clean
> when GuC submission is enabled. The reason is that the request (so
> the LRC associated with it) is freed early than moving the vma list
> to inactive. When retire a gem object, this patch moves its vma
> list to inactive first to avoid the false alert of memory leak.
> 
> We are not seeing this in ExecList (non-GuC) mode because the gem
> request is moved to execlist_retired_req_list queue. The management
> of this queue, therefore free of LRC, happens after retire of vma
> list (i915_gem_retire_requests_ring).

Instead of hacking up the core active tracking code can we just fix lrc
context object tracking instead? This patch here seems to be supremely
fragile, and I really don't want it.
-Daniel

> 
> Signed-off-by: Alex Dai 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 29 -
>  1 file changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7d6b0c8..a903d45 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2377,28 +2377,31 @@ i915_gem_object_retire__read(struct 
> drm_i915_gem_object *obj, int ring)
>   RQ_BUG_ON(obj->last_read_req[ring] == NULL);
>   RQ_BUG_ON(!(obj->active & (1 << ring)));
>  
> + obj->active &= ~(1 << ring);
> + if (!obj->active) {
> + /* Bump our place on the bound list to keep it roughly in LRU
> +  * order so that we don't steal from recently used but inactive
> +  * objects (unless we are forced to ofc!)
> +  */
> + list_move_tail(&obj->global_list,
> + &to_i915(obj->base.dev)->mm.bound_list);
> +
> + list_for_each_entry(vma, &obj->vma_list, vma_link) {
> + if (!list_empty(&vma->mm_list))
> + list_move_tail(&vma->mm_list,
> + &vma->vm->inactive_list);
> + }
> + }
> +
>   list_del_init(&obj->ring_list[ring]);
>   i915_gem_request_assign(&obj->last_read_req[ring], NULL);
>  
>   if (obj->last_write_req && obj->last_write_req->ring->id == ring)
>   i915_gem_object_retire__write(obj);
>  
> - obj->active &= ~(1 << ring);
>   if (obj->active)
>   return;
>  
> - /* Bump our place on the bound list to keep it roughly in LRU order
> -  * so that we don't steal from recently used but inactive objects
> -  * (unless we are forced to ofc!)
> -  */
> - list_move_tail(&obj->global_list,
> -&to_i915(obj->base.dev)->mm.bound_list);
> -
> - list_for_each_entry(vma, &obj->vma_list, vma_link) {
> - if (!list_empty(&vma->mm_list))
> - list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
> - }
> -
>   i915_gem_request_assign(&obj->last_fenced_req, NULL);
>   drm_gem_object_unreference(&obj->base);
>  }
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/5] drm/i915: Make wait_for_flips interruptible.

2015-10-20 Thread Daniel Vetter
On Tue, Oct 20, 2015 at 10:38:41AM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2015-10-19 at 15:30 +0200, Daniel Vetter wrote:
> > On Mon, Oct 19, 2015 at 04:16:53PM +0300, Ander Conselvan De Oliveira wrote:
> > > On Wed, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> > > > @@ -13306,6 +13299,29 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > > > if (ret)
> > > > return ret;
> > > >  
> > > > +   if (old_obj) {
> > > > +   struct drm_crtc_state *crtc_state =
> > > > +   drm_atomic_get_existing_crtc_state(new_state
> > > > ->state,
> > > > plane->state->crtc);
> > > > +
> > > > +   /* Big Hammer, we also need to ensure that any pending
> > > > +* MI_WAIT_FOR_EVENT inside a user batch buffer on the
> > > > +* current scanout is retired before unpinning the old
> > > > +* framebuffer. Note that we rely on userspace rendering
> > > > +* into the buffer attached to the pipe they are waiting
> > > > +* on. If not, userspace generates a GPU hang with IPEHR
> > > > +* point to the MI_WAIT_FOR_EVENT.
> > > > +*
> > > > +* This should only fail upon a hung GPU, in which case
> > > > we
> > > > +* can safely continue.
> > > > +*/
> > > > +   if (needs_modeset(crtc_state))
> > > > +   ret = i915_gem_object_wait_rendering(old_obj,
> > > > true);
> > > > +
> > > > +   /* Swallow -EIO errors to allow updates during hw 
> > > > lockup.
> > > > */
> > > > +   if (ret && ret != -EIO)
> > > > +   goto out;
> > > 
> > > Doesn't this change the behavior of a modeset after a GPU hang? Since
> > > mm.interruptible is true, i915_gem_check_wedge() might return -EAGAIN
> > > instead of
> > > -EIO. Previously the modeset would continue in that scenario, but now,
> > > somewhat
> > > contrary to the comment above, we don't continue and instead pass the 
> > > -EAGAIN to
> > > user space.
> > 
> > It's "while the gpu hang is pending" not "after", but this change is the
> > hole point of making pinning interruptible. With current modeset code the
> > only thing we could hope for is that the reset would go through, and
> > otherwise we'd have to fail the modeset. Now we can correctly retry the
> > operation if it has run into a concurrent gpu hang/reset.
> 
> So in that case should user space retry the modeset? I don't think it does 
> that
> at moment, at least weston and xf86-video-intel don't. I'm not sure how big 
> of a
> deal that is, though, since it is an unlikely corner case.

Every drm ioctl goes through drmIoctl in libdrm, which does this
restarting. If not then that's a userspace bug, since this is a core bit
of the drm ABI design.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

2015-10-20 Thread Sharma, Shashank
Yes, please note that as per the discussion, the legacy gamma IOCTL is still 
existing, to maintain the backward compatibility, we have not broken it. 
And we have added provision to program legacy-8bit gamma via color manager 
also, so everyone should be happy :)

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, October 20, 2015 12:58 PM
To: Smith, Gary K
Cc: Daniel Vetter; Bish, Jim; Sharma, Shashank; 
dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; 
emil.l.veli...@gmail.com; Roper, Matthew D; Bradford, Robert; Matheson, Annie 
J; kausalmall...@gmail.com; Vetter, Daniel
Subject: Re: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
correction

On Mon, Oct 19, 2015 at 10:27:17PM +, Smith, Gary K wrote:
> Unless legacy mode enables it of course.

I thought we decided to ignore legacy gamma stuff (at least for now, until 
someone complains about the inconsistency). So yeah, I think we're fine.
-Daniel

> 
> Thanks
> Gary
> 
> 
> "Smith, Gary K"  wrote:
> 
> Bear in mind that it will only happen after the property has been set. 
> Initially there will be no clients setting the property - so I think it 
> should be OK.
> 
> Thanks
> Gary
> 
> 
> Daniel Vetter  wrote:
> 
> On Mon, Oct 19, 2015 at 08:39:54PM +, Bish, Jim wrote:
> >
> >
> > On 10/19/2015 11:54 AM, Daniel Vetter wrote:
> > > On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote:
> > >> FYI - this shouldn't block the commits, but should be optimized later 
> > >> (fairly soon).
> > >>
> > >> I believe the current implementation ends up executing
> > >> while (count < CHV_DEGAMMA_MAX_VALS) {
> > >> // Do lots of caclulation
> > >> I915_WRITE(cgm_degamma_reg, word); Every 
> > >> frame after you set the property, whether you change the contents of the 
> > >> blob or not. Clearly this is really inefficient when there are 100s of 
> > >> gamma values to write.
> > >> Same with the Gamma and CTM. CTM is less of an issue with only 9 entries.
> > >>
> > >> My suggestion here is to set a boolean when the property has been 
> > >> set as part of a flip and only apply it on the atomic commit 
> > >> after the update was received.
> > >
> > > Yeah the usual design is to add a foo_changed boolean (or bitmask, e.g.
> > > for changed planes tracked in the crtc_state) in the state where 
> > > we need to commit the update. That /should/ be there really, 
> > > didn't ever realize it's not done. Note that that for legacy 
> > > cursors we update them without waiting for vblanks and legacy 
> > > userspace does that a _lot_ (*cough* X server *cough*), if the 
> > > overhead is severe this might be a problem and needs to be fixed before 
> > > merging.
> > >
> > > -Daniel
> > Severe enough to block? I wanted to get this closed out this week but...
> > I see your point Gary but need a reading on Daniel's last sentence.
> 
> X server doing silly amounts of setcursor calls is a known issue that 
> has bitten us in the past (with people complaining about seriously 
> sluggish desktops). Just needs to be tested, and depending upon 
> results either fixed before or after merging. I hope we can get away 
> with fixing up post-merge. But writing a few kb through mmio for each 
> cursor is a lot, so it might show up in real world.
> -Daniel
> 
> >
> > Jim
> > >
> > >>
> > >> Thanks
> > >> Gary
> > >>
> > >> -Original Message-
> > >> From: Sharma, Shashank
> > >> Sent: Friday, October 16, 2015 3:29 PM
> > >> To: dri-de...@lists.freedesktop.org; 
> > >> intel-gfx@lists.freedesktop.org; emil.l.veli...@gmail.com; Roper, 
> > >> Matthew D; Bradford, Robert; Bish, Jim
> > >> Cc: Matheson, Annie J; kausalmall...@gmail.com; Kumar, Kiran S; 
> > >> Smith, Gary K; Vetter, Daniel; Mukherjee, Indranil; Palleti, 
> > >> Avinash Reddy; Sharma, Shashank
> > >> Subject: [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
> > >> correction
> > >>
> > >> CHV/BSW supports Degamma color correction, which linearizes all the 
> > >> non-linear color values. This will be applied before Color 
> > >> Transformation.
> > >>
> > >> This patch does the following:
> > >> 1. Attach deGamma property to CRTC 2. Add the core function to 
> > >> program DeGamma correction values for
> > >>CHV/BSW platform
> > >> 2. Add DeGamma correction macros/defines
> > >>
> > >> Signed-off-by: Shashank Sharma 
> > >> Signed-off-by: Kausal Malladi 
> > >> ---
> > >>  drivers/gpu/drm/i915/i915_reg.h|  6 ++
> > >>  drivers/gpu/drm/i915/intel_color_manager.c | 92 
> > >> ++  
> > >> drivers/gpu/drm/i915/intel_color_manager.h |  5 ++
> > >>  3 files changed, 103 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > >> b/drivers/gpu/drm/i915/i915_reg.h index 45ddd84..1e46562 100644
> > >> --- a/drivers/gpu/drm/i915/i915_reg.h
> > >> +++ b/drivers/gpu/drm/i915/i915

Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Tvrtko Ursulin


On 20/10/15 08:42, Daniel Vetter wrote:

On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:

On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

Signed-off-by: Tvrtko Ursulin 
Cc: Sonika Jindal 
---
  drivers/gpu/drm/i915/intel_display.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 539c3737e823..6328788193e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
  {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane *plane = intel_crtc->base.primary;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride;
+   u32 ctl, stride, tile_height;

ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 * The stride is either expressed as a multiple of 64 bytes chunks for
 * linear buffers or in number of tiles for tiled buffers.
 */
-   stride = fb->pitches[0] /
-intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+   if (intel_rotation_90_or_270(plane->state->rotation)) {
+   /* stride = Surface height in tiles */
+   tile_height = intel_tile_height(dev, fb->pixel_format,
+   fb->modifier[0], 0);
+   stride = DIV_ROUND_UP(fb->height, tile_height);
+   } else {
+   stride = fb->pitches[0] /
+   intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+   }


I was wondering why we are allowing stride changes during page flip, but
after looking at the history it seems we are not. The reason for
updating the stride register is the fact that the units we specify it
in change between different tiling modes on SKL+. We still reject actual
stride changes during page flip, which is good because allowing it would
cause problems for my fb->offsets[] stuff since the interpretation of the
linear offset would change with the stride.

We do allow changes to the rotated stride though since we don't reject
changes to the fb height. I think I need to draw some pictures before I
can say for sure whether that can cause problems or not. But we ca
leave that for another patch if it turns out to need handling.

One thing that's dodgy here is the plane->state->rotation check. I
think currently we wait for pending flips during the atomic commit
phase after we've swapped the state. So this may end up using the
wrong rotation setting. It would be an even bigger problem if we
already allowed queueing up or replaceing pending plane updates. I
suppose the primary->fb thing doesn't suffer from this problem because
we swap that pointer only after we've waited for pending flips.


Current rule is that pageflip doesn't allow any change in any metadata.
There's some minor exception that on some platforms we can change the
tiling because someone asked for that specifically and it's possible.

atomic flips will be able to cope with this. But for legacy pageflips imo
reject everything aggressively that changes metadata (stride, tiling,
rotation).


I am not sure what is the conclusion. To re-iterate, idea is not to 
allow rotation changes between page flips, just to program PLANE_STRIDE 
accordingly, when rotation is already enabled. Since otherwise page flip 
will calculate it incorrectly.


I though Ville was raising two concerns:

1. Will the plane state be swapped from under the pending page flips 
prematurely?


2. Do we need to program the stride in page flips at all?

Did I get that right? Unless 1) is true it looks safe to me to have this 
patch, and if answer to 2) is no then we could rip out more code?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier

2015-10-20 Thread Tvrtko Ursulin


On 20/10/15 02:14, Vivek Kasireddy wrote:

Hi Tvrtko,

On Mon, 19 Oct 2015 11:20:05 +0100
Tvrtko Ursulin  wrote:



Hi,

On 17/10/15 03:47, Vivek Kasireddy wrote:

The main goal of this subtest is to verify whether flipping a
framebuffer with a Y fb modifier (90/270 degree rotation) and
an associated Y-tiled object works or not.

Cc: Tvrtko Ursulin 
Signed-off-by: Vivek Kasireddy 
---
   tests/kms_rotation_crc.c | 83
 1 file changed, 83
insertions(+)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index cc9847e..bb9aecb 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -264,6 +264,83 @@ static void test_plane_rotation(data_t *data,
enum igt_plane plane_type) igt_require_f(valid_tests, "no valid
crtc/connector combinations found\n"); }

+static void test_plane_rotation_ytiled_obj(data_t *data, enum
igt_plane plane_type) +{
+   igt_display_t *display = &data->display;
+   uint64_t tiling = LOCAL_I915_FORMAT_MOD_Y_TILED;
+   uint32_t format = DRM_FORMAT_XRGB;
+   int bpp = igt_drm_format_to_bpp(format);
+   enum igt_commit_style commit = COMMIT_LEGACY;
+   int fd = data->gfx_fd;
+   int valid_tests = 0;
+   igt_output_t *output;
+   int ret;
+
+   if (plane_type == IGT_PLANE_PRIMARY || plane_type ==
IGT_PLANE_CURSOR) {
+   igt_require(data->display.has_universal_planes);
+   commit = COMMIT_UNIVERSAL;
+   }
+
+   for_each_connected_output(display, output) {
+   igt_plane_t *plane;
+   drmModeModeInfo *mode =
igt_output_get_mode(output);
+   unsigned int w = mode->hdisplay;
+   unsigned int h = mode->vdisplay;
+   unsigned int stride, size;
+   uint32_t gem_handle;
+
+   for (stride = 512; stride < (w * bpp / 8); stride
*= 2)
+   ;
+   for (size = 1024*1024; size < stride * h; size *=
2)
+   ;
+
+   gem_handle = gem_create(fd, size);
+   ret = __gem_set_tiling(fd, gem_handle,
I915_TILING_Y, stride);
+   igt_assert(ret == 0);
+
+   do_or_die(__kms_addfb(fd, gem_handle, w, h, stride,
+ format, tiling,
LOCAL_DRM_MODE_FB_MODIFIERS,
+ &data->fb.fb_id));
+
+   data->fb.width = w;
+   data->fb.height = h;
+   data->fb.gem_handle = gem_handle;
+   data->fb.stride = stride;
+   data->fb.size = size;
+   data->fb.tiling = tiling;
+   data->fb.drm_format = format;
+
+   plane = igt_output_get_plane(output, plane_type);
+   igt_require(igt_plane_supports_rotation(plane));
+
+   igt_plane_set_fb(plane, NULL);
+   igt_display_commit(display);
+
+   igt_plane_set_rotation(plane, data->rotation);
+   paint_squares(data, mode, IGT_ROTATION_0, plane);
+   igt_plane_set_fb(plane, &data->fb);
+
+   drmModeObjectSetProperty(fd,
plane->drm_plane->plane_id,
+DRM_MODE_OBJECT_PLANE,
+plane->rotation_property,
+plane->rotation);
+   ret = igt_display_try_commit2(display, commit);
+   igt_assert(ret == 0);


This manages to trigger the WARN? How come since paint_squares above
will have created the normal VMA?


Yes, this does trigger the WARN regardless of whether paint_squares is
called or not. I am going to have to find out why the normal VMA was
not created when paint_squares was called. And, this subtest does not
restore the console cleanly which is something I also have to fix.


Could be that normal VMA is not created in the Cairo rendering path for 
Y tiled buffers. Since the final rendering is done via a blit and if you 
have PPGTT that would do it I think.


If PPGTT is always true for gen9 then this could work.

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 3/6] drm/i915: Unify execlist and legacy request life-cycles

2015-10-20 Thread Nick Hoath
There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support.  As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.

A request is considered retireable if its seqno passed (i.e. the request
has completed) and either it was never submitted to the ELSP or its
context completed.  This ensures that context save is carried out before
the last request for a context is considered retireable. request_complete()
now checks the elsp_submitted count when deciding if a request is complete.
Requests that were not waiting for a context
switch interrupt (either as a result of being merged into a following
request or by being a legacy request) will be considered retireable as
soon as their seqno has passed.

Removed the extra request reference held for the execlist request.

Removed intel_execlists_retire_requests() and all references to
intel_engine_cs.execlist_retired_req_list.

Changed gen8_cs_irq_handler() so that notify_ring() is called when
contexts complete as well as when a user interrupt occurs so that
notification happens when a request is complete and context save has
finished.

v2: Rebase over the read-read optimisation changes

v3: Reworked IRQ handler after removing IRQ handler cleanup patch

v4: Fixed various pin leaks

v5: Removed ctx_complete flag & associated changes. Removed extraneous
request pin of context.
(Chris Wilson/Daniel Vetter)

Issue: VIZ-4277
Signed-off-by: Thomas Daniel 
Signed-off-by: Nick Hoath 
Cc: Daniel Vetter 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 23 -
 drivers/gpu/drm/i915/i915_irq.c |  7 ++---
 drivers/gpu/drm/i915/intel_lrc.c| 45 -
 drivers/gpu/drm/i915/intel_lrc.h|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 6 files changed, 21 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8afda45..ae08e57 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2914,7 +2914,7 @@ static inline bool i915_gem_request_completed(struct 
drm_i915_gem_request *req,
 
seqno = req->ring->get_seqno(req->ring, lazy_coherency);
 
-   return i915_seqno_passed(seqno, req->seqno);
+   return i915_seqno_passed(seqno, req->seqno) && !req->elsp_submitted;
 }
 
 int __must_check i915_gem_get_seqno(struct drm_device *dev, u32 *seqno);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e57061a..290a1ac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2848,12 +2848,16 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
*ring)
 
if (!list_empty(&obj->last_read_req[ring->id]->list))
break;
+   if (!i915_gem_request_completed(obj->last_read_req[ring->id],
+   true))
+   break;
 
i915_gem_object_retire__read(obj, ring->id);
}
 
if (unlikely(ring->trace_irq_req &&
-i915_gem_request_completed(ring->trace_irq_req, true))) {
+i915_gem_request_completed(ring->trace_irq_req,
+   true))) {
ring->irq_put(ring);
i915_gem_request_assign(&ring->trace_irq_req, NULL);
}
@@ -2872,15 +2876,6 @@ i915_gem_retire_requests(struct drm_device *dev)
for_each_ring(ring, dev_priv, i) {
i915_gem_retire_requests_ring(ring);
idle &= list_empty(&ring->request_list);
-   if (i915.enable_execlists) {
-   unsigned long flags;
-
-   spin_lock_irqsave(&ring->execlist_lock, flags);
-   idle &= list_empty(&ring->execlist_queue);
-   spin_unlock_irqrestore(&ring->execlist_lock, flags);
-
-   intel_execlists_retire_requests(ring);
-   }
}
 
if (idle)
@@ -2956,12 +2951,14 @@ i915_gem_object_flush_active(struct drm_i915_gem_object 
*obj)
if (req == NULL)
continue;
 
-   if (list_empty(&req->list))
-   goto retire;
+   if (list_empty(&req->list)) {
+   if (i915_gem_request_completed(req, true))
+   i915_gem_object_retire__read(obj, i);
+   continue;
+   }
 
if (i915_gem_request_completed(req, true)) {
__i915_gem_request_retire__upto(req);
-retire:
i915_gem_object_retire__read(obj, i);
}
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
inde

[Intel-gfx] [PATCH 4/6] drm/i915: Improve dynamic management/eviction of lrc backing objects

2015-10-20 Thread Nick Hoath
Shovel all context related objects through the active queue and obj
management.

- Added callback in vma_(un)bind to add CPU (un)mapping at same time
  if desired
- Inserted LRC hw context & ringbuf to vma active list

Issue: VIZ-4277
Signed-off-by: Nick Hoath 
---
 drivers/gpu/drm/i915/i915_drv.h |  4 ++
 drivers/gpu/drm/i915/i915_gem.c |  3 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c |  8 
 drivers/gpu/drm/i915/intel_lrc.c| 28 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 71 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 --
 6 files changed, 79 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ae08e57..0dd4ace 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2161,6 +2161,10 @@ struct drm_i915_gem_object {
struct work_struct *work;
} userptr;
};
+
+   /** Support for automatic CPU side mapping of object */
+   int (*mmap)(struct drm_i915_gem_object *obj, bool unmap);
+   void *mappable;
 };
 #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 290a1ac..8bd318a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3222,6 +3222,9 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
if (vma->pin_count)
return -EBUSY;
 
+   if (obj->mmap)
+   obj->mmap(obj, true);
+
BUG_ON(obj->pages == NULL);
 
if (wait) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 43f35d1..2812757 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3517,6 +3517,14 @@ int i915_vma_bind(struct i915_vma *vma, enum 
i915_cache_level cache_level,
 
vma->bound |= bind_flags;
 
+   if (vma->obj->mmap) {
+   ret = vma->obj->mmap(vma->obj, false);
+   if (ret) {
+   i915_vma_unbind(vma);
+   return ret;
+   }
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8428ebd..069950e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -719,6 +719,18 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
 
intel_logical_ring_advance(request->ringbuf);
 
+   /* Push the hw context on to the active list */
+   i915_vma_move_to_active(
+   i915_gem_obj_to_ggtt(
+   request->ctx->engine[ring->id].state),
+   request);
+
+   /* Push the ringbuf on to the active list */
+   i915_vma_move_to_active(
+   i915_gem_obj_to_ggtt(
+   request->ctx->engine[ring->id].ringbuf->obj),
+   request);
+
request->tail = request->ringbuf->tail;
 
if (intel_ring_stopped(ring))
@@ -987,10 +999,15 @@ static int intel_lr_context_do_pin(struct intel_engine_cs 
*ring,
if (ret)
return ret;
 
-   ret = intel_pin_and_map_ringbuffer_obj(ring->dev, ringbuf);
+   ret = i915_gem_obj_ggtt_pin(ringbuf->obj, PAGE_SIZE,
+   PIN_MAPPABLE);
if (ret)
goto unpin_ctx_obj;
 
+   ret = i915_gem_object_set_to_gtt_domain(ringbuf->obj, true);
+   if (ret)
+   goto unpin_rb_obj;
+
ctx_obj->dirty = true;
 
/* Invalidate GuC TLB. */
@@ -999,6 +1016,8 @@ static int intel_lr_context_do_pin(struct intel_engine_cs 
*ring,
 
return ret;
 
+unpin_rb_obj:
+   i915_gem_object_ggtt_unpin(ringbuf->obj);
 unpin_ctx_obj:
i915_gem_object_ggtt_unpin(ctx_obj);
 
@@ -1033,7 +1052,7 @@ void intel_lr_context_unpin(struct drm_i915_gem_request 
*rq)
if (ctx_obj) {
WARN_ON(!mutex_is_locked(&ring->dev->struct_mutex));
if (--rq->ctx->engine[ring->id].pin_count == 0) {
-   intel_unpin_ringbuffer_obj(ringbuf);
+   i915_gem_object_ggtt_unpin(ringbuf->obj);
i915_gem_object_ggtt_unpin(ctx_obj);
}
}
@@ -2351,7 +2370,7 @@ void intel_lr_context_free(struct intel_context *ctx)
struct intel_engine_cs *ring = ringbuf->ring;
 
if (ctx == ring->default_context) {
-   intel_unpin_ringbuffer_obj(ringbuf);
+   i915_gem_object_ggtt_unpin(ringbuf->obj);
i915_gem_object_ggtt_unpin(ctx_obj);
}
WARN_ON(ctx->engine[ring->id].pin_count);
@@ -2518,5 +2537,8 @@ void intel_lr_context_reset(struct drm_device *dev,

[Intel-gfx] [PATCH 1/6] drm/i195: Rename gt_irq_handler variable

2015-10-20 Thread Nick Hoath
Renamed tmp variable to the more descriptive iir. (Daniel Vetter/
Thomas Daniel)

Issue: VIZ-4277
Signed-off-by: Nick Hoath 
Cc: Daniel Vetter 
Cc: David Gordon 
Cc: Thomas Daniel 
---
 drivers/gpu/drm/i915/i915_irq.c | 46 -
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d68328f..fbf9153 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1296,64 +1296,64 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,
irqreturn_t ret = IRQ_NONE;
 
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
-   u32 tmp = I915_READ_FW(GEN8_GT_IIR(0));
-   if (tmp) {
-   I915_WRITE_FW(GEN8_GT_IIR(0), tmp);
+   u32 iir = I915_READ_FW(GEN8_GT_IIR(0));
+   if (iir) {
+   I915_WRITE_FW(GEN8_GT_IIR(0), iir);
ret = IRQ_HANDLED;
 
-   if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_RCS_IRQ_SHIFT))
+   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_RCS_IRQ_SHIFT))
intel_lrc_irq_handler(&dev_priv->ring[RCS]);
-   if (tmp & (GT_RENDER_USER_INTERRUPT << 
GEN8_RCS_IRQ_SHIFT))
+   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_RCS_IRQ_SHIFT))
notify_ring(&dev_priv->ring[RCS]);
 
-   if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_BCS_IRQ_SHIFT))
+   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_BCS_IRQ_SHIFT))
intel_lrc_irq_handler(&dev_priv->ring[BCS]);
-   if (tmp & (GT_RENDER_USER_INTERRUPT << 
GEN8_BCS_IRQ_SHIFT))
+   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_BCS_IRQ_SHIFT))
notify_ring(&dev_priv->ring[BCS]);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
 
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
-   u32 tmp = I915_READ_FW(GEN8_GT_IIR(1));
-   if (tmp) {
-   I915_WRITE_FW(GEN8_GT_IIR(1), tmp);
+   u32 iir = I915_READ_FW(GEN8_GT_IIR(1));
+   if (iir) {
+   I915_WRITE_FW(GEN8_GT_IIR(1), iir);
ret = IRQ_HANDLED;
 
-   if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VCS1_IRQ_SHIFT))
+   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VCS1_IRQ_SHIFT))
intel_lrc_irq_handler(&dev_priv->ring[VCS]);
-   if (tmp & (GT_RENDER_USER_INTERRUPT << 
GEN8_VCS1_IRQ_SHIFT))
+   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_VCS1_IRQ_SHIFT))
notify_ring(&dev_priv->ring[VCS]);
 
-   if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VCS2_IRQ_SHIFT))
+   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VCS2_IRQ_SHIFT))
intel_lrc_irq_handler(&dev_priv->ring[VCS2]);
-   if (tmp & (GT_RENDER_USER_INTERRUPT << 
GEN8_VCS2_IRQ_SHIFT))
+   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_VCS2_IRQ_SHIFT))
notify_ring(&dev_priv->ring[VCS2]);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
 
if (master_ctl & GEN8_GT_VECS_IRQ) {
-   u32 tmp = I915_READ_FW(GEN8_GT_IIR(3));
-   if (tmp) {
-   I915_WRITE_FW(GEN8_GT_IIR(3), tmp);
+   u32 iir = I915_READ_FW(GEN8_GT_IIR(3));
+   if (iir) {
+   I915_WRITE_FW(GEN8_GT_IIR(3), iir);
ret = IRQ_HANDLED;
 
-   if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VECS_IRQ_SHIFT))
+   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VECS_IRQ_SHIFT))
intel_lrc_irq_handler(&dev_priv->ring[VECS]);
-   if (tmp & (GT_RENDER_USER_INTERRUPT << 
GEN8_VECS_IRQ_SHIFT))
+   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_VECS_IRQ_SHIFT))
notify_ring(&dev_priv->ring[VECS]);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
 
if (master_ctl & GEN8_GT_PM_IRQ) {
-   u32 tmp = I915_READ_FW(GEN8_GT_IIR(2));
-   if (tmp & dev_priv->pm_rps_events) {
+   u32 iir = I915_READ_FW(GEN8_GT_IIR(2));
+   if (iir & dev_priv->pm_rps_events) {
I915_WRITE_FW(GEN8_GT_IIR(2),
- tmp & dev_priv->pm_rp

[Intel-gfx] [PATCH 2/6] drm/i915: Break out common code from gen8_gt_irq_handler

2015-10-20 Thread Nick Hoath
Break out common code from gen8_gt_irq_handler and put it in to
an always inlined function. gcc optimises out the shift at compile
time. (Thomas Daniel/Daniel Vetter/Chris Wilson)

Issue: VIZ-4277
Signed-off-by: Nick Hoath 
Cc: Thomas Daniel 
Cc: Daniel Vetter 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_irq.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fbf9153..7837f5e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1290,6 +1290,16 @@ static void snb_gt_irq_handler(struct drm_device *dev,
ivybridge_parity_error_irq_handler(dev, gt_iir);
 }
 
+static __always_inline void
+   gen8_cs_irq_handler(struct intel_engine_cs *ring, u32 iir,
+   int test_shift)
+{
+   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
+   notify_ring(ring);
+   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
+   intel_lrc_irq_handler(ring);
+}
+
 static irqreturn_t gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
   u32 master_ctl)
 {
@@ -1301,15 +1311,11 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,
I915_WRITE_FW(GEN8_GT_IIR(0), iir);
ret = IRQ_HANDLED;
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_RCS_IRQ_SHIFT))
-   intel_lrc_irq_handler(&dev_priv->ring[RCS]);
-   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_RCS_IRQ_SHIFT))
-   notify_ring(&dev_priv->ring[RCS]);
+   gen8_cs_irq_handler(&dev_priv->ring[RCS],
+   iir, GEN8_RCS_IRQ_SHIFT);
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_BCS_IRQ_SHIFT))
-   intel_lrc_irq_handler(&dev_priv->ring[BCS]);
-   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_BCS_IRQ_SHIFT))
-   notify_ring(&dev_priv->ring[BCS]);
+   gen8_cs_irq_handler(&dev_priv->ring[BCS],
+   iir, GEN8_BCS_IRQ_SHIFT);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
@@ -1320,15 +1326,11 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,
I915_WRITE_FW(GEN8_GT_IIR(1), iir);
ret = IRQ_HANDLED;
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VCS1_IRQ_SHIFT))
-   intel_lrc_irq_handler(&dev_priv->ring[VCS]);
-   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_VCS1_IRQ_SHIFT))
-   notify_ring(&dev_priv->ring[VCS]);
+   gen8_cs_irq_handler(&dev_priv->ring[VCS],
+   iir, GEN8_VCS1_IRQ_SHIFT);
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VCS2_IRQ_SHIFT))
-   intel_lrc_irq_handler(&dev_priv->ring[VCS2]);
-   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_VCS2_IRQ_SHIFT))
-   notify_ring(&dev_priv->ring[VCS2]);
+   gen8_cs_irq_handler(&dev_priv->ring[VCS2],
+   iir, GEN8_VCS2_IRQ_SHIFT);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
@@ -1339,10 +1341,8 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,
I915_WRITE_FW(GEN8_GT_IIR(3), iir);
ret = IRQ_HANDLED;
 
-   if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
GEN8_VECS_IRQ_SHIFT))
-   intel_lrc_irq_handler(&dev_priv->ring[VECS]);
-   if (iir & (GT_RENDER_USER_INTERRUPT << 
GEN8_VECS_IRQ_SHIFT))
-   notify_ring(&dev_priv->ring[VECS]);
+   gen8_cs_irq_handler(&dev_priv->ring[VECS],
+   iir, GEN8_VECS_IRQ_SHIFT);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 6/6] drm/i915: Only update ringbuf address when necessary

2015-10-20 Thread Nick Hoath
We now only need to update the address of the ringbuf object in the
hw context when it is pinned, and the hw context is first CPU mapped

Issue: VIZ-4277
Signed-off-by: Nick Hoath 
Cc: David Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a35efcd..2e529a4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -368,7 +368,6 @@ static int execlists_update_context(struct 
drm_i915_gem_request *rq)
WARN_ON(!i915_gem_obj_is_pinned(rb_obj));
 
reg_state[CTX_RING_TAIL+1] = rq->tail;
-   reg_state[CTX_RING_BUFFER_START+1] = i915_gem_obj_ggtt_offset(rb_obj);
 
if (ppgtt && !USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
/* True 32b PPGTT with dynamic page allocation: update PDP
@@ -1027,6 +1026,9 @@ static int intel_lr_context_do_pin(
if (ret)
goto unpin_rb_obj;
 
+   ctx->engine[ring->id].reg_state[CTX_RING_BUFFER_START+1] =
+   i915_gem_obj_ggtt_offset(ringbuf->obj);
+
ctx_obj->dirty = true;
 
/* Invalidate GuC TLB. */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 5/6] drm/i915: Add the CPU mapping of the hw context to the pinned items.

2015-10-20 Thread Nick Hoath
Pin the hw ctx mapping so that it is not mapped/unmapped per bb
when doing GuC submission.

v2: Removed interim development extra mapping. (Daniel Vetter)

Issue: VIZ-4277
Signed-off-by: Nick Hoath 
Cc: David Gordon 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 14 ---
 drivers/gpu/drm/i915/i915_drv.h |  4 +++-
 drivers/gpu/drm/i915/intel_lrc.c| 46 ++---
 3 files changed, 40 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a3b22bd..f0a172e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1970,10 +1970,9 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
 
 static void i915_dump_lrc_obj(struct seq_file *m,
  struct intel_engine_cs *ring,
- struct drm_i915_gem_object *ctx_obj)
+ struct drm_i915_gem_object *ctx_obj,
+ uint32_t *reg_state)
 {
-   struct page *page;
-   uint32_t *reg_state;
int j;
unsigned long ggtt_offset = 0;
 
@@ -1996,17 +1995,13 @@ static void i915_dump_lrc_obj(struct seq_file *m,
return;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
-   if (!WARN_ON(page == NULL)) {
-   reg_state = kmap_atomic(page);
-
+   if (!WARN_ON(reg_state == NULL)) {
for (j = 0; j < 0x600 / sizeof(u32) / 4; j += 4) {
seq_printf(m, "\t[0x%08lx] 0x%08x 0x%08x 0x%08x 
0x%08x\n",
   ggtt_offset + 4096 + (j * 4),
   reg_state[j], reg_state[j + 1],
   reg_state[j + 2], reg_state[j + 3]);
}
-   kunmap_atomic(reg_state);
}
 
seq_putc(m, '\n');
@@ -2034,7 +2029,8 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
for_each_ring(ring, dev_priv, i) {
if (ring->default_context != ctx)
i915_dump_lrc_obj(m, ring,
- ctx->engine[i].state);
+ ctx->engine[i].state,
+ ctx->engine[i].reg_state);
}
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0dd4ace..dc69d67 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -881,8 +881,10 @@ struct intel_context {
} legacy_hw_ctx;
 
/* Execlists */
-   struct {
+   struct intel_context_engine {
struct drm_i915_gem_object *state;
+   uint32_t *reg_state;
+   struct page *page;
struct intel_ringbuffer *ringbuf;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 069950e..a35efcd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -360,16 +360,13 @@ static int execlists_update_context(struct 
drm_i915_gem_request *rq)
struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
struct drm_i915_gem_object *rb_obj = rq->ringbuf->obj;
-   struct page *page;
-   uint32_t *reg_state;
+   uint32_t *reg_state = rq->ctx->engine[ring->id].reg_state;
 
BUG_ON(!ctx_obj);
+   WARN_ON(!reg_state);
WARN_ON(!i915_gem_obj_is_pinned(ctx_obj));
WARN_ON(!i915_gem_obj_is_pinned(rb_obj));
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
-   reg_state = kmap_atomic(page);
-
reg_state[CTX_RING_TAIL+1] = rq->tail;
reg_state[CTX_RING_BUFFER_START+1] = i915_gem_obj_ggtt_offset(rb_obj);
 
@@ -385,8 +382,6 @@ static int execlists_update_context(struct 
drm_i915_gem_request *rq)
ASSIGN_CTX_PDP(ppgtt, reg_state, 0);
}
 
-   kunmap_atomic(reg_state);
-
return 0;
 }
 
@@ -985,7 +980,31 @@ int logical_ring_flush_all_caches(struct 
drm_i915_gem_request *req)
return 0;
 }
 
-static int intel_lr_context_do_pin(struct intel_engine_cs *ring,
+static int intel_mmap_hw_context(struct drm_i915_gem_object *obj,
+   bool unmap)
+{
+   int ret = 0;
+   struct intel_context_engine *ice =
+   (struct intel_context_engine *)obj->mappable;
+   struct page *page;
+   uint32_t *reg_state;
+
+   if (unmap) {
+   kunmap(ice->page);
+   ice->reg_state = NULL;
+   ice->page = NULL;
+   } else {
+   page = i915_gem_object_get_page(obj, LRC_STATE_PN);
+   reg_state = kmap(page);
+   ice->reg_state = reg_state;
+  

[Intel-gfx] [PATCH 0/6] lrc lifecycle cleanups

2015-10-20 Thread Nick Hoath
These changes are a result of the requests made in VIZ-4277.
Make the lrc path more like the legacy submission path.
Attach the CPU mappings to vma (un)bind, so that the shrinker
also cleans those up.
Pin the CPU mappings while context is busy (pending requests), so
that the mappings aren't released/made continuously as this is
an expensive process.

V2: Removed unecessary changes in the lrc retiring code path
Removed unecessary map/unmap

Nick Hoath (6):
  drm/i195: Rename gt_irq_handler variable
  drm/i915: Break out common code from gen8_gt_irq_handler
  drm/i915: Unify execlist and legacy request life-cycles
  drm/i915: Improve dynamic management/eviction of lrc backing objects
  drm/i915: Add the CPU mapping of the hw context to the  pinned
items.
  drm/i915: Only update ringbuf address when necessary

 drivers/gpu/drm/i915/i915_debugfs.c |  14 ++--
 drivers/gpu/drm/i915/i915_drv.h |  10 ++-
 drivers/gpu/drm/i915/i915_gem.c |  26 +++
 drivers/gpu/drm/i915/i915_gem_gtt.c |   8 +++
 drivers/gpu/drm/i915/i915_irq.c |  67 -
 drivers/gpu/drm/i915/intel_lrc.c| 123 +---
 drivers/gpu/drm/i915/intel_lrc.h|   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  71 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |   4 --
 9 files changed, 173 insertions(+), 152 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/6] drm/i915: Unify execlist and legacy request life-cycles

2015-10-20 Thread Chris Wilson
On Tue, Oct 20, 2015 at 10:23:53AM +0100, Nick Hoath wrote:
> There is a desire to simplify the i915 driver by reducing the number of
> different code paths introduced by the LRC / execlists support.  As the
> execlists request is now part of the gem request it is possible and
> desirable to unify the request life-cycles for execlist and legacy
> requests.
> 
> A request is considered retireable if its seqno passed (i.e. the request
> has completed) and either it was never submitted to the ELSP or its
> context completed.  This ensures that context save is carried out before
> the last request for a context is considered retireable. request_complete()
> now checks the elsp_submitted count when deciding if a request is complete.
> Requests that were not waiting for a context
> switch interrupt (either as a result of being merged into a following
> request or by being a legacy request) will be considered retireable as
> soon as their seqno has passed.
> 
> Removed the extra request reference held for the execlist request.
> 
> Removed intel_execlists_retire_requests() and all references to
> intel_engine_cs.execlist_retired_req_list.
> 
> Changed gen8_cs_irq_handler() so that notify_ring() is called when
> contexts complete as well as when a user interrupt occurs so that
> notification happens when a request is complete and context save has
> finished.
> 
> v2: Rebase over the read-read optimisation changes
> 
> v3: Reworked IRQ handler after removing IRQ handler cleanup patch
> 
> v4: Fixed various pin leaks
> 
> v5: Removed ctx_complete flag & associated changes. Removed extraneous
>   request pin of context.
>   (Chris Wilson/Daniel Vetter)
> 
> Issue: VIZ-4277
> Signed-off-by: Thomas Daniel 
> Signed-off-by: Nick Hoath 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/i915_gem.c | 23 -
>  drivers/gpu/drm/i915/i915_irq.c |  7 ++---
>  drivers/gpu/drm/i915/intel_lrc.c| 45 
> -
>  drivers/gpu/drm/i915/intel_lrc.h|  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
>  6 files changed, 21 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8afda45..ae08e57 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2914,7 +2914,7 @@ static inline bool i915_gem_request_completed(struct 
> drm_i915_gem_request *req,
>  
>   seqno = req->ring->get_seqno(req->ring, lazy_coherency);
>  
> - return i915_seqno_passed(seqno, req->seqno);
> + return i915_seqno_passed(seqno, req->seqno) && !req->elsp_submitted;
>  }
>  
>  int __must_check i915_gem_get_seqno(struct drm_device *dev, u32 *seqno);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e57061a..290a1ac 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2848,12 +2848,16 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
> *ring)
>  
>   if (!list_empty(&obj->last_read_req[ring->id]->list))
>   break;
> + if (!i915_gem_request_completed(obj->last_read_req[ring->id],
> + true))
> + break;

What No. request_completed is and should only ever be has the seqno
passed.
-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 4/6] drm/i915: Improve dynamic management/eviction of lrc backing objects

2015-10-20 Thread Chris Wilson
On Tue, Oct 20, 2015 at 10:23:54AM +0100, Nick Hoath wrote:
> Shovel all context related objects through the active queue and obj
> management.
> 
> - Added callback in vma_(un)bind to add CPU (un)mapping at same time
>   if desired
> - Inserted LRC hw context & ringbuf to vma active list
> 
> Issue: VIZ-4277
> Signed-off-by: Nick Hoath 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  4 ++
>  drivers/gpu/drm/i915/i915_gem.c |  3 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  8 
>  drivers/gpu/drm/i915/intel_lrc.c| 28 +++--
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 71 
> ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  3 --
>  6 files changed, 79 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ae08e57..0dd4ace 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2161,6 +2161,10 @@ struct drm_i915_gem_object {
>   struct work_struct *work;
>   } userptr;
>   };
> +
> + /** Support for automatic CPU side mapping of object */
> + int (*mmap)(struct drm_i915_gem_object *obj, bool unmap);
> + void *mappable;
>  };
>  #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 290a1ac..8bd318a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3222,6 +3222,9 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
> wait)
>   if (vma->pin_count)
>   return -EBUSY;
>  
> + if (obj->mmap)
> + obj->mmap(obj, true);

This is not a per-obj callback.
-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 5/6] drm/i915: Add the CPU mapping of the hw context to the pinned items.

2015-10-20 Thread Chris Wilson
On Tue, Oct 20, 2015 at 10:23:55AM +0100, Nick Hoath wrote:
> Pin the hw ctx mapping so that it is not mapped/unmapped per bb
> when doing GuC submission.
> 
> v2: Removed interim development extra mapping. (Daniel Vetter)

You've missed the point here. I've shown how to do kmapping once neatly,
what you need the unbind callback for is to amoritize the cost of the
ioremap.
-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] [v3] drm/i915/skl: If needed sanitize bios programmed cdclk

2015-10-20 Thread Kumar, Shobhit

On 10/19/2015 07:18 PM, Ville Syrjälä wrote:

On Fri, Oct 16, 2015 at 06:48:53PM +0530, Shobhit Kumar wrote:

Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.

v2: Check if BIOS programmed correctly rather than always calling init
 - Do validation of programmed cdctl and what it is expected
 - Only do slk_init_cdclk if validation failed else reuse BIOS
   programmed value

v3: Move the validation logic in a separate sanitize function (Ville)

Cc: Imre Deak 
Cc: Ville Syrjälä 
Signed-off-by: Shobhit Kumar 
---
  drivers/gpu/drm/i915/intel_ddi.c | 12 
  drivers/gpu/drm/i915/intel_display.c | 31 +++
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b25e99a..86d43e6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2949,10 +2949,14 @@ void intel_ddi_pll_init(struct drm_device *dev)

cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
-   else
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+   if (skl_sanitize_cdclk(dev_priv))
+   DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
+   else {
+   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
+   DRM_ERROR("LCPLL1 is disabled\n");


Since skl_sanitize_cdclk() will enable the PLL this shouldn't
happen anymore, right?



Yeah right. Will remove.


+   else
+   intel_display_power_get(dev_priv, 
POWER_DOMAIN_PLLS);
+   }
} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f37f84..98333d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5784,6 +5784,37 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
DRM_ERROR("DBuf power enable timeout\n");
  }

+int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
+{
+   uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
+   uint32_t cdctl = I915_READ(CDCLK_CTL);
+   int freq = dev_priv->skl_boot_cdclk;
+
+   /* Is PLL enabled and locked ? */
+   if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 & LCPLL_PLL_LOCK)))
+   goto sanitize;
+
+   /* DPLL okay; verify the cdclock
+*
+* Noticed in some instances that the freq selection is correct but
+* decimal part is programmed wrong from BIOS where pre-os does not
+* enable display. Verify the same as well.
+*/
+   if (cdctl == ((cdctl & CDCLK_FREQ_SEL_MASK) | skl_cdclk_decimal(freq)))
+   /* All well; nothing to sanitize */
+   return false;
+sanitize:
+   /*
+* As of now initialize with max cdclk till
+* we get dynamic cdclk support
+* */
+   dev_priv->skl_boot_cdclk = 675000;


Should be '= dev_priv->max_cdclk'

I think we end up doing the intel_update_cdclk() before this gets
called, so max_cdclk should already contain something sensible. The
whole init sequence is a bit messy currently, but I think we can put
off cleaning it up after the dc6 stuff gets sorted.



Actually at the end of skl_init_cdclock, intel_update_cdclk will be 
called and initialize the max_cdclk correctly. In case there was no 
sanitization needed, the BIOS programmed cdclk is stored in 
skl_boot_cdclk and that is used inside the skl_init_cdclk. Same is 
invoked resume time, so we need to update this variable or else change 
the logic.



+   skl_init_cdclk(dev_priv);
+
+   /* we did have to sanitize */
+   return true;
+}
+
  /* Adjust CDclk dividers to allow high res or save power if possible */
  static void valleyview_set_cdclk(struct drm_device *dev, int cdclk)
  {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0598932..ec10e6a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1152,6 +1152,7 @@ void broxton_ddi_phy_uninit(struct drm_device *dev);
  void bxt_enable_dc9(struct drm_i915_private *dev_priv);
  void bxt_disable_dc9(struct drm_i915_private *dev_priv);
  void skl_init_cdclk(struct drm_i915_private *dev_priv);
+int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
  void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
  void intel_dp_get_m_n(struct intel_crtc *crtc,

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Improve dynamic management/eviction of lrc backing objects

2015-10-20 Thread kbuild test robot
Hi Nick,

[auto build test WARNING on next-20151020 -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Nick-Hoath/lrc-lifecycle-cleanups/20151020-173347
config: i386-randconfig-x009-10191220 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'i915_vma_bind':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:3523:4: warning: ignoring return value 
>> of 'i915_vma_unbind', declared with attribute warn_unused_result 
>> [-Wunused-result]
   i915_vma_unbind(vma);
   ^

vim +/i915_vma_unbind +3523 drivers/gpu/drm/i915/i915_gem_gtt.c

  3507   vma->node.start,
  3508   vma->node.size);
  3509  vma->pin_count--;
  3510  if (ret)
  3511  return ret;
  3512  }
  3513  
  3514  ret = vma->vm->bind_vma(vma, cache_level, bind_flags);
  3515  if (ret)
  3516  return ret;
  3517  
  3518  vma->bound |= bind_flags;
  3519  
  3520  if (vma->obj->mmap) {
  3521  ret = vma->obj->mmap(vma->obj, false);
  3522  if (ret) {
> 3523  i915_vma_unbind(vma);
  3524  return ret;
  3525  }
  3526  }
  3527  
  3528  return 0;
  3529  }
  3530  
  3531  /**

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Allow minimum brightness upon backlight enable

2015-10-20 Thread Jani Nikula
On Fri, 02 Oct 2015, Chris Wilson  wrote:
> On Fri, Oct 02, 2015 at 10:50:50AM +0300, Jani Nikula wrote:
>> On Fri, 02 Oct 2015, clinton.a.tay...@intel.com wrote:
>> > From: Clint Taylor 
>> >
>> > backlight minimum is a valid value so you don't need to set maximum.
>> >
>> > Signed-off-by: Clint Taylor 
>> > ---
>> >  drivers/gpu/drm/i915/intel_panel.c |2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>> > b/drivers/gpu/drm/i915/intel_panel.c
>> > index 4d28c7b..d509904 100644
>> > --- a/drivers/gpu/drm/i915/intel_panel.c
>> > +++ b/drivers/gpu/drm/i915/intel_panel.c
>> > @@ -1069,7 +1069,7 @@ void intel_panel_enable_backlight(struct 
>> > intel_connector *connector)
>> >  
>> >WARN_ON(panel->backlight.max == 0);
>> >  
>> > -  if (panel->backlight.level <= panel->backlight.min) {
>> > +  if (panel->backlight.level < panel->backlight.min) {
>> >panel->backlight.level = panel->backlight.max;
>> >if (panel->backlight.device)
>> >panel->backlight.device->props.brightness =
>> 
>> This is policy in action in the kernel. We have this whole if block here
>> because some, uh, misguided userspace sets brightness to minimum before
>> switching the backlight off, and assumes enabling backlight cranks up
>> the brightness as well. (*)
>
> If you mean X, no. It has to set the backlight because on some intel
> models the backlight is not routed through i915 and so it needs to
> explicitly control it. On resume, it sets the previous value. This is
> just a broken kernel.

Okay, I guess I'm willing to give this a shot. This may result in
regression reports, but let's see.

However, the meaning of the whole check changes. What Clint now checks
(level below minimum) shouldn't happen, something failed already. Maybe
we should set the level to minimum instead, with debug logging?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
> 
> On 20/10/15 08:42, Daniel Vetter wrote:
> > On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
> >> On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin 
> >>>
> >>> Previously rotation was ignored and wrong stride programmed
> >>> into the plane registers resulting in a corrupt image on screen.
> >>>
> >>> Signed-off-by: Tvrtko Ursulin 
> >>> Cc: Sonika Jindal 
> >>> ---
> >>>   drivers/gpu/drm/i915/intel_display.c | 16 
> >>>   1 file changed, 12 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index 539c3737e823..6328788193e4 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
> >>> *intel_crtc)
> >>>   {
> >>>   struct drm_device *dev = intel_crtc->base.dev;
> >>>   struct drm_i915_private *dev_priv = dev->dev_private;
> >>> + struct drm_plane *plane = intel_crtc->base.primary;
> >>>   struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
> >>>   const enum pipe pipe = intel_crtc->pipe;
> >>> - u32 ctl, stride;
> >>> + u32 ctl, stride, tile_height;
> >>>
> >>>   ctl = I915_READ(PLANE_CTL(pipe, 0));
> >>>   ctl &= ~PLANE_CTL_TILED_MASK;
> >>> @@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
> >>> *intel_crtc)
> >>>* The stride is either expressed as a multiple of 64 bytes 
> >>> chunks for
> >>>* linear buffers or in number of tiles for tiled buffers.
> >>>*/
> >>> - stride = fb->pitches[0] /
> >>> -  intel_fb_stride_alignment(dev, fb->modifier[0],
> >>> -fb->pixel_format);
> >>> + if (intel_rotation_90_or_270(plane->state->rotation)) {
> >>> + /* stride = Surface height in tiles */
> >>> + tile_height = intel_tile_height(dev, fb->pixel_format,
> >>> + fb->modifier[0], 0);
> >>> + stride = DIV_ROUND_UP(fb->height, tile_height);
> >>> + } else {
> >>> + stride = fb->pitches[0] /
> >>> + intel_fb_stride_alignment(dev, fb->modifier[0],
> >>> +   fb->pixel_format);
> >>> + }
> >>
> >> I was wondering why we are allowing stride changes during page flip, but
> >> after looking at the history it seems we are not. The reason for
> >> updating the stride register is the fact that the units we specify it
> >> in change between different tiling modes on SKL+. We still reject actual
> >> stride changes during page flip, which is good because allowing it would
> >> cause problems for my fb->offsets[] stuff since the interpretation of the
> >> linear offset would change with the stride.
> >>
> >> We do allow changes to the rotated stride though since we don't reject
> >> changes to the fb height. I think I need to draw some pictures before I
> >> can say for sure whether that can cause problems or not. But we ca
> >> leave that for another patch if it turns out to need handling.
> >>
> >> One thing that's dodgy here is the plane->state->rotation check. I
> >> think currently we wait for pending flips during the atomic commit
> >> phase after we've swapped the state. So this may end up using the
> >> wrong rotation setting. It would be an even bigger problem if we
> >> already allowed queueing up or replaceing pending plane updates. I
> >> suppose the primary->fb thing doesn't suffer from this problem because
> >> we swap that pointer only after we've waited for pending flips.
> >
> > Current rule is that pageflip doesn't allow any change in any metadata.
> > There's some minor exception that on some platforms we can change the
> > tiling because someone asked for that specifically and it's possible.
> >
> > atomic flips will be able to cope with this. But for legacy pageflips imo
> > reject everything aggressively that changes metadata (stride, tiling,
> > rotation).
> 
> I am not sure what is the conclusion. To re-iterate, idea is not to 
> allow rotation changes between page flips, just to program PLANE_STRIDE 
> accordingly, when rotation is already enabled. Since otherwise page flip 
> will calculate it incorrectly.
> 
> I though Ville was raising two concerns:
> 
> 1. Will the plane state be swapped from under the pending page flips 
> prematurely?

The answer is yes.

> 
> 2. Do we need to program the stride in page flips at all?

Yes, on SKL+. Because we allow tiling changes. We've always allowed that
because CS flips allow it as well. And IIRC we even had some specific
user for that since someone noticed that it didn't actually work on VLV.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.free

Re: [Intel-gfx] [v3] drm/i915/skl: If needed sanitize bios programmed cdclk

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 03:27:24PM +0530, Kumar, Shobhit wrote:
> On 10/19/2015 07:18 PM, Ville Syrjälä wrote:
> > On Fri, Oct 16, 2015 at 06:48:53PM +0530, Shobhit Kumar wrote:
> >> Especially in cases where pre-os does not enable display, cdclk might
> >> not be in sane state. During sanitization initialize cdclk with maximum
> >> value till we get dynamic cdclk support.
> >>
> >> v2: Check if BIOS programmed correctly rather than always calling init
> >>  - Do validation of programmed cdctl and what it is expected
> >>  - Only do slk_init_cdclk if validation failed else reuse BIOS
> >>programmed value
> >>
> >> v3: Move the validation logic in a separate sanitize function (Ville)
> >>
> >> Cc: Imre Deak 
> >> Cc: Ville Syrjälä 
> >> Signed-off-by: Shobhit Kumar 
> >> ---
> >>   drivers/gpu/drm/i915/intel_ddi.c | 12 
> >>   drivers/gpu/drm/i915/intel_display.c | 31 +++
> >>   drivers/gpu/drm/i915/intel_drv.h |  1 +
> >>   3 files changed, 40 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index b25e99a..86d43e6 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2949,10 +2949,14 @@ void intel_ddi_pll_init(struct drm_device *dev)
> >>
> >>cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
> >>dev_priv->skl_boot_cdclk = cdclk_freq;
> >> -  if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> >> -  DRM_ERROR("LCPLL1 is disabled\n");
> >> -  else
> >> -  intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> >> +  if (skl_sanitize_cdclk(dev_priv))
> >> +  DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
> >> +  else {
> >> +  if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> >> +  DRM_ERROR("LCPLL1 is disabled\n");
> >
> > Since skl_sanitize_cdclk() will enable the PLL this shouldn't
> > happen anymore, right?
> >
> 
> Yeah right. Will remove.
> 
> >> +  else
> >> +  intel_display_power_get(dev_priv, 
> >> POWER_DOMAIN_PLLS);
> >> +  }
> >>} else if (IS_BROXTON(dev)) {
> >>broxton_init_cdclk(dev);
> >>broxton_ddi_phy_init(dev);
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 5f37f84..98333d3 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -5784,6 +5784,37 @@ void skl_init_cdclk(struct drm_i915_private 
> >> *dev_priv)
> >>DRM_ERROR("DBuf power enable timeout\n");
> >>   }
> >>
> >> +int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> >> +{
> >> +  uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
> >> +  uint32_t cdctl = I915_READ(CDCLK_CTL);
> >> +  int freq = dev_priv->skl_boot_cdclk;
> >> +
> >> +  /* Is PLL enabled and locked ? */
> >> +  if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 & LCPLL_PLL_LOCK)))
> >> +  goto sanitize;
> >> +
> >> +  /* DPLL okay; verify the cdclock
> >> +   *
> >> +   * Noticed in some instances that the freq selection is correct but
> >> +   * decimal part is programmed wrong from BIOS where pre-os does not
> >> +   * enable display. Verify the same as well.
> >> +   */
> >> +  if (cdctl == ((cdctl & CDCLK_FREQ_SEL_MASK) | skl_cdclk_decimal(freq)))
> >> +  /* All well; nothing to sanitize */
> >> +  return false;
> >> +sanitize:
> >> +  /*
> >> +   * As of now initialize with max cdclk till
> >> +   * we get dynamic cdclk support
> >> +   * */
> >> +  dev_priv->skl_boot_cdclk = 675000;
> >
> > Should be '= dev_priv->max_cdclk'
> >
> > I think we end up doing the intel_update_cdclk() before this gets
> > called, so max_cdclk should already contain something sensible. The
> > whole init sequence is a bit messy currently, but I think we can put
> > off cleaning it up after the dc6 stuff gets sorted.
> >
> 
> Actually at the end of skl_init_cdclock, intel_update_cdclk will be 
> called and initialize the max_cdclk correctly.

It gets called already earlier from intel_modeset_init().

> In case there was no 
> sanitization needed, the BIOS programmed cdclk is stored in 
> skl_boot_cdclk and that is used inside the skl_init_cdclk. Same is 
> invoked resume time, so we need to update this variable or else change 
> the logic.
> 
> >> +  skl_init_cdclk(dev_priv);
> >> +
> >> +  /* we did have to sanitize */
> >> +  return true;
> >> +}
> >> +
> >>   /* Adjust CDclk dividers to allow high res or save power if possible */
> >>   static void valleyview_set_cdclk(struct drm_device *dev, int cdclk)
> >>   {
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index 0598932..ec10e6a 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i91

Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Tvrtko Ursulin


On 20/10/15 12:07, Ville Syrjälä wrote:

On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:


On 20/10/15 08:42, Daniel Vetter wrote:

On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:

On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

Signed-off-by: Tvrtko Ursulin 
Cc: Sonika Jindal 
---
   drivers/gpu/drm/i915/intel_display.c | 16 
   1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 539c3737e823..6328788193e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
   {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane *plane = intel_crtc->base.primary;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride;
+   u32 ctl, stride, tile_height;

ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 * The stride is either expressed as a multiple of 64 bytes chunks for
 * linear buffers or in number of tiles for tiled buffers.
 */
-   stride = fb->pitches[0] /
-intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+   if (intel_rotation_90_or_270(plane->state->rotation)) {
+   /* stride = Surface height in tiles */
+   tile_height = intel_tile_height(dev, fb->pixel_format,
+   fb->modifier[0], 0);
+   stride = DIV_ROUND_UP(fb->height, tile_height);
+   } else {
+   stride = fb->pitches[0] /
+   intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+   }


I was wondering why we are allowing stride changes during page flip, but
after looking at the history it seems we are not. The reason for
updating the stride register is the fact that the units we specify it
in change between different tiling modes on SKL+. We still reject actual
stride changes during page flip, which is good because allowing it would
cause problems for my fb->offsets[] stuff since the interpretation of the
linear offset would change with the stride.

We do allow changes to the rotated stride though since we don't reject
changes to the fb height. I think I need to draw some pictures before I
can say for sure whether that can cause problems or not. But we ca
leave that for another patch if it turns out to need handling.

One thing that's dodgy here is the plane->state->rotation check. I
think currently we wait for pending flips during the atomic commit
phase after we've swapped the state. So this may end up using the
wrong rotation setting. It would be an even bigger problem if we
already allowed queueing up or replaceing pending plane updates. I
suppose the primary->fb thing doesn't suffer from this problem because
we swap that pointer only after we've waited for pending flips.


Current rule is that pageflip doesn't allow any change in any metadata.
There's some minor exception that on some platforms we can change the
tiling because someone asked for that specifically and it's possible.

atomic flips will be able to cope with this. But for legacy pageflips imo
reject everything aggressively that changes metadata (stride, tiling,
rotation).


I am not sure what is the conclusion. To re-iterate, idea is not to
allow rotation changes between page flips, just to program PLANE_STRIDE
accordingly, when rotation is already enabled. Since otherwise page flip
will calculate it incorrectly.

I though Ville was raising two concerns:

1. Will the plane state be swapped from under the pending page flips
prematurely?


The answer is yes.


And is that OK? Would it not make more sense to wait for pending flips 
and then swap state?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 12:44:05PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/10/15 12:07, Ville Syrjälä wrote:
> > On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 20/10/15 08:42, Daniel Vetter wrote:
> >>> On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
>  On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> >
> > Previously rotation was ignored and wrong stride programmed
> > into the plane registers resulting in a corrupt image on screen.
> >
> > Signed-off-by: Tvrtko Ursulin 
> > Cc: Sonika Jindal 
> > ---
> >drivers/gpu/drm/i915/intel_display.c | 16 
> >1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 539c3737e823..6328788193e4 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
> > *intel_crtc)
> >{
> > struct drm_device *dev = intel_crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > +   struct drm_plane *plane = intel_crtc->base.primary;
> > struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
> > const enum pipe pipe = intel_crtc->pipe;
> > -   u32 ctl, stride;
> > +   u32 ctl, stride, tile_height;
> >
> > ctl = I915_READ(PLANE_CTL(pipe, 0));
> > ctl &= ~PLANE_CTL_TILED_MASK;
> > @@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
> > *intel_crtc)
> >  * The stride is either expressed as a multiple of 64 bytes 
> > chunks for
> >  * linear buffers or in number of tiles for tiled buffers.
> >  */
> > -   stride = fb->pitches[0] /
> > -intel_fb_stride_alignment(dev, fb->modifier[0],
> > -  fb->pixel_format);
> > +   if (intel_rotation_90_or_270(plane->state->rotation)) {
> > +   /* stride = Surface height in tiles */
> > +   tile_height = intel_tile_height(dev, fb->pixel_format,
> > +   fb->modifier[0], 0);
> > +   stride = DIV_ROUND_UP(fb->height, tile_height);
> > +   } else {
> > +   stride = fb->pitches[0] /
> > +   intel_fb_stride_alignment(dev, 
> > fb->modifier[0],
> > + 
> > fb->pixel_format);
> > +   }
> 
>  I was wondering why we are allowing stride changes during page flip, but
>  after looking at the history it seems we are not. The reason for
>  updating the stride register is the fact that the units we specify it
>  in change between different tiling modes on SKL+. We still reject actual
>  stride changes during page flip, which is good because allowing it would
>  cause problems for my fb->offsets[] stuff since the interpretation of the
>  linear offset would change with the stride.
> 
>  We do allow changes to the rotated stride though since we don't reject
>  changes to the fb height. I think I need to draw some pictures before I
>  can say for sure whether that can cause problems or not. But we ca
>  leave that for another patch if it turns out to need handling.
> 
>  One thing that's dodgy here is the plane->state->rotation check. I
>  think currently we wait for pending flips during the atomic commit
>  phase after we've swapped the state. So this may end up using the
>  wrong rotation setting. It would be an even bigger problem if we
>  already allowed queueing up or replaceing pending plane updates. I
>  suppose the primary->fb thing doesn't suffer from this problem because
>  we swap that pointer only after we've waited for pending flips.
> >>>
> >>> Current rule is that pageflip doesn't allow any change in any metadata.
> >>> There's some minor exception that on some platforms we can change the
> >>> tiling because someone asked for that specifically and it's possible.
> >>>
> >>> atomic flips will be able to cope with this. But for legacy pageflips imo
> >>> reject everything aggressively that changes metadata (stride, tiling,
> >>> rotation).
> >>
> >> I am not sure what is the conclusion. To re-iterate, idea is not to
> >> allow rotation changes between page flips, just to program PLANE_STRIDE
> >> accordingly, when rotation is already enabled. Since otherwise page flip
> >> will calculate it incorrectly.
> >>
> >> I though Ville was raising two concerns:
> >>
> >> 1. Will the plane state be swapped from under the pending page flips
> >> prematurely?
> >
> > The answer is y

Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Tvrtko Ursulin


On 20/10/15 12:53, Ville Syrjälä wrote:

On Tue, Oct 20, 2015 at 12:44:05PM +0100, Tvrtko Ursulin wrote:


On 20/10/15 12:07, Ville Syrjälä wrote:

On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:


On 20/10/15 08:42, Daniel Vetter wrote:

On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:

On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

Signed-off-by: Tvrtko Ursulin 
Cc: Sonika Jindal 
---
drivers/gpu/drm/i915/intel_display.c | 16 
1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 539c3737e823..6328788193e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
{
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane *plane = intel_crtc->base.primary;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride;
+   u32 ctl, stride, tile_height;

ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc)
 * The stride is either expressed as a multiple of 64 bytes chunks for
 * linear buffers or in number of tiles for tiled buffers.
 */
-   stride = fb->pitches[0] /
-intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+   if (intel_rotation_90_or_270(plane->state->rotation)) {
+   /* stride = Surface height in tiles */
+   tile_height = intel_tile_height(dev, fb->pixel_format,
+   fb->modifier[0], 0);
+   stride = DIV_ROUND_UP(fb->height, tile_height);
+   } else {
+   stride = fb->pitches[0] /
+   intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+   }


I was wondering why we are allowing stride changes during page flip, but
after looking at the history it seems we are not. The reason for
updating the stride register is the fact that the units we specify it
in change between different tiling modes on SKL+. We still reject actual
stride changes during page flip, which is good because allowing it would
cause problems for my fb->offsets[] stuff since the interpretation of the
linear offset would change with the stride.

We do allow changes to the rotated stride though since we don't reject
changes to the fb height. I think I need to draw some pictures before I
can say for sure whether that can cause problems or not. But we ca
leave that for another patch if it turns out to need handling.

One thing that's dodgy here is the plane->state->rotation check. I
think currently we wait for pending flips during the atomic commit
phase after we've swapped the state. So this may end up using the
wrong rotation setting. It would be an even bigger problem if we
already allowed queueing up or replaceing pending plane updates. I
suppose the primary->fb thing doesn't suffer from this problem because
we swap that pointer only after we've waited for pending flips.


Current rule is that pageflip doesn't allow any change in any metadata.
There's some minor exception that on some platforms we can change the
tiling because someone asked for that specifically and it's possible.

atomic flips will be able to cope with this. But for legacy pageflips imo
reject everything aggressively that changes metadata (stride, tiling,
rotation).


I am not sure what is the conclusion. To re-iterate, idea is not to
allow rotation changes between page flips, just to program PLANE_STRIDE
accordingly, when rotation is already enabled. Since otherwise page flip
will calculate it incorrectly.

I though Ville was raising two concerns:

1. Will the plane state be swapped from under the pending page flips
prematurely?


The answer is yes.


And is that OK?


No, we could misprogram the stride and corrupt the display.


Oh I did not mean that but if it is OK to replace the state under queued 
flips. Sounded like a bug to me but what do I know.



Would it not make more sense to wait for pending flips
and then swap state?


I think eventually we want to queue up multiple flips and/or allow
later flips to override previous ones, so consulting the current
state from the mmio flip is a not a good idea in any case. I would
just add work->rotation and populate it with a snapshot at the time
when the flip is queued.


Yes I can certainly do that if

Re: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

2015-10-20 Thread Sharma, Shashank
We have added two patches to optimize multiple commit calls, to address Gary's 
comment, using one additional flag in CRTC state. 
We have tested this, and it's working for both Android and Linux. 

I am sending this new patch set now (v7), which has these two additional 
patches, in total 25 in count.
Please have a look. 

Regards
Shashank
-Original Message-
From: Sharma, Shashank 
Sent: Tuesday, October 20, 2015 1:46 PM
To: 'Daniel Vetter'; Smith, Gary K
Cc: Bish, Jim; dri-de...@lists.freedesktop.org; 
intel-gfx@lists.freedesktop.org; emil.l.veli...@gmail.com; Roper, Matthew D; 
Bradford, Robert; Matheson, Annie J; kausalmall...@gmail.com; Vetter, Daniel
Subject: RE: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
correction

Yes, please note that as per the discussion, the legacy gamma IOCTL is still 
existing, to maintain the backward compatibility, we have not broken it. 
And we have added provision to program legacy-8bit gamma via color manager 
also, so everyone should be happy :)

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, October 20, 2015 12:58 PM
To: Smith, Gary K
Cc: Daniel Vetter; Bish, Jim; Sharma, Shashank; 
dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; 
emil.l.veli...@gmail.com; Roper, Matthew D; Bradford, Robert; Matheson, Annie 
J; kausalmall...@gmail.com; Vetter, Daniel
Subject: Re: [Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
correction

On Mon, Oct 19, 2015 at 10:27:17PM +, Smith, Gary K wrote:
> Unless legacy mode enables it of course.

I thought we decided to ignore legacy gamma stuff (at least for now, until 
someone complains about the inconsistency). So yeah, I think we're fine.
-Daniel

> 
> Thanks
> Gary
> 
> 
> "Smith, Gary K"  wrote:
> 
> Bear in mind that it will only happen after the property has been set. 
> Initially there will be no clients setting the property - so I think it 
> should be OK.
> 
> Thanks
> Gary
> 
> 
> Daniel Vetter  wrote:
> 
> On Mon, Oct 19, 2015 at 08:39:54PM +, Bish, Jim wrote:
> >
> >
> > On 10/19/2015 11:54 AM, Daniel Vetter wrote:
> > > On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote:
> > >> FYI - this shouldn't block the commits, but should be optimized later 
> > >> (fairly soon).
> > >>
> > >> I believe the current implementation ends up executing
> > >> while (count < CHV_DEGAMMA_MAX_VALS) {
> > >> // Do lots of caclulation
> > >> I915_WRITE(cgm_degamma_reg, word); Every 
> > >> frame after you set the property, whether you change the contents of the 
> > >> blob or not. Clearly this is really inefficient when there are 100s of 
> > >> gamma values to write.
> > >> Same with the Gamma and CTM. CTM is less of an issue with only 9 entries.
> > >>
> > >> My suggestion here is to set a boolean when the property has been 
> > >> set as part of a flip and only apply it on the atomic commit 
> > >> after the update was received.
> > >
> > > Yeah the usual design is to add a foo_changed boolean (or bitmask, e.g.
> > > for changed planes tracked in the crtc_state) in the state where 
> > > we need to commit the update. That /should/ be there really, 
> > > didn't ever realize it's not done. Note that that for legacy 
> > > cursors we update them without waiting for vblanks and legacy 
> > > userspace does that a _lot_ (*cough* X server *cough*), if the 
> > > overhead is severe this might be a problem and needs to be fixed before 
> > > merging.
> > >
> > > -Daniel
> > Severe enough to block? I wanted to get this closed out this week but...
> > I see your point Gary but need a reading on Daniel's last sentence.
> 
> X server doing silly amounts of setcursor calls is a known issue that 
> has bitten us in the past (with people complaining about seriously 
> sluggish desktops). Just needs to be tested, and depending upon 
> results either fixed before or after merging. I hope we can get away 
> with fixing up post-merge. But writing a few kb through mmio for each 
> cursor is a lot, so it might show up in real world.
> -Daniel
> 
> >
> > Jim
> > >
> > >>
> > >> Thanks
> > >> Gary
> > >>
> > >> -Original Message-
> > >> From: Sharma, Shashank
> > >> Sent: Friday, October 16, 2015 3:29 PM
> > >> To: dri-de...@lists.freedesktop.org; 
> > >> intel-gfx@lists.freedesktop.org; emil.l.veli...@gmail.com; Roper, 
> > >> Matthew D; Bradford, Robert; Bish, Jim
> > >> Cc: Matheson, Annie J; kausalmall...@gmail.com; Kumar, Kiran S; 
> > >> Smith, Gary K; Vetter, Daniel; Mukherjee, Indranil; Palleti, 
> > >> Avinash Reddy; Sharma, Shashank
> > >> Subject: [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma 
> > >> correction
> > >>
> > >> CHV/BSW supports Degamma color correction, which linearizes all the 
> > >> non-linear color values. This will be applied before Color 
> > >> Transformation.
> > >>
> > >> This patch does the follow

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Break out common code from gen8_gt_irq_handler

2015-10-20 Thread Daniel Vetter
On Tue, Oct 20, 2015 at 10:23:52AM +0100, Nick Hoath wrote:
> Break out common code from gen8_gt_irq_handler and put it in to
> an always inlined function. gcc optimises out the shift at compile
> time. (Thomas Daniel/Daniel Vetter/Chris Wilson)
> 
> Issue: VIZ-4277
> Signed-off-by: Nick Hoath 
> Cc: Thomas Daniel 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 

Merged the first two patches to dinq, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 40 
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index fbf9153..7837f5e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1290,6 +1290,16 @@ static void snb_gt_irq_handler(struct drm_device *dev,
>   ivybridge_parity_error_irq_handler(dev, gt_iir);
>  }
>  
> +static __always_inline void
> + gen8_cs_irq_handler(struct intel_engine_cs *ring, u32 iir,
> + int test_shift)
> +{
> + if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
> + notify_ring(ring);
> + if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
> + intel_lrc_irq_handler(ring);
> +}
> +
>  static irqreturn_t gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
>  u32 master_ctl)
>  {
> @@ -1301,15 +1311,11 @@ static irqreturn_t gen8_gt_irq_handler(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE_FW(GEN8_GT_IIR(0), iir);
>   ret = IRQ_HANDLED;
>  
> - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
> GEN8_RCS_IRQ_SHIFT))
> - intel_lrc_irq_handler(&dev_priv->ring[RCS]);
> - if (iir & (GT_RENDER_USER_INTERRUPT << 
> GEN8_RCS_IRQ_SHIFT))
> - notify_ring(&dev_priv->ring[RCS]);
> + gen8_cs_irq_handler(&dev_priv->ring[RCS],
> + iir, GEN8_RCS_IRQ_SHIFT);
>  
> - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
> GEN8_BCS_IRQ_SHIFT))
> - intel_lrc_irq_handler(&dev_priv->ring[BCS]);
> - if (iir & (GT_RENDER_USER_INTERRUPT << 
> GEN8_BCS_IRQ_SHIFT))
> - notify_ring(&dev_priv->ring[BCS]);
> + gen8_cs_irq_handler(&dev_priv->ring[BCS],
> + iir, GEN8_BCS_IRQ_SHIFT);
>   } else
>   DRM_ERROR("The master control interrupt lied (GT0)!\n");
>   }
> @@ -1320,15 +1326,11 @@ static irqreturn_t gen8_gt_irq_handler(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE_FW(GEN8_GT_IIR(1), iir);
>   ret = IRQ_HANDLED;
>  
> - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
> GEN8_VCS1_IRQ_SHIFT))
> - intel_lrc_irq_handler(&dev_priv->ring[VCS]);
> - if (iir & (GT_RENDER_USER_INTERRUPT << 
> GEN8_VCS1_IRQ_SHIFT))
> - notify_ring(&dev_priv->ring[VCS]);
> + gen8_cs_irq_handler(&dev_priv->ring[VCS],
> + iir, GEN8_VCS1_IRQ_SHIFT);
>  
> - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
> GEN8_VCS2_IRQ_SHIFT))
> - intel_lrc_irq_handler(&dev_priv->ring[VCS2]);
> - if (iir & (GT_RENDER_USER_INTERRUPT << 
> GEN8_VCS2_IRQ_SHIFT))
> - notify_ring(&dev_priv->ring[VCS2]);
> + gen8_cs_irq_handler(&dev_priv->ring[VCS2],
> + iir, GEN8_VCS2_IRQ_SHIFT);
>   } else
>   DRM_ERROR("The master control interrupt lied (GT1)!\n");
>   }
> @@ -1339,10 +1341,8 @@ static irqreturn_t gen8_gt_irq_handler(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE_FW(GEN8_GT_IIR(3), iir);
>   ret = IRQ_HANDLED;
>  
> - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << 
> GEN8_VECS_IRQ_SHIFT))
> - intel_lrc_irq_handler(&dev_priv->ring[VECS]);
> - if (iir & (GT_RENDER_USER_INTERRUPT << 
> GEN8_VECS_IRQ_SHIFT))
> - notify_ring(&dev_priv->ring[VECS]);
> + gen8_cs_irq_handler(&dev_priv->ring[VECS],
> + iir, GEN8_VECS_IRQ_SHIFT);
>   } else
>   DRM_ERROR("The master control interrupt lied (GT3)!\n");
>   }
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 3/3] drm/i915: add helpers for platform specific revision id range checks

2015-10-20 Thread Jani Nikula
Revision checks are almost always accompanied by a platform check. (The
exceptions are platform specific code.) Add helpers to check for a
platform and a revision range: IS_SKL_REVID() and IS_BXT_REVID(). In
most places this simplifies and clarifies the code. It will be obvious
that revid macros are used for the correct platform.

This should make it easier to find all the revision checks for
workarounds for each platform, and make it easier to remove them once we
drop support for early hardware revisions.

This should also make it easier to differentiate between Skylake and
Kabylake revision checks when Kabylake support is added.

v2: rebase

Acked-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h| 13 +++
 drivers/gpu/drm/i915/i915_gem.c|  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  6 ++--
 drivers/gpu/drm/i915/intel_ddi.c   |  3 +-
 drivers/gpu/drm/i915/intel_dp.c|  4 +--
 drivers/gpu/drm/i915/intel_guc_loader.c|  4 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 26 +++---
 drivers/gpu/drm/i915/intel_pm.c| 15 
 drivers/gpu/drm/i915/intel_ringbuffer.c| 56 +-
 10 files changed, 68 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 28e71c32c0d5..48a742c5e00f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2432,6 +2432,15 @@ struct drm_i915_cmd_table {
 #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
 #define INTEL_REVID(p) (__I915__(p)->dev->pdev->revision)
 
+#define REVID_FOREVER  0xff
+/*
+ * Return true if revision is in range [since,until] inclusive.
+ *
+ * Use 0 for open-ended since, and REVID_FOREVER for open-ended until.
+ */
+#define IS_REVID(p, since, until) \
+   (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
+
 #define IS_I830(dev)   (INTEL_DEVID(dev) == 0x3577)
 #define IS_845G(dev)   (INTEL_DEVID(dev) == 0x2562)
 #define IS_I85X(dev)   (INTEL_INFO(dev)->is_i85x)
@@ -2500,11 +2509,15 @@ struct drm_i915_cmd_table {
 #define SKL_REVID_E0   0x4
 #define SKL_REVID_F0   0x5
 
+#define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p, since, 
until))
+
 #define BXT_REVID_A0   0x0
 #define BXT_REVID_A1   0x1
 #define BXT_REVID_B0   0x3
 #define BXT_REVID_C0   0x9
 
+#define IS_BXT_REVID(p, since, until) (IS_BROXTON(p) && IS_REVID(p, since, 
until))
+
 /*
  * The genX designation typically refers to the render engine, so render
  * capability related checks should use IS_GEN, while display and other checks
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 408ed6f8e33c..d0fa5481543c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3826,7 +3826,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
 * cacheline, whereas normally such cachelines would get
 * invalidated.
 */
-   if (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A1)
+   if (IS_BXT_REVID(dev, 0, BXT_REVID_A1))
return -ENODEV;
 
level = I915_CACHE_LLC;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 863aa5c82466..4bf9aa54c75e 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -161,9 +161,9 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
/* WaRsDisableCoarsePowerGating:skl,bxt */
if (!intel_enable_rc6(dev_priv->dev) ||
-   (IS_BROXTON(dev) && (INTEL_REVID(dev) <= BXT_REVID_A1)) ||
-   (IS_SKL_GT3(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)) ||
-   (IS_SKL_GT4(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
+   IS_BXT_REVID(dev, 0, BXT_REVID_A1) ||
+   (IS_SKL_GT3(dev) && IS_SKL_REVID(dev, 0, SKL_REVID_E0)) ||
+   (IS_SKL_GT4(dev) && IS_SKL_REVID(dev, 0, SKL_REVID_E0)))
data[1] = 0;
else
/* bit 0 and 1 are for Render and Media domain separately */
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b80e0f5ec5dc..7bcca708393d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3247,8 +3247,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
 * On BXT A0/A1, sw needs to activate DDIA HPD logic and
 * interrupts to check the external panel connection.
 */
-   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) <= BXT_REVID_A1)
-&& port == PORT_B)
+   if (IS_BXT_REVI

[Intel-gfx] [PATCH v2 1/3] drm/i915: remove parens around revision ids

2015-10-20 Thread Jani Nikula
Totally unnecessary.

Acked-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8afda459a26e..f222114981c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2493,16 +2493,16 @@ struct drm_i915_cmd_table {
 
 #define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
 
-#define SKL_REVID_A0   (0x0)
-#define SKL_REVID_B0   (0x1)
-#define SKL_REVID_C0   (0x2)
-#define SKL_REVID_D0   (0x3)
-#define SKL_REVID_E0   (0x4)
-#define SKL_REVID_F0   (0x5)
-
-#define BXT_REVID_A0   (0x0)
-#define BXT_REVID_B0   (0x3)
-#define BXT_REVID_C0   (0x9)
+#define SKL_REVID_A0   0x0
+#define SKL_REVID_B0   0x1
+#define SKL_REVID_C0   0x2
+#define SKL_REVID_D0   0x3
+#define SKL_REVID_E0   0x4
+#define SKL_REVID_F0   0x5
+
+#define BXT_REVID_A0   0x0
+#define BXT_REVID_B0   0x3
+#define BXT_REVID_C0   0x9
 
 /*
  * The genX designation typically refers to the render engine, so render
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 2/3] drm/i915/bxt: add revision id for A1 stepping and use it

2015-10-20 Thread Jani Nikula
Prefer inclusive ranges for revision checks rather than "below B0". Per
specs A2 is not used, so revid <= A1 matches revid < B0.

Acked-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h| 1 +
 drivers/gpu/drm/i915/i915_gem.c| 2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/intel_ddi.c   | 2 +-
 drivers/gpu/drm/i915/intel_dp.c| 2 +-
 drivers/gpu/drm/i915/intel_hdmi.c  | 2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 8 
 drivers/gpu/drm/i915/intel_pm.c| 6 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c| 6 +++---
 9 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f222114981c0..28e71c32c0d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2501,6 +2501,7 @@ struct drm_i915_cmd_table {
 #define SKL_REVID_F0   0x5
 
 #define BXT_REVID_A0   0x0
+#define BXT_REVID_A1   0x1
 #define BXT_REVID_B0   0x3
 #define BXT_REVID_C0   0x9
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e57061ac0219..408ed6f8e33c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3826,7 +3826,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
 * cacheline, whereas normally such cachelines would get
 * invalidated.
 */
-   if (IS_BROXTON(dev) && INTEL_REVID(dev) < BXT_REVID_B0)
+   if (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A1)
return -ENODEV;
 
level = I915_CACHE_LLC;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 036b42bae827..863aa5c82466 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -161,7 +161,7 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
/* WaRsDisableCoarsePowerGating:skl,bxt */
if (!intel_enable_rc6(dev_priv->dev) ||
-   (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+   (IS_BROXTON(dev) && (INTEL_REVID(dev) <= BXT_REVID_A1)) ||
(IS_SKL_GT3(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)) ||
(IS_SKL_GT4(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
data[1] = 0;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b25e99a432fb..b80e0f5ec5dc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3247,7 +3247,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
 * On BXT A0/A1, sw needs to activate DDIA HPD logic and
 * interrupts to check the external panel connection.
 */
-   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
+   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) <= BXT_REVID_A1)
 && port == PORT_B)
dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
else
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 09bdd94ca3ba..92413e5d215c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6087,7 +6087,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
break;
case PORT_B:
intel_encoder->hpd_pin = HPD_PORT_B;
-   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0))
+   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) <= BXT_REVID_A1))
intel_encoder->hpd_pin = HPD_PORT_A;
break;
case PORT_C:
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9eafa191cee2..35c6e211baf5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2039,7 +2039,7 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
 * On BXT A0/A1, sw needs to activate DDIA HPD logic and
 * interrupts to check the external panel connection.
 */
-   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0))
+   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) <= BXT_REVID_A1))
intel_encoder->hpd_pin = HPD_PORT_A;
else
intel_encoder->hpd_pin = HPD_PORT_B;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 88e12bdf79e2..0f5a1d63b51d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1972,7 +1972,7 @@ static int logical_render_ring_init(struct drm_

Re: [Intel-gfx] [PATCH] drm/i915: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 01:05:22PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/10/15 12:53, Ville Syrjälä wrote:
> > On Tue, Oct 20, 2015 at 12:44:05PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 20/10/15 12:07, Ville Syrjälä wrote:
> >>> On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
> 
>  On 20/10/15 08:42, Daniel Vetter wrote:
> > On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
> >> On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin 
> >>>
> >>> Previously rotation was ignored and wrong stride programmed
> >>> into the plane registers resulting in a corrupt image on screen.
> >>>
> >>> Signed-off-by: Tvrtko Ursulin 
> >>> Cc: Sonika Jindal 
> >>> ---
> >>> drivers/gpu/drm/i915/intel_display.c | 16 
> >>> 1 file changed, 12 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index 539c3737e823..6328788193e4 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -11126,9 +11126,10 @@ static void skl_do_mmio_flip(struct 
> >>> intel_crtc *intel_crtc)
> >>> {
> >>>   struct drm_device *dev = intel_crtc->base.dev;
> >>>   struct drm_i915_private *dev_priv = dev->dev_private;
> >>> + struct drm_plane *plane = intel_crtc->base.primary;
> >>>   struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
> >>>   const enum pipe pipe = intel_crtc->pipe;
> >>> - u32 ctl, stride;
> >>> + u32 ctl, stride, tile_height;
> >>>
> >>>   ctl = I915_READ(PLANE_CTL(pipe, 0));
> >>>   ctl &= ~PLANE_CTL_TILED_MASK;
> >>> @@ -11152,9 +11153,16 @@ static void skl_do_mmio_flip(struct 
> >>> intel_crtc *intel_crtc)
> >>>* The stride is either expressed as a multiple of 64 bytes 
> >>> chunks for
> >>>* linear buffers or in number of tiles for tiled buffers.
> >>>*/
> >>> - stride = fb->pitches[0] /
> >>> -  intel_fb_stride_alignment(dev, fb->modifier[0],
> >>> -fb->pixel_format);
> >>> + if (intel_rotation_90_or_270(plane->state->rotation)) {
> >>> + /* stride = Surface height in tiles */
> >>> + tile_height = intel_tile_height(dev, fb->pixel_format,
> >>> + fb->modifier[0], 0);
> >>> + stride = DIV_ROUND_UP(fb->height, tile_height);
> >>> + } else {
> >>> + stride = fb->pitches[0] /
> >>> + intel_fb_stride_alignment(dev, 
> >>> fb->modifier[0],
> >>> +   
> >>> fb->pixel_format);
> >>> + }
> >>
> >> I was wondering why we are allowing stride changes during page flip, 
> >> but
> >> after looking at the history it seems we are not. The reason for
> >> updating the stride register is the fact that the units we specify it
> >> in change between different tiling modes on SKL+. We still reject 
> >> actual
> >> stride changes during page flip, which is good because allowing it 
> >> would
> >> cause problems for my fb->offsets[] stuff since the interpretation of 
> >> the
> >> linear offset would change with the stride.
> >>
> >> We do allow changes to the rotated stride though since we don't reject
> >> changes to the fb height. I think I need to draw some pictures before I
> >> can say for sure whether that can cause problems or not. But we ca
> >> leave that for another patch if it turns out to need handling.
> >>
> >> One thing that's dodgy here is the plane->state->rotation check. I
> >> think currently we wait for pending flips during the atomic commit
> >> phase after we've swapped the state. So this may end up using the
> >> wrong rotation setting. It would be an even bigger problem if we
> >> already allowed queueing up or replaceing pending plane updates. I
> >> suppose the primary->fb thing doesn't suffer from this problem because
> >> we swap that pointer only after we've waited for pending flips.
> >
> > Current rule is that pageflip doesn't allow any change in any metadata.
> > There's some minor exception that on some platforms we can change the
> > tiling because someone asked for that specifically and it's possible.
> >
> > atomic flips will be able to cope with this. But for legacy pageflips 
> > imo
> > reject everything aggressively that changes metadata (stride, tiling,
> > rotation).
> 
>  I am not sure what is the conclusion. To re-iterate, idea is not to
>  allow rotation changes between page flips, just to program PLAN

[Intel-gfx] [PATCH v7 00/25] Color Management for DRM framework

2015-10-20 Thread Shashank Sharma
This patch set adds Color Manager implementation in DRM layer. Color Manager
is an extension in DRM framework to support color correction/enhancement.

Various Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a user
space UI agent to correct/enhance the display using the DRM property interface.

How is this going to work?
==
1. This patch series adds a few new properties in DRM framework. These 
properties are:
a. color_capabilities property (type blob)
b. Color Transformation Matrix property for corrections like CSC 
(called CTM, type blob)
c. Palette correction properties for corrections like gamma fixup 
(called palette_correction, type blob)
2. Also, this patch series adds few structures to indicate specifications of a 
property like size, no_of_samples for correction etc.
3. These properties are present in mode_config.
4. When the platform's display driver loads, it fills up the values of 
color_capabilities property using the standard structures (added in step 2).
   For example, Intel's I915 driver adds following color correction 
capabilities:
a. gamma correction capability as palette correction property, with 257 
correction coefficients and a max/min value
b. csc correction capability as CTM correction property, with 3x3 
transformation matrix values and max/min values
5. Now when userspace comes up, it queries the platform's color capabilities by 
doing a get_property() on color_capabilities DRM property
6. Reading the blob, the userspace understands the color capabilities of the 
platform.
   For example, userspace will understand it can support:
a. palette_correction with 257 coefficients
b. CSC correction with 3x3 = 9 values
7. To set color correction values, userspace:
a. creates a blob using the create_blob_ioctl in standard 
palette_correction structure format, with the correction values
b. calls the set_property_ioctl with the blob_id as value for the 
property
8. Driver refers to the blob, gets the correction values and applies the 
correction in HW.
9. To get currently applied color correction values, userspace:
a. calls a get_property_ioctl on that color property
b. gets the blob_id for the currently applied correction from DRM 
infrastructure
c. gets the blob using get_blob_ioctl and hence the currently applied 
values

That's all! :)

About the patch series:
===
The patch series first adds the color management support in DRM layer.
Then it adds the color management framework in I915 layer.
After that, it implements platform specific core color correction functios.

Intel color manager registers color correction with DRM color manager in this 
way:
 - CSC transformation is registered as CTM DRM property
 - Gamma correction is registered as palette_after_ctm DRM property
 - Degamma correction is registered as palette_before_ctm DRM property

Our thanks to all the reviewers who have given valuable comments in terms of 
design
and implementation to our previous sets of patches. Special mention of thanks 
should
go to Matt Roper for all his inputs/suggestions in implementation of this 
module,
using DRM atomic CRTC commit path.

V2: Worked on review comments from Matt, Jim, Thierry, Rob.
V3: Worked on review comments from Matt, Jim, Rob:
 - Jim, Rob:
   
   Re-arranged the whole patch series in the sequence of features, currently:
   First 5 patches add color management support in DRM layer
   Next 7 patches add Intel color management framework in I915 driver
   Next 5 patches add color correction for CHV (gamma, degamma and CSC)
   Next 2 patches enable color management, by attaching the properties to 
CRTC(Matt)
   Next 4 patches add color correction for BDW (gamma, degamma)
 - Matt:
   =
   Patch 3: Added refernce/unreference for blob
   Patch 7: return -EINVAL and added debug message
   Patch 8: check for valid blob, from create blob
moved call to intel_crtc_attach_color_prop in the end of full 
implementation (CHV)
   Patch 9: DRM_ERROR->DRM_DEBUG for NULL blob case
   Patch 13: Added static for internal functions
   Patch 20-24: renamed gen9_* functions to bdw_*
   Added new variables in device_info structure num_samples_after_ctm and 
num_samples_before_ctm
   Added new function in patch 8 to load capabilities based on device_info 
across all platforms

V4: Worked on review comments from Daniel, Matt, Rob, Jim
 - Rob, Jim:
   =
   Patch 15, 22: Prepare CSC coeff properly(chv, bdw).
   Patch 13, 20: Gamma max should be (1<<24) -1(chv, bdw).
 - Daniel, Matt:
   =
   Patch 2: Create separate properties to query color capabilities, not a 
single blob.
   Patch 4, 5, 10: Add set/get property interface in DRM layer, not in I915 
layer.

V5: Addressed review comments from Emil, Rob.
 -Emil:
  ==
  Patch 3: Fixed chan

[Intel-gfx] [PATCH v7 01/25] drm: Create Color Management DRM properties

2015-10-20 Thread Shashank Sharma
Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.

There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a correction
   matrix is used for color correction.
- Palette correction: Where direct LUT values are sent to be applied
   on a color palette.

This patch initializes color management framework by:
1. Introducing new pointers in DRM mode_config structure to
   carry CTM and Palette color correction properties.
2. Creating these DRM properties in DRM standard properties creation
   sequence.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/drm_crtc.c | 19 +++
 include/drm/drm_crtc.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e54660a..cee1415 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1470,6 +1470,25 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
 
+   /* Color Management properties */
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_palette_after_ctm_property = prop;
+
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_palette_before_ctm_property = prop;
+
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB, "CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_ctm_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3f0c690..4225341 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1143,6 +1143,11 @@ struct drm_mode_config {
struct drm_property *suggested_x_property;
struct drm_property *suggested_y_property;
 
+   /* Color Management Properties */
+   struct drm_property *cm_palette_before_ctm_property;
+   struct drm_property *cm_palette_after_ctm_property;
+   struct drm_property *cm_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 03/25] drm: Add color correction blobs in CRTC state

2015-10-20 Thread Shashank Sharma
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 
 include/drm/drm_crtc.h  |  5 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0c6f621..57a1bcf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2198,6 +2198,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
 
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+   if (state->ctm_blob)
+   drm_property_reference_blob(state->ctm_blob);
+   if (state->palette_after_ctm_blob)
+   drm_property_reference_blob(state->palette_after_ctm_blob);
+   if (state->palette_before_ctm_blob)
+   drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2243,6 +2249,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct 
drm_crtc *crtc,
 {
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+   if (state->ctm_blob)
+   drm_property_unreference_blob(state->ctm_blob);
+   if (state->palette_after_ctm_blob)
+   drm_property_unreference_blob(state->palette_after_ctm_blob);
+   if (state->palette_before_ctm_blob)
+   drm_property_unreference_blob(state->palette_before_ctm_blob);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f58b595..cea6b3b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -304,6 +304,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
 
+   /* blob properties to hold the color properties' blobs */
+   struct drm_property_blob *palette_before_ctm_blob;
+   struct drm_property_blob *palette_after_ctm_blob;
+   struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
 
struct drm_atomic_state *state;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 08/25] drm: Add color correction state flag

2015-10-20 Thread Shashank Sharma
Add a color correction state flag, to indicate a change in
color correction states. This flag will help a core driver to
optimize its commit calls, by appling the color correction only
when there is a change, not every commit.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c | 6 ++
 include/drm/drm_crtc.h   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b49aaeb..1c163a6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -459,18 +459,24 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
&state->palette_after_ctm_blob, val);
if (ret)
DRM_ERROR("Failed to load blob palette_after_ctm\n");
+   else
+   state->color_correction_changed = true;
return ret;
} else if (property == config->cm_palette_before_ctm_property) {
ret = drm_atomic_crtc_set_blob(dev,
&state->palette_before_ctm_blob, val);
if (ret)
DRM_ERROR("Failed to load blob palette_before_ctm\n");
+   else
+   state->color_correction_changed = true;
return ret;
} else if (property == config->cm_ctm_property) {
ret = drm_atomic_crtc_set_blob(dev,
&state->ctm_blob, val);
if (ret)
DRM_ERROR("Failed to load blob ctm\n");
+   else
+   state->color_correction_changed = true;
return ret;
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index cea6b3b..d002994 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -285,6 +285,7 @@ struct drm_crtc_state {
bool mode_changed : 1;
bool active_changed : 1;
bool connectors_changed : 1;
+   bool color_correction_changed : 1;
 
/* attached planes bitmask:
 * WARNING: transitional helpers do not maintain plane_mask so
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 02/25] drm: Create Color Management query properties

2015-10-20 Thread Shashank Sharma
DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.

Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after/before color
transformation (CTM) unit in the display pipeline.

This patch adds two new read-only properties,
  - cm_coeff_before_ctm_property: A platform driver should use this
property to show supported no_of_coefficients for palette correction,
which gets applied before ctm correction.
  - cm_coeff_after_ctm_property: A platform driver should use this property
to show supported no_of_coefficients for palette correction, which gets
applied after ctm correction.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_crtc.c | 13 +
 include/drm/drm_crtc.h |  4 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cee1415..b342d45 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1489,6 +1489,19 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.cm_ctm_property = prop;
 
+   /* DRM properties to query color capabilities */
+   prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+   "COEFFICIENTS_BEFORE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_coeff_before_ctm_property = prop;
+
+   prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+   "COEFFICIENTS_AFTER_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_coeff_after_ctm_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4225341..f58b595 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1148,6 +1148,10 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;
 
+   /* Color management capabilities query */
+   struct drm_property *cm_coeff_before_ctm_property;
+   struct drm_property *cm_coeff_after_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 09/25] drm/i915: Add set property interface for CRTC

2015-10-20 Thread Shashank Sharma
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f37f84..7cad341 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13241,6 +13241,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };
 
 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 07/25] drm: Add structure for CTM color property

2015-10-20 Thread Shashank Sharma
Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).

This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for color correction.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 include/uapi/drm/drm.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3dce251..d4de772 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -849,6 +849,16 @@ struct drm_palette {
struct drm_r32g32b32 lut[0];
 };
 
+struct drm_ctm {
+   /*
+* Each value is in S31.32 format.
+* This is 3x3 matrix in row major format.
+* Integer part will be clipped to nearest
+* max/min boundary as supported by the HW platform.
+*/
+   __s64 ctm_coeff[9];
+};
+
 /* typedef area */
 #ifndef __KERNEL__
 typedef struct drm_clip_rect drm_clip_rect_t;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 11/25] drm/i915: Register color correction capabilities

2015-10-20 Thread Shashank Sharma
From DRM color management:

DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
   color transformation matrix of 9 correction values gets
   applied as correction.
2. "palette_before_ctm": for corrections which get applied
   beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
   after color transformation matrix correction.

These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
  (CTM is fix to 9 coefficients across industry)

Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
   capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.

So finally, This patch does the following:
1. Add a function which loads the platform's color correction
   capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
   getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
   "num_samples_before_ctm" in intel_device_info as gamma and
   degamma coefficients vary per platform basis.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 31 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8afda45..613bee2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -789,6 +789,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+   u16 num_samples_after_ctm;
+   u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index b03ee94..334bfff 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -30,4 +30,35 @@
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
 {
+   struct drm_mode_config *config = &dev->mode_config;
+   struct drm_mode_object *mode_obj = &crtc->base;
+
+   /*
+   * Register:
+   * =
+   * Gamma correction as palette_after_ctm property
+   * Degamma correction as palette_before_ctm property
+   *
+   * Load:
+   * =
+   * no. of coefficients supported on this platform for gamma
+   * and degamma with the query properties. A user
+   * space agent should read these query property, and prepare
+   * the color correction values accordingly. Its expected from the
+   * driver to load the right number of coefficients during the init
+   * phase.
+   */
+   if (config->cm_coeff_after_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_after_ctm_property,
+   INTEL_INFO(dev)->num_samples_after_ctm);
+   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+   }
+
+   if (config->cm_coeff_before_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_before_ctm_property,
+   INTEL_INFO(dev)->num_samples_before_ctm);
+   DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+   }
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 05/25] drm: Add get property support for color manager

2015-10-20 Thread Shashank Sharma
As per the DRM get_property implementation for a blob, framework
is supposed to return the blob_id to the caller. All the color
management blobs are saved in CRTC state during the set call.

This patch adds get_property support for color management
properties, by referring to the existing blob for the property
and passing its blob_id.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 12a34e9..b49aaeb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -499,6 +499,14 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+   else if (property == config->cm_palette_after_ctm_property)
+   *val = (state->palette_after_ctm_blob) ?
+   state->palette_after_ctm_blob->base.id : 0;
+   else if (property == config->cm_palette_before_ctm_property)
+   *val = (state->palette_before_ctm_blob) ?
+   state->palette_before_ctm_blob->base.id : 0;
+   else if (property == config->cm_ctm_property)
+   *val = (state->ctm_blob) ? state->ctm_blob->base.id : 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 12/25] drm/i915: CHV: Load gamma color correction values

2015-10-20 Thread Shashank Sharma
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.

This patch adds no of coefficitents for best gamma color correction
modes possible in CHV, in device info structure, which is:
Gamma(10 bit, CGM HW unit): 257 coeff

These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 2 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 760e0ce..7780de4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_color_manager.h"
 
 #include 
 #include 
@@ -349,6 +350,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index eec52a7..a378fe1 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -48,3 +48,6 @@
CLEAR_BITS(target, start_bit, no_bits); \
target |= (bit_pattern << start_bit);  \
} while (0)
+
+/* CHV */
+#define CHV_10BIT_GAMMA_MAX_VALS   257
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 15/25] drm/i915: CHV: Pipe level degamma correction

2015-10-20 Thread Shashank Sharma
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.

This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
   CHV/BSW platform
2. Add DeGamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h|  6 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 92 ++
 drivers/gpu/drm/i915/intel_color_manager.h |  5 ++
 3 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 45ddd84..1e46562 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8160,4 +8160,10 @@ enum skl_disp_power_wells {
 #define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
 
+#define PIPEA_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index acb9647..aa815a5 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,92 @@
 
 #include "intel_color_manager.h"
 
+static int chv_set_degamma(struct drm_device *dev,
+   struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+   u16 red_fract, green_fract, blue_fract;
+   u32 red, green, blue;
+   u32 num_samples;
+   u32 word = 0;
+   u32 count, cgm_control_reg, cgm_degamma_reg;
+   enum pipe pipe;
+   struct drm_palette *degamma_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_r32g32b32 *correction_values = NULL;
+   struct drm_crtc_state *state = crtc->state;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   degamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = blob->length / sizeof(struct drm_r32g32b32);
+
+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+   /* Disable DeGamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg &= ~CGM_DEGAMMA_EN;
+   state->palette_before_ctm_blob = NULL;
+
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+   DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   case CHV_DEGAMMA_MAX_VALS:
+   cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+   count = 0;
+   correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+   while (count < CHV_DEGAMMA_MAX_VALS) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   if (blue > CHV_MAX_GAMMA)
+   blue = CHV_MAX_GAMMA;
+
+   if (green > CHV_MAX_GAMMA)
+   green = CHV_MAX_GAMMA;
+
+   if (red > CHV_MAX_GAMMA)
+   red = CHV_MAX_GAMMA;
+
+   blue_fract = GET_BITS(blue, 8, 14);
+   green_fract = GET_BITS(green, 8, 14);
+   red_fract = GET_BITS(red, 8, 14);
+
+   /* Green (29:16) and Blue (13:0) in DWORD1 */
+   SET_BITS(word, green_fract, 16, 14);
+   SET_BITS(word, blue_fract, 0, 14);
+   I915_WRITE(cgm_degamma_reg, word);
+   cgm_degamma_reg += 4;
+
+   /* Red (13:0) to be written to DWORD2 */
+   word = red_fract;
+   I915_WRITE(cgm_degamma_reg, word);
+   cgm_degamma_reg += 4;
+   count++;
+   }
+
+   DRM_DEBUG_DRIVER("DeGamma LUT loaded for Pipe %c\n",
+   pipe_name(pipe));
+
+   /* Enable DeGamma on Pipe */
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+   I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_DEGAMMA_EN);
+
+   DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   default:
+   DRM_ERROR("Invalid number of samples for DeGamma LUT\n");
+   return -EINVAL;
+

[Intel-gfx] [PATCH v7 13/25] drm/i915: CHV: Load degamma color correction values

2015-10-20 Thread Shashank Sharma
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.

This patch adds no of coefficitents for degamma color correction
modes possible in CHV, in device info structure, which is:
CGM Degamma(10 bit, CGM HW unit): 65 coeff

These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 1 +
 drivers/gpu/drm/i915/intel_color_manager.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7780de4..6adf002 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
+   .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index a378fe1..14a1309 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -51,3 +51,4 @@
 
 /* CHV */
 #define CHV_10BIT_GAMMA_MAX_VALS   257
+#define CHV_DEGAMMA_MAX_VALS   65
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 14/25] drm/i915: CHV: Pipe level Gamma correction

2015-10-20 Thread Shashank Sharma
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode

This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h| 12 
 drivers/gpu/drm/i915/intel_color_manager.c | 94 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 13 +
 3 files changed, 119 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ebf032..45ddd84 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8148,4 +8148,16 @@ enum skl_disp_power_wells {
 #define GEN9_VEBOX_MOCS_0  0xcb00  /* Video MOCS base register*/
 #define GEN9_BLT_MOCS_00xcc00  /* Blitter MOCS base register*/
 
+/* Color Management */
+#define PIPEA_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 334bfff..acb9647 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,92 @@
 
 #include "intel_color_manager.h"
 
+static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob 
*blob,
+   struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   u16 red_fract, green_fract, blue_fract;
+   u32 red, green, blue, num_samples;
+   u32 word = 0;
+   u32 count, cgm_gamma_reg, cgm_control_reg;
+   struct drm_r32g32b32 *correction_values;
+   struct drm_palette *gamma_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc_state *state = crtc->state;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   gamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = blob->length / sizeof(struct drm_r32g32b32);
+
+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+
+   /* Disable Gamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg &= ~CGM_GAMMA_EN;
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+   state->palette_after_ctm_blob = NULL;
+   DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+   pipe_name(pipe));
+   return 0;
+
+   case CHV_8BIT_GAMMA_MAX_VALS:
+   case CHV_10BIT_GAMMA_MAX_VALS:
+
+   count = 0;
+   cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+   correction_values = gamma_data->lut;
+
+   while (count < num_samples) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   if (blue > CHV_MAX_GAMMA)
+   blue = CHV_MAX_GAMMA;
+
+   if (green > CHV_MAX_GAMMA)
+   green = CHV_MAX_GAMMA;
+
+   if (red > CHV_MAX_GAMMA)
+   red = CHV_MAX_GAMMA;
+
+   /* get MSB 10 bits from fraction part (14:23) */
+   blue_fract = GET_BITS(blue, 14, 10);
+   green_fract = GET_BITS(green, 14, 10);
+   red_fract = GET_BITS(red, 14, 10);
+
+   /* Green (25:16) and Blue (9:0) to be written */
+   SET_BITS(word, green_fract, 16, 10);
+   SET_BITS(word, blue_fract, 0, 10);
+   I915_WRITE(cgm_gamma_reg, word);
+   cgm_gamma_reg += 4;
+
+   /* Red (9:0) to be written */
+   word = red_fract;
+   I915_WRITE(cgm_gamma_reg, word);
+
+   cgm_gamma_reg += 4;
+   count++;
+   }
+
+   /* Enable (CGM) Gamma on Pipe */
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+   I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_

[Intel-gfx] [PATCH v7 06/25] drm: Add drm structures for palette color property

2015-10-20 Thread Shashank Sharma
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 include/uapi/drm/drm.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..3dce251 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,26 @@ struct drm_event_vblank {
__u32 reserved;
 };
 
+struct drm_r32g32b32 {
+   /*
+* Data is in U8.24 fixed point format.
+* All platforms support values within [0, 1.0] range,
+* for Red, Green and Blue colors.
+*/
+   __u32 r32;
+   __u32 g32;
+   __u32 b32;
+   __u32 reserved;
+};
+
+struct drm_palette {
+   /*
+* Starting of palette LUT in R32G32B32 format.
+* Each of RGB value is in U8.24 fixed point format.
+*/
+   struct drm_r32g32b32 lut[0];
+};
+
 /* typedef area */
 #ifndef __KERNEL__
 typedef struct drm_clip_rect drm_clip_rect_t;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 10/25] drm/i915: Create color management files

2015-10-20 Thread Shashank Sharma
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h

The per color property patches coming up in this patch series
will fill the appropriate functions in this file.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/Makefile  |  3 +-
 drivers/gpu/drm/i915/intel_color_manager.c | 33 
 drivers/gpu/drm/i915/intel_color_manager.h | 50 ++
 drivers/gpu/drm/i915/intel_drv.h   |  3 ++
 4 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44d290a..56caf9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
  intel_overlay.o \
  intel_psr.o \
  intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
 i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
 i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
 
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..b03ee94
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Kausal Malladi 
+ */
+
+#include "intel_color_manager.h"
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+   struct drm_crtc *crtc)
+{
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..eec52a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Kausal Malladi 
+ */
+#include 
+#include 
+#include "i915_drv.h"
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+   ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+   x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */
+#define 

[Intel-gfx] [PATCH v7 04/25] drm: Add set property support for color manager

2015-10-20 Thread Shashank Sharma
As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from the blob can referred and applied on display controller
registers.

This patch adds this set_property support for color correction blobs
in drm framework.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal malladi 
---
 drivers/gpu/drm/drm_atomic.c | 53 ++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..12a34e9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
 EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
 
 /**
+ * drm_atomic_crtc_set_blob - find and set a blob
+ * @state_blob: reference pointer to the color blob in the crtc_state
+ * @blob_id: blob_id coming from set_property() call
+ *
+ * Set a color correction blob (originating from a set blob property) on the
+ * desired CRTC state. This function will take reference of the blob property
+ * in the CRTC state, finds the blob based on blob_id (which comes from
+ * set_property call) and set the blob at the proper place.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+static int drm_atomic_crtc_set_blob(struct drm_device *dev,
+   struct drm_property_blob **state_blob, uint32_t blob_id)
+{
+   struct drm_property_blob *blob;
+
+   blob = drm_property_lookup_blob(dev, blob_id);
+   if (!blob) {
+   DRM_DEBUG_KMS("Invalid Blob ID\n");
+   return -EINVAL;
+   }
+
+   if (*state_blob)
+   drm_property_unreference_blob(*state_blob);
+
+   /* Attach the blob to be committed in state */
+   *state_blob = blob;
+   return 0;
+}
+
+/**
  * drm_atomic_crtc_set_property - set property on CRTC
  * @crtc: the drm CRTC to set a property on
  * @state: the state object to update with the new property value
@@ -422,8 +454,25 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
if (mode)
drm_property_unreference_blob(mode);
return ret;
-   }
-   else if (crtc->funcs->atomic_set_property)
+   } else if (property == config->cm_palette_after_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   &state->palette_after_ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob palette_after_ctm\n");
+   return ret;
+   } else if (property == config->cm_palette_before_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   &state->palette_before_ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob palette_before_ctm\n");
+   return ret;
+   } else if (property == config->cm_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   &state->ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob ctm\n");
+   return ret;
+   } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
return -EINVAL;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 17/25] drm/i915: Commit color correction to CRTC

2015-10-20 Thread Shashank Sharma
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 44 ++
 drivers/gpu/drm/i915/intel_display.c   |  2 ++
 drivers/gpu/drm/i915/intel_drv.h   |  2 ++
 3 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7669df8..ac4074a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -291,6 +291,50 @@ static int chv_set_gamma(struct drm_device *dev, struct 
drm_property_blob *blob,
}
 }
 
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state)
+{
+   struct drm_property_blob *blob;
+   struct drm_crtc *crtc = crtc_state->crtc;
+   int ret = -EINVAL;
+
+   blob = crtc_state->palette_after_ctm_blob;
+   if (blob) {
+   /* Gamma correction is platform specific */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_gamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set Gamma correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("Gamma correction success\n");
+   }
+
+   blob = crtc_state->palette_before_ctm_blob;
+   if (blob) {
+   /* Degamma correction */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_degamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set degamma correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("degamma correction success\n");
+   }
+
+   blob = crtc_state->ctm_blob;
+   if (blob) {
+   /* CSC correction */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_csc(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set CSC correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("CSC correction success\n");
+   }
+}
+
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
 {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7cad341..f94ed6d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13530,6 +13530,8 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+   intel_color_manager_crtc_commit(dev, crtc->state);
 }
 
 static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2e4e97d..4b24496 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1480,4 +1480,6 @@ extern const struct drm_plane_helper_funcs 
intel_plane_helper_funcs;
 /* intel_color_manager.c */
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc);
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state);
 #endif /* __INTEL_DRV_H__ */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 16/25] drm/i915: CHV: Pipe level CSC correction

2015-10-20 Thread Shashank Sharma
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.

This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/i915_reg.h|  8 +++
 drivers/gpu/drm/i915/intel_color_manager.c | 99 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
 3 files changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1e46562..3db42f4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8166,4 +8166,12 @@ enum skl_disp_power_wells {
 #define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
 
+#define PIPEA_CGM_CSC  (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC  (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC  (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index aa815a5..7669df8 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,98 @@
 
 #include "intel_color_manager.h"
 
+static s32 chv_prepare_csc_coeff(s64 csc_value)
+{
+   s32 csc_int_value;
+   u32 csc_fract_value;
+   s32 csc_s3_12_format;
+
+   if (csc_value >= 0) {
+   csc_value += CHV_CSC_FRACT_ROUNDOFF;
+   if (csc_value > CHV_CSC_COEFF_MAX)
+   csc_value = CHV_CSC_COEFF_MAX;
+   } else {
+   csc_value = -csc_value;
+   csc_value += CHV_CSC_FRACT_ROUNDOFF;
+   if (csc_value > CHV_CSC_COEFF_MAX + 1)
+   csc_value = CHV_CSC_COEFF_MAX + 1;
+   csc_value = -csc_value;
+   }
+
+   csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+   csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+   if (csc_value < 0)
+   csc_int_value |= CSC_COEFF_SIGN;
+
+   csc_fract_value = csc_value;
+   csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+   csc_s3_12_format = csc_int_value | csc_fract_value;
+
+   return csc_s3_12_format;
+}
+
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+   struct drm_crtc *crtc)
+{
+   struct drm_ctm *csc_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 reg;
+   enum pipe pipe;
+   s32 word = 0, temp;
+   int count = 0;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   if (blob->length != sizeof(struct drm_ctm)) {
+   DRM_ERROR("Invalid length of data received\n");
+   return -EINVAL;
+   }
+
+   csc_data = (struct drm_ctm *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   /* Disable CSC functionality */
+   reg = _PIPE_CGM_CONTROL(pipe);
+   I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+   DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+   pipe_name(pipe));
+
+   reg = _PIPE_CSC_BASE(pipe);
+
+   /*
+   * First 8 of 9 CSC correction values go in pair, to first
+   * 4 CSC register (bit 0:15 and 16:31)
+   */
+   while (count < CSC_MAX_VALS - 1) {
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+   count++;
+
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+   count++;
+
+   I915_WRITE(reg, word);
+   reg += 4;
+   }
+
+   /* 9th coeff goes to 5th register, bit 0:16 */
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+   I915_WRITE(reg, word);
+
+   /* Enable CSC functionality */
+   reg = _PIPE_CGM_CONTROL(pipe);
+   I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+   DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+   return 0;
+}
+
 static int chv_set_degamma(struct drm_device *dev,
struct drm_property_blob *blob, struct drm_crtc *crtc)
 {
@@ -247,4 +339,11 @@ void intel_attach_color_properties_to_crtc(struct 
drm_device *dev,
config->cm_palette_before_ctm_property, 0);
DRM_DEBUG_DRIVER("degamma property attached to CRTC\n");
}
+
+ 

[Intel-gfx] [PATCH v7 23/25] drm/i915: BDW: Pipe level CSC correction

2015-10-20 Thread Shashank Sharma
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.

This patch does the following:
1. Adds the core function to program CSC correction values for
   BDW/SKL/BXT platform
2. Adds CSC correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/i915_reg.h|   7 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 113 +
 drivers/gpu/drm/i915/intel_color_manager.h |   8 ++
 3 files changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 39fbafc..9838afc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8195,4 +8195,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
 
 
+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+   (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 03c51ad..f301b4e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -363,6 +363,117 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
 }
 
+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+   uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+   int32_t mantissa;
+   uint64_t abs_coeff;
+
+   coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+   coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+   abs_coeff = abs(coeff);
+   if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+   /* abs_coeff < 0.125 */
+   exponent_bits = 3;
+   ls_bit_pos = 19;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+   /* abs_coeff >= 0.125 && val < 0.25 */
+   exponent_bits = 2;
+   ls_bit_pos = 20;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+   && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+   /* abs_coeff >= 0.25 && val < 0.5 */
+   exponent_bits = 1;
+   ls_bit_pos = 21;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+   && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+   /* abs_coeff >= 0.5 && val < 1.0 */
+   exponent_bits = 0;
+   ls_bit_pos = 22;
+   } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+   /* abs_coeff >= 1.0 && val < 2.0 */
+   exponent_bits = 7;
+   ls_bit_pos = 23;
+   } else {
+   /* abs_coeff >= 2.0 && val < 4.0 */
+   exponent_bits = 6;
+   ls_bit_pos = 24;
+   }
+
+   mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
+   if (coeff < 0)
+   sign_bit = 1;
+
+   reg_val = 0;
+   SET_BITS(reg_val, exponent_bits, 12, 3);
+   SET_BITS(reg_val, mantissa, 3, 9);
+   SET_BITS(reg_val, sign_bit, 15, 1);
+   return reg_val;
+}
+
+static int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+   struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   enum plane plane;
+   int temp, word;
+   int count = 0;
+   u32 reg, plane_ctl, mode;
+   struct drm_ctm *csc_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   if (blob->length != sizeof(struct drm_ctm)) {
+   DRM_ERROR("Invalid length of data received\n");
+   return -EINVAL;
+   }
+
+   csc_data = (struct drm_ctm *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   plane = to_intel_crtc(crtc)->plane;
+
+   plane_ctl = I915_READ(PLANE_CTL(pipe, plane));
+   plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
+   I915_WRITE(PLANE_CTL(pipe, plane), plane_ctl);
+   reg = _PIPE_CSC_COEFF(pipe);
+
+   /*
+   * BDW CSC correction coefficients are written like this:
+   * first two values go in a pair, into first register(0:15 and 16:31)
+   * third one alone goes into second register (16:31). Same
+   * pattern repeats for 3 times = 3 * 3 = 9 values.
+   */
+   while (count < CSC_MAX_VALS) {
+   word = 0;
+   temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+   SET_BITS(word, temp, 16, 16);
+
+   temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+   SET

[Intel-gfx] [PATCH v7 19/25] drm/i915: BDW: Load gamma correction values

2015-10-20 Thread Shashank Sharma
I915 color manager registers pipe gamma correction as palette
correction after CTM property.

For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info structures, for all of those.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 7 +++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6adf002..8beac5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,6 +302,7 @@ static const struct intel_device_info 
intel_broadwell_d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -314,6 +315,7 @@ static const struct intel_device_info 
intel_broadwell_m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -326,6 +328,7 @@ static const struct intel_device_info 
intel_broadwell_gt3d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -338,6 +341,7 @@ static const struct intel_device_info 
intel_broadwell_gt3m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -363,6 +367,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -376,6 +381,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -389,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index 7b96512..271246a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -89,3 +89,6 @@
 #define CGM_GAMMA_EN   (1 << 2)
 #define CGM_CSC_EN (1 << 1)
 #define CGM_DEGAMMA_EN (1 << 0)
+
+/* Gamma on BDW */
+#define BDW_SPLITGAMMA_MAX_VALS512
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 20/25] drm/i915: BDW: Pipe level Gamma correction

2015-10-20 Thread Shashank Sharma
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. Split mode
4. 12-bit mode

This patch does the following:
1. Adds the core function to program Gamma correction values
   for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h|  25 ++-
 drivers/gpu/drm/i915/intel_color_manager.c | 281 +
 drivers/gpu/drm/i915/intel_color_manager.h |   6 +
 3 files changed, 310 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3db42f4..39fbafc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5685,11 +5685,15 @@ enum skl_disp_power_wells {
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
-#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) + 
(i) * 4)
+#define _LGC_PALETTE_C   0x4b000
+#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B, \
+_LGC_PALETTE_C) + (i) * 4)
 
 #define _GAMMA_MODE_A  0x4a480
 #define _GAMMA_MODE_B  0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C  0x4b480
+#define GAMMA_MODE(pipe) \
+   _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
 #define GAMMA_MODE_MODE_MASK   (3 << 0)
 #define GAMMA_MODE_MODE_8BIT   (0 << 0)
 #define GAMMA_MODE_MODE_10BIT  (1 << 0)
@@ -8172,6 +8176,23 @@ enum skl_disp_power_wells {
 #define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
 
+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A   0x4A400
+#define PAL_PREC_INDEX_B   0x4AC00
+#define PAL_PREC_INDEX_C   0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GCMAX_A   0x4A410
+#define PAL_PREC_GCMAX_B   0x4AC10
+#define PAL_PREC_GCMAX_C   0x4B410
+
+#define _PREC_PAL_INDEX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+   (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+#define _PREC_PAL_GCMAX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
 
 
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index ac4074a..fbb5d03 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,285 @@
 
 #include "intel_color_manager.h"
 
+static void bdw_write_8bit_gamma_legacy(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 palette)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 blue, green, red;
+   u32 count = 0;
+   u32 word = 0;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < BDW_8BIT_GAMMA_MAX_VALS) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   /*
+   * Maximum possible gamma correction value supported
+   * for BDW is 0x, so clamp the values accordingly
+   */
+   if (blue >= BDW_MAX_GAMMA)
+   blue = BDW_MAX_GAMMA;
+   if (green >= BDW_MAX_GAMMA)
+   green = BDW_MAX_GAMMA;
+   if (red >= BDW_MAX_GAMMA)
+   red = BDW_MAX_GAMMA;
+
+   blue_fract = GET_BITS(blue, 16, 8);
+   green_fract = GET_BITS(green, 16, 8);
+   red_fract = GET_BITS(red, 16, 8);
+
+   /* Blue (7:0) Green (15:8) and Red (23:16) */
+   SET_BITS(word, blue_fract, 0, 8);
+   SET_BITS(word, green_fract, 8, 8);
+   SET_BITS(word, red_fract, 16, 8);
+   I915_WRITE(palette, word);
+   palette += 4;
+   count++;
+   }
+}
+
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+   u32 no_of_coeff)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 word = 0;
+   u32 count = 0;
+   u32 blue, green, red;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < no_of_coeff) {
+
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   /*
+   

[Intel-gfx] [PATCH v7 18/25] drm/i915: Attach color properties to CRTC

2015-10-20 Thread Shashank Sharma
Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization sequence.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f94ed6d..61562a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13861,6 +13861,7 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
intel_crtc->cursor_size = ~0;
 
intel_crtc->wm.cxsr_allowed = true;
+   intel_attach_color_properties_to_crtc(dev, &intel_crtc->base);
 
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
   dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [v3] drm/i915/skl: If needed sanitize bios programmed cdclk

2015-10-20 Thread Kumar, Shobhit

On 10/20/2015 04:49 PM, Ville Syrjälä wrote:

On Tue, Oct 20, 2015 at 03:27:24PM +0530, Kumar, Shobhit wrote:

On 10/19/2015 07:18 PM, Ville Syrjälä wrote:

On Fri, Oct 16, 2015 at 06:48:53PM +0530, Shobhit Kumar wrote:

Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.

v2: Check if BIOS programmed correctly rather than always calling init
  - Do validation of programmed cdctl and what it is expected
  - Only do slk_init_cdclk if validation failed else reuse BIOS
programmed value

v3: Move the validation logic in a separate sanitize function (Ville)

Cc: Imre Deak 
Cc: Ville Syrjälä 
Signed-off-by: Shobhit Kumar 
---
   drivers/gpu/drm/i915/intel_ddi.c | 12 
   drivers/gpu/drm/i915/intel_display.c | 31 +++
   drivers/gpu/drm/i915/intel_drv.h |  1 +
   3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b25e99a..86d43e6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2949,10 +2949,14 @@ void intel_ddi_pll_init(struct drm_device *dev)

cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
-   else
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+   if (skl_sanitize_cdclk(dev_priv))
+   DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
+   else {
+   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
+   DRM_ERROR("LCPLL1 is disabled\n");


Since skl_sanitize_cdclk() will enable the PLL this shouldn't
happen anymore, right?



Yeah right. Will remove.


+   else
+   intel_display_power_get(dev_priv, 
POWER_DOMAIN_PLLS);
+   }
} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f37f84..98333d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5784,6 +5784,37 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
DRM_ERROR("DBuf power enable timeout\n");
   }

+int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
+{
+   uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
+   uint32_t cdctl = I915_READ(CDCLK_CTL);
+   int freq = dev_priv->skl_boot_cdclk;
+
+   /* Is PLL enabled and locked ? */
+   if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 & LCPLL_PLL_LOCK)))
+   goto sanitize;
+
+   /* DPLL okay; verify the cdclock
+*
+* Noticed in some instances that the freq selection is correct but
+* decimal part is programmed wrong from BIOS where pre-os does not
+* enable display. Verify the same as well.
+*/
+   if (cdctl == ((cdctl & CDCLK_FREQ_SEL_MASK) | skl_cdclk_decimal(freq)))
+   /* All well; nothing to sanitize */
+   return false;
+sanitize:
+   /*
+* As of now initialize with max cdclk till
+* we get dynamic cdclk support
+* */
+   dev_priv->skl_boot_cdclk = 675000;


Should be '= dev_priv->max_cdclk'

I think we end up doing the intel_update_cdclk() before this gets
called, so max_cdclk should already contain something sensible. The
whole init sequence is a bit messy currently, but I think we can put
off cleaning it up after the dc6 stuff gets sorted.



Actually at the end of skl_init_cdclock, intel_update_cdclk will be
called and initialize the max_cdclk correctly.


It gets called already earlier from intel_modeset_init().


Yeah, I misunderstood your comment earlier.




In case there was no
sanitization needed, the BIOS programmed cdclk is stored in
skl_boot_cdclk and that is used inside the skl_init_cdclk. Same is
invoked resume time, so we need to update this variable or else change
the logic.


+   skl_init_cdclk(dev_priv);
+
+   /* we did have to sanitize */
+   return true;
+}
+
   /* Adjust CDclk dividers to allow high res or save power if possible */
   static void valleyview_set_cdclk(struct drm_device *dev, int cdclk)
   {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0598932..ec10e6a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1152,6 +1152,7 @@ void broxton_ddi_phy_uninit(struct drm_device *dev);
   void bxt_enable_dc9(struct drm_i915_private *dev_priv);
   void bxt_disable_dc9(struct drm_i915_private *dev_priv);
   void skl_ini

[Intel-gfx] [PATCH v7 21/25] drm/i915: BDW: Load degamma correction values

2015-10-20 Thread Shashank Sharma
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.

This patch adds the no of coefficients(512) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 7 +++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8beac5c..1c68e91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info 
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info 
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info 
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info 
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6c7cb08..e0c486e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -98,3 +98,6 @@
 #define BDW_MAX_GAMMA ((1 << 24) - 1)
 #define BDW_INDEX_AUTO_INCREMENT   (1 << 15)
 #define BDW_INDEX_SPLIT_MODE   (1 << 31)
+
+/* Degamma on BDW */
+#define BDW_DEGAMMA_MAX_VALS   512
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 22/25] drm/i915: BDW: Pipe level degamma correction

2015-10-20 Thread Shashank Sharma
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.

This patch does the following:
1. Adds the core function to program DeGamma correction values for
   BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index fbb5d03..03c51ad 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -306,6 +306,63 @@ static int bdw_set_gamma(struct drm_device *dev, struct 
drm_property_blob *blob,
return 0;
 }
 
+static int bdw_set_degamma(struct drm_device *dev,
+   struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   int num_samples;
+   u32 index, mode;
+   u32 pal_prec_index, pal_prec_data;
+   struct drm_palette *degamma_data;
+   struct drm_crtc_state *state = crtc->state;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_r32g32b32 *correction_values = NULL;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   degamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = blob->length / sizeof(struct drm_r32g32b32);
+
+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+   /* Disable degamma on Pipe */
+   mode = I915_READ(GAMMA_MODE(pipe)) & ~GAMMA_MODE_MODE_MASK;
+   I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_8BIT);
+
+   state->palette_before_ctm_blob = NULL;
+   DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   case BDW_SPLITGAMMA_MAX_VALS:
+   pal_prec_index = _PREC_PAL_INDEX(pipe);
+   pal_prec_data = _PREC_PAL_DATA(pipe);
+   correction_values = degamma_data->lut;
+
+   index = I915_READ(pal_prec_index);
+   index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+   I915_WRITE(pal_prec_index, index);
+
+   bdw_write_10bit_gamma_precision(dev, correction_values,
+   pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
+
+   /* Enable degamma on Pipe */
+   mode = I915_READ(GAMMA_MODE(pipe));
+   mode &= ~GAMMA_MODE_MODE_MASK;
+   I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+   DRM_DEBUG_DRIVER("degamma correction enabled on Pipe %c\n",
+   pipe_name(pipe));
+   break;
+
+   default:
+   DRM_ERROR("Invalid number of samples\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 static s32 chv_prepare_csc_coeff(s64 csc_value)
 {
s32 csc_int_value;
@@ -596,6 +653,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* Degamma correction */
if (IS_CHERRYVIEW(dev))
ret = chv_set_degamma(dev, blob, crtc);
+   else if (IS_BROADWELL(dev) || IS_GEN9(dev))
+   ret = bdw_set_degamma(dev, blob, crtc);
 
if (ret)
DRM_ERROR("set degamma correction failed\n");
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 25/25] drm/i915: Commit color correction only when needed

2015-10-20 Thread Shashank Sharma
This patch optimizes the commit path for i915 driver, by applying
color corrections, only when required. Pipe level color correction
(like CSC/gamma/degamma) once applied, sustain until the next change.

DRM layer sets a flag in crtc state (color_correction_changed),
whenever there is new set_property call. Apply color correction
from the commit layer, only when this flag is set, else pass.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index f301b4e..5196a82 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -745,6 +745,15 @@ void intel_color_manager_crtc_commit(struct drm_device 
*dev,
struct drm_crtc *crtc = crtc_state->crtc;
int ret = -EINVAL;
 
+   /*
+   * CRTC level color correction, once applied on the
+   * pipe, goes on forever, until disabled, so there is no
+   * need to program all those correction registers on every
+   * commit. Do this only when a new correction applied.
+   */
+   if (!crtc_state->color_correction_changed)
+   return;
+
blob = crtc_state->palette_after_ctm_blob;
if (blob) {
/* Gamma correction is platform specific */
@@ -786,6 +795,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
else
DRM_DEBUG_DRIVER("CSC correction success\n");
}
+
+   crtc_state->color_correction_changed = false;
 }
 
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v7 24/25] drm/i915: disable plane gamma

2015-10-20 Thread Shashank Sharma
In plane enabling sequence, plane gamma bit is by default enabled.
Plane gamma gets higher priority than pipe gamma, if both enabled.

This patch disables plane gamma from sequence. If required, plane
gamma can be enabled via the color manager drm interface.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 61562a3..72b701a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2820,7 +2820,7 @@ static void ironlake_update_primary_plane(struct drm_crtc 
*crtc,
 
pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
 
-   dspcntr = DISPPLANE_GAMMA_ENABLE;
+   dspcntr = (DISPPLANE_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);
 
dspcntr |= DISPLAY_PLANE_ENABLE;
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 56dc132..6e2be1c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -204,7 +204,8 @@ skl_update_plane(struct drm_plane *drm_plane, struct 
drm_crtc *crtc,
 
plane_ctl = PLANE_CTL_ENABLE |
PLANE_CTL_PIPE_GAMMA_ENABLE |
-   PLANE_CTL_PIPE_CSC_ENABLE;
+   PLANE_CTL_PIPE_CSC_ENABLE |
+   PLANE_CTL_PLANE_GAMMA_DISABLE;
 
plane_ctl |= skl_plane_ctl_format(fb->pixel_format);
plane_ctl |= skl_plane_ctl_tiling(fb->modifier[0]);
@@ -409,7 +410,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
 * Enable gamma to match primary/cursor plane behaviour.
 * FIXME should be user controllable via propertiesa.
 */
-   sprctl |= SP_GAMMA_ENABLE;
+   sprctl |= (SP_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);
 
if (obj->tiling_mode != I915_TILING_NONE)
sprctl |= SP_TILED;
@@ -528,7 +529,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
 * Enable gamma to match primary/cursor plane behaviour.
 * FIXME should be user controllable via propertiesa.
 */
-   sprctl |= SPRITE_GAMMA_ENABLE;
+   sprctl |= (SPRITE_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);
 
if (obj->tiling_mode != I915_TILING_NONE)
sprctl |= SPRITE_TILED;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 3/3] drm/i915: refactor stepping info retrieval

2015-10-20 Thread Jani Nikula
Have only one if ladder for platforms and only one range check for
size. Makes it easier to handle new platforms. Remove the use of
negative return values in char, which might underflow to be positive for
some negative error codes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_csr.c | 46 
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index fe9a55cf8212..3e7953254803 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -188,28 +188,25 @@ static const struct stepping_info bxt_stepping_info[] = {
{'B', '0'}, {'B', '1'}, {'B', '2'}
 };
 
-static char intel_get_stepping(struct drm_device *dev)
+static const struct stepping_info *intel_get_stepping_info(struct drm_device 
*dev)
 {
-   if (IS_SKYLAKE(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(skl_stepping_info)))
-   return skl_stepping_info[dev->pdev->revision].stepping;
-   else if (IS_BROXTON(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(bxt_stepping_info)))
-   return bxt_stepping_info[dev->pdev->revision].stepping;
-   else
-   return -ENODATA;
-}
+   const struct stepping_info *si;
+   unsigned int size;
+
+   if (IS_SKYLAKE(dev)) {
+   size = ARRAY_SIZE(skl_stepping_info);
+   si = skl_stepping_info;
+   } else if (IS_BROXTON(dev)) {
+   size = ARRAY_SIZE(bxt_stepping_info);
+   si = bxt_stepping_info;
+   } else {
+   return NULL;
+   }
 
-static char intel_get_substepping(struct drm_device *dev)
-{
-   if (IS_SKYLAKE(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(skl_stepping_info)))
-   return skl_stepping_info[dev->pdev->revision].substepping;
-   else if (IS_BROXTON(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(bxt_stepping_info)))
-   return bxt_stepping_info[dev->pdev->revision].substepping;
-   else
-   return -ENODATA;
+   if (INTEL_REVID(dev) < size)
+   return si + INTEL_REVID(dev);
+
+   return NULL;
 }
 
 /**
@@ -296,8 +293,8 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
struct intel_package_header *package_header;
struct intel_dmc_header *dmc_header;
struct intel_csr *csr = &dev_priv->csr;
-   char stepping = intel_get_stepping(dev);
-   char substepping = intel_get_substepping(dev);
+   const struct stepping_info *stepping_info = 
intel_get_stepping_info(dev);
+   char stepping, substepping;
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
uint32_t *dmc_payload;
@@ -308,11 +305,14 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
goto out;
}
 
-   if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
+   if (!stepping_info) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
goto out;
}
 
+   stepping = stepping_info->stepping;
+   substepping = stepping_info->substepping;
+
/* Extract CSS Header information*/
css_header = (struct intel_css_header *)fw->data;
if (sizeof(struct intel_css_header) !=
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/3] drm/i915: constify bxt stepping info

2015-10-20 Thread Jani Nikula
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_csr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 7d9c2d42fc1a..fe9a55cf8212 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -183,7 +183,7 @@ static const struct stepping_info skl_stepping_info[] = {
{'G', '0'}, {'H', '0'}, {'I', '0'}
 };
 
-static struct stepping_info bxt_stepping_info[] = {
+static const struct stepping_info bxt_stepping_info[] = {
{'A', '0'}, {'A', '1'}, {'A', '2'},
{'B', '0'}, {'B', '1'}, {'B', '2'}
 };
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/3] drm/i915: fix indentation on skl stepping info

2015-10-20 Thread Jani Nikula
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_csr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9e530a739354..7d9c2d42fc1a 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -178,9 +178,9 @@ struct stepping_info {
 };
 
 static const struct stepping_info skl_stepping_info[] = {
-   {'A', '0'}, {'B', '0'}, {'C', '0'},
-   {'D', '0'}, {'E', '0'}, {'F', '0'},
-   {'G', '0'}, {'H', '0'}, {'I', '0'}
+   {'A', '0'}, {'B', '0'}, {'C', '0'},
+   {'D', '0'}, {'E', '0'}, {'F', '0'},
+   {'G', '0'}, {'H', '0'}, {'I', '0'}
 };
 
 static struct stepping_info bxt_stepping_info[] = {
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/6] drm/i915: Break out common code from gen8_gt_irq_handler

2015-10-20 Thread Chris Wilson
On Tue, Oct 20, 2015 at 02:12:21PM +0200, Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 10:23:52AM +0100, Nick Hoath wrote:
> > Break out common code from gen8_gt_irq_handler and put it in to
> > an always inlined function. gcc optimises out the shift at compile
> > time. (Thomas Daniel/Daniel Vetter/Chris Wilson)
> > 
> > Issue: VIZ-4277
> > Signed-off-by: Nick Hoath 
> > Cc: Thomas Daniel 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> 
> Merged the first two patches to dinq, thanks.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 40 
> > 
> >  1 file changed, 20 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index fbf9153..7837f5e 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1290,6 +1290,16 @@ static void snb_gt_irq_handler(struct drm_device 
> > *dev,
> > ivybridge_parity_error_irq_handler(dev, gt_iir);
> >  }
> >  
> > +static __always_inline void
> > +   gen8_cs_irq_handler(struct intel_engine_cs *ring, u32 iir,
> > +   int test_shift)

Pray tell you fixed the formatting first?
-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


[Intel-gfx] [v4] drm/i915/skl: If needed sanitize bios programmed cdclk

2015-10-20 Thread Shobhit Kumar
Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.

v2: Check if BIOS programmed correctly rather than always calling init
- Do validation of programmed cdctl and what it is expected
- Only do slk_init_cdclk if validation failed else reuse BIOS
  programmed value

v3: Move the validation logic in a separate sanitize function (Ville)

v4: No need to check LCPLL after sanitize and use max_cdclk_freq instead
of hardcoded value (Ville)

Cc: Imre Deak 
Cc: Ville Syrjälä 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/intel_ddi.c |  4 ++--
 drivers/gpu/drm/i915/intel_display.c | 31 +++
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b25e99a..824b863 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2949,8 +2949,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
 
cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
+   if (skl_sanitize_cdclk(dev_priv))
+   DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
else
intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
} else if (IS_BROXTON(dev)) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f37f84..4933b72 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5784,6 +5784,37 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
DRM_ERROR("DBuf power enable timeout\n");
 }
 
+int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
+{
+   uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
+   uint32_t cdctl = I915_READ(CDCLK_CTL);
+   int freq = dev_priv->skl_boot_cdclk;
+
+   /* Is PLL enabled and locked ? */
+   if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 & LCPLL_PLL_LOCK)))
+   goto sanitize;
+
+   /* DPLL okay; verify the cdclock
+*
+* Noticed in some instances that the freq selection is correct but
+* decimal part is programmed wrong from BIOS where pre-os does not
+* enable display. Verify the same as well.
+*/
+   if (cdctl == ((cdctl & CDCLK_FREQ_SEL_MASK) | skl_cdclk_decimal(freq)))
+   /* All well; nothing to sanitize */
+   return false;
+sanitize:
+   /*
+* As of now initialize with max cdclk till
+* we get dynamic cdclk support
+* */
+   dev_priv->skl_boot_cdclk = dev_priv->max_cdclk_freq;
+   skl_init_cdclk(dev_priv);
+
+   /* we did have to sanitize */
+   return true;
+}
+
 /* Adjust CDclk dividers to allow high res or save power if possible */
 static void valleyview_set_cdclk(struct drm_device *dev, int cdclk)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0598932..ec10e6a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1152,6 +1152,7 @@ void broxton_ddi_phy_uninit(struct drm_device *dev);
 void bxt_enable_dc9(struct drm_i915_private *dev_priv);
 void bxt_disable_dc9(struct drm_i915_private *dev_priv);
 void skl_init_cdclk(struct drm_i915_private *dev_priv);
+int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
 void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
 void intel_dp_get_m_n(struct intel_crtc *crtc,
  struct intel_crtc_state *pipe_config);
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [v4] drm/i915/skl: If needed sanitize bios programmed cdclk

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 06:13:12PM +0530, Shobhit Kumar wrote:
> Especially in cases where pre-os does not enable display, cdclk might
> not be in sane state. During sanitization initialize cdclk with maximum
> value till we get dynamic cdclk support.
> 
> v2: Check if BIOS programmed correctly rather than always calling init
> - Do validation of programmed cdctl and what it is expected
> - Only do slk_init_cdclk if validation failed else reuse BIOS
>   programmed value
> 
> v3: Move the validation logic in a separate sanitize function (Ville)
> 
> v4: No need to check LCPLL after sanitize and use max_cdclk_freq instead
> of hardcoded value (Ville)
> 
> Cc: Imre Deak 
> Cc: Ville Syrjälä 
> Signed-off-by: Shobhit Kumar 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c |  4 ++--
>  drivers/gpu/drm/i915/intel_display.c | 31 +++
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  3 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b25e99a..824b863 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2949,8 +2949,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
>  
>   cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
>   dev_priv->skl_boot_cdclk = cdclk_freq;
> - if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> - DRM_ERROR("LCPLL1 is disabled\n");
> + if (skl_sanitize_cdclk(dev_priv))
> + DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
>   else
>   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
>   } else if (IS_BROXTON(dev)) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5f37f84..4933b72 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5784,6 +5784,37 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
>   DRM_ERROR("DBuf power enable timeout\n");
>  }
>  
> +int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> +{
> + uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
> + uint32_t cdctl = I915_READ(CDCLK_CTL);
> + int freq = dev_priv->skl_boot_cdclk;
> +
> + /* Is PLL enabled and locked ? */
> + if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 & LCPLL_PLL_LOCK)))
> + goto sanitize;
> +
> + /* DPLL okay; verify the cdclock
> +  *
> +  * Noticed in some instances that the freq selection is correct but
> +  * decimal part is programmed wrong from BIOS where pre-os does not
> +  * enable display. Verify the same as well.
> +  */
> + if (cdctl == ((cdctl & CDCLK_FREQ_SEL_MASK) | skl_cdclk_decimal(freq)))
> + /* All well; nothing to sanitize */
> + return false;
> +sanitize:
> + /*
> +  * As of now initialize with max cdclk till
> +  * we get dynamic cdclk support
> +  * */
> + dev_priv->skl_boot_cdclk = dev_priv->max_cdclk_freq;
> + skl_init_cdclk(dev_priv);
> +
> + /* we did have to sanitize */
> + return true;
> +}
> +
>  /* Adjust CDclk dividers to allow high res or save power if possible */
>  static void valleyview_set_cdclk(struct drm_device *dev, int cdclk)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0598932..ec10e6a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1152,6 +1152,7 @@ void broxton_ddi_phy_uninit(struct drm_device *dev);
>  void bxt_enable_dc9(struct drm_i915_private *dev_priv);
>  void bxt_disable_dc9(struct drm_i915_private *dev_priv);
>  void skl_init_cdclk(struct drm_i915_private *dev_priv);
> +int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
>  void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
>  void intel_dp_get_m_n(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
> -- 
> 2.4.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 2.9/5] drm/i915: Do not wait for flips in intel_crtc_disable_noatomic.

2015-10-20 Thread Ander Conselvan De Oliveira
On Mon, 2015-10-19 at 17:09 +0200, Maarten Lankhorst wrote:
> Op 19-10-15 om 15:16 schreef Ander Conselvan De Oliveira:
> > On Wed, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> > > Move it from intel_crtc_atomic_commit to prepare_plane_fb.
> > > Waiting is done before committing, otherwise it's too late
> > > to undo the changes.
> > > 
> > > Signed-off-by: Maarten Lankhorst 
> > > ---
> > >  drivers/gpu/drm/i915/intel_atomic.c  |   2 -
> > >  drivers/gpu/drm/i915/intel_display.c | 107 --
> > > 
> > > -
> > >  drivers/gpu/drm/i915/intel_drv.h |   2 -
> > >  3 files changed, 62 insertions(+), 49 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > index f1975f267710..25a891aa3824 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > @@ -205,8 +205,6 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
> > >* but since this plane is unchanged just
> > > do
> > > the
> > >* minimum required validation.
> > >*/
> > > - if (plane->type ==
> > > DRM_PLANE_TYPE_PRIMARY)
> > > - intel_crtc->atomic.wait_for_flips
> > > =
> > > true;
> > >   crtc_state->base.planes_changed = true;
> > >   }
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 25e1eac260fd..cd651ff6c15b 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3221,32 +3221,6 @@ void intel_finish_reset(struct drm_device *dev)
> > >   drm_modeset_unlock_all(dev);
> > >  }
> > >  
> > > -static void
> > > -intel_finish_fb(struct drm_framebuffer *old_fb)
> > > -{
> > > - struct drm_i915_gem_object *obj = intel_fb_obj(old_fb);
> > > - struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> > > - bool was_interruptible = dev_priv->mm.interruptible;
> > > - int ret;
> > > -
> > > - /* Big Hammer, we also need to ensure that any pending
> > > -  * MI_WAIT_FOR_EVENT inside a user batch buffer on the
> > > -  * current scanout is retired before unpinning the old
> > > -  * framebuffer. Note that we rely on userspace rendering
> > > -  * into the buffer attached to the pipe they are waiting
> > > -  * on. If not, userspace generates a GPU hang with IPEHR
> > > -  * point to the MI_WAIT_FOR_EVENT.
> > > -  *
> > > -  * This should only fail upon a hung GPU, in which case we
> > > -  * can safely continue.
> > > -  */
> > > - dev_priv->mm.interruptible = false;
> > > - ret = i915_gem_object_wait_rendering(obj, true);
> > > - dev_priv->mm.interruptible = was_interruptible;
> > > -
> > > - WARN_ON(ret);
> > > -}
> > > -
> > >  static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
> > >  {
> > >   struct drm_device *dev = crtc->dev;
> > > @@ -3867,15 +3841,23 @@ static void page_flip_completed(struct intel_crtc
> > > *intel_crtc)
> > >work->pending_flip_obj);
> > >  }
> > >  
> > > -void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
> > > +static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
> > >  {
> > >   struct drm_device *dev = crtc->dev;
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > + long ret;
> > >  
> > >   WARN_ON(waitqueue_active(&dev_priv->pending_flip_queue));
> > > - if (WARN_ON(wait_event_timeout(dev_priv->pending_flip_queue,
> > > -   
> > >  !intel_crtc_has_pending_flip(crtc),
> > > -60*HZ) == 0)) {
> > > +
> > > + ret = wait_event_interruptible_timeout(
> > > + dev_priv->pending_flip_queue,
> > > + !intel_crtc_has_pending_flip(crtc
> > > ),
> > > + 60*HZ);
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + if (ret == 0) {
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >  
> > >   spin_lock_irq(&dev->event_lock);
> > > @@ -3886,11 +3868,7 @@ void intel_crtc_wait_for_pending_flips(struct
> > > drm_crtc
> > > *crtc)
> > >   spin_unlock_irq(&dev->event_lock);
> > >   }
> > >  
> > > - if (crtc->primary->fb) {
> > > - mutex_lock(&dev->struct_mutex);
> > > - intel_finish_fb(crtc->primary->fb);
> > > - mutex_unlock(&dev->struct_mutex);
> > > - }
> > There is another caller of intel_crtc_wait_for_pending_flips() besides the
> > one
> > touched in this patch: intel_crtc_disable_noatomic(). In your previous
> > series
> > you dropped that call based on the fact that there shouldn't be any pending
> > flips at that point, but that patch has been dropped.
> > 
> > Wouldn't it be better to add a WARN_ON as Chris suggested then instead of
> > keeping the wait 

Re: [Intel-gfx] [PATCH v2 38/43] drm/i915: Parametrize AUX registers

2015-10-20 Thread Jani Nikula
On Mon, 28 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> v2: Keep some MISSING_CASE() stuff (Jani)
> s/-1/-PIPE_B/ in the register macro
> Fix typo in patch subject
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 102 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |  23 +++--
>  drivers/gpu/drm/i915/intel_psr.c |   5 +-
>  3 files changed, 63 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2c518a0..7723ed3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3068,11 +3068,7 @@ enum skl_disp_power_wells {
>  #define   EDP_PSR_IDLE_FRAME_SHIFT   0
>  
>  #define EDP_PSR_AUX_CTL(dev) (EDP_PSR_BASE(dev) + 0x10)
> -#define EDP_PSR_AUX_DATA1(dev)   (EDP_PSR_BASE(dev) + 
> 0x14)
> -#define EDP_PSR_AUX_DATA2(dev)   (EDP_PSR_BASE(dev) + 
> 0x18)
> -#define EDP_PSR_AUX_DATA3(dev)   (EDP_PSR_BASE(dev) + 
> 0x1c)
> -#define EDP_PSR_AUX_DATA4(dev)   (EDP_PSR_BASE(dev) + 
> 0x20)
> -#define EDP_PSR_AUX_DATA5(dev)   (EDP_PSR_BASE(dev) + 
> 0x24)
> +#define EDP_PSR_AUX_DATA(dev, i) (EDP_PSR_BASE(dev) + 0x14 + (i) 
> * 4) /* 5 registers */
>  
>  #define EDP_PSR_STATUS_CTL(dev)  (EDP_PSR_BASE(dev) + 
> 0x40)
>  #define   EDP_PSR_STATUS_STATE_MASK  (7<<29)
> @@ -4188,33 +4184,36 @@ enum skl_disp_power_wells {
>   * is 20 bytes in each direction, hence the 5 fixed
>   * data registers
>   */
> -#define DPA_AUX_CH_CTL   (dev_priv->info.display_mmio_offset + 
> 0x64010)
> -#define DPA_AUX_CH_DATA1 (dev_priv->info.display_mmio_offset + 0x64014)
> -#define DPA_AUX_CH_DATA2 (dev_priv->info.display_mmio_offset + 0x64018)
> -#define DPA_AUX_CH_DATA3 (dev_priv->info.display_mmio_offset + 0x6401c)
> -#define DPA_AUX_CH_DATA4 (dev_priv->info.display_mmio_offset + 0x64020)
> -#define DPA_AUX_CH_DATA5 (dev_priv->info.display_mmio_offset + 0x64024)
> -
> -#define DPB_AUX_CH_CTL   (dev_priv->info.display_mmio_offset + 
> 0x64110)
> -#define DPB_AUX_CH_DATA1 (dev_priv->info.display_mmio_offset + 0x64114)
> -#define DPB_AUX_CH_DATA2 (dev_priv->info.display_mmio_offset + 0x64118)
> -#define DPB_AUX_CH_DATA3 (dev_priv->info.display_mmio_offset + 0x6411c)
> -#define DPB_AUX_CH_DATA4 (dev_priv->info.display_mmio_offset + 0x64120)
> -#define DPB_AUX_CH_DATA5 (dev_priv->info.display_mmio_offset + 0x64124)
> -
> -#define DPC_AUX_CH_CTL   (dev_priv->info.display_mmio_offset + 
> 0x64210)
> -#define DPC_AUX_CH_DATA1 (dev_priv->info.display_mmio_offset + 0x64214)
> -#define DPC_AUX_CH_DATA2 (dev_priv->info.display_mmio_offset + 0x64218)
> -#define DPC_AUX_CH_DATA3 (dev_priv->info.display_mmio_offset + 0x6421c)
> -#define DPC_AUX_CH_DATA4 (dev_priv->info.display_mmio_offset + 0x64220)
> -#define DPC_AUX_CH_DATA5 (dev_priv->info.display_mmio_offset + 0x64224)
> -
> -#define DPD_AUX_CH_CTL   (dev_priv->info.display_mmio_offset + 
> 0x64310)
> -#define DPD_AUX_CH_DATA1 (dev_priv->info.display_mmio_offset + 0x64314)
> -#define DPD_AUX_CH_DATA2 (dev_priv->info.display_mmio_offset + 0x64318)
> -#define DPD_AUX_CH_DATA3 (dev_priv->info.display_mmio_offset + 0x6431c)
> -#define DPD_AUX_CH_DATA4 (dev_priv->info.display_mmio_offset + 0x64320)
> -#define DPD_AUX_CH_DATA5 (dev_priv->info.display_mmio_offset + 0x64324)
> +#define _DPA_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64010)
> +#define _DPA_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64014)
> +#define _DPA_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64018)
> +#define _DPA_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6401c)
> +#define _DPA_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64020)
> +#define _DPA_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64024)
> +
> +#define _DPB_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64110)
> +#define _DPB_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64114)
> +#define _DPB_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64118)
> +#define _DPB_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6411c)
> +#define _DPB_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64120)
> +#define _DPB_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64124)
> +
> +#define _DPC_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64210)
> +#define _DPC_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64214)
> +#define _DPC_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64218)
> +#define _DPC_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6421c)
> +#define _DPC_AUX_CH_DATA4(dev_priv->info.display_mmio_offset +

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Make wait_for_flips interruptible.

2015-10-20 Thread Ander Conselvan De Oliveira
On Tue, 2015-10-20 at 10:10 +0200, Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 10:38:41AM +0300, Ander Conselvan De Oliveira wrote:
> > On Mon, 2015-10-19 at 15:30 +0200, Daniel Vetter wrote:
> > > On Mon, Oct 19, 2015 at 04:16:53PM +0300, Ander Conselvan De Oliveira
> > > wrote:
> > > > On Wed, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> > > > > @@ -13306,6 +13299,29 @@ intel_prepare_plane_fb(struct drm_plane
> > > > > *plane,
> > > > >   if (ret)
> > > > >   return ret;
> > > > >  
> > > > > + if (old_obj) {
> > > > > + struct drm_crtc_state *crtc_state =
> > > > > + drm_atomic_get_existing_crtc_state(new_state
> > > > > ->state,
> > > > > plane->state->crtc);
> > > > > +
> > > > > + /* Big Hammer, we also need to ensure that any
> > > > > pending
> > > > > +  * MI_WAIT_FOR_EVENT inside a user batch buffer on
> > > > > the
> > > > > +  * current scanout is retired before unpinning the
> > > > > old
> > > > > +  * framebuffer. Note that we rely on userspace
> > > > > rendering
> > > > > +  * into the buffer attached to the pipe they are
> > > > > waiting
> > > > > +  * on. If not, userspace generates a GPU hang with
> > > > > IPEHR
> > > > > +  * point to the MI_WAIT_FOR_EVENT.
> > > > > +  *
> > > > > +  * This should only fail upon a hung GPU, in which
> > > > > case
> > > > > we
> > > > > +  * can safely continue.
> > > > > +  */
> > > > > + if (needs_modeset(crtc_state))
> > > > > + ret = i915_gem_object_wait_rendering(old_obj,
> > > > > true);
> > > > > +
> > > > > + /* Swallow -EIO errors to allow updates during hw
> > > > > lockup.
> > > > > */
> > > > > + if (ret && ret != -EIO)
> > > > > + goto out;
> > > > 
> > > > Doesn't this change the behavior of a modeset after a GPU hang? Since
> > > > mm.interruptible is true, i915_gem_check_wedge() might return -EAGAIN
> > > > instead of
> > > > -EIO. Previously the modeset would continue in that scenario, but now,
> > > > somewhat
> > > > contrary to the comment above, we don't continue and instead pass the 
> > > > -EAGAIN to
> > > > user space.
> > > 
> > > It's "while the gpu hang is pending" not "after", but this change is the
> > > hole point of making pinning interruptible. With current modeset code the
> > > only thing we could hope for is that the reset would go through, and
> > > otherwise we'd have to fail the modeset. Now we can correctly retry the
> > > operation if it has run into a concurrent gpu hang/reset.
> > 
> > So in that case should user space retry the modeset? I don't think it does
> > that
> > at moment, at least weston and xf86-video-intel don't. I'm not sure how big
> > of a
> > deal that is, though, since it is an unlikely corner case.
> 
> Every drm ioctl goes through drmIoctl in libdrm, which does this
> restarting. If not then that's a userspace bug, since this is a core bit
> of the drm ABI design.

Ah, true, completely forgot about that.


With the new 2.9 patch, I don't see any other issues with this. I'm happy to
give my r-b, but I think someone else that knows this stuff a bit better should
at least ack the patch.

Ander

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 39/43] drm/i915: Add dev_priv->psr_mmio_base

2015-10-20 Thread Jani Nikula
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
> under dev_priv, like we for DSI and GPIO for example.
>
> TODO: could probably move a bunch of this kind of stuff into the device
> info instead...
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_reg.h | 15 ---
>  drivers/gpu/drm/i915/intel_psr.c| 28 
>  4 files changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2322dac..38b0e38 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2536,7 +2536,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
> *data)
>  yesno(work_busy(&dev_priv->psr.work.work)));
>  
>   if (HAS_DDI(dev))
> - enabled = I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE;
> + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>   else {
>   for_each_pipe(dev_priv, pipe) {
>   stat[pipe] = I915_READ(VLV_PSRSTAT(pipe)) &
> @@ -2558,7 +2558,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
> *data)
>  
>   /* CHV PSR has no kind of performance counter */
>   if (HAS_DDI(dev)) {
> - psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) &
> + psrperf = I915_READ(EDP_PSR_PERF_CNT) &
>   EDP_PSR_PERF_CNT_MASK;
>  
>   seq_printf(m, "Performance_Counter: %u\n", psrperf);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 91ed3c2..4359af1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1744,6 +1744,8 @@ struct drm_i915_private {
>   /* MMIO base address for MIPI regs */
>   uint32_t mipi_mmio_base;
>  
> + uint32_t psr_mmio_base;
> +
>   wait_queue_head_t gmbus_wait_queue;
>  
>   struct pci_dev *bridge_dev;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 04b2063..3437934 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3037,8 +3037,9 @@ enum skl_disp_power_wells {
>  #define VLV_PSRSTAT(pipe) _PIPE(pipe, _PSRSTATA, _PSRSTATB)
>  
>  /* HSW+ eDP PSR registers */
> -#define EDP_PSR_BASE(dev)   (IS_HASWELL(dev) ? 0x64800 : 
> 0x6f800)
> -#define EDP_PSR_CTL(dev) (EDP_PSR_BASE(dev) + 0)
> +#define HSW_EDP_PSR_BASE 0x64800
> +#define BDW_EDP_PSR_BASE 0x6f800
> +#define EDP_PSR_CTL  (dev_priv->psr_mmio_base + 0)
>  #define   EDP_PSR_ENABLE (1<<31)
>  #define   BDW_PSR_SINGLE_FRAME   (1<<30)
>  #define   EDP_PSR_LINK_STANDBY   (1<<27)
> @@ -3061,10 +3062,10 @@ enum skl_disp_power_wells {
>  #define   EDP_PSR_TP1_TIME_0us   (3<<4)
>  #define   EDP_PSR_IDLE_FRAME_SHIFT   0
>  
> -#define EDP_PSR_AUX_CTL(dev) (EDP_PSR_BASE(dev) + 0x10)
> -#define EDP_PSR_AUX_DATA(dev, i) (EDP_PSR_BASE(dev) + 0x14 + (i) 
> * 4) /* 5 registers */
> +#define EDP_PSR_AUX_CTL  
> (dev_priv->psr_mmio_base + 0x10)
> +#define EDP_PSR_AUX_DATA(i)  (dev_priv->psr_mmio_base + 0x14 
> + (i) * 4) /* 5 registers */
>  
> -#define EDP_PSR_STATUS_CTL(dev)  (EDP_PSR_BASE(dev) + 
> 0x40)
> +#define EDP_PSR_STATUS_CTL   (dev_priv->psr_mmio_base + 0x40)
>  #define   EDP_PSR_STATUS_STATE_MASK  (7<<29)
>  #define   EDP_PSR_STATUS_STATE_IDLE  (0<<29)
>  #define   EDP_PSR_STATUS_STATE_SRDONACK  (1<<29)
> @@ -3088,10 +3089,10 @@ enum skl_disp_power_wells {
>  #define   EDP_PSR_STATUS_SENDING_TP1 (1<<4)
>  #define   EDP_PSR_STATUS_IDLE_MASK   0xf
>  
> -#define EDP_PSR_PERF_CNT(dev)(EDP_PSR_BASE(dev) + 0x44)
> +#define EDP_PSR_PERF_CNT (dev_priv->psr_mmio_base + 0x44)
>  #define   EDP_PSR_PERF_CNT_MASK  0xff
>  
> -#define EDP_PSR_DEBUG_CTL(dev)   (EDP_PSR_BASE(dev) + 0x60)
> +#define EDP_PSR_DEBUG_CTL(dev_priv->psr_mmio_base + 0x60)
>  #define   EDP_PSR_DEBUG_MASK_LPSP(1<<27)
>  #define   EDP_PSR_DEBUG_MASK_MEMUP   (1<<26)
>  #define   EDP_PSR_DEBUG_MASK_HPD (1<<25)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index ff66718..90153e7 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -183,9 +183,9 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
>   DP_AUX_FRAME_SYNC_ENABLE);
>  
>   aux_data_reg = (INTEL_INFO(dev)->gen >= 9) ?
> - DP_AUX_CH

Re: [Intel-gfx] [PATCH v2 38/43] drm/i915: Parametrize AUX registers

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 04:05:24PM +0300, Jani Nikula wrote:
> On Mon, 28 Sep 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > v2: Keep some MISSING_CASE() stuff (Jani)
> > s/-1/-PIPE_B/ in the register macro
> > Fix typo in patch subject
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  | 102 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  |  23 +++--
> >  drivers/gpu/drm/i915/intel_psr.c |   5 +-
> >  3 files changed, 63 insertions(+), 67 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 2c518a0..7723ed3 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3068,11 +3068,7 @@ enum skl_disp_power_wells {
> >  #define   EDP_PSR_IDLE_FRAME_SHIFT 0
> >  
> >  #define EDP_PSR_AUX_CTL(dev)   (EDP_PSR_BASE(dev) + 
> > 0x10)
> > -#define EDP_PSR_AUX_DATA1(dev) (EDP_PSR_BASE(dev) + 
> > 0x14)
> > -#define EDP_PSR_AUX_DATA2(dev) (EDP_PSR_BASE(dev) + 
> > 0x18)
> > -#define EDP_PSR_AUX_DATA3(dev) (EDP_PSR_BASE(dev) + 
> > 0x1c)
> > -#define EDP_PSR_AUX_DATA4(dev) (EDP_PSR_BASE(dev) + 
> > 0x20)
> > -#define EDP_PSR_AUX_DATA5(dev) (EDP_PSR_BASE(dev) + 
> > 0x24)
> > +#define EDP_PSR_AUX_DATA(dev, i)   (EDP_PSR_BASE(dev) + 0x14 + (i) 
> > * 4) /* 5 registers */
> >  
> >  #define EDP_PSR_STATUS_CTL(dev)(EDP_PSR_BASE(dev) + 
> > 0x40)
> >  #define   EDP_PSR_STATUS_STATE_MASK(7<<29)
> > @@ -4188,33 +4184,36 @@ enum skl_disp_power_wells {
> >   * is 20 bytes in each direction, hence the 5 fixed
> >   * data registers
> >   */
> > -#define DPA_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 
> > 0x64010)
> > -#define DPA_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64014)
> > -#define DPA_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64018)
> > -#define DPA_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6401c)
> > -#define DPA_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64020)
> > -#define DPA_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64024)
> > -
> > -#define DPB_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 
> > 0x64110)
> > -#define DPB_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64114)
> > -#define DPB_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64118)
> > -#define DPB_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6411c)
> > -#define DPB_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64120)
> > -#define DPB_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64124)
> > -
> > -#define DPC_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 
> > 0x64210)
> > -#define DPC_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64214)
> > -#define DPC_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64218)
> > -#define DPC_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6421c)
> > -#define DPC_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64220)
> > -#define DPC_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64224)
> > -
> > -#define DPD_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 
> > 0x64310)
> > -#define DPD_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64314)
> > -#define DPD_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64318)
> > -#define DPD_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6431c)
> > -#define DPD_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64320)
> > -#define DPD_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64324)
> > +#define _DPA_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
> > 0x64010)
> > +#define _DPA_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64014)
> > +#define _DPA_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64018)
> > +#define _DPA_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6401c)
> > +#define _DPA_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64020)
> > +#define _DPA_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64024)
> > +
> > +#define _DPB_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
> > 0x64110)
> > +#define _DPB_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64114)
> > +#define _DPB_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64118)
> > +#define _DPB_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6411c)
> > +#define _DPB_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64120)
> > +#define _DPB_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64124)
> > +
> > +#define _DPC_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
> > 0x64210)
> > +#define _DPC_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64214)
> > +#define _DPC_AUX_CH_DATA2  (dev_priv->info.di

[Intel-gfx] [maintainer-tools PATCH] dim: Add CONTRIBUTING section to manpage

2015-10-20 Thread Daniel Vetter
v2: Also add same text to qf help.

v3: Ask submission to have a subject prefix (Jani)
---
 dim.rst | 11 +++
 qf  | 11 +++
 2 files changed, 22 insertions(+)

diff --git a/dim.rst b/dim.rst
index da5fdd3a814d..b909e1d87a40 100644
--- a/dim.rst
+++ b/dim.rst
@@ -307,3 +307,14 @@ Path to a file containing a greeting template for pull 
request mails.
 DIM_TEMPLATE_SIGNATURE
 --
 Path to a file containing a signature template for pull request mails.
+
+CONTRIBUTING
+
+
+Submit patches for any of the maintainer tools to
+intel-gfx@lists.freedesktop.org with [maintainer-tools PATCH] prefix. Use
+
+$ git format-patch --subject-prefix="maintainer-tools PATCH"
+
+for that. Push them once you have
+an ack from maintainers (Jani/Daniel).
diff --git a/qf b/qf
index 80d87fc6d649..4e9cb03f31fe 100755
--- a/qf
+++ b/qf
@@ -698,6 +698,17 @@ Any other subcommands are executed directly in the quilt 
patches
 directory as git commans. When using quilt flow in scripts it is
 import to use the explicit forwarding to avoid clashes with
 furture extensions.
+
+CONTRIBUTING
+
+
+Submit patches for any of the maintainer tools to
+intel-gfx@lists.freedesktop.org with [maintainer-tools PATCH] prefix. Use
+
+$ git format-patch --subject-prefix="maintainer-tools PATCH"
+
+for that. Push them once you have
+an ack from maintainers (Jani/Daniel).
 HERE
;;
*)
-- 
2.5.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 09/18] drm/i915: don't disable_fbc() if FBC is already disabled

2015-10-20 Thread Paulo Zanoni
If FBC is disabled we will still call intel_fbc_invalidate(), and as a
result we may call intel_fbc_deactivate(), which will try to touch
registers.

I'm pretty sure I saw this happen on a runtime suspended device, and
I'm almost sure I was running igt/pm_rpm. It produced the "you touched
registers while the device is suspended" WARNs. But this was some time
ago and I can't remember exactly which conditions were necessary to
reproduce the problem.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 2a55c1b..a114ee3 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -488,7 +488,8 @@ static void intel_fbc_deactivate(struct drm_i915_private 
*dev_priv)
 
intel_fbc_cancel_work(dev_priv);
 
-   dev_priv->fbc.disable_fbc(dev_priv);
+   if (dev_priv->fbc.enabled)
+   dev_priv->fbc.disable_fbc(dev_priv);
 }
 
 static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 07/18] drm/i915: fix the __intel_fbc_update() comments

2015-10-20 Thread Paulo Zanoni
Don't try to list in comments the cases where we should enable or
disable FBC: it varies a lot with the hardware generations and the
code should be the documentation. Also notice that there's already a
huge gap between the comments and what's in the code.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 26 ++
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e856304..5fa4ce4 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -853,20 +853,8 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
  * @dev_priv: i915 device instance
  *
- * Set up the framebuffer compression hardware at mode set time.  We
- * enable it if possible:
- *   - plane A only (on pre-965)
- *   - no pixel mulitply/line duplication
- *   - no alpha buffer discard
- *   - no dual wide
- *   - framebuffer <= max_hdisplay in width, max_vdisplay in height
- *
- * We can't assume that any compression will take place (worst case),
- * so the compressed buffer has to be the same size as the uncompressed
- * one.  It also must reside (along with the line length buffer) in
- * stolen memory.
- *
- * We need to enable/disable FBC on a global basis.
+ * This function completely reevaluates the status of FBC, then enables,
+ * disables or maintains it on the same state.
  */
 static void __intel_fbc_update(struct drm_i915_private *dev_priv)
 {
@@ -878,7 +866,6 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
-   /* disable framebuffer compression in vGPU */
if (intel_vgpu_active(dev_priv->dev))
i915.enable_fbc = 0;
 
@@ -892,15 +879,6 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   /*
-* If FBC is already on, we just have to verify that we can
-* keep it that way...
-* Need to disable if:
-*   - more than one pipe is active
-*   - changing FBC params (stride, fence, mode)
-*   - new fb is too large to fit in compressed buffer
-*   - going to an unsupported config (interlace, pixel multiply, etc.)
-*/
drm_crtc = intel_fbc_find_crtc(dev_priv);
if (!drm_crtc) {
set_no_fbc_reason(dev_priv, "no output");
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 08/18] drm/i915: pass the crtc as an argument to intel_fbc_update()

2015-10-20 Thread Paulo Zanoni
There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.

With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the state of
pipe A only to conclude FBC should remain enabled on pipe A. If any
change on pipe A triggers a need to recompute whether FBC is valid on
pipe A, then at some point someone is going to call
intel_fbc_update(PIPE_A).

The addition of intel_fbc_deactivate() is necessary so we keep track
of the previously selected CRTC when we do invalidate/flush. We're
also going to continue the enable/disable/activate/deactivate concept
in the next patches.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c |  3 +-
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 70 
 3 files changed, 32 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e83a428..3050bfe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4778,7 +4778,6 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
 {
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_plane *plane;
 
if (atomic->wait_vblank)
@@ -4793,7 +4792,7 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
intel_update_watermarks(&crtc->base);
 
if (atomic->update_fbc)
-   intel_fbc_update(dev_priv);
+   intel_fbc_update(crtc);
 
if (atomic->post_enable_primary)
intel_post_enable_primary(&crtc->base);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1e08c8a..27c8403 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1278,7 +1278,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 
 /* intel_fbc.c */
 bool intel_fbc_enabled(struct drm_i915_private *dev_priv);
-void intel_fbc_update(struct drm_i915_private *dev_priv);
+void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
 void intel_fbc_disable_crtc(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 5fa4ce4..2a55c1b 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -482,13 +482,18 @@ static void intel_fbc_schedule_enable(struct intel_crtc 
*crtc)
schedule_delayed_work(&work->work, msecs_to_jiffies(50));
 }
 
-static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
+static void intel_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
intel_fbc_cancel_work(dev_priv);
 
dev_priv->fbc.disable_fbc(dev_priv);
+}
+
+static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
+{
+   intel_fbc_deactivate(dev_priv);
dev_priv->fbc.crtc = NULL;
 }
 
@@ -551,24 +556,6 @@ static bool crtc_is_valid(struct intel_crtc *crtc)
   crtc->base.primary->fb != NULL;
 }
 
-static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
-{
-   struct drm_crtc *crtc = NULL, *tmp_crtc;
-   enum pipe pipe;
-
-   for_each_pipe(dev_priv, pipe) {
-   tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
-
-   if (crtc_is_valid(to_intel_crtc(tmp_crtc)))
-   crtc = tmp_crtc;
-   }
-
-   if (!crtc)
-   return NULL;
-
-   return crtc;
-}
-
 static bool multiple_pipes_ok(struct drm_i915_private *dev_priv)
 {
enum pipe pipe;
@@ -851,21 +838,28 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
 
 /**
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
- * @dev_priv: i915 device instance
+ * @crtc: the CRTC that triggered the update
  *
  * This function completely reevaluates the status of FBC, then enables,
  * disables or maintains it on the same state.
  */
-static void __intel_fbc_update(struct drm_i915_private *dev_priv)
+static void __intel_fbc_update(struct intel_crtc *crtc)
 {
-   struct drm_crtc *drm_crtc = NULL;
-   struct intel_crtc *crtc;
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
const struct drm_display_mode *adjusted_mode;
 
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
+   if (!multiple_pipes_ok(dev_priv)) {
+   set_no_fbc_reason(dev_priv, "more than one pipe active");
+   goto out_disabl

[Intel-gfx] [PATCH 04/18] drm/i915: extract crtc_is_valid() on the FBC code

2015-10-20 Thread Paulo Zanoni
We're going to kill intel_fbc_find_crtc(), that's why a big part of
the logic moved from intel_fbc_find_crtc() to crtc_is_valid().

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b9cfd16..1162787 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -538,27 +538,33 @@ static void set_no_fbc_reason(struct drm_i915_private 
*dev_priv,
DRM_DEBUG_KMS("Disabling FBC: %s\n", reason);
 }
 
+static bool crtc_is_valid(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   enum pipe pipe = crtc->pipe;
+
+   if ((IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8) &&
+   pipe != PIPE_A)
+   return false;
+
+   return intel_crtc_active(&crtc->base) &&
+  to_intel_plane_state(crtc->base.primary->state)->visible &&
+  crtc->base.primary->fb != NULL;
+}
+
 static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
 {
struct drm_crtc *crtc = NULL, *tmp_crtc;
enum pipe pipe;
-   bool pipe_a_only = false;
-
-   if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
-   pipe_a_only = true;
 
for_each_pipe(dev_priv, pipe) {
tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
 
-   if (intel_crtc_active(tmp_crtc) &&
-   to_intel_plane_state(tmp_crtc->primary->state)->visible)
+   if (crtc_is_valid(to_intel_crtc(tmp_crtc)))
crtc = tmp_crtc;
-
-   if (pipe_a_only)
-   break;
}
 
-   if (!crtc || crtc->primary->fb == NULL)
+   if (!crtc)
return NULL;
 
return crtc;
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 12/18] drm/i915: introduce intel_fbc_{enable, disable}

2015-10-20 Thread Paulo Zanoni
These are the functions that lock/unlock FBC to/from a CRTC without
changing the hardware state. The goal is to run once per modeset. For
now the functions don't really do much, but we'll still move more
stuff there, such as the stolen memory allocations.

With this, activate/deactivate will just start/stop FBC without
changing its associated pipe. This is the same naming scheme we use in
other features, such as PSR.

This will also help in case we decide to move FBC to pipe_config or
something else later.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  14 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_fbc.c | 202 ---
 4 files changed, 158 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c9035a..8755808 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -915,6 +915,7 @@ struct i915_fbc {
 
bool false_color;
 
+   bool enabled;
bool active;
 
struct intel_fbc_work {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7acdc77..cb008d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4814,7 +4814,7 @@ static void intel_pre_plane_update(struct intel_crtc 
*crtc)
intel_crtc_wait_for_pending_flips(&crtc->base);
 
if (atomic->disable_fbc)
-   intel_fbc_disable_crtc(crtc);
+   intel_fbc_deactivate(crtc);
 
if (crtc->atomic.disable_ips)
hsw_disable_ips(crtc);
@@ -4915,6 +4915,8 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
 
if (HAS_PCH_CPT(dev))
cpt_verify_modeset(dev, intel_crtc->pipe);
+
+   intel_fbc_enable(intel_crtc);
 }
 
 /* IPS only exists on ULT machines and is tied to pipe A. */
@@ -5017,6 +5019,8 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_wait_for_vblank(dev, hsw_workaround_pipe);
intel_wait_for_vblank(dev, hsw_workaround_pipe);
}
+
+   intel_fbc_enable(intel_crtc);
 }
 
 static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force)
@@ -5083,6 +5087,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 
ironlake_fdi_pll_disable(intel_crtc);
}
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void haswell_crtc_disable(struct drm_crtc *crtc)
@@ -5129,6 +5135,8 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder->post_disable)
encoder->post_disable(encoder);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
@@ -6157,6 +6165,8 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
 
for_each_encoder_on_crtc(dev, crtc, encoder)
encoder->enable(encoder);
+
+   intel_fbc_enable(intel_crtc);
 }
 
 static void i9xx_pfit_disable(struct intel_crtc *crtc)
@@ -6219,6 +6229,8 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
 
if (!IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7203087..3854288 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1278,8 +1278,10 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 
 /* intel_fbc.c */
 bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
+void intel_fbc_deactivate(struct intel_crtc *crtc);
 void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
+void intel_fbc_enable(struct intel_crtc *crtc);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
 void intel_fbc_disable_crtc(struct intel_crtc *crtc);
 void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 15f74e2..502ab0b 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -452,7 +452,6 @@ static void intel_fbc_schedule_activation(struct intel_crtc 
*crtc)
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
intel_fbc_cancel_work(dev_priv);
-   dev_priv->fbc.crtc = crtc;
 
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL) {
@@ -482,7 +481,7 @@ static void intel_fbc_schedule_activation(struct intel_crtc 
*crtc)
schedule_delayed_work(&work->work, msecs_to_jiffies(50));
 }
 
-static void intel_fbc_deactivate(struct drm_i915_private *dev_priv)
+static void __intel_fbc_deactivate(struct drm_i915_pri

[Intel-gfx] [PATCH 03/18] drm/i915: only nuke FBC when a drawing operation triggers a flush

2015-10-20 Thread Paulo Zanoni
There's no need to stop and restart FBC: a nuke should be fine.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 9477379..b9cfd16 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1088,8 +1088,10 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
if (origin == ORIGIN_FLIP) {
__intel_fbc_update(dev_priv);
} else {
-   __intel_fbc_disable(dev_priv);
-   __intel_fbc_update(dev_priv);
+   if (dev_priv->fbc.enabled)
+   intel_fbc_nuke(dev_priv);
+   else
+   __intel_fbc_update(dev_priv);
}
}
 
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 15/18] drm/i915: alloc/free the FBC CFB during enable/disable

2015-10-20 Thread Paulo Zanoni
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disbale FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.

I thought about three different approaches to solve this, and they all
have downsides.

The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.

The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
flip_prepare, disable and other calls in the middle of the wait.

Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.

The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow, even
though it is uncommon - see igt's kms_frontbuffer_tracking test,
fbc-stridechange subtest. It could be possible to implement a way to
free+alloc the CFB during said stride change, but it would involve a
lot of book-keeping - exactly as mentioned above - just for a rare
case, so for now I'll keep it simple and just deactivate FBC. Besides,
we may not even need to disable FBC since we do CFB over-allocation.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 132 ---
 1 file changed, 68 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index bf855b2..48d8cfc 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -59,6 +59,45 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
return crtc->base.y - crtc->adjusted_y;
 }
 
+/*
+ * For SKL+, the plane source size used by the hardware is based on the value 
we
+ * write to the PLANE_SIZE register. For BDW-, the hardware looks at the value
+ * we wrote to PIPESRC.
+ */
+static void intel_fbc_get_plane_source_size(struct intel_crtc *crtc,
+   int *width, int *height)
+{
+   struct intel_plane_state *plane_state =
+   to_intel_plane_state(crtc->base.primary->state);
+   int w, h;
+
+   if (intel_rotation_90_or_270(plane_state->base.rotation)) {
+   w = drm_rect_height(&plane_state->src) >> 16;
+   h = drm_rect_width(&plane_state->src) >> 16;
+   } else {
+   w = drm_rect_width(&plane_state->src) >> 16;
+   h = drm_rect_height(&plane_state->src) >> 16;
+   }
+
+   if (width)
+   *width = w;
+   if (height)
+   *height = h;
+}
+
+static int intel_fbc_calculate_cfb_size(struct intel_crtc *crtc,
+   struct drm_framebuffer *fb)
+{
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   int lines;
+
+   intel_fbc_get_plane_source_size(crtc, NULL, &lines);
+   if (INTEL_INFO(dev_priv)->gen >= 7)
+   lines = min(lines, 2048);
+
+   return lines * fb->pitches[0];
+}
+
 static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
u32 fbc_ctl;
@@ -604,11 +643,17 @@ again:
}
 }
 
-static int intel_fbc_alloc_cfb(struct drm_i915_private *dev_p

[Intel-gfx] [PATCH 13/18] drm/i915: remove too-frequent FBC debug message

2015-10-20 Thread Paulo Zanoni
If we run igt/kms_frontbuffer_tracking, this message will appear
thousands of times, eating a significant part of our dmesg buffer.
It's part of the expected FBC behavior, so let's just silence it.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 502ab0b..5dab0e0 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -426,8 +426,6 @@ static void intel_fbc_cancel_work(struct drm_i915_private 
*dev_priv)
if (dev_priv->fbc.fbc_work == NULL)
return;
 
-   DRM_DEBUG_KMS("cancelling pending FBC activation\n");
-
/* Synchronisation is provided by struct_mutex and checking of
 * dev_priv->fbc.fbc_work, so we can perform the cancellation
 * entirely asynchronously.
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 16/18] drm/i915: move adjusted_mode checks from fbc_update to fbc_enable

2015-10-20 Thread Paulo Zanoni
These things can't change without a full modeset.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 48d8cfc..af22bc8 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -815,7 +815,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
-   const struct drm_display_mode *adjusted_mode;
 
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
@@ -834,13 +833,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
 
fb = crtc->base.primary->fb;
obj = intel_fb_obj(fb);
-   adjusted_mode = &crtc->config->base.adjusted_mode;
-
-   if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
-   (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
-   set_no_fbc_reason(dev_priv, "incompatible mode");
-   goto out_disable;
-   }
 
if (!intel_fbc_hw_tracking_covers_screen(crtc)) {
set_no_fbc_reason(dev_priv, "mode too large for compression");
@@ -1065,6 +1057,8 @@ void intel_fbc_flip_prepare(struct drm_i915_private 
*dev_priv,
 void intel_fbc_enable(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   const struct drm_display_mode *adjusted_mode =
+   &crtc->config->base.adjusted_mode;
 
if (!fbc_supported(dev_priv))
return;
@@ -1099,6 +1093,12 @@ void intel_fbc_enable(struct intel_crtc *crtc)
goto out;
}
 
+   if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
+   (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
+   set_no_fbc_reason(dev_priv, "incompatible mode");
+   goto out;
+   }
+
if (intel_fbc_alloc_cfb(crtc)) {
set_no_fbc_reason(dev_priv, "not enough stolen memory");
goto out;
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 10/18] drm/i915: introduce is_active/activate/deactivate to the FBC terminology

2015-10-20 Thread Paulo Zanoni
The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. Let's start this by renaming the
functions that touch the hardware state and their wrappers.

The conversion to the full correct terminology is not complete yet, so
there is still some confusion that will be solved in the next patches.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  10 ++-
 drivers/gpu/drm/i915/intel_display.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h |   2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 116 +--
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 6 files changed, 67 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ac4ba3..3386493 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1636,7 +1636,7 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
mutex_lock(&dev_priv->fbc.lock);
 
-   if (intel_fbc_enabled(dev_priv))
+   if (intel_fbc_is_active(dev_priv))
seq_puts(m, "FBC enabled\n");
else
seq_printf(m, "FBC disabled: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2cb7a05..9c9035a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -915,9 +915,7 @@ struct i915_fbc {
 
bool false_color;
 
-   /* Tracks whether the HW is actually enabled, not whether the feature is
-* possible. */
-   bool enabled;
+   bool active;
 
struct intel_fbc_work {
struct delayed_work work;
@@ -926,9 +924,9 @@ struct i915_fbc {
 
const char *no_fbc_reason;
 
-   bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
-   void (*enable_fbc)(struct intel_crtc *crtc);
-   void (*disable_fbc)(struct drm_i915_private *dev_priv);
+   bool (*is_active)(struct drm_i915_private *dev_priv);
+   void (*activate)(struct intel_crtc *crtc);
+   void (*deactivate)(struct drm_i915_private *dev_priv);
void (*flip_prepare)(struct drm_i915_private *dev_priv);
 };
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3050bfe..fcaf865 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3173,8 +3173,8 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   if (dev_priv->fbc.disable_fbc)
-   dev_priv->fbc.disable_fbc(dev_priv);
+   if (dev_priv->fbc.deactivate)
+   dev_priv->fbc.deactivate(dev_priv);
 
dev_priv->display.update_primary_plane(crtc, fb, x, y);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 27c8403..7203087 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1277,7 +1277,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 #endif
 
 /* intel_fbc.c */
-bool intel_fbc_enabled(struct drm_i915_private *dev_priv);
+bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
 void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index a114ee3..29becf7 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -43,7 +43,7 @@
 
 static inline bool fbc_supported(struct drm_i915_private *dev_priv)
 {
-   return dev_priv->fbc.enable_fbc != NULL;
+   return dev_priv->fbc.activate != NULL;
 }
 
 /*
@@ -59,11 +59,11 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
return crtc->base.y - crtc->adjusted_y;
 }
 
-static void i8xx_fbc_disable(struct drm_i915_private *dev_priv)
+static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
u32 fbc_ctl;
 
-   dev_priv->fbc.enabled = false;
+   dev_priv->fbc.active = false;
 
/* Disable compression */
fbc_ctl = I915_READ(FBC_CONTROL);
@@ -79,7 +79,7 @@ static void i8xx_fbc_disable(struct drm_i915_private 
*dev_priv)
return;
}
 
-   DRM_DEBUG_KMS("disabled FBC\n");
+   DRM_DEBUG_KMS("deactivated FBC\n");
 }
 
 static void i8xx_fbc_flip_prepare(struct drm_i915_private *dev_priv)
@@ -98,7 +98,7 @@ static void i8xx_fbc_flip_prepare(struct drm_i915_private 
*dev_priv)
I915_WRITE(FBC_CONTROL, val);
 }
 
-static void i8xx_fbc_enable(struct intel_crtc *crtc)
+static void i8xx_fbc_activate(struct intel_crtc *crtc)
 {
struct 

[Intel-gfx] [PATCH 18/18] drm/i915: check for FBC planes in the same place as the pipes

2015-10-20 Thread Paulo Zanoni
This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 7f54b6f..47862c5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -563,6 +563,8 @@ static bool crtc_can_fbc(struct intel_crtc *crtc)
 
if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
return crtc->pipe == PIPE_A;
+   else if (INTEL_INFO(dev_priv)->gen < 4)
+   return crtc->plane == PLANE_A;
else
return true;
 }
@@ -839,12 +841,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
goto out_disable;
}
 
-   if ((INTEL_INFO(dev_priv)->gen < 4 || HAS_DDI(dev_priv)) &&
-   crtc->plane != PLANE_A) {
-   set_no_fbc_reason(dev_priv, "FBC unsupported on plane");
-   goto out_disable;
-   }
-
/* The use of a CPU fence is mandatory in order to detect writes
 * by the CPU to the scanout and trigger updates to the FBC.
 */
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 17/18] drm/i915: move clock frequency checks from fbc_update to fbc_enable

2015-10-20 Thread Paulo Zanoni
These also can't change without a full modeset.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index af22bc8..7f54b6f 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -875,14 +875,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
goto out_disable;
}
 
-   /* WaFbcExceedCdClockThreshold:hsw,bdw */
-   if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
-   ilk_pipe_pixel_rate(crtc->config) >=
-   dev_priv->cdclk_freq * 95 / 100) {
-   set_no_fbc_reason(dev_priv, "pixel rate is too big");
-   goto out_disable;
-   }
-
/* It is possible for the required CFB size change without a
 * crtc->disable + crtc->enable since it is possible to change the
 * stride without triggering a full modeset. Since we try to
@@ -1099,6 +1091,14 @@ void intel_fbc_enable(struct intel_crtc *crtc)
goto out;
}
 
+   /* WaFbcExceedCdClockThreshold:hsw,bdw */
+   if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
+   ilk_pipe_pixel_rate(crtc->config) >=
+   dev_priv->cdclk_freq * 95 / 100) {
+   set_no_fbc_reason(dev_priv, "pixel rate is too big");
+   goto out;
+   }
+
if (intel_fbc_alloc_cfb(crtc)) {
set_no_fbc_reason(dev_priv, "not enough stolen memory");
goto out;
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 06/18] drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()

2015-10-20 Thread Paulo Zanoni
This change was part of the commit that makes intel_fbc_update()
receive an intel_crtc as argument instead of dev_priv, but since it
was polluting the diff with too many chunks I decided to move it to
its own commit.

It seems that our developers are favoring having this instead of the
old combination drm_crtc *crtc + intel_crtc *intel_crtc, and on the
mentioned commit we'll get rid of the drm_crtc variable, so let's do
an intermediate commit with the rename, so on the next commit we'll
have just struct intel_crtc *crtc.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index dd66649..e856304 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -870,8 +870,8 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
  */
 static void __intel_fbc_update(struct drm_i915_private *dev_priv)
 {
-   struct drm_crtc *crtc = NULL;
-   struct intel_crtc *intel_crtc;
+   struct drm_crtc *drm_crtc = NULL;
+   struct intel_crtc *crtc;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
const struct drm_display_mode *adjusted_mode;
@@ -901,8 +901,8 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 *   - new fb is too large to fit in compressed buffer
 *   - going to an unsupported config (interlace, pixel multiply, etc.)
 */
-   crtc = intel_fbc_find_crtc(dev_priv);
-   if (!crtc) {
+   drm_crtc = intel_fbc_find_crtc(dev_priv);
+   if (!drm_crtc) {
set_no_fbc_reason(dev_priv, "no output");
goto out_disable;
}
@@ -912,10 +912,10 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   intel_crtc = to_intel_crtc(crtc);
-   fb = crtc->primary->fb;
+   crtc = to_intel_crtc(drm_crtc);
+   fb = crtc->base.primary->fb;
obj = intel_fb_obj(fb);
-   adjusted_mode = &intel_crtc->config->base.adjusted_mode;
+   adjusted_mode = &crtc->config->base.adjusted_mode;
 
if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
(adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
@@ -923,13 +923,13 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   if (!intel_fbc_hw_tracking_covers_screen(intel_crtc)) {
+   if (!intel_fbc_hw_tracking_covers_screen(crtc)) {
set_no_fbc_reason(dev_priv, "mode too large for compression");
goto out_disable;
}
 
if ((INTEL_INFO(dev_priv)->gen < 4 || HAS_DDI(dev_priv)) &&
-   intel_crtc->plane != PLANE_A) {
+   crtc->plane != PLANE_A) {
set_no_fbc_reason(dev_priv, "FBC unsupported on plane");
goto out_disable;
}
@@ -943,7 +943,7 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
-   crtc->primary->state->rotation != BIT(DRM_ROTATE_0)) {
+   crtc->base.primary->state->rotation != BIT(DRM_ROTATE_0)) {
set_no_fbc_reason(dev_priv, "rotation unsupported");
goto out_disable;
}
@@ -966,13 +966,13 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 
/* WaFbcExceedCdClockThreshold:hsw,bdw */
if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
-   ilk_pipe_pixel_rate(intel_crtc->config) >=
+   ilk_pipe_pixel_rate(crtc->config) >=
dev_priv->cdclk_freq * 95 / 100) {
set_no_fbc_reason(dev_priv, "pixel rate is too big");
goto out_disable;
}
 
-   if (intel_fbc_setup_cfb(intel_crtc)) {
+   if (intel_fbc_setup_cfb(crtc)) {
set_no_fbc_reason(dev_priv, "not enough stolen memory");
goto out_disable;
}
@@ -982,9 +982,9 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 * cannot be unpinned (and have its GTT offset and fence revoked)
 * without first being decoupled from the scanout and FBC disabled.
 */
-   if (dev_priv->fbc.crtc == intel_crtc &&
+   if (dev_priv->fbc.crtc == crtc &&
dev_priv->fbc.fb_id == fb->base.id &&
-   dev_priv->fbc.y == crtc->y)
+   dev_priv->fbc.y == crtc->base.y)
return;
 
if (intel_fbc_enabled(dev_priv)) {
@@ -1015,7 +1015,7 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
__intel_fbc_disable(dev_priv);
}
 
-   intel_fbc_schedule_enable(intel_crtc);
+   intel_fbc_schedule_enable(crtc);
dev_priv->fbc.no_fbc_reason = "FBC enabled (not necessar

[Intel-gfx] [PATCH 11/18] drm/i915: refactor FBC deactivation at init

2015-10-20 Thread Paulo Zanoni
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the
call from intel_display.c.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ---
 drivers/gpu/drm/i915/intel_fbc.c | 5 +++--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fcaf865..7acdc77 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14839,9 +14839,6 @@ void intel_modeset_init(struct drm_device *dev)
i915_disable_vga(dev);
intel_setup_outputs(dev);
 
-   /* Just in case the BIOS is doing something questionable. */
-   intel_fbc_disable(dev_priv);
-
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev);
drm_modeset_unlock_all(dev);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 29becf7..15f74e2 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1103,9 +1103,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
enum pipe pipe;
 
mutex_init(&dev_priv->fbc.lock);
+   dev_priv->fbc.active = false;
 
if (!HAS_FBC(dev_priv)) {
-   dev_priv->fbc.active = false;
dev_priv->fbc.no_fbc_reason = "unsupported by this chipset";
return;
}
@@ -1146,5 +1146,6 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
I915_WRITE(FBC_CONTROL, 500 << FBC_CTL_INTERVAL_SHIFT);
}
 
-   dev_priv->fbc.active = dev_priv->fbc.is_active(dev_priv);
+   if (dev_priv->fbc.is_active(dev_priv))
+   dev_priv->fbc.deactivate(dev_priv);
 }
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 02/18] drm/i915: don't stop+start FBC at every flip

2015-10-20 Thread Paulo Zanoni
The hardware already takes care of disabling and recompressing FBC
when we do a page flip, so all we need to do is to update the fence
registers and move on.

One of the important things to notice is that on the pre-gen6
platforms the fence is programmed on the FBC control register and the
documentation says we can't update the control register while FBC is
enabled. This would basically mean we'd have to to disable+enable FBC
at every flip in order to make sure the hardware tracking still works,
which doesn't seem to make too much sense. So I sent an email to the
hardware team requesting some clarification. The information I got was
this:

"I don't think any hardware is latching on to 0x100100, 0x100104, or
the old fence number in FBC_CTL. Instructions against changing on the
fly would be to simplify testing and ensure you don't miss any
invalidation that happened right at that time."

So I guess we're fine for flips. But I can't really say I tested FBC
on these ancient platforms - nor that I'll ever propose enabling FBC
by default on them exactly because of problems like these.

Testcase: igt/kms_frontbuffer_tracking/fbc*-fliptrack
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_reg.h  |  3 +
 drivers/gpu/drm/i915/intel_display.c |  1 -
 drivers/gpu/drm/i915/intel_drv.h |  2 +
 drivers/gpu/drm/i915/intel_fbc.c | 98 +++-
 drivers/gpu/drm/i915/intel_frontbuffer.c |  1 +
 6 files changed, 103 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c334525..f04f56f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -930,6 +930,7 @@ struct i915_fbc {
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
void (*enable_fbc)(struct intel_crtc *crtc);
void (*disable_fbc)(struct drm_i915_private *dev_priv);
+   void (*flip_prepare)(struct drm_i915_private *dev_priv);
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ebf032..3620b59 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2028,6 +2028,7 @@ enum skl_disp_power_wells {
 #define   FBC_CTL_C3_IDLE  (1<<13)
 #define   FBC_CTL_STRIDE_SHIFT (5)
 #define   FBC_CTL_FENCENO_SHIFT(0)
+#define   FBC_CTL_FENCENO_MASK 0xF
 #define FBC_COMMAND0x0320c
 #define   FBC_CMD_COMPRESS (1<<0)
 #define FBC_STATUS 0x03210
@@ -2064,6 +2065,7 @@ enum skl_disp_power_wells {
 #define   DPFC_CTL_LIMIT_1X(0<<6)
 #define   DPFC_CTL_LIMIT_2X(1<<6)
 #define   DPFC_CTL_LIMIT_4X(2<<6)
+#define   DPFC_CTL_FENCE_MASK  0xF
 #define DPFC_RECOMP_CTL0x320c
 #define   DPFC_RECOMP_STALL_EN (1<<27)
 #define   DPFC_RECOMP_STALL_WM_SHIFT (16)
@@ -2086,6 +2088,7 @@ enum skl_disp_power_wells {
 #define   FBC_CTL_FALSE_COLOR  (1<<10)
 /* The bit 28-8 is reserved */
 #define   DPFC_RESERVED(0x1F00)
+#define   ILK_DPFC_FENCE_MASK  0xF
 #define ILK_DPFC_RECOMP_CTL0x4320c
 #define ILK_DPFC_STATUS0x43210
 #define ILK_DPFC_FENCE_YOFF0x43218
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1fc1d24..e83a428 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11470,7 +11470,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
  to_intel_plane(primary)->frontbuffer_bit);
mutex_unlock(&dev->struct_mutex);
 
-   intel_fbc_disable_crtc(intel_crtc);
intel_frontbuffer_flip_prepare(dev,
   
to_intel_plane(primary)->frontbuffer_bit);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dc55e4c..1e08c8a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1287,6 +1287,8 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
  enum fb_op_origin origin);
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
+void intel_fbc_flip_prepare(struct drm_i915_private *dev_priv,
+   unsigned int frontbuffer_bits);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index d9d7e54..9477379 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -82,6 +82,22 @@ static void i8xx_fbc_disable(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("disabled FBC\n");
 }
 
+static void i8xx_fbc_flip_prepare(struct drm_i915_private *dev_priv)
+{
+   struct intel_crtc *crtc = dev_priv->fbc.crtc;
+   struct drm_framebuffer *fb = crtc->base.primary->fb;
+   struct drm_i915_g

[Intel-gfx] [PATCH 01/18] drm/i915: change no_fbc_reason from enum to string

2015-10-20 Thread Paulo Zanoni
I wanted to add yet another check to intel_fbc_update() and realized
I would need to create yet another enum no_fbc_reason case. So I
remembered this patch series that Damien wrote a long time ago and
nobody ever reviewed, so I decided to reimplement it since the code
changed a lot since then.

Credits-to: Damien Lespiau 
Cc: Damien Lespiau 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h | 19 +
 drivers/gpu/drm/i915/intel_drv.h|  1 -
 drivers/gpu/drm/i915/intel_fbc.c| 77 +
 4 files changed, 20 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a3b22bd..6ac4ba3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1640,7 +1640,7 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
seq_puts(m, "FBC enabled\n");
else
seq_printf(m, "FBC disabled: %s\n",
- intel_no_fbc_reason_str(dev_priv->fbc.no_fbc_reason));
+  dev_priv->fbc.no_fbc_reason);
 
if (INTEL_INFO(dev_priv)->gen >= 7)
seq_printf(m, "Compressing: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8afda45..c334525 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -925,24 +925,7 @@ struct i915_fbc {
struct drm_framebuffer *fb;
} *fbc_work;
 
-   enum no_fbc_reason {
-   FBC_OK, /* FBC is enabled */
-   FBC_UNSUPPORTED, /* FBC is not supported by this chipset */
-   FBC_NO_OUTPUT, /* no outputs enabled to compress */
-   FBC_STOLEN_TOO_SMALL, /* not enough space for buffers */
-   FBC_UNSUPPORTED_MODE, /* interlace or doublescanned mode */
-   FBC_MODE_TOO_LARGE, /* mode too large for compression */
-   FBC_BAD_PLANE, /* fbc not supported on plane */
-   FBC_NOT_TILED, /* buffer not tiled */
-   FBC_MULTIPLE_PIPES, /* more than one pipe active */
-   FBC_MODULE_PARAM,
-   FBC_CHIP_DEFAULT, /* disabled by default on this chip */
-   FBC_ROTATION, /* rotation is not supported */
-   FBC_IN_DBG_MASTER, /* kernel debugger is active */
-   FBC_BAD_STRIDE, /* stride is not supported */
-   FBC_PIXEL_RATE, /* pixel rate is too big */
-   FBC_PIXEL_FORMAT /* pixel format is invalid */
-   } no_fbc_reason;
+   const char *no_fbc_reason;
 
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
void (*enable_fbc)(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 27dccf3..dc55e4c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1287,7 +1287,6 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
  enum fb_op_origin origin);
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
-const char *intel_no_fbc_reason_str(enum no_fbc_reason reason);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index cf47352..d9d7e54 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -471,55 +471,14 @@ void intel_fbc_disable_crtc(struct intel_crtc *crtc)
mutex_unlock(&dev_priv->fbc.lock);
 }
 
-const char *intel_no_fbc_reason_str(enum no_fbc_reason reason)
-{
-   switch (reason) {
-   case FBC_OK:
-   return "FBC enabled but currently disabled in hardware";
-   case FBC_UNSUPPORTED:
-   return "unsupported by this chipset";
-   case FBC_NO_OUTPUT:
-   return "no output";
-   case FBC_STOLEN_TOO_SMALL:
-   return "not enough stolen memory";
-   case FBC_UNSUPPORTED_MODE:
-   return "mode incompatible with compression";
-   case FBC_MODE_TOO_LARGE:
-   return "mode too large for compression";
-   case FBC_BAD_PLANE:
-   return "FBC unsupported on plane";
-   case FBC_NOT_TILED:
-   return "framebuffer not tiled or fenced";
-   case FBC_MULTIPLE_PIPES:
-   return "more than one pipe active";
-   case FBC_MODULE_PARAM:
-   return "disabled per module param";
-   case FBC_CHIP_DEFAULT:
-   return "disabled per chip default";
-   case FBC_ROTATION:
-   return "rotation unsupported";
-   case FBC_IN_DBG_MASTER:
-   return "Kernel debugger is active";
-   case FBC_BAD_STRIDE:
-   return "framebuffer stride not supported";
-

[Intel-gfx] [PATCH 00/18] Yet another FBC series

2015-10-20 Thread Paulo Zanoni
Hello

This series has two main goals:
  - Simplify FBC handling so we don't recompute state or disable+reenable when
it's not necessary.
  - Solve the CFB race we have that make it possible for the hardware to use the
CFB even after we free its drm_mm node.

Of course we can always do more and more code reworks, but this series kills the
last real bugs I can see on HSW+, so it will be time to consider enabling FBC on
these platforms after we merge the series.

Thanks,
Paulo

Paulo Zanoni (18):
  drm/i915: change no_fbc_reason from enum to string
  drm/i915: don't stop+start FBC at every flip
  drm/i915: only nuke FBC when a drawing operation triggers a flush
  drm/i915: extract crtc_is_valid() on the FBC code
  drm/i915: set dev_priv->fbc.crtc before scheduling the enable work
  drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()
  drm/i915: fix the __intel_fbc_update() comments
  drm/i915: pass the crtc as an argument to intel_fbc_update()
  drm/i915: don't disable_fbc() if FBC is already disabled
  drm/i915: introduce is_active/activate/deactivate to the FBC
terminology
  drm/i915: refactor FBC deactivation at init
  drm/i915: introduce intel_fbc_{enable,disable}
  drm/i915: remove too-frequent FBC debug message
  drm/i915: fix the CFB size check
  drm/i915: alloc/free the FBC CFB during enable/disable
  drm/i915: move adjusted_mode checks from fbc_update to fbc_enable
  drm/i915: move clock frequency checks from fbc_update to fbc_enable
  drm/i915: check for FBC planes in the same place as the pipes

 drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |  32 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_display.c |  25 +-
 drivers/gpu/drm/i915/intel_drv.h |   9 +-
 drivers/gpu/drm/i915/intel_fbc.c | 715 ++-
 drivers/gpu/drm/i915/intel_frontbuffer.c |   1 +
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 8 files changed, 447 insertions(+), 344 deletions(-)

-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 14/18] drm/i915: fix the CFB size check

2015-10-20 Thread Paulo Zanoni
In function find_compression_threshold() we try to over-allocate CFB
space in order to reudce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.

There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 5dab0e0..bf855b2 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -733,7 +733,8 @@ static int intel_fbc_setup_cfb(struct intel_crtc *crtc)
size = intel_fbc_calculate_cfb_size(crtc);
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
 
-   if (size <= dev_priv->fbc.uncompressed_size)
+   if (dev_priv->fbc.compressed_fb.allocated &&
+   size <= dev_priv->fbc.compressed_fb.size * dev_priv->fbc.threshold)
return 0;
 
/* Release any current block */
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 05/18] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

2015-10-20 Thread Paulo Zanoni
This thing where we need to get the crtc either from the work
structure or the fbc structure itself is confusing and unnecessary.
Set fbc.crtc right when scheduling the enable work so we can always
use it.

Besides the immediate advantages, this is also going to make one of
the next commits much simpler.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_fbc.c | 25 ++---
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f04f56f..2cb7a05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -921,7 +921,6 @@ struct i915_fbc {
 
struct intel_fbc_work {
struct delayed_work work;
-   struct intel_crtc *crtc;
struct drm_framebuffer *fb;
} *fbc_work;
 
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 1162787..dd66649 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -385,14 +385,13 @@ bool intel_fbc_enabled(struct drm_i915_private *dev_priv)
return dev_priv->fbc.enabled;
 }
 
-static void intel_fbc_enable(struct intel_crtc *crtc,
-const struct drm_framebuffer *fb)
+static void intel_fbc_enable(const struct drm_framebuffer *fb)
 {
-   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   struct drm_i915_private *dev_priv = fb->dev->dev_private;
+   struct intel_crtc *crtc = dev_priv->fbc.crtc;
 
dev_priv->fbc.enable_fbc(crtc);
 
-   dev_priv->fbc.crtc = crtc;
dev_priv->fbc.fb_id = fb->base.id;
dev_priv->fbc.y = crtc->base.y;
 }
@@ -402,8 +401,8 @@ static void intel_fbc_work_fn(struct work_struct *__work)
struct intel_fbc_work *work =
container_of(to_delayed_work(__work),
 struct intel_fbc_work, work);
-   struct drm_i915_private *dev_priv = work->crtc->base.dev->dev_private;
-   struct drm_framebuffer *crtc_fb = work->crtc->base.primary->fb;
+   struct drm_i915_private *dev_priv = work->fb->dev->dev_private;
+   struct drm_framebuffer *crtc_fb = dev_priv->fbc.crtc->base.primary->fb;
 
mutex_lock(&dev_priv->fbc.lock);
if (work == dev_priv->fbc.fbc_work) {
@@ -411,7 +410,7 @@ static void intel_fbc_work_fn(struct work_struct *__work)
 * the prior work.
 */
if (crtc_fb == work->fb)
-   intel_fbc_enable(work->crtc, work->fb);
+   intel_fbc_enable(work->fb);
 
dev_priv->fbc.fbc_work = NULL;
}
@@ -453,15 +452,15 @@ static void intel_fbc_schedule_enable(struct intel_crtc 
*crtc)
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
intel_fbc_cancel_work(dev_priv);
+   dev_priv->fbc.crtc = crtc;
 
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL) {
DRM_ERROR("Failed to allocate FBC work structure\n");
-   intel_fbc_enable(crtc, crtc->base.primary->fb);
+   intel_fbc_enable(crtc->base.primary->fb);
return;
}
 
-   work->crtc = crtc;
work->fb = crtc->base.primary->fb;
INIT_DELAYED_WORK(&work->work, intel_fbc_work_fn);
 
@@ -1059,11 +1058,8 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
 
mutex_lock(&dev_priv->fbc.lock);
 
-   if (dev_priv->fbc.enabled)
+   if (dev_priv->fbc.enabled || dev_priv->fbc.fbc_work)
fbc_bits = INTEL_FRONTBUFFER_PRIMARY(dev_priv->fbc.crtc->pipe);
-   else if (dev_priv->fbc.fbc_work)
-   fbc_bits = INTEL_FRONTBUFFER_PRIMARY(
-   dev_priv->fbc.fbc_work->crtc->pipe);
else
fbc_bits = dev_priv->fbc.possible_framebuffer_bits;
 
@@ -1119,8 +1115,7 @@ void intel_fbc_flip_prepare(struct drm_i915_private 
*dev_priv,
if (fbc_bits & frontbuffer_bits)
dev_priv->fbc.flip_prepare(dev_priv);
} else if (dev_priv->fbc.fbc_work) {
-   fbc_bits = INTEL_FRONTBUFFER_PRIMARY(
-   dev_priv->fbc.fbc_work->crtc->pipe);
+   fbc_bits = INTEL_FRONTBUFFER_PRIMARY(dev_priv->fbc.crtc->pipe);
if (fbc_bits & frontbuffer_bits)
__intel_fbc_disable(dev_priv);
}
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v7 08/25] drm: Add color correction state flag

2015-10-20 Thread kbuild test robot
Hi Shashank,

[auto build test WARNING on drm-intel/for-linux-next -- if it's inappropriate 
base, please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/Color-Management-for-DRM-framework/20151020-202959
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for 
parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for 
parameter 'fmt'
   drivers/gpu/drm/drm_atomic.c:407: warning: No description found for 
parameter 'dev'
>> include/drm/drm_crtc.h:314: warning: No description found for parameter 
>> 'color_correction_changed'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'mode_blob'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'palette_before_ctm_blob'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'palette_after_ctm_blob'
   include/drm/drm_crtc.h:314: warning: No description found for parameter 
'ctm_blob'
   include/drm/drm_crtc.h:746: warning: No description found for parameter 
'tile_blob_ptr'
   include/drm/drm_crtc.h:785: warning: No description found for parameter 
'rotation'
   include/drm/drm_crtc.h:881: warning: No description found for parameter 
'mutex'
   include/drm/drm_crtc.h:881: warning: No description found for parameter 
'helper_private'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tile_idr'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'delayed_event'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'edid_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'dpms_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'path_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tile_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'plane_type_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'rotation_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_x'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_y'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_w'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_src_h'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_x'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_y'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_w'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_h'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_fb_id'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_crtc_id'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_active'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'prop_mode_id'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_select_subconnector_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_mode_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_left_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_right_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_top_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_bottom_margin_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_brightness_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_contrast_property'
   include/drm/drm_crtc.h:1175: warning: No description found for parameter 
'tv_flicker_red

[Intel-gfx] [PATCH v3 40/43] drm/i915: Store aux data reg offsets in intel_dp->aux_ch_data_reg[]

2015-10-20 Thread ville . syrjala
From: Ville Syrjälä 

Rather than computing on demand, store also the aux data reg
offsets under intel_dp.

v2: Duplicate some code to make things less magic (Jani)
v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg()

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c  | 94 +++-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 85 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ca219be..cb41802 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -791,7 +791,6 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t ch_ctl = intel_dp->aux_ch_ctl_reg;
-   uint32_t ch_data = ch_ctl + 4;
uint32_t aux_clock_divider;
int i, ret, recv_bytes;
uint32_t status;
@@ -857,7 +856,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
for (try = 0; try < 5; try++) {
/* Load the send data into the aux channel data 
registers */
for (i = 0; i < send_bytes; i += 4)
-   I915_WRITE(ch_data + i,
+   I915_WRITE(intel_dp->aux_ch_data_reg[i >> 2],
   intel_dp_pack_aux(send + i,
 send_bytes - i));
 
@@ -921,7 +920,7 @@ done:
recv_bytes = recv_size;
 
for (i = 0; i < recv_bytes; i += 4)
-   intel_dp_unpack_aux(I915_READ(ch_data + i),
+   intel_dp_unpack_aux(I915_READ(intel_dp->aux_ch_data_reg[i >> 
2]),
recv + i, recv_bytes - i);
 
ret = recv_bytes;
@@ -1023,6 +1022,20 @@ static uint32_t g4x_aux_ctl_reg(struct drm_i915_private 
*dev_priv,
}
 }
 
+static uint32_t g4x_aux_data_reg(struct drm_i915_private *dev_priv,
+enum port port, int index)
+{
+   switch (port) {
+   case PORT_B:
+   case PORT_C:
+   case PORT_D:
+   return DP_AUX_CH_DATA(port, index);
+   default:
+   MISSING_CASE(port);
+   return DP_AUX_CH_DATA(PORT_B, index);
+   }
+}
+
 static uint32_t ilk_aux_ctl_reg(struct drm_i915_private *dev_priv,
enum port port)
 {
@@ -1039,6 +1052,22 @@ static uint32_t ilk_aux_ctl_reg(struct drm_i915_private 
*dev_priv,
}
 }
 
+static uint32_t ilk_aux_data_reg(struct drm_i915_private *dev_priv,
+enum port port, int index)
+{
+   switch (port) {
+   case PORT_A:
+   return DP_AUX_CH_DATA(port, index);
+   case PORT_B:
+   case PORT_C:
+   case PORT_D:
+   return PCH_DP_AUX_CH_DATA(port, index);
+   default:
+   MISSING_CASE(port);
+   return DP_AUX_CH_DATA(PORT_A, index);
+   }
+}
+
 /*
  * On SKL we don't have Aux for port E so we rely
  * on VBT to set a proper alternate aux channel.
@@ -1081,11 +1110,61 @@ static uint32_t skl_aux_ctl_reg(struct drm_i915_private 
*dev_priv,
}
 }
 
+static uint32_t skl_aux_data_reg(struct drm_i915_private *dev_priv,
+enum port port, int index)
+{
+   if (port == PORT_E)
+   port = skl_porte_aux_port(dev_priv);
+
+   switch (port) {
+   case PORT_A:
+   case PORT_B:
+   case PORT_C:
+   case PORT_D:
+   return DP_AUX_CH_DATA(port, index);
+   default:
+   MISSING_CASE(port);
+   return DP_AUX_CH_DATA(PORT_A, index);
+   }
+}
+
+static uint32_t intel_aux_ctl_reg(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+   if (INTEL_INFO(dev_priv)->gen >= 9)
+   return skl_aux_ctl_reg(dev_priv, port);
+   else if (HAS_PCH_SPLIT(dev_priv))
+   return ilk_aux_ctl_reg(dev_priv, port);
+   else
+   return g4x_aux_ctl_reg(dev_priv, port);
+}
+
+static uint32_t intel_aux_data_reg(struct drm_i915_private *dev_priv,
+  enum port port, int index)
+{
+   if (INTEL_INFO(dev_priv)->gen >= 9)
+   return skl_aux_data_reg(dev_priv, port, index);
+   else if (HAS_PCH_SPLIT(dev_priv))
+   return ilk_aux_data_reg(dev_priv, port, index);
+   else
+   return g4x_aux_data_reg(dev_priv, port, index);
+}
+
+static void intel_aux_reg_init(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+   enum port port = dp_to_dig_port(intel_dp)->port;
+   int i;
+
+   intel_dp->aux_ch_ctl_reg = intel_aux_ctl_reg(dev_priv, port);
+   for (i = 0; i < ARRAY_SIZE(intel_dp->aux_ch_data_reg); i++)
+   intel_dp->aux

[Intel-gfx] [PATCH v3 38/43] drm/i915: Parametrize AUX registers

2015-10-20 Thread ville . syrjala
From: Ville Syrjälä 

v2: Keep some MISSING_CASE() stuff (Jani)
s/-1/-PIPE_B/ in the register macro
Fix typo in patch subject
v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  | 102 ---
 drivers/gpu/drm/i915/intel_dp.c  |  23 +++--
 drivers/gpu/drm/i915/intel_psr.c |   5 +-
 3 files changed, 63 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2c518a0..7723ed3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3068,11 +3068,7 @@ enum skl_disp_power_wells {
 #define   EDP_PSR_IDLE_FRAME_SHIFT 0
 
 #define EDP_PSR_AUX_CTL(dev)   (EDP_PSR_BASE(dev) + 0x10)
-#define EDP_PSR_AUX_DATA1(dev) (EDP_PSR_BASE(dev) + 0x14)
-#define EDP_PSR_AUX_DATA2(dev) (EDP_PSR_BASE(dev) + 0x18)
-#define EDP_PSR_AUX_DATA3(dev) (EDP_PSR_BASE(dev) + 0x1c)
-#define EDP_PSR_AUX_DATA4(dev) (EDP_PSR_BASE(dev) + 0x20)
-#define EDP_PSR_AUX_DATA5(dev) (EDP_PSR_BASE(dev) + 0x24)
+#define EDP_PSR_AUX_DATA(dev, i)   (EDP_PSR_BASE(dev) + 0x14 + (i) 
* 4) /* 5 registers */
 
 #define EDP_PSR_STATUS_CTL(dev)(EDP_PSR_BASE(dev) + 
0x40)
 #define   EDP_PSR_STATUS_STATE_MASK(7<<29)
@@ -4188,33 +4184,36 @@ enum skl_disp_power_wells {
  * is 20 bytes in each direction, hence the 5 fixed
  * data registers
  */
-#define DPA_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 0x64010)
-#define DPA_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64014)
-#define DPA_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64018)
-#define DPA_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6401c)
-#define DPA_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64020)
-#define DPA_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64024)
-
-#define DPB_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 0x64110)
-#define DPB_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64114)
-#define DPB_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64118)
-#define DPB_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6411c)
-#define DPB_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64120)
-#define DPB_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64124)
-
-#define DPC_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 0x64210)
-#define DPC_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64214)
-#define DPC_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64218)
-#define DPC_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6421c)
-#define DPC_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64220)
-#define DPC_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64224)
-
-#define DPD_AUX_CH_CTL (dev_priv->info.display_mmio_offset + 0x64310)
-#define DPD_AUX_CH_DATA1   (dev_priv->info.display_mmio_offset + 0x64314)
-#define DPD_AUX_CH_DATA2   (dev_priv->info.display_mmio_offset + 0x64318)
-#define DPD_AUX_CH_DATA3   (dev_priv->info.display_mmio_offset + 0x6431c)
-#define DPD_AUX_CH_DATA4   (dev_priv->info.display_mmio_offset + 0x64320)
-#define DPD_AUX_CH_DATA5   (dev_priv->info.display_mmio_offset + 0x64324)
+#define _DPA_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64010)
+#define _DPA_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64014)
+#define _DPA_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64018)
+#define _DPA_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6401c)
+#define _DPA_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64020)
+#define _DPA_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64024)
+
+#define _DPB_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64110)
+#define _DPB_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64114)
+#define _DPB_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64118)
+#define _DPB_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6411c)
+#define _DPB_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64120)
+#define _DPB_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64124)
+
+#define _DPC_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64210)
+#define _DPC_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64214)
+#define _DPC_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64218)
+#define _DPC_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6421c)
+#define _DPC_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64220)
+#define _DPC_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64224)
+
+#define _DPD_AUX_CH_CTL 

[Intel-gfx] [PATCH v2 39/43] drm/i915: Add dev_priv->psr_mmio_base

2015-10-20 Thread ville . syrjala
From: Ville Syrjälä 

Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
under dev_priv, like we for DSI and GPIO for example.

TODO: could probably move a bunch of this kind of stuff into the device
info instead...

v2: Drop the surious whitespace change (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_reg.h | 15 ---
 drivers/gpu/drm/i915/intel_psr.c| 27 +++
 4 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c38f766..74b17b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2536,7 +2536,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
   yesno(work_busy(&dev_priv->psr.work.work)));
 
if (HAS_DDI(dev))
-   enabled = I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE;
+   enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
else {
for_each_pipe(dev_priv, pipe) {
stat[pipe] = I915_READ(VLV_PSRSTAT(pipe)) &
@@ -2558,7 +2558,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
 
/* CHV PSR has no kind of performance counter */
if (HAS_DDI(dev)) {
-   psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) &
+   psrperf = I915_READ(EDP_PSR_PERF_CNT) &
EDP_PSR_PERF_CNT_MASK;
 
seq_printf(m, "Performance_Counter: %u\n", psrperf);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e79f239..71a496d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1744,6 +1744,8 @@ struct drm_i915_private {
/* MMIO base address for MIPI regs */
uint32_t mipi_mmio_base;
 
+   uint32_t psr_mmio_base;
+
wait_queue_head_t gmbus_wait_queue;
 
struct pci_dev *bridge_dev;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7723ed3..ed90915 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3043,8 +3043,9 @@ enum skl_disp_power_wells {
 #define VLV_PSRSTAT(pipe) _PIPE(pipe, _PSRSTATA, _PSRSTATB)
 
 /* HSW+ eDP PSR registers */
-#define EDP_PSR_BASE(dev)   (IS_HASWELL(dev) ? 0x64800 : 
0x6f800)
-#define EDP_PSR_CTL(dev)   (EDP_PSR_BASE(dev) + 0)
+#define HSW_EDP_PSR_BASE   0x64800
+#define BDW_EDP_PSR_BASE   0x6f800
+#define EDP_PSR_CTL(dev_priv->psr_mmio_base + 0)
 #define   EDP_PSR_ENABLE   (1<<31)
 #define   BDW_PSR_SINGLE_FRAME (1<<30)
 #define   EDP_PSR_LINK_STANDBY (1<<27)
@@ -3067,10 +3068,10 @@ enum skl_disp_power_wells {
 #define   EDP_PSR_TP1_TIME_0us (3<<4)
 #define   EDP_PSR_IDLE_FRAME_SHIFT 0
 
-#define EDP_PSR_AUX_CTL(dev)   (EDP_PSR_BASE(dev) + 0x10)
-#define EDP_PSR_AUX_DATA(dev, i)   (EDP_PSR_BASE(dev) + 0x14 + (i) 
* 4) /* 5 registers */
+#define EDP_PSR_AUX_CTL
(dev_priv->psr_mmio_base + 0x10)
+#define EDP_PSR_AUX_DATA(i)(dev_priv->psr_mmio_base + 0x14 
+ (i) * 4) /* 5 registers */
 
-#define EDP_PSR_STATUS_CTL(dev)(EDP_PSR_BASE(dev) + 
0x40)
+#define EDP_PSR_STATUS_CTL (dev_priv->psr_mmio_base + 0x40)
 #define   EDP_PSR_STATUS_STATE_MASK(7<<29)
 #define   EDP_PSR_STATUS_STATE_IDLE(0<<29)
 #define   EDP_PSR_STATUS_STATE_SRDONACK(1<<29)
@@ -3094,10 +3095,10 @@ enum skl_disp_power_wells {
 #define   EDP_PSR_STATUS_SENDING_TP1   (1<<4)
 #define   EDP_PSR_STATUS_IDLE_MASK 0xf
 
-#define EDP_PSR_PERF_CNT(dev)  (EDP_PSR_BASE(dev) + 0x44)
+#define EDP_PSR_PERF_CNT   (dev_priv->psr_mmio_base + 0x44)
 #define   EDP_PSR_PERF_CNT_MASK0xff
 
-#define EDP_PSR_DEBUG_CTL(dev) (EDP_PSR_BASE(dev) + 0x60)
+#define EDP_PSR_DEBUG_CTL  (dev_priv->psr_mmio_base + 0x60)
 #define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
 #define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
 #define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ff66718..3c973c5 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -183,9 +183,9 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
DP_AUX_FRAME_SYNC_ENABLE);
 
aux_data_reg = (INTEL_INFO(dev)->gen >= 9) ?
-   DP_AUX_CH_DATA(port, 0) : EDP_PSR_AUX_DATA(dev, 0);
+   DP_AUX_CH_DATA(port, 0) : EDP_PSR_AUX_DATA(0);
aux_ctl_reg = (INTEL_INFO(dev)->gen

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

2015-10-20 Thread da...@codemonkey.org.uk
On Tue, Oct 20, 2015 at 03:33:27PM +1000, Dave Airlie wrote:
 > On 20 October 2015 at 07:54, Daniel Vetter  wrote:
 > > On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
 > >> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
 > >>
 > >>  > > The warning on boot seems to be gone as of rc3, but I can now 
 > >> trigger this pretty easily..
 > >>  >
 > >>  > http://patchwork.freedesktop.org/patch/60618/
 > >>
 > >> Back from several weeks of travel..  I tried again with rc6, and
 > >> I'm still seeing the same traces.
 > >
 > > Oh crap, applied patch to wrong tree. We need to cherry-pick
 > >
 > > commit 621bd0f6982badd6483acb191eb7b6226a578328
 > > Author: Daniel Vetter 
 > > Date:   Tue Sep 29 09:56:53 2015 +0200
 > >
 > > drm: Fix locking for sysfs dpms file
 > >
 > > to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
 > > even comes with the needed cc: stable included (since the locking breakage
 > > was done in 4.0, it only surface due to a new warning in 4.3).
 > 
 > That is already in Linus's tree, I picked it last week I think.

Yeah, that's in the tree I'm testing.

Dave
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm/i915/skl: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

v2: Do not access potentialy old plane state at flip time,
but store the rotation value at the time of queing the flip.
(Ville)

Signed-off-by: Tvrtko Ursulin 
Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL)
Cc: Sonika Jindal 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 30 +++---
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1fc1d240d3c1..9cb29086971a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11091,13 +11091,14 @@ static bool use_mmio_flip(struct intel_engine_cs 
*ring,
 }
 
 static void skl_do_mmio_flip(struct intel_crtc *intel_crtc,
+unsigned int rotation,
 struct intel_unpin_work *work)
 {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride;
+   u32 ctl, stride, tile_height;
 
ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11121,9 +11122,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc,
 * The stride is either expressed as a multiple of 64 bytes chunks for
 * linear buffers or in number of tiles for tiled buffers.
 */
-   stride = fb->pitches[0] /
-intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+   if (intel_rotation_90_or_270(rotation)) {
+   /* stride = Surface height in tiles */
+   tile_height = intel_tile_height(dev, fb->pixel_format,
+   fb->modifier[0], 0);
+   stride = DIV_ROUND_UP(fb->height, tile_height);
+   } else {
+   stride = fb->pitches[0] /
+   intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+   }
 
/*
 * Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
@@ -11181,7 +11189,7 @@ static void intel_do_mmio_flip(struct intel_mmio_flip 
*mmio_flip)
intel_pipe_update_start(crtc);
 
if (INTEL_INFO(mmio_flip->i915)->gen >= 9)
-   skl_do_mmio_flip(crtc, work);
+   skl_do_mmio_flip(crtc, mmio_flip->rotation, work);
else
/* use_mmio_flip() retricts MMIO flips to ilk+ */
ilk_do_mmio_flip(crtc, work);
@@ -11208,10 +11216,8 @@ static void intel_mmio_flip_work_func(struct 
work_struct *work)
 
 static int intel_queue_mmio_flip(struct drm_device *dev,
 struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj,
-struct intel_engine_cs *ring,
-uint32_t flags)
+unsigned int rotation,
+struct drm_i915_gem_object *obj)
 {
struct intel_mmio_flip *mmio_flip;
 
@@ -11222,6 +11228,7 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
mmio_flip->i915 = to_i915(dev);
mmio_flip->req = i915_gem_request_reference(obj->last_write_req);
mmio_flip->crtc = to_intel_crtc(crtc);
+   mmio_flip->rotation = rotation;
 
INIT_WORK(&mmio_flip->work, intel_mmio_flip_work_func);
schedule_work(&mmio_flip->work);
@@ -11438,8 +11445,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work->gtt_offset += intel_crtc->dspaddr_offset;
 
if (mmio_flip) {
-   ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
-   page_flip_flags);
+   ret = intel_queue_mmio_flip(dev, crtc,
+   crtc->primary->state->rotation,
+   obj);
if (ret)
goto cleanup_unpin;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 27dccf35f9bc..140f949302c7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -493,6 +493,7 @@ struct intel_mmio_flip {
struct drm_i915_private *i915;
struct drm_i915_gem_request *req;
struct intel_crtc *crtc;
+   unsigned int rotation;
 };
 
 struct skl_pipe_wm {
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://

[Intel-gfx] [PATCH v2] drm/i915/skl: Assume no scaling is available when things are not as expected

2015-10-20 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Cdclk < crtc_clock is not allowed and suggests a different problem
elsewhere in the code.

It is more robust and safe to assume no scaling is possible in
this case with no other downsides since it will also WARN_ON_ONCE
so that this definitely gets noticed.

Call it an assert to help new platform bring-up in simulation.

v2: Better commit msg and use WARN_ON_ONCE to signify the unexpectedness.

Signed-off-by: Tvrtko Ursulin 
Cc: 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 9cb29086971a..f315ed45358f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13439,7 +13439,7 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
 
-   if (!crtc_clock || !cdclk)
+   if (!crtc_clock || !cdclk || WARN_ON_ONCE(cdclk < crtc_clock))
return DRM_PLANE_HELPER_NO_SCALING;
 
/*
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915/skl: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Ville Syrjälä
On Tue, Oct 20, 2015 at 03:54:11PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Previously rotation was ignored and wrong stride programmed
> into the plane registers resulting in a corrupt image on screen.
> 
> v2: Do not access potentialy old plane state at flip time,
> but store the rotation value at the time of queing the flip.
> (Ville)
> 
> Signed-off-by: Tvrtko Ursulin 
> Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL)
> Cc: Sonika Jindal 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 30 +++---
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  2 files changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1fc1d240d3c1..9cb29086971a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11091,13 +11091,14 @@ static bool use_mmio_flip(struct intel_engine_cs 
> *ring,
>  }
>  
>  static void skl_do_mmio_flip(struct intel_crtc *intel_crtc,
> +  unsigned int rotation,
>struct intel_unpin_work *work)
>  {
>   struct drm_device *dev = intel_crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
>   const enum pipe pipe = intel_crtc->pipe;
> - u32 ctl, stride;
> + u32 ctl, stride, tile_height;
>  
>   ctl = I915_READ(PLANE_CTL(pipe, 0));
>   ctl &= ~PLANE_CTL_TILED_MASK;
> @@ -11121,9 +11122,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
> *intel_crtc,
>* The stride is either expressed as a multiple of 64 bytes chunks for
>* linear buffers or in number of tiles for tiled buffers.
>*/
> - stride = fb->pitches[0] /
> -  intel_fb_stride_alignment(dev, fb->modifier[0],
> -fb->pixel_format);
> + if (intel_rotation_90_or_270(rotation)) {
> + /* stride = Surface height in tiles */
> + tile_height = intel_tile_height(dev, fb->pixel_format,
> + fb->modifier[0], 0);
> + stride = DIV_ROUND_UP(fb->height, tile_height);
> + } else {
> + stride = fb->pitches[0] /
> + intel_fb_stride_alignment(dev, fb->modifier[0],
> +   fb->pixel_format);
> + }
>  
>   /*
>* Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
> @@ -11181,7 +11189,7 @@ static void intel_do_mmio_flip(struct intel_mmio_flip 
> *mmio_flip)
>   intel_pipe_update_start(crtc);
>  
>   if (INTEL_INFO(mmio_flip->i915)->gen >= 9)
> - skl_do_mmio_flip(crtc, work);
> + skl_do_mmio_flip(crtc, mmio_flip->rotation, work);
>   else
>   /* use_mmio_flip() retricts MMIO flips to ilk+ */
>   ilk_do_mmio_flip(crtc, work);
> @@ -11208,10 +11216,8 @@ static void intel_mmio_flip_work_func(struct 
> work_struct *work)
>  
>  static int intel_queue_mmio_flip(struct drm_device *dev,
>struct drm_crtc *crtc,
> -  struct drm_framebuffer *fb,
> -  struct drm_i915_gem_object *obj,
> -  struct intel_engine_cs *ring,
> -  uint32_t flags)
> +  unsigned int rotation,
> +  struct drm_i915_gem_object *obj)
>  {
>   struct intel_mmio_flip *mmio_flip;
>  
> @@ -11222,6 +11228,7 @@ static int intel_queue_mmio_flip(struct drm_device 
> *dev,
>   mmio_flip->i915 = to_i915(dev);
>   mmio_flip->req = i915_gem_request_reference(obj->last_write_req);
>   mmio_flip->crtc = to_intel_crtc(crtc);
> + mmio_flip->rotation = rotation;

Could just do the crtc->primary->state->rotation thing here and avoid
having to pass the rotation from the caller.

But the patch looks OK anyway:
Reviewed-by: Ville Syrjälä 

>  
>   INIT_WORK(&mmio_flip->work, intel_mmio_flip_work_func);
>   schedule_work(&mmio_flip->work);
> @@ -11438,8 +11445,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
>   work->gtt_offset += intel_crtc->dspaddr_offset;
>  
>   if (mmio_flip) {
> - ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
> - page_flip_flags);
> + ret = intel_queue_mmio_flip(dev, crtc,
> + crtc->primary->state->rotation,
> + obj);
>   if (ret)
>   goto cleanup_unpin;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 27dccf35f9bc..140f949302c7 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/in

Re: [Intel-gfx] [PATCH v2] drm/i915/skl: Consider plane rotation when calculating stride in skl_do_mmio_flip

2015-10-20 Thread Tvrtko Ursulin


On 20/10/15 16:08, Ville Syrjälä wrote:

On Tue, Oct 20, 2015 at 03:54:11PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

v2: Do not access potentialy old plane state at flip time,
 but store the rotation value at the time of queing the flip.
 (Ville)

Signed-off-by: Tvrtko Ursulin 
Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL)
Cc: Sonika Jindal 
Cc: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_display.c | 30 +++---
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1fc1d240d3c1..9cb29086971a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11091,13 +11091,14 @@ static bool use_mmio_flip(struct intel_engine_cs 
*ring,
  }

  static void skl_do_mmio_flip(struct intel_crtc *intel_crtc,
+unsigned int rotation,
 struct intel_unpin_work *work)
  {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride;
+   u32 ctl, stride, tile_height;

ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11121,9 +11122,16 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc,
 * The stride is either expressed as a multiple of 64 bytes chunks for
 * linear buffers or in number of tiles for tiled buffers.
 */
-   stride = fb->pitches[0] /
-intel_fb_stride_alignment(dev, fb->modifier[0],
-  fb->pixel_format);
+   if (intel_rotation_90_or_270(rotation)) {
+   /* stride = Surface height in tiles */
+   tile_height = intel_tile_height(dev, fb->pixel_format,
+   fb->modifier[0], 0);
+   stride = DIV_ROUND_UP(fb->height, tile_height);
+   } else {
+   stride = fb->pitches[0] /
+   intel_fb_stride_alignment(dev, fb->modifier[0],
+ fb->pixel_format);
+   }

/*
 * Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
@@ -11181,7 +11189,7 @@ static void intel_do_mmio_flip(struct intel_mmio_flip 
*mmio_flip)
intel_pipe_update_start(crtc);

if (INTEL_INFO(mmio_flip->i915)->gen >= 9)
-   skl_do_mmio_flip(crtc, work);
+   skl_do_mmio_flip(crtc, mmio_flip->rotation, work);
else
/* use_mmio_flip() retricts MMIO flips to ilk+ */
ilk_do_mmio_flip(crtc, work);
@@ -11208,10 +11216,8 @@ static void intel_mmio_flip_work_func(struct 
work_struct *work)

  static int intel_queue_mmio_flip(struct drm_device *dev,
 struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj,
-struct intel_engine_cs *ring,
-uint32_t flags)
+unsigned int rotation,
+struct drm_i915_gem_object *obj)
  {
struct intel_mmio_flip *mmio_flip;

@@ -11222,6 +11228,7 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
mmio_flip->i915 = to_i915(dev);
mmio_flip->req = i915_gem_request_reference(obj->last_write_req);
mmio_flip->crtc = to_intel_crtc(crtc);
+   mmio_flip->rotation = rotation;


Could just do the crtc->primary->state->rotation thing here and avoid
having to pass the rotation from the caller.


Oh that would indeed be nicer. I'll do a v3.


But the patch looks OK anyway:
Reviewed-by: Ville Syrjälä 


Can I carry over the r-b to v3?

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


  1   2   >