Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

2015-09-24 Thread Tomi Valkeinen


On 01/09/15 17:34, Rob Clark wrote:

> I hadn't had a chance to look at it further yet..  I think Daniel
> claimed it worked for him, but he was probably on intel-next, where I
> was on drm-next at the time which seemed to be having some unrelated
> i915 issues (when I was trying to debug atomic fb-helper patches).  So
> can't really say that the issue I had was actually related to this
> patch.  I'll try again later this week or next, when hopefully i915 in
> drm-next is in better shape..

Rob, did you have a chance to test this?

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too

2015-09-24 Thread Chris Wilson
On Thu, Sep 24, 2015 at 10:55:17AM +0100, Tvrtko Ursulin wrote:
> 
> On 09/23/2015 06:03 PM, Chris Wilson wrote:
> >On Wed, Sep 23, 2015 at 12:52:26PM -0300, Paulo Zanoni wrote:
> >>The trick is not strictly necessary on SKL because the offset
> >>registers allow more bits. But for FBC, doing this changes how the
> >>hardware tracking works - it starts at the surface address we provide
> >>- so there's a higher chance that the CRTC will be pointing to an area
> >>of the frontbuffer that is actually being covered by the hardware
> >>tracking mechanism. This fixes fbc-farfromfence on SKL.
> >>
> >>Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence
> >>Signed-off-by: Paulo Zanoni 
> >>---
> >>  drivers/gpu/drm/i915/intel_display.c | 7 +++
> >>  1 file changed, 7 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >>b/drivers/gpu/drm/i915/intel_display.c
> >>index 24b8a72..d40ae71 100644
> >>--- a/drivers/gpu/drm/i915/intel_display.c
> >>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>@@ -3031,6 +3031,7 @@ static void skylake_update_primary_plane(struct 
> >>drm_crtc *crtc,
> >>int src_x = 0, src_y = 0, src_w = 0, src_h = 0;
> >>int dst_x = 0, dst_y = 0, dst_w = 0, dst_h = 0;
> >>int scaler_id = -1;
> >>+   int pixel_size;
> >>
> >>plane_state = to_intel_plane_state(plane->state);
> >>
> >>@@ -3079,6 +3080,12 @@ static void skylake_update_primary_plane(struct 
> >>drm_crtc *crtc,
> >>src_h = intel_crtc->config->pipe_src_h;
> >>}
> >>
> >>+   pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
> >>+   intel_crtc->dspaddr_offset = intel_gen4_compute_page_offset(dev_priv,
> >>+   , , obj->tiling_mode,
> >>+   pixel_size, fb->pitches[0]);
> >>+   surf_addr += intel_crtc->dspaddr_offset;
> >>+
> >>if (intel_rotation_90_or_270(rotation)) {
> >>/* stride = Surface height in tiles */
> >>tile_height = intel_tile_height(dev, fb->pixel_format,
> >
> >Tvrtko mind running this past your 90/270 rotation sanity tester?
> 
> You mean igt/kms_rotation_crc ?

I actually meant you! :)
-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 v3 1/2] drm/i915/gtt: Do not initialize drm_mm twice.

2015-09-24 Thread Winiarski, Michal
On Wed, 2015-09-23 at 15:55 -0300, Paulo Zanoni wrote:
> 2015-09-23 13:48 GMT-03:00 Imre Deak :
> > On ke, 2015-09-16 at 11:49 +0200, Michał Winiarski wrote:
> > > It would be initialized just moments later by i915_init_vm.
> > > 
> > > v2: Commit msg update,
> > > s/i915_init_vm/i915_address_space_init, move to
> > > i915_gem_gtt.c,
> > > init address_space during i915_gem_setup_global_gtt for ggtt.
> > > v3: Do not init global_link - we are adding it to vm_list moments
> > > later,
> > > make i915_address_space_init static, use OOP style parameter
> > > order.
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Michel Thierry 
> > > Cc: Mika Kuoppala 
> > > Signed-off-by: Michał Winiarski 
> > 
> > With this patch I get the oops below when booting. Looking at it
> > it's
> > caused by dev_priv->gtt being initialized now too late for
> > i915_gem_object_create_stolen_for_preallocated().
> 
> My BDW machine stopped booting, and git bisect tells me this patch is
> the cause. I didn't setup anything to help me grab the logs before
> the
> crash, so I can't confirm the backtrace below.
> 
> Something interesting is that if I boot with i915.modeset=0, then
> later "rmmod i915; modprobe i915 modeset=1", the driver loads
> successfully.

drm/i915: Defer adding preallocated stolen objects to the VM list
from Chris fixes this. I missed it because I usually just reload i915
module after the machine boots - sorry for breaking your setups :(

-Michał
 
> > 
> > [   13.547091] BUG: unable to handle kernel NULL pointer
> > dereference at   (null)
> > [   13.555857] IP: []
> > i915_gem_object_create_stolen_for_preallocated+0x1e9/0x320 [i915]
> > [   13.566380] PGD 0
> > [   13.568634] Oops: 0002 [#1] PREEMPT SMP
> > [   13.573035] Modules linked in: snd_hda_codec_hdmi snd_hda_intel
> > i915(O+) snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_dummy
> > snd_seq_oss kvm_intel i2c_algo_bit snd_seq_midi drm_kms_helper kvm
> > snd_rawmidi syscopyarea sysfillrect sysimgblt snd_seq_midi_event
> > crc32c_intel fb_sys_fops microcode snd_seq drm snd_seq_device
> > snd_timer efivars intel_gtt snd agpgart fuse
> > [   13.609814] CPU: 1 PID: 329 Comm: systemd-udevd Tainted: G  
> > IO4.3.0-rc2-bxt+ #177
> > [   13.619401] Hardware name: Intel Corp. BROXTON A1
> > PLATFORM/TABLET, BIOS BXTM_IFWI_X64_R_2015_36_4_00 09/02/2015
> > [   13.630681] task: 88007674cc80 ti: 880075c1c000 task.ti:
> > 880075c1c000
> > [   13.639049] RIP: 0010:[]  []
> > i915_gem_object_create_stolen_for_preallocated+0x1e9/0x320 [i915]
> > [   13.652219] RSP: 0018:880075c1f810  EFLAGS: 00010286
> > [   13.658154] RAX:  RBX: 008ca000 RCX:
> > 880072e61ca8
> > [   13.666129] RDX: 880072e61c00 RSI: 88006de4a0c8 RDI:
> > 88007674d4c8
> > [   13.674103] RBP: 880075c1f848 R08: 000196f0 R09:
> > 880072e61c00
> > [   13.682078] R10: 0001 R11: 0001 R12:
> > 88006de49f18
> > [   13.690053] R13: 88006df0 R14: 8800754154e0 R15:
> > 
> > [   13.698034] FS:  7f4d61c0f880()
> > GS:88007948() knlGS:
> > [   13.707089] CS:  0010 DS:  ES:  CR0: 80050033
> > [   13.713513] CR2:  CR3: 73304000 CR4:
> > 003406e0
> > [   13.721494] Stack:
> > [   13.723740]  88006de4a048 88006de49e18 880075c1f928
> > 880075c1f858
> > [   13.732044]  880072cba540 880076061000 880076061000
> > 880075c1f8e8
> > [   13.740345]  a027bdbc  
> > [   13.745411] sdhci-pci :00:1c.0: power state changed by ACPI
> > to D3cold
> > [   13.754373]  
> > 
> > [   13.757903] Call Trace:
> > [   13.760709]  []
> > intel_alloc_initial_plane_obj.isra.56+0x7c/0x190 [i915]
> > [   13.769930]  []
> > intel_modeset_init+0xbb4/0x1a10 [i915]
> > [   13.777495]  [] i915_driver_load+0xeec/0x14e0
> > [i915]
> > [   13.784831]  [] drm_dev_register+0xa9/0xc0
> > [drm]
> > [   13.791762]  [] drm_get_pci_dev+0x8d/0x1e0
> > [drm]
> > [   13.798682]  [] ?
> > _raw_spin_unlock_irqrestore+0x42/0x70
> > [   13.806321]  [] i915_pci_probe+0x34/0x50
> > [i915]
> > [   13.813144]  [] pci_device_probe+0x8c/0x100
> > [   13.819577]  []
> > driver_probe_device+0x169/0x4a0
> > [   13.826393]  [] __driver_attach+0x88/0x90
> > [   13.832628]  [] ?
> > driver_probe_device+0x4a0/0x4a0
> > [   13.839643]  [] bus_for_each_dev+0x66/0xa0
> > [   13.845976]  [] driver_attach+0x1e/0x20
> > [   13.852012]  [] bus_add_driver+0x1f4/0x290
> > [   13.858343]  [] driver_register+0x60/0xe0
> > [   13.864577]  []
> > __pci_register_driver+0x60/0x70
> > [   13.871410]  [] drm_pci_init+0xe0/0x110 [drm]
> > [   13.878034]  [] ? trace_hardirqs_on+0xd/0x10
> > [   13.884560]  [] ? 0xa032b000
> > [   13.890350]  

Re: [Intel-gfx] [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too

2015-09-24 Thread Tvrtko Ursulin


On 09/23/2015 06:03 PM, Chris Wilson wrote:

On Wed, Sep 23, 2015 at 12:52:26PM -0300, Paulo Zanoni wrote:

The trick is not strictly necessary on SKL because the offset
registers allow more bits. But for FBC, doing this changes how the
hardware tracking works - it starts at the surface address we provide
- so there's a higher chance that the CRTC will be pointing to an area
of the frontbuffer that is actually being covered by the hardware
tracking mechanism. This fixes fbc-farfromfence on SKL.

Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence
Signed-off-by: Paulo Zanoni 
---
  drivers/gpu/drm/i915/intel_display.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 24b8a72..d40ae71 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3031,6 +3031,7 @@ static void skylake_update_primary_plane(struct drm_crtc 
*crtc,
int src_x = 0, src_y = 0, src_w = 0, src_h = 0;
int dst_x = 0, dst_y = 0, dst_w = 0, dst_h = 0;
int scaler_id = -1;
+   int pixel_size;

plane_state = to_intel_plane_state(plane->state);

@@ -3079,6 +3080,12 @@ static void skylake_update_primary_plane(struct drm_crtc 
*crtc,
src_h = intel_crtc->config->pipe_src_h;
}

+   pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+   intel_crtc->dspaddr_offset = intel_gen4_compute_page_offset(dev_priv,
+   , , obj->tiling_mode,
+   pixel_size, fb->pitches[0]);
+   surf_addr += intel_crtc->dspaddr_offset;
+
if (intel_rotation_90_or_270(rotation)) {
/* stride = Surface height in tiles */
tile_height = intel_tile_height(dev, fb->pixel_format,


Tvrtko mind running this past your 90/270 rotation sanity tester?


You mean igt/kms_rotation_crc ?

I don't have the background of what is this doing, but what jumps out at 
me is use of obj->tiling_mode which is not used for display tiling on 
skl+, and tile size calculations in intel_gen4_compute_page_offset seems 
to only support X tiling.


The two together would make me say that it can't possibly work. :)

Maybe Paolo can get quicker to running that igt since it sounds like he 
is already set up?


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: Convert WARNs during userptr revoke to SIGBUS

2015-09-24 Thread Tvrtko Ursulin


On 09/23/2015 09:07 PM, Chris Wilson wrote:

If the client revokes the virtual address it asked to be mapped into GPU
space via userptr (by using anything along the lines of mmap, mprotect,
madvise, munmap, ftruncate etc) the mmu notifier sends a range
invalidate command to userptr. Upon receiving the invalidation signal
for the revoked range, we try to release the struct pages we pinned into
the GTT. However, this can fail if any of the GPU's VMA are pinned for
use by the hardware (i.e. despite the user's intention we cannot
relinquish the client's address range and keep uptodate with whatever is
placed in there). Currently we emit a few WARN so that we would notice
if this every occurred in the wild; it has. Sadly this means we need to
replace those WARNs with the proper SIGBUS to the offending clients
instead.


How does it happen? Frame buffer?


Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
  drivers/gpu/drm/i915/i915_gem_userptr.c | 41 +
  1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index f75d9011..efb404b9fe69 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -81,11 +81,44 @@ static void __cancel_userptr__worker(struct work_struct 
*work)


This line is a reminder the previous series still hasn't landed. I think 
it was all r-b-ed, with only my request to not rely on release_pages (or 
something) handle negative and zero page count.



was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;

-   list_for_each_entry_safe(vma, tmp, >vma_list, obj_link) {
-   int ret = i915_vma_unbind(vma);
-   WARN_ON(ret && ret != -EIO);
+   list_for_each_entry_safe(vma, tmp, >vma_list, obj_link)
+   i915_vma_unbind(vma);
+   if (i915_gem_object_put_pages(obj)) {
+   struct task_struct *p;
+
+   DRM_ERROR("Unable to revoke ownership by userptr of"
+ " invalidated address range, sending SIGBUS"
+ " to attached clients.\n");
+
+   rcu_read_lock();
+   for_each_process(p) {


I don't think this is safe this without holding the tasklist_lock.

Regards,

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


[Intel-gfx] [PATCH i-g-t] gem_storedw_loop: fix segfault when listing subtests

2015-09-24 Thread Thomas Wood
Commit fb66cd5 (tests/gem_storedw_loop: Fix use after free for bufmgr)
introduced a segmentation fault when listing subtests because
drm_intel_bufmgr_destroy is called with NULL. Move this and the call to
the close function inside an igt_fixture block to prevent them being
called when listing subtests.

Cc: Robert Beckett 
Cc: Jesse Barnes 
Cc: Daniel Vetter 
Signed-off-by: Thomas Wood 
---
 tests/gem_storedw_loop.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
index e7ebcc2..e17e190 100644
--- a/tests/gem_storedw_loop.c
+++ b/tests/gem_storedw_loop.c
@@ -180,6 +180,8 @@ igt_main
}
}
 
-   drm_intel_bufmgr_destroy(bufmgr);
-   close(fd);
+   igt_fixture {
+   drm_intel_bufmgr_destroy(bufmgr);
+   close(fd);
+   }
 }
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

2015-09-24 Thread Chris Wilson
On Thu, Sep 24, 2015 at 11:23:48AM +0100, Tvrtko Ursulin wrote:
> 
> On 09/23/2015 09:07 PM, Chris Wilson wrote:
> >If the client revokes the virtual address it asked to be mapped into GPU
> >space via userptr (by using anything along the lines of mmap, mprotect,
> >madvise, munmap, ftruncate etc) the mmu notifier sends a range
> >invalidate command to userptr. Upon receiving the invalidation signal
> >for the revoked range, we try to release the struct pages we pinned into
> >the GTT. However, this can fail if any of the GPU's VMA are pinned for
> >use by the hardware (i.e. despite the user's intention we cannot
> >relinquish the client's address range and keep uptodate with whatever is
> >placed in there). Currently we emit a few WARN so that we would notice
> >if this every occurred in the wild; it has. Sadly this means we need to
> >replace those WARNs with the proper SIGBUS to the offending clients
> >instead.
> 
> How does it happen? Frame buffer?

Ignoring the issue of -EIO since patches to fix that path also haven't
landed, the primary cause is through binding the userptr to a scanout
(framebuffer). This is not recommended usage for userptr since the CPU
view is then incoherent, but not impossible.
 
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Michał Winiarski 
> >---
> >  drivers/gpu/drm/i915/i915_gem_userptr.c | 41 
> > +
> >  1 file changed, 37 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> >b/drivers/gpu/drm/i915/i915_gem_userptr.c
> >index f75d9011..efb404b9fe69 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> >@@ -81,11 +81,44 @@ static void __cancel_userptr__worker(struct work_struct 
> >*work)
> 
> This line is a reminder the previous series still hasn't landed. I
> think it was all r-b-ed, with only my request to not rely on
> release_pages (or something) handle negative and zero page count.
> 
> > was_interruptible = dev_priv->mm.interruptible;
> > dev_priv->mm.interruptible = false;
> >
> >-list_for_each_entry_safe(vma, tmp, >vma_list, obj_link) {
> >-int ret = i915_vma_unbind(vma);
> >-WARN_ON(ret && ret != -EIO);
> >+list_for_each_entry_safe(vma, tmp, >vma_list, obj_link)
> >+i915_vma_unbind(vma);
> >+if (i915_gem_object_put_pages(obj)) {
> >+struct task_struct *p;
> >+
> >+DRM_ERROR("Unable to revoke ownership by userptr of"
> >+  " invalidated address range, sending SIGBUS"
> >+  " to attached clients.\n");
> >+
> >+rcu_read_lock();
> >+for_each_process(p) {
> 
> I don't think this is safe this without holding the tasklist_lock.

Hmm, it's the only lock taken in the oom-killer for sending the signal.
The list will not change nor will tasks disappear whilst we hold the
read-lock so it seems sane.
-Chirs

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

2015-09-24 Thread Jani Nikula
On Thu, 24 Sep 2015, "Winiarski, Michal"  wrote:
> On Thu, 2015-09-24 at 11:57 +0100, Chris Wilson wrote:
>> When preallocating a stolen object during early initialisation, we
>> may
>> be running before we have setup the the global GTT VM state, in
>> particular before we have initialised the range manager and
>> associated
>> lists. As this is the case, we defer binding the stolen object until
>> we
>> call i915_gem_setup_global_gtt(). Not only should we defer the
>> binding,
>> but we should also defer the VM list manipulation.
>> 
>> Fixes regression uncovered by commit
>> a2cad9dff4dd44d0244b966d980de9d602d87593
>> Author: Michał Winiarski 
>> Date:   Wed Sep 16 11:49:00 2015 +0200
>> 
>> drm/i915/gtt: Do not initialize drm_mm twice.

I confirm reverting the above works.

This patch is

Tested-by: Jani Nikula 

on a BWD GT2 ULT.

>> 
>> Whilst I am here remove the duplicate work leaving dangling pointers
>> from the error path...
>> 
>> v2: Typos galore before coffee.
>> 
>> Reported-by: Jesse Barnes 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099
>> Signed-off-by: Chris Wilson 
>> Cc: Jesse Barnes 
>> Cc: Michel Thierry 
>> Cc: Mika Kuoppala 
>> Cc: Michał Winiarski 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>
> Reviewed-by: Michał Winiarski 
>
> -Michał
>
>> ---
>>  drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
>>  drivers/gpu/drm/i915/i915_gem_stolen.c | 16 ++--
>>  2 files changed, 7 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 01f3521e77d3..291305fb2f3c 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -2533,7 +2533,6 @@ static int ggtt_bind_vma(struct i915_vma *vma,
>>   * the bound flag ourselves.
>>   */
>>  vma->bound |= GLOBAL_BIND;
>> -
>>  }
>>  
>>  if (dev_priv->mm.aliasing_ppgtt && flags & LOCAL_BIND) {
>> @@ -2657,6 +2656,7 @@ static int i915_gem_setup_global_gtt(struct
>> drm_device *dev,
>>  return ret;
>>  }
>>  vma->bound |= GLOBAL_BIND;
>> +list_add_tail(>mm_list, _vm
>> ->inactive_list);
>>  }
>>  
>>  /* Clear any non-preallocated blocks */
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index 55df6ce34751..15207796e1b3 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> @@ -584,7 +584,7 @@
>> i915_gem_object_create_stolen_for_preallocated(struct drm_device
>> *dev,
>>  vma = i915_gem_obj_lookup_or_create_vma(obj, ggtt);
>>  if (IS_ERR(vma)) {
>>  ret = PTR_ERR(vma);
>> -goto err_out;
>> +goto err;
>>  }
>>  
>>  /* To simplify the initialisation sequence between KMS and
>> GTT,
>> @@ -598,23 +598,19 @@
>> i915_gem_object_create_stolen_for_preallocated(struct drm_device
>> *dev,
>>  ret = drm_mm_reserve_node(>mm, >node);
>>  if (ret) {
>>  DRM_DEBUG_KMS("failed to allocate stolen GTT
>> space\n");
>> -goto err_vma;
>> +goto err;
>>  }
>> -}
>>  
>> -vma->bound |= GLOBAL_BIND;
>> +vma->bound |= GLOBAL_BIND;
>> +list_add_tail(>mm_list, >inactive_list);
>> +}
>>  
>>  list_add_tail(>global_list, _priv->mm.bound_list);
>> -list_add_tail(>mm_list, >inactive_list);
>>  i915_gem_object_pin_pages(obj);
>>  
>>  return obj;
>>  
>> -err_vma:
>> -i915_gem_vma_destroy(vma);
>> -err_out:
>> -i915_gem_stolen_remove_node(dev_priv, stolen);
>> -kfree(stolen);
>> +err:
>>  drm_gem_object_unreference(>base);
>>  return NULL;
>>  }

-- 
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: Defer adding preallocated stolen objects to the VM list

2015-09-24 Thread Jani Nikula
On Thu, 24 Sep 2015, Chris Wilson  wrote:
> When preallocating a stolen object during early initialisation, we may
> be running before we have setup the the global GTT VM state, in
> particular before we have initialised the range manager and associated
> lists. As this is the case, we defer binding the stolen object until we
> call i915_gem_setup_global_gtt(). Not only should we defer the binding,
> but we should also defer the VM list manipulation.
>
> Fixes regression from commit a2cad9dff4dd44d0244b966d980de9d602d87593
> Author: Michał Winiarski 
> Date:   Wed Sep 16 11:49:00 2015 +0200
>
> drm/i915/gtt: Do not initialize drm_mm twice.
>
> Whilst I am here remove the duplicate work leaving dangling pointers
> from the error path...
>
> Reported-by: Jesse Barnes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
> Cc: Michel Thierry 
> Cc: Mika Kuoppala 
> Cc: Michał Winiarski 
> Cc: Daniel Vetter 

  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘i915_gem_setup_global_gtt’:
drivers/gpu/drm/i915/i915_gem_gtt.c:2659:33: error: ‘ggtt’ undeclared (first 
use in this function)
   list_add_tail(>mm_list, >inactive_list);
 ^
Jani.

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 16 ++--
>  2 files changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 01f3521e77d3..9cc68624410e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2533,7 +2533,6 @@ static int ggtt_bind_vma(struct i915_vma *vma,
>* the bound flag ourselves.
>*/
>   vma->bound |= GLOBAL_BIND;
> -
>   }
>  
>   if (dev_priv->mm.aliasing_ppgtt && flags & LOCAL_BIND) {
> @@ -2657,6 +2656,7 @@ static int i915_gem_setup_global_gtt(struct drm_device 
> *dev,
>   return ret;
>   }
>   vma->bound |= GLOBAL_BIND;
> + list_add_tail(>mm_list, >inactive_list);
>   }
>  
>   /* Clear any non-preallocated blocks */
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 55df6ce34751..15207796e1b3 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -584,7 +584,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
> drm_device *dev,
>   vma = i915_gem_obj_lookup_or_create_vma(obj, ggtt);
>   if (IS_ERR(vma)) {
>   ret = PTR_ERR(vma);
> - goto err_out;
> + goto err;
>   }
>  
>   /* To simplify the initialisation sequence between KMS and GTT,
> @@ -598,23 +598,19 @@ i915_gem_object_create_stolen_for_preallocated(struct 
> drm_device *dev,
>   ret = drm_mm_reserve_node(>mm, >node);
>   if (ret) {
>   DRM_DEBUG_KMS("failed to allocate stolen GTT space\n");
> - goto err_vma;
> + goto err;
>   }
> - }
>  
> - vma->bound |= GLOBAL_BIND;
> + vma->bound |= GLOBAL_BIND;
> + list_add_tail(>mm_list, >inactive_list);
> + }
>  
>   list_add_tail(>global_list, _priv->mm.bound_list);
> - list_add_tail(>mm_list, >inactive_list);
>   i915_gem_object_pin_pages(obj);
>  
>   return obj;
>  
> -err_vma:
> - i915_gem_vma_destroy(vma);
> -err_out:
> - i915_gem_stolen_remove_node(dev_priv, stolen);
> - kfree(stolen);
> +err:
>   drm_gem_object_unreference(>base);
>   return NULL;
>  }
> -- 
> 2.5.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[Intel-gfx] [PATCH i-g-t] lib/tests: explicitly raise SIGSEGV

2015-09-24 Thread Thomas Wood
Dereferencing a NULL pointer is undefined behaviour and may not always
result in a segmentation fault. Explicitly raise the SIGSEGV signal to
test handling of this signal.

Signed-off-by: Thomas Wood 
---
 lib/tests/igt_segfault.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/tests/igt_segfault.c b/lib/tests/igt_segfault.c
index b420b1a..bc7641d 100644
--- a/lib/tests/igt_segfault.c
+++ b/lib/tests/igt_segfault.c
@@ -57,11 +57,15 @@ bool runc;
 char test[] = "test";
 char *argv_run[] = { test };
 
+static void crashme(void)
+{
+   raise(SIGSEGV);
+}
+
 static int do_fork(void)
 {
int pid, status;
int argc;
-   void (*crashme)(void) = NULL;
 
switch (pid = fork()) {
case -1:
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

2015-09-24 Thread Tvrtko Ursulin


On 09/24/2015 11:31 AM, Chris Wilson wrote:

On Thu, Sep 24, 2015 at 11:23:48AM +0100, Tvrtko Ursulin wrote:


On 09/23/2015 09:07 PM, Chris Wilson wrote:

If the client revokes the virtual address it asked to be mapped into GPU
space via userptr (by using anything along the lines of mmap, mprotect,
madvise, munmap, ftruncate etc) the mmu notifier sends a range
invalidate command to userptr. Upon receiving the invalidation signal
for the revoked range, we try to release the struct pages we pinned into
the GTT. However, this can fail if any of the GPU's VMA are pinned for
use by the hardware (i.e. despite the user's intention we cannot
relinquish the client's address range and keep uptodate with whatever is
placed in there). Currently we emit a few WARN so that we would notice
if this every occurred in the wild; it has. Sadly this means we need to
replace those WARNs with the proper SIGBUS to the offending clients
instead.


How does it happen? Frame buffer?


Ignoring the issue of -EIO since patches to fix that path also haven't
landed, the primary cause is through binding the userptr to a scanout
(framebuffer). This is not recommended usage for userptr since the CPU
view is then incoherent, but not impossible.


Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
  drivers/gpu/drm/i915/i915_gem_userptr.c | 41 +
  1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index f75d9011..efb404b9fe69 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -81,11 +81,44 @@ static void __cancel_userptr__worker(struct work_struct 
*work)


This line is a reminder the previous series still hasn't landed. I
think it was all r-b-ed, with only my request to not rely on
release_pages (or something) handle negative and zero page count.


was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;

-   list_for_each_entry_safe(vma, tmp, >vma_list, obj_link) {
-   int ret = i915_vma_unbind(vma);
-   WARN_ON(ret && ret != -EIO);
+   list_for_each_entry_safe(vma, tmp, >vma_list, obj_link)
+   i915_vma_unbind(vma);
+   if (i915_gem_object_put_pages(obj)) {
+   struct task_struct *p;
+
+   DRM_ERROR("Unable to revoke ownership by userptr of"
+ " invalidated address range, sending SIGBUS"
+ " to attached clients.\n");
+
+   rcu_read_lock();
+   for_each_process(p) {


I don't think this is safe this without holding the tasklist_lock.


Hmm, it's the only lock taken in the oom-killer for sending the signal.
The list will not change nor will tasks disappear whilst we hold the
read-lock so it seems sane.


Then I'll say hmm as well. Since I've now seen there is both in use, 
with and without holding the tasklist_lock.


I thought that with just rcu_read_lock, nothing prevents another CPU 
from obtaining the write tasklist_lock and mess about with it. But maybe 
we are talking about some complex locking scheme here? I don't know. Did 
not find any documentation on the tasklist_lock..


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: Defer adding preallocated stolen objects to the VM list

2015-09-24 Thread Winiarski, Michal
On Thu, 2015-09-24 at 11:57 +0100, Chris Wilson wrote:
> When preallocating a stolen object during early initialisation, we
> may
> be running before we have setup the the global GTT VM state, in
> particular before we have initialised the range manager and
> associated
> lists. As this is the case, we defer binding the stolen object until
> we
> call i915_gem_setup_global_gtt(). Not only should we defer the
> binding,
> but we should also defer the VM list manipulation.
> 
> Fixes regression uncovered by commit
> a2cad9dff4dd44d0244b966d980de9d602d87593
> Author: Michał Winiarski 
> Date:   Wed Sep 16 11:49:00 2015 +0200
> 
> drm/i915/gtt: Do not initialize drm_mm twice.
> 
> Whilst I am here remove the duplicate work leaving dangling pointers
> from the error path...
> 
> v2: Typos galore before coffee.
> 
> Reported-by: Jesse Barnes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
> Cc: Michel Thierry 
> Cc: Mika Kuoppala 
> Cc: Michał Winiarski 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 16 ++--
>  2 files changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 01f3521e77d3..291305fb2f3c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2533,7 +2533,6 @@ static int ggtt_bind_vma(struct i915_vma *vma,
>* the bound flag ourselves.
>*/
>   vma->bound |= GLOBAL_BIND;
> -
>   }
>  
>   if (dev_priv->mm.aliasing_ppgtt && flags & LOCAL_BIND) {
> @@ -2657,6 +2656,7 @@ static int i915_gem_setup_global_gtt(struct
> drm_device *dev,
>   return ret;
>   }
>   vma->bound |= GLOBAL_BIND;
> + list_add_tail(>mm_list, _vm
> ->inactive_list);
>   }
>  
>   /* Clear any non-preallocated blocks */
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 55df6ce34751..15207796e1b3 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -584,7 +584,7 @@
> i915_gem_object_create_stolen_for_preallocated(struct drm_device
> *dev,
>   vma = i915_gem_obj_lookup_or_create_vma(obj, ggtt);
>   if (IS_ERR(vma)) {
>   ret = PTR_ERR(vma);
> - goto err_out;
> + goto err;
>   }
>  
>   /* To simplify the initialisation sequence between KMS and
> GTT,
> @@ -598,23 +598,19 @@
> i915_gem_object_create_stolen_for_preallocated(struct drm_device
> *dev,
>   ret = drm_mm_reserve_node(>mm, >node);
>   if (ret) {
>   DRM_DEBUG_KMS("failed to allocate stolen GTT
> space\n");
> - goto err_vma;
> + goto err;
>   }
> - }
>  
> - vma->bound |= GLOBAL_BIND;
> + vma->bound |= GLOBAL_BIND;
> + list_add_tail(>mm_list, >inactive_list);
> + }
>  
>   list_add_tail(>global_list, _priv->mm.bound_list);
> - list_add_tail(>mm_list, >inactive_list);
>   i915_gem_object_pin_pages(obj);
>  
>   return obj;
>  
> -err_vma:
> - i915_gem_vma_destroy(vma);
> -err_out:
> - i915_gem_stolen_remove_node(dev_priv, stolen);
> - kfree(stolen);
> +err:
>   drm_gem_object_unreference(>base);
>   return NULL;
>  }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/3] drm/i915: Add current CD clock frequency to debugfs

2015-09-24 Thread Mika Kahola
Add information on current CD clock frequency to
debugfs 'i915_frequency_info'

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5615d3d..674fefa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1309,6 +1309,8 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_puts(m, "no P-state info available\n");
}
 
+   seq_printf(m, "Current CD clock freq: %dkHz\n", dev_priv->cdclk_freq);
+
 out:
intel_runtime_pm_put(dev_priv);
return ret;
-- 
1.9.1

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


[Intel-gfx] [PATCH i-g-t v3] gem_ppgtt: Test VMA leak on context destruction

2015-09-24 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Test that VMAs associated with a context are cleaned up when
contexts are destroyed.

In practice this emulates the leak seen between fbcon and X server.
Every time the X server exits we gain one VMA on the fbcon frame
buffer object as externally visible via for example
/sys/kernel/debug/dri/0/i915_gem_gtt.

v2: Use igt_debugfs_open, getline and strstr instead of home-brewed
string matching. (Thomas Wood)

v3: Rebase for drm_open_driver.

Signed-off-by: Tvrtko Ursulin 
Cc: Thomas Wood 
---
 tests/gem_ppgtt.c | 86 +++
 1 file changed, 86 insertions(+)

diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c
index 22adf805f0ac..f891411ab0c2 100644
--- a/tests/gem_ppgtt.c
+++ b/tests/gem_ppgtt.c
@@ -37,6 +37,7 @@
 #include 
 
 #include "intel_bufmgr.h"
+#include "igt_debugfs.h"
 
 #define WIDTH 512
 #define STRIDE (WIDTH*4)
@@ -265,6 +266,88 @@ static void flink_and_close(void)
close(fd2);
 }
 
+static bool grep_name(const char *fname, const char *match)
+{
+   int fd;
+   FILE *fh;
+   size_t n = 0;
+   char *line = NULL;
+   char *matched = NULL;
+
+   fd = igt_debugfs_open(fname, O_RDONLY);
+   igt_assert(fd >= 0);
+
+   fh = fdopen(fd, "r");
+   igt_assert(fh);
+
+   while (getline(, , fh) >= 0) {
+   matched = strstr(line, match);
+   if (line) {
+   free(line);
+   line = NULL;
+   }
+   if (matched)
+   break;
+   }
+
+   if (line)
+   free(line);
+   fclose(fh);
+
+   return matched != NULL;
+}
+
+static void flink_and_exit(void)
+{
+   uint32_t fd, fd2;
+   uint32_t bo, flinked_bo, name;
+   char match[100];
+   int to_match;
+   bool matched;
+   int retry = 0;
+   const int retries = 50;
+
+   fd = drm_open_driver(DRIVER_INTEL);
+   igt_require(uses_full_ppgtt(fd));
+
+   bo = gem_create(fd, 4096);
+   name = gem_flink(fd, bo);
+
+   to_match  = snprintf(match, sizeof(match), "(name: %u)", name);
+   igt_assert(to_match < sizeof(match));
+
+   fd2 = drm_open_driver(DRIVER_INTEL);
+
+   flinked_bo = gem_open(fd2, name);
+   exec_and_get_offset(fd2, flinked_bo);
+   gem_sync(fd2, flinked_bo);
+
+   /* Verify looking for string works OK. */
+   matched = grep_name("i915_gem_gtt", match);
+   igt_assert_eq(matched, true);
+
+   gem_close(fd2, flinked_bo);
+
+   /* Close the context. */
+   close(fd2);
+
+retry:
+   /* Give cleanup some time to run. */
+   usleep(10);
+
+   /* The flinked bo VMA should have been cleared now, so list of VMAs
+* in debugfs should not contain the one for the imported object.
+*/
+   matched = grep_name("i915_gem_gtt", match);
+   if (matched && retry++ < retries)
+   goto retry;
+
+   igt_assert_eq(matched, false);
+
+   gem_close(fd, bo);
+   close(fd);
+}
+
 #define N_CHILD 8
 int main(int argc, char **argv)
 {
@@ -297,5 +380,8 @@ int main(int argc, char **argv)
igt_subtest("flink-and-close-vma-leak")
flink_and_close();
 
+   igt_subtest("flink-and-exit-vma-leak")
+   flink_and_exit();
+
igt_exit();
 }
-- 
2.5.1

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


Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set oscaledcompmethod to enable scale value

2015-09-24 Thread Imre Deak
On to, 2015-09-24 at 10:22 +0530, Sonika Jindal wrote:
> Bspec update tells that we have to enable oscaledcompmethod instead of
> ouniqetrangenmethod for enabling scale value during swing programming.
> 
> v2: Adding back 'don't care' values to bxt_ddi_translations_dp and add
> error message if ouniquetrangemethod was set (Imre)
> 
> Signed-off-by: Sonika Jindal 
> Reviewed-by: Sivakumar Thulasimani (v1)

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |3 ++-
>  drivers/gpu/drm/i915/intel_ddi.c |8 ++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 812b7b2..3f2135d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1395,7 +1395,8 @@ enum skl_disp_power_wells {
>  #define BXT_PORT_TX_DW3_LN0(port)_PORT3(port, _PORT_TX_DW3_LN0_A,  \
>_PORT_TX_DW3_LN0_B,  \
>_PORT_TX_DW3_LN0_C)
> -#define   UNIQE_TRANGE_EN_METHOD (1 << 27)
> +#define   SCALE_DCOMP_METHOD (1 << 26)
> +#define   UNIQUE_TRANGE_EN_METHOD(1 << 27)
>  
>  #define _PORT_TX_DW4_LN0_A   0x162510
>  #define _PORT_TX_DW4_LN0_B   0x6C510
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index fec51df..7705bc9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2151,9 +2151,13 @@ static void bxt_ddi_vswing_sequence(struct drm_device 
> *dev, u32 level,
>   I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
>  
>   val = I915_READ(BXT_PORT_TX_DW3_LN0(port));
> - val &= ~UNIQE_TRANGE_EN_METHOD;
> + val &= ~SCALE_DCOMP_METHOD;
>   if (ddi_translations[level].enable)
> - val |= UNIQE_TRANGE_EN_METHOD;
> + val |= SCALE_DCOMP_METHOD;
> +
> + if ((val & UNIQUE_TRANGE_EN_METHOD) && !(val & SCALE_DCOMP_METHOD))
> + DRM_ERROR("Disabled scaling while ouniqetrangenmethod was set");
> +
>   I915_WRITE(BXT_PORT_TX_DW3_GRP(port), val);
>  
>   val = I915_READ(BXT_PORT_TX_DW4_LN0(port));


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


[Intel-gfx] [PATCH 3/3] drm/i915: Add max DOT clock frequency to debugfs

2015-09-24 Thread Mika Kahola
Information on maximum supported pixel clock frequency to
i915_frequency_info.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6882455..b418d9b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1311,6 +1311,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
 
seq_printf(m, "Current CD clock freq: %dkHz\n", dev_priv->cdclk_freq);
seq_printf(m, "Max CD clock freq: %dkHz\n", dev_priv->max_cdclk_freq);
+   seq_printf(m, "Max pixel clock freq: %dkHz\n", 
dev_priv->max_dotclk_freq);
 
 out:
intel_runtime_pm_put(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 2/3] drm/i915: Add max CD clock to debugfs

2015-09-24 Thread Mika Kahola
This adds information on maximum supported
CD clock frequency to debugfs 'i915_frequency_info'

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 674fefa..6882455 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1310,6 +1310,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
}
 
seq_printf(m, "Current CD clock freq: %dkHz\n", dev_priv->cdclk_freq);
+   seq_printf(m, "Max CD clock freq: %dkHz\n", dev_priv->max_cdclk_freq);
 
 out:
intel_runtime_pm_put(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 0/3] drm/i915: Add CD and pixel clock information

2015-09-24 Thread Mika Kahola
These patches add information of current and maximum CD clock
frequency and pixel clock frequency information on 'i915_debugfs.c'.


Mika Kahola (3):
  drm/i915: Add current CD clock frequency to debugfs
  drm/i915: Add max CD clock to debugfs
  drm/i915: Add max DOT clock frequency to debugfs

 drivers/gpu/drm/i915/i915_debugfs.c | 4 
 1 file changed, 4 insertions(+)

-- 
1.9.1

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


Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

2015-09-24 Thread Stephen Rothwell
Hi Jani,

On Thu, 24 Sep 2015 11:57:05 +0300 Jani Nikula  
wrote:
>
> That was the right thing to do.
> 
> The former commit is headed for v4.3, and there will have to be another
> version of it for -next. This will cause you another conflict, and you
> should resolve it with the same approach.

OK, thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

2015-09-24 Thread Chris Wilson
On Thu, Sep 24, 2015 at 10:02:00AM +0100, Chris Wilson wrote:
> When preallocating a stolen object during early initialisation, we may
> be running before we have setup the the global GTT VM state, in
> particular before we have initialised the range manager and associated
> lists. As this is the case, we defer binding the stolen object until we
> call i915_gem_setup_global_gtt(). Not only should we defer the binding,
> but we should also defer the VM list manipulation.
> 
> Fixes regression from commit a2cad9dff4dd44d0244b966d980de9d602d87593
> Author: Michał Winiarski 
> Date:   Wed Sep 16 11:49:00 2015 +0200
> 
> drm/i915/gtt: Do not initialize drm_mm twice.

For the record, this is not the root cause of the bug just the trigger
fr the current breakage. s/from/uncovered by/ ?
 
> Whilst I am here remove the duplicate work leaving dangling pointers
> from the error path...
> 
> Reported-by: Jesse Barnes 
Reported-by: Jesse Barnes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
Cc: Jesse Barnes 
> Cc: Michel Thierry 
> Cc: Mika Kuoppala 
> Cc: Michał Winiarski 
> Cc: Daniel Vetter 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/7] drm/i915: Always call the adjusted mode 'adjusted_mode'

2015-09-24 Thread Mika Kahola
coccinelle does a fine job on renaming the variables. Although, it does
break the rule of 80 character line width. 

Reviewed-by: Mika Kahola 

On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Always name any variable pointing at the adjusted mode as
> 'adjustead_mode'. This will make it much easier to identify
> when we should use the crtc_ timings and when we shoudln't.
> 
> Conversion was performed with coccinelle:
> @@
> expression E;
> identifier I;
> @@
> - struct drm_display_mode *I = _mode;
> + struct drm_display_mode *adjusted_mode = _mode;
> <...
> - I
> + adjusted_mode
> ...>
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_audio.c   |  7 ---
>  drivers/gpu/drm/i915/intel_display.c | 12 +---
>  drivers/gpu/drm/i915/intel_dsi.c | 13 ++---
>  drivers/gpu/drm/i915/intel_hdmi.c|  9 +++--
>  drivers/gpu/drm/i915/intel_lvds.c|  3 +--
>  drivers/gpu/drm/i915/intel_pm.c  | 14 ++
>  drivers/gpu/drm/i915/intel_sdvo.c|  3 +--
>  drivers/gpu/drm/i915/intel_sprite.c  |  8 
>  8 files changed, 30 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index f73de0b..cf4f5d1 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -396,7 +396,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>  {
>   struct drm_encoder *encoder = _encoder->base;
>   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> - struct drm_display_mode *mode = >config->base.adjusted_mode;
> + struct drm_display_mode *adjusted_mode = 
> >config->base.adjusted_mode;
>   struct drm_connector *connector;
>   struct drm_device *dev = encoder->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -419,10 +419,11 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
>   connector->eld[5] |= (1 << 2);
>  
> - connector->eld[6] = drm_av_sync_delay(connector, mode) / 2;
> + connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
>  
>   if (dev_priv->display.audio_codec_enable)
> - dev_priv->display.audio_codec_enable(connector, intel_encoder, 
> mode);
> + dev_priv->display.audio_codec_enable(connector, intel_encoder,
> +  adjusted_mode);
>  
>   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
>   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> (int) port);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e629a1b..b8b7540 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4348,8 +4348,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
> bool force_detach,
>  int skl_update_scaler_crtc(struct intel_crtc_state *state)
>  {
>   struct intel_crtc *intel_crtc = to_intel_crtc(state->base.crtc);
> - struct drm_display_mode *adjusted_mode =
> - >base.adjusted_mode;
> + struct drm_display_mode *adjusted_mode = >base.adjusted_mode;
>  
>   DRM_DEBUG_KMS("Updating scaler for [CRTC:%i] scaler_user index %u.%u\n",
> intel_crtc->base.base.id, intel_crtc->pipe, 
> SKL_CRTC_INDEX);
> @@ -7575,8 +7574,7 @@ static void intel_set_pipe_timings(struct intel_crtc 
> *intel_crtc)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   enum pipe pipe = intel_crtc->pipe;
>   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
> - struct drm_display_mode *adjusted_mode =
> - _crtc->config->base.adjusted_mode;
> + struct drm_display_mode *adjusted_mode = 
> _crtc->config->base.adjusted_mode;
>   uint32_t crtc_vtotal, crtc_vblank_end;
>   int vsyncshift = 0;
>  
> @@ -12767,11 +12765,11 @@ static void update_scanline_offset(struct 
> intel_crtc *crtc)
>* one to the value.
>*/
>   if (IS_GEN2(dev)) {
> - const struct drm_display_mode *mode = 
> >config->base.adjusted_mode;
> + const struct drm_display_mode *adjusted_mode = 
> >config->base.adjusted_mode;
>   int vtotal;
>  
> - vtotal = mode->crtc_vtotal;
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + vtotal = adjusted_mode->crtc_vtotal;
> + if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   vtotal /= 2;
>  
>   crtc->scanline_offset = vtotal - 1;
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 781c267..0c26ba5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ 

[Intel-gfx] [PULL] drm-intel-fixes

2015-09-24 Thread Jani Nikula

Hi Dave, a few drm/i915 fixes, including a fix to the recent regression
reported by Sedat Dilek [1].

BR,
Jani.


[1] 
http://mid.gmane.org/ca+iczuuwi96rv5pfdg3femg95vfpfjbmubiwrdzgduyjvt1...@mail.gmail.com

The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-09-24

for you to fetch changes up to cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd:

  drm/i915/bios: handle MIPI Sequence Block v3+ gracefully (2015-09-23 16:59:37 
+0300)


Geliang Tang (1):
  drm/i915: fix kernel-doc warnings in intel_audio.c

Jani Nikula (1):
  drm/i915/bios: handle MIPI Sequence Block v3+ gracefully

Jesse Barnes (1):
  drm/i915: workaround bad DSL readout v3

Maarten Lankhorst (1):
  drm/i915: Add primary plane to mask if it's visible

 drivers/gpu/drm/i915/i915_irq.c  | 26 ++
 drivers/gpu/drm/i915/intel_audio.c   |  2 +-
 drivers/gpu/drm/i915/intel_bios.c| 12 +++-
 drivers/gpu/drm/i915/intel_display.c |  7 +--
 4 files changed, 43 insertions(+), 4 deletions(-)

-- 
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 1/7] drm/i915: Use intel_panel for DVO fixed mode handling

2015-09-24 Thread Mika Kahola
Reviewed-by: Mika Kahola 

On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Replace intel_dvo->panel_fixed_mode with the appropriate intel_panel
> stuff. Now all connectors that have a fixed mode use intel_panel.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dvo.c | 49 
> ++--
>  1 file changed, 22 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index c80fe1f..0bc8aa8 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -97,7 +97,8 @@ struct intel_dvo {
>  
>   struct intel_dvo_device dev;
>  
> - struct drm_display_mode *panel_fixed_mode;
> + struct intel_connector *attached_connector;
> +
>   bool panel_wants_dither;
>  };
>  
> @@ -201,6 +202,8 @@ intel_dvo_mode_valid(struct drm_connector *connector,
>struct drm_display_mode *mode)
>  {
>   struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
> + const struct drm_display_mode *fixed_mode =
> + to_intel_connector(connector)->panel.fixed_mode;
>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>   int target_clock = mode->clock;
>  
> @@ -209,13 +212,13 @@ intel_dvo_mode_valid(struct drm_connector *connector,
>  
>   /* XXX: Validate clock range */
>  
> - if (intel_dvo->panel_fixed_mode) {
> - if (mode->hdisplay > intel_dvo->panel_fixed_mode->hdisplay)
> + if (fixed_mode) {
> + if (mode->hdisplay > fixed_mode->hdisplay)
>   return MODE_PANEL;
> - if (mode->vdisplay > intel_dvo->panel_fixed_mode->vdisplay)
> + if (mode->vdisplay > fixed_mode->vdisplay)
>   return MODE_PANEL;
>  
> - target_clock = intel_dvo->panel_fixed_mode->clock;
> + target_clock = fixed_mode->clock;
>   }
>  
>   if (target_clock > max_dotclk)
> @@ -228,6 +231,8 @@ static bool intel_dvo_compute_config(struct intel_encoder 
> *encoder,
>struct intel_crtc_state *pipe_config)
>  {
>   struct intel_dvo *intel_dvo = enc_to_dvo(encoder);
> + const struct drm_display_mode *fixed_mode =
> + intel_dvo->attached_connector->panel.fixed_mode;
>   struct drm_display_mode *adjusted_mode = 
> _config->base.adjusted_mode;
>  
>   /* If we have timings from the BIOS for the panel, put them in
> @@ -235,21 +240,8 @@ static bool intel_dvo_compute_config(struct 
> intel_encoder *encoder,
>* with the panel scaling set up to source from the H/VDisplay
>* of the original mode.
>*/
> - if (intel_dvo->panel_fixed_mode != NULL) {
> -#define C(x) adjusted_mode->x = intel_dvo->panel_fixed_mode->x
> - C(hdisplay);
> - C(hsync_start);
> - C(hsync_end);
> - C(htotal);
> - C(vdisplay);
> - C(vsync_start);
> - C(vsync_end);
> - C(vtotal);
> - C(clock);
> -#undef C
> -
> - drm_mode_set_crtcinfo(adjusted_mode, 0);
> - }
> + if (fixed_mode)
> + intel_fixed_panel_mode(fixed_mode, adjusted_mode);
>  
>   return true;
>  }
> @@ -318,8 +310,9 @@ intel_dvo_detect(struct drm_connector *connector, bool 
> force)
>  
>  static int intel_dvo_get_modes(struct drm_connector *connector)
>  {
> - struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
>   struct drm_i915_private *dev_priv = connector->dev->dev_private;
> + const struct drm_display_mode *fixed_mode =
> + to_intel_connector(connector)->panel.fixed_mode;
>  
>   /* We should probably have an i2c driver get_modes function for those
>* devices which will have a fixed set of modes determined by the chip
> @@ -331,9 +324,9 @@ static int intel_dvo_get_modes(struct drm_connector 
> *connector)
>   if (!list_empty(>probed_modes))
>   return 1;
>  
> - if (intel_dvo->panel_fixed_mode != NULL) {
> + if (fixed_mode) {
>   struct drm_display_mode *mode;
> - mode = drm_mode_duplicate(connector->dev, 
> intel_dvo->panel_fixed_mode);
> + mode = drm_mode_duplicate(connector->dev, fixed_mode);
>   if (mode) {
>   drm_mode_probed_add(connector, mode);
>   return 1;
> @@ -346,6 +339,7 @@ static int intel_dvo_get_modes(struct drm_connector 
> *connector)
>  static void intel_dvo_destroy(struct drm_connector *connector)
>  {
>   drm_connector_cleanup(connector);
> + intel_panel_fini(_intel_connector(connector)->panel);
>   kfree(connector);
>  }
>  
> @@ -372,8 +366,6 @@ static void intel_dvo_enc_destroy(struct drm_encoder 
> *encoder)
>   if 

Re: [Intel-gfx] [PATCH 3/7] drm/i915: s/mode/adjusted_mode/ in functions that really get passed the adjusted_mode

2015-09-24 Thread Mika Kahola
On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Rename the function argument to 'adjusted_mode' whenever the function
> only ever gets passed the adjusted_mode.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/intel_audio.c  | 17 +
>  drivers/gpu/drm/i915/intel_dsi.c| 16 
>  drivers/gpu/drm/i915/intel_panel.c  | 36 ++--
>  drivers/gpu/drm/i915/intel_sdvo.c   |  6 +++---
>  drivers/gpu/drm/i915/intel_sprite.c |  8 +---
>  6 files changed, 44 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 503dff5..4f4b504 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -646,7 +646,7 @@ struct drm_i915_display_funcs {
>   void (*crtc_disable)(struct drm_crtc *crtc);
>   void (*audio_codec_enable)(struct drm_connector *connector,
>  struct intel_encoder *encoder,
> -struct drm_display_mode *mode);
> +const struct drm_display_mode 
> *adjusted_mode);
>   void (*audio_codec_disable)(struct intel_encoder *encoder);
>   void (*fdi_link_train)(struct drm_crtc *crtc);
>   void (*init_clock_gating)(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index cf4f5d1..ca90ba3 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -69,17 +69,18 @@ static const struct {
>  };
>  
>  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> -static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
> +static u32 audio_config_hdmi_pixel_clock(const struct drm_display_mode 
> *adjusted_mode)
>  {
>   int i;
>  
>   for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> - if (mode->clock == hdmi_audio_clock[i].clock)
> + if (adjusted_mode->clock == hdmi_audio_clock[i].clock)
>   break;
>   }
>  
>   if (i == ARRAY_SIZE(hdmi_audio_clock)) {
> - DRM_DEBUG_KMS("HDMI audio pixel clock setting for %d not found, 
> falling back to defaults\n", mode->clock);
> + DRM_DEBUG_KMS("HDMI audio pixel clock setting for %d not found, 
> falling back to defaults\n",
> +   adjusted_mode->clock);
>   i = 1;
>   }
>  
> @@ -138,7 +139,7 @@ static void g4x_audio_codec_disable(struct intel_encoder 
> *encoder)
>  
>  static void g4x_audio_codec_enable(struct drm_connector *connector,
>  struct intel_encoder *encoder,
> -struct drm_display_mode *mode)
> +const struct drm_display_mode *adjusted_mode)
>  {
>   struct drm_i915_private *dev_priv = connector->dev->dev_private;
>   uint8_t *eld = connector->eld;
> @@ -203,7 +204,7 @@ static void hsw_audio_codec_disable(struct intel_encoder 
> *encoder)
>  
>  static void hsw_audio_codec_enable(struct drm_connector *connector,
>  struct intel_encoder *encoder,
> -struct drm_display_mode *mode)
> +const struct drm_display_mode *adjusted_mode)
>  {
>   struct drm_i915_private *dev_priv = connector->dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> @@ -251,7 +252,7 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
>   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
>   tmp |= AUD_CONFIG_N_VALUE_INDEX;
>   else
> - tmp |= audio_config_hdmi_pixel_clock(mode);
> + tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
>   I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>  }
>  
> @@ -304,7 +305,7 @@ static void ilk_audio_codec_disable(struct intel_encoder 
> *encoder)
>  
>  static void ilk_audio_codec_enable(struct drm_connector *connector,
>  struct intel_encoder *encoder,
> -struct drm_display_mode *mode)
> +const struct drm_display_mode *adjusted_mode)
>  {
>   struct drm_i915_private *dev_priv = connector->dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> @@ -381,7 +382,7 @@ static void ilk_audio_codec_enable(struct drm_connector 
> *connector,
>   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
>   tmp |= AUD_CONFIG_N_VALUE_INDEX;
>   else
> - tmp |= audio_config_hdmi_pixel_clock(mode);
> + tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
>   I915_WRITE(aud_config, tmp);
>  }
>  
> 

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Move HDMI aspect ratio setup to .compute_config()

2015-09-24 Thread Mika Kahola
Reviewed-by: Mika Kahola 

On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We shouldn't frob adjusted_mode after .compute_config(), so move the
> infoframe aspect ratio setup to .compute_config() from
> intel_hdmi_set_avi_infoframe().
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 0b256c9..e03dca0 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -454,9 +454,6 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>   union hdmi_infoframe frame;
>   int ret;
>  
> - /* Set user selected PAR to incoming mode's member */
> - adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
> -
>   ret = drm_hdmi_avi_infoframe_from_display_mode(,
>  adjusted_mode);
>   if (ret < 0) {
> @@ -1312,6 +1309,9 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   return false;
>   }
>  
> + /* Set user selected PAR to incoming mode's member */
> + adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
> +
>   return true;
>  }
>  


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


Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/guc: Add host2guc notification for suspend and resume

2015-09-24 Thread Kamble, Sagar A



On 9/23/2015 2:18 AM, yu@intel.com wrote:

From: Alex Dai 

Add host2guc interfaces to nofigy GuC power state changes when

*notify

enter or resume from power saving state.

v1: Change to a more flexible way when fill host to GuC scratch
data in order to remove hard coding.

Signed-off-by: Alex Dai 
---
  drivers/gpu/drm/i915/i915_drv.c|  1 +
  drivers/gpu/drm/i915/i915_gem.c|  1 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 50 ++
  drivers/gpu/drm/i915/intel_guc.h   |  2 ++
  drivers/gpu/drm/i915/intel_guc_fwif.h  |  8 +
  drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++-
  6 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e2bf9e2..8f2a139 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -735,6 +735,7 @@ static int i915_drm_resume(struct drm_device *dev)
DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
atomic_or(I915_WEDGED, 
_priv->gpu_error.reset_counter);
}
+   intel_guc_resume(dev);

Need to call from intel_runtime_resume as well.

mutex_unlock(>struct_mutex);
  
  	intel_modeset_init_hw(dev);

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 46f0e83..92dd4ff 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4458,6 +4458,7 @@ i915_gem_suspend(struct drm_device *dev)
i915_gem_retire_requests(dev);
  
  	i915_gem_stop_ringbuffers(dev);

+   intel_guc_suspend(dev);

Should this be called as part of i915_drm_suspend for consistency?
Need to call from intel_runtime_suspend as well.

mutex_unlock(>struct_mutex);
  
  	cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 792d0b9..38b6ef4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -914,3 +914,53 @@ void i915_guc_submission_fini(struct drm_device *dev)
gem_release_guc_obj(guc->ctx_pool_obj);
guc->ctx_pool_obj = NULL;
  }
+
+/**
+ * intel_guc_suspend() - notify GuC entering suspend state
+ * @dev:   drm device
+ */
+int intel_guc_suspend(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
+   /* any value greater than GUC_POWER_D0 */
+   data[1] = GUC_POWER_D1;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_action(guc, data, ARRAY_SIZE(data));
+}
+
+
+/**
+ * intel_guc_resume() - notify GuC resuming from suspend state
+ * @dev:   drm device
+ */
+int intel_guc_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
+   data[1] = GUC_POWER_D0;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_action(guc, data, ARRAY_SIZE(data));
+}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index e1389fc..e90c156 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -110,6 +110,8 @@ extern void intel_guc_ucode_init(struct drm_device *dev);
  extern int intel_guc_ucode_load(struct drm_device *dev);
  extern void intel_guc_ucode_fini(struct drm_device *dev);
  extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
+extern int intel_guc_suspend(struct drm_device *dev);
+extern int intel_guc_resume(struct drm_device *dev);
  
  /* i915_guc_submission.c */

  int i915_guc_submission_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 006dc0d..f6d0aa4 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -254,12 +254,20 @@ struct guc_context_desc {
u64 desc_private;
  } __packed;
  
+#define GUC_POWER_UNSPECIFIED	0

+#define GUC_POWER_D0   1
+#define GUC_POWER_D1   2
+#define GUC_POWER_D2   3
+#define GUC_POWER_D3   4
+
  /* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
  enum host2guc_action {

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

2015-09-24 Thread Jani Nikula
On Thu, 24 Sep 2015, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
>   drivers/gpu/drm/i915/intel_display.c
>
> between commit:
>
>   721a09f7393d ("drm/i915: Add primary plane to mask if it's visible")
>
> from the drm-intel-fixes tree and commit:
>
>   f9cd7b881a04 ("drm/i915: Move sprite/cursor plane disable to 
> intel_sanitize_crtc()")
>
> from the drm-intel tree.
>
> I fixed it up (I have no idea what do to here, so I just used the version
> from the drm-intel tree) and can carry the fix as necessary (no action
> is required - unless there is a better fix).

That was the right thing to do.

The former commit is headed for v4.3, and there will have to be another
version of it for -next. This will cause you another conflict, and you
should resolve it with the same approach.

Thanks,
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] [regression] Re: [Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled

2015-09-24 Thread Jani Nikula
On Thu, 24 Sep 2015, Sedat Dilek  wrote:
> On Wed, Sep 23, 2015 at 9:18 AM, Daniel Vetter  wrote:
>> Adding Jairo to track this regression.
>
> Hi,
>
> commit 721a09f7393de6c28a07516dccd654c6e995944a
> "drm/i915: Add primary plane to mask if it's visible"
>
> ...pending in drm-intel.git#drm-intel-fixes fixes the issue here.

Thanks for following up. The pull request has been sent.
http://mid.gmane.org/87si646uyf@intel.com

BR,
Jani.


>
> - sed@ -
>
> [1] 
> http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a
>
>> -Daniel
>>
>> On Wed, Sep 23, 2015 at 08:23:04AM +0200, Sedat Dilek wrote:
>>> On Sun, Sep 13, 2015 at 9:06 AM, Sedat Dilek  wrote:
>>> > On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek  wrote:
>>> >> [ TO INTEL DRM DRIVERS maintainers ]
>>> >>
>>> >> Hi,
>>> >>
>>> >> out of curiosity and to play with the new bindeb-pkg make-target I
>>> >> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a)
>>> >> Debian-kernel packages.
>>> >>
>>> >> I see several bugs and call-traces.
>>> >>
>>> >> Two hit a warning in i915 (one snippet here, full dmesg-log and
>>> >> kernel-config are attached).
>>> >>
>>> >> [   20.920943] [ cut here ]
>>> >> [   20.920982] WARNING: CPU: 0 PID: 114 at
>>> >> drivers/gpu/drm/i915/intel_display.c:1377
>>> >> assert_planes_disabled+0xe4/0x150 [i915]()
>>> >> [   20.920983] plane A assertion failure, should be disabled but not
>>> >> [   20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi
>>> >> snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel
>>> >> snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm
>>> >> joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage
>>> >> kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit
>>> >> drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth
>>> >> snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea
>>> >> snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device
>>> >> serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst
>>> >> mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii
>>> >> [   20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted
>>> >> 4.2.0-10463.1-iniza-small #1
>>> >> [   20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> >> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> >> [   20.921033] Workqueue: events_unbound async_run_entry_fn
>>> >> [   20.921037]  a06a9d60 8800378af718 813df89b
>>> >> 8800378af760
>>> >> [   20.921039]  8800378af750 8107cdc6 8800c200
>>> >> 
>>> >> [   20.921042]   8800bf90b000 8800bf90b000
>>> >> 8800378af7b0
>>> >> [   20.921043] Call Trace:
>>> >> [   20.921046]  [] dump_stack+0x4b/0x70
>>> >> [   20.921050]  [] warn_slowpath_common+0x86/0xc0
>>> >> [   20.921052]  [] warn_slowpath_fmt+0x4c/0x50
>>> >> [   20.921081]  [] assert_planes_disabled+0xe4/0x150 
>>> >> [i915]
>>> >> [   20.921106]  [] intel_disable_pipe+0x4f/0x2d0 [i915]
>>> >> [   20.921129]  [] ironlake_crtc_disable+0x85/0x7d0 
>>> >> [i915]
>>> >> [   20.921151]  [] ?
>>> >> intel_crtc_disable_planes+0xde/0xf0 [i915]
>>> >> [   20.921176]  [] intel_atomic_commit+0x108/0x1370 
>>> >> [i915]
>>> >> [   20.921192]  [] ? drm_atomic_check_only+0x1d7/0x5a0 
>>> >> [drm]
>>> >> [   20.921205]  [] ?
>>> >> drm_atomic_get_connector_state+0x49/0x110 [drm]
>>> >> [   20.921216]  [] drm_atomic_commit+0x37/0x60 [drm]
>>> >> [   20.921223]  []
>>> >> drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper]
>>> >> [   20.921234]  []
>>> >> drm_mode_set_config_internal+0x65/0x110 [drm]
>>> >> [   20.921240]  [] restore_fbdev_mode+0xbe/0xe0
>>> >> [drm_kms_helper]
>>> >> [   20.921246]  []
>>> >> drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
>>> >> [   20.921251]  [] drm_fb_helper_set_par+0x2d/0x50
>>> >> [drm_kms_helper]
>>> >> [   20.921280]  [] intel_fbdev_set_par+0x1a/0x60 [i915]
>>> >> [   20.921283]  [] fbcon_init+0x53e/0x5d0
>>> >> [   20.921286]  [] visual_init+0xca/0x130
>>> >> [   20.921289]  [] do_bind_con_driver+0x167/0x3a0
>>> >> [   20.921292]  [] do_take_over_console+0xac/0x1d0
>>> >> [   20.921294]  [] do_fbcon_takeover+0x57/0xb0
>>> >> [   20.921296]  [] fbcon_event_notify+0x752/0x860
>>> >> [   20.921299]  [] ? 
>>> >> __blocking_notifier_call_chain+0x35/0x70
>>> >> [   20.921301]  [] notifier_call_chain+0x5d/0x80
>>> >> [   20.921304]  [] 
>>> >> __blocking_notifier_call_chain+0x4d/0x70
>>> >> [   20.921306]  [] 
>>> >> blocking_notifier_call_chain+0x16/0x20
>>> >> [   20.921308]  [] fb_notifier_call_chain+0x1b/0x20
>>> >> [   20.921311]  [] register_framebuffer+0x204/0x330
>>> >> [   20.921317]  []
>>> >> drm_fb_helper_initial_config+0x234/0x3b0 [drm_kms_helper]
>>> >> [   

[Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

2015-09-24 Thread Chris Wilson
When preallocating a stolen object during early initialisation, we may
be running before we have setup the the global GTT VM state, in
particular before we have initialised the range manager and associated
lists. As this is the case, we defer binding the stolen object until we
call i915_gem_setup_global_gtt(). Not only should we defer the binding,
but we should also defer the VM list manipulation.

Fixes regression from commit a2cad9dff4dd44d0244b966d980de9d602d87593
Author: Michał Winiarski 
Date:   Wed Sep 16 11:49:00 2015 +0200

drm/i915/gtt: Do not initialize drm_mm twice.

Whilst I am here remove the duplicate work leaving dangling pointers
from the error path...

Reported-by: Jesse Barnes 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099
Signed-off-by: Chris Wilson 
Cc: Jesse Barnes 
Cc: Michel Thierry 
Cc: Mika Kuoppala 
Cc: Michał Winiarski 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c | 16 ++--
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 01f3521e77d3..9cc68624410e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2533,7 +2533,6 @@ static int ggtt_bind_vma(struct i915_vma *vma,
 * the bound flag ourselves.
 */
vma->bound |= GLOBAL_BIND;
-
}
 
if (dev_priv->mm.aliasing_ppgtt && flags & LOCAL_BIND) {
@@ -2657,6 +2656,7 @@ static int i915_gem_setup_global_gtt(struct drm_device 
*dev,
return ret;
}
vma->bound |= GLOBAL_BIND;
+   list_add_tail(>mm_list, >inactive_list);
}
 
/* Clear any non-preallocated blocks */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 55df6ce34751..15207796e1b3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -584,7 +584,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
vma = i915_gem_obj_lookup_or_create_vma(obj, ggtt);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
-   goto err_out;
+   goto err;
}
 
/* To simplify the initialisation sequence between KMS and GTT,
@@ -598,23 +598,19 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
ret = drm_mm_reserve_node(>mm, >node);
if (ret) {
DRM_DEBUG_KMS("failed to allocate stolen GTT space\n");
-   goto err_vma;
+   goto err;
}
-   }
 
-   vma->bound |= GLOBAL_BIND;
+   vma->bound |= GLOBAL_BIND;
+   list_add_tail(>mm_list, >inactive_list);
+   }
 
list_add_tail(>global_list, _priv->mm.bound_list);
-   list_add_tail(>mm_list, >inactive_list);
i915_gem_object_pin_pages(obj);
 
return obj;
 
-err_vma:
-   i915_gem_vma_destroy(vma);
-err_out:
-   i915_gem_stolen_remove_node(dev_priv, stolen);
-   kfree(stolen);
+err:
drm_gem_object_unreference(>base);
return NULL;
 }
-- 
2.5.3

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


Re: [Intel-gfx] [PATCH 6/7] drm/i915: Constify adjusted_mode

2015-09-24 Thread Mika Kahola
Reviewed-by: Mika Kahola 

On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Make adjusted_mode const whereever we don't have to modify it. This only
> covers cases when we have a local adjusted_mode variable, and doesn't
> make any difference for cases where we just dereference
> pipe_config->adjusted_mode.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/dvo.h   |  4 ++--
>  drivers/gpu/drm/i915/dvo_ch7017.c|  4 ++--
>  drivers/gpu/drm/i915/dvo_ch7xxx.c|  4 ++--
>  drivers/gpu/drm/i915/dvo_ivch.c  |  4 ++--
>  drivers/gpu/drm/i915/dvo_ns2501.c|  4 ++--
>  drivers/gpu/drm/i915/dvo_sil164.c|  4 ++--
>  drivers/gpu/drm/i915/dvo_tfp410.c|  4 ++--
>  drivers/gpu/drm/i915/intel_audio.c   |  2 +-
>  drivers/gpu/drm/i915/intel_crt.c |  2 +-
>  drivers/gpu/drm/i915/intel_display.c |  8 
>  drivers/gpu/drm/i915/intel_dp.c  |  2 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c  |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>  drivers/gpu/drm/i915/intel_dsi.c |  2 +-
>  drivers/gpu/drm/i915/intel_dvo.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c| 22 +++---
>  drivers/gpu/drm/i915/intel_panel.c   | 14 --
>  drivers/gpu/drm/i915/intel_pm.c  |  9 +++--
>  drivers/gpu/drm/i915/intel_sdvo.c|  2 +-
>  19 files changed, 44 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h
> index 3121633..0e2c1b9 100644
> --- a/drivers/gpu/drm/i915/dvo.h
> +++ b/drivers/gpu/drm/i915/dvo.h
> @@ -94,8 +94,8 @@ struct intel_dvo_dev_ops {
>* after this function is called.
>*/
>   void (*mode_set)(struct intel_dvo_device *dvo,
> -  struct drm_display_mode *mode,
> -  struct drm_display_mode *adjusted_mode);
> +  const struct drm_display_mode *mode,
> +  const struct drm_display_mode *adjusted_mode);
>  
>   /*
>* Probe for a connected output, and return detect_status.
> diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
> b/drivers/gpu/drm/i915/dvo_ch7017.c
> index 86b27d1..cbb2202 100644
> --- a/drivers/gpu/drm/i915/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/dvo_ch7017.c
> @@ -255,8 +255,8 @@ static enum drm_mode_status ch7017_mode_valid(struct 
> intel_dvo_device *dvo,
>  }
>  
>  static void ch7017_mode_set(struct intel_dvo_device *dvo,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
>  {
>   uint8_t lvds_pll_feedback_div, lvds_pll_vco_control;
>   uint8_t outputs_enable, lvds_control_2, lvds_power_down;
> diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c 
> b/drivers/gpu/drm/i915/dvo_ch7xxx.c
> index 80449f4..4b4acc1 100644
> --- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
> +++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
> @@ -275,8 +275,8 @@ static enum drm_mode_status ch7xxx_mode_valid(struct 
> intel_dvo_device *dvo,
>  }
>  
>  static void ch7xxx_mode_set(struct intel_dvo_device *dvo,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
>  {
>   uint8_t tvco, tpcp, tpd, tlpf, idf;
>  
> diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
> index e082f75..ff9f1b0 100644
> --- a/drivers/gpu/drm/i915/dvo_ivch.c
> +++ b/drivers/gpu/drm/i915/dvo_ivch.c
> @@ -394,8 +394,8 @@ static bool ivch_get_hw_state(struct intel_dvo_device 
> *dvo)
>  }
>  
>  static void ivch_mode_set(struct intel_dvo_device *dvo,
> -   struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> +   const struct drm_display_mode *mode,
> +   const struct drm_display_mode *adjusted_mode)
>  {
>   struct ivch_priv *priv = dvo->dev_priv;
>   uint16_t vr40 = 0;
> diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
> b/drivers/gpu/drm/i915/dvo_ns2501.c
> index 97ae8aa..063859f 100644
> --- a/drivers/gpu/drm/i915/dvo_ns2501.c
> +++ b/drivers/gpu/drm/i915/dvo_ns2501.c
> @@ -546,8 +546,8 @@ static enum drm_mode_status ns2501_mode_valid(struct 
> intel_dvo_device *dvo,
>  }
>  
>  static void ns2501_mode_set(struct intel_dvo_device *dvo,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
>  {
>   const struct 

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Always use crtc_ timings when dealing with adjustead_mode

2015-09-24 Thread Mika Kahola
Reviewed-by: Mika Kahola 

On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The adjustead_mode crtc_ timings are what we will program into the hardware,
> so it's those timings we should be looking practically everywhere.
> 
> The normal and crtc_ timings should differ only when stere doubling is
> used. In that case the normal timings are the orignal non-doubled
> timigns, and crtc_ timings are the doubled timings used by the hardware.
> 
> The only case where we continue to look at the normal timings is when we
> pass the adjusted_mode to drm_match_{cea,hdmi}_mode() to find the VIC.
> drm_edid keeps the modes aronund in the non-double form only, so it
> needs the non-double timings to match against.
> 
> Done with sed
> 's/adjusted_mode->\([vhVH]\)/adjusted_mode->crtc_\1/g'
> 's/adjusted_mode->clock/adjusted_mode->crtc_clock/g'
> with a manual s/VDisplay/vdisplay/ within the comment in intel_dvo.c
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/dvo_ivch.c  |  8 ++---
>  drivers/gpu/drm/i915/intel_audio.c   |  4 +--
>  drivers/gpu/drm/i915/intel_display.c |  4 +--
>  drivers/gpu/drm/i915/intel_dp_mst.c  |  2 +-
>  drivers/gpu/drm/i915/intel_dsi.c | 24 +++
>  drivers/gpu/drm/i915/intel_dvo.c |  8 ++---
>  drivers/gpu/drm/i915/intel_panel.c   | 58 
> ++--
>  drivers/gpu/drm/i915/intel_sdvo.c|  4 +--
>  8 files changed, 56 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
> index 732ce87..e082f75 100644
> --- a/drivers/gpu/drm/i915/dvo_ivch.c
> +++ b/drivers/gpu/drm/i915/dvo_ivch.c
> @@ -414,16 +414,16 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
>   vr40 = (VR40_STALL_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
>   VR40_HORIZONTAL_INTERP_ENABLE);
>  
> - if (mode->hdisplay != adjusted_mode->hdisplay ||
> - mode->vdisplay != adjusted_mode->vdisplay) {
> + if (mode->hdisplay != adjusted_mode->crtc_hdisplay ||
> + mode->vdisplay != adjusted_mode->crtc_vdisplay) {
>   uint16_t x_ratio, y_ratio;
>  
>   vr01 |= VR01_PANEL_FIT_ENABLE;
>   vr40 |= VR40_CLOCK_GATING_ENABLE;
>   x_ratio = (((mode->hdisplay - 1) << 16) /
> -(adjusted_mode->hdisplay - 1)) >> 2;
> +(adjusted_mode->crtc_hdisplay - 1)) >> 2;
>   y_ratio = (((mode->vdisplay - 1) << 16) /
> -(adjusted_mode->vdisplay - 1)) >> 2;
> +(adjusted_mode->crtc_vdisplay - 1)) >> 2;
>   ivch_write(dvo, VR42, x_ratio);
>   ivch_write(dvo, VR41, y_ratio);
>   } else {
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index ca90ba3..5848a50 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -74,13 +74,13 @@ static u32 audio_config_hdmi_pixel_clock(const struct 
> drm_display_mode *adjusted
>   int i;
>  
>   for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> - if (adjusted_mode->clock == hdmi_audio_clock[i].clock)
> + if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock)
>   break;
>   }
>  
>   if (i == ARRAY_SIZE(hdmi_audio_clock)) {
>   DRM_DEBUG_KMS("HDMI audio pixel clock setting for %d not found, 
> falling back to defaults\n",
> -   adjusted_mode->clock);
> +   adjusted_mode->crtc_clock);
>   i = 1;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b8b7540..f83e25d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4356,7 +4356,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state 
> *state)
>   return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
>   >scaler_state.scaler_id, DRM_ROTATE_0,
>   state->pipe_src_w, state->pipe_src_h,
> - adjusted_mode->hdisplay, adjusted_mode->vdisplay);
> + adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
>  }
>  
>  /**
> @@ -6543,7 +6543,7 @@ static int intel_crtc_compute_config(struct intel_crtc 
> *crtc,
>* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
>*/
>   if ((INTEL_INFO(dev)->gen > 4 || IS_G4X(dev)) &&
> - adjusted_mode->hsync_start == adjusted_mode->hdisplay)
> + adjusted_mode->crtc_hsync_start == adjusted_mode->crtc_hdisplay)
>   return -EINVAL;
>  
>   if (HAS_IPS(dev))
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 677d70e..dc2f67e 100644
> --- 

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

2015-09-24 Thread Jani Nikula
On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"  wrote:
> On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
>  > Hey,
>  > 
>  > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
>  > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
>  > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
>  > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
>  > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one 
> of
>  > >  > > > their recent patches.
>  > >  > 
>  > >  > Sounds like this showed up before my recent work, but I think I might
>  > >  > have seen similar problems while working on atomic watermarks; the
>  > >  > issues I was seeing were because the initial hardware readout could
>  > >  > leave primary->visible set to true even when the CRTC was off.  My
>  > >  > series (which is still under development) contains this patch to fix
>  > >  > that:
>  > >  > 
>  > >  > http://patchwork.freedesktop.org/patch/59564/
>  > >  > 
>  > >  > Does applying that help with the problems reported here?
>  > > 
>  > > No difference at all for me.
>  > Looks like a (reopened) dup of 91952?
>  > 
>  > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
>  > visible", and get me the results?
>
> This doesn't apply on top of Linus' current tree.
> If you let me know what it's dependant on, I'll do a build with
> those patches tomorrow.

It's now part of the drm-intel-fixes pull request [1], maybe it's
easiest to pull that in? Just four commits on top of
v4.3-rc2. Alternatively pick it up from our repo [2].

Thanks,
Jani.



[1] http://mid.gmane.org/87si646uyf@intel.com
[2] 
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a

>
>   Dave
>  

-- 
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] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well

2015-09-24 Thread Patrik Jakobsson
On Wed, Sep 23, 2015 at 01:18:00PM +0200, Patrik Jakobsson wrote:
> On Wed, Sep 23, 2015 at 10:43:00AM +0200, Daniel Vetter wrote:
> > On Mon, Sep 21, 2015 at 10:00:45AM +0200, Patrik Jakobsson wrote:
> > > On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> > > > > We need to be able to control if DC6 is allowed or not. Much like
> > > > > requesting power to a specific piece of the hardware we need to be 
> > > > > able
> > > > > to request that we don't enter DC6 during certain hw access.
> > > > > 
> > > > > To solve this without introducing too much infrastructure I'm hooking
> > > > > into the power well / power domain framework. DC6 prevention is 
> > > > > modeled
> > > > > much like an enabled power well. Thus I'm using the terminology on/off
> > > > > for DC states instead of enable/disable.
> > > > > 
> > > > > The problem that started this work is the need for DC6 to be disabled
> > > > > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
> > > > > patch.
> > > > > 
> > > > > This is posted as an RFC since DMC and DC state handling is being
> > > > > reworked and will possibly affect the outcome of this patch. The patch
> > > > > has known warnings.
> > > > > 
> > > > > Signed-off-by: Patrik Jakobsson 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_ddi.c|  9 +
> > > > >  drivers/gpu/drm/i915/intel_drv.h|  2 +
> > > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 69 
> > > > > +
> > > > >  3 files changed, 64 insertions(+), 16 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > index 4823184..c2c1ad2 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct 
> > > > > intel_encoder *intel_encoder)
> > > > >   if (type == INTEL_OUTPUT_DISPLAYPORT || type == 
> > > > > INTEL_OUTPUT_EDP) {
> > > > >   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > >  
> > > > > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > > > +
> > > > 
> > > > These I think shouldn't be necessary with my
> > > > intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
> > > > itself grab the appropriate power domain.
> > > > 
> > > > That's of course assuming that AUX is the only reason why we need to
> > > > keep DC6 disabled here.
> > > > 
> > > 
> > > The upside with having get/put around bigger aux transfers is that we 
> > > don't get
> > > tons of enable/disable lines in the log. My vote is that we keep this but 
> > > also
> > > have your fine-grained get/puts.
> > 
> > Imo the correct solution to avoid this is by adding a slight bit of
> > hystersis to the power well code. Which means that yes, we reinvent
> > another feature of the core power_domain code in our home-grown solution -
> > I hate it when my years old predictions come true ;-)
> > 
> > Sprinkling higher-level get/put calls all over the place is imo just
> > leaking the abstraction, which isn't good.
> > -Daniel
> 
> With Ville's patches the problem is not as bad as I first thought. We can add
> hysteresis later if needed.
> 
> -Patrik

So I discovered that we cannot have DC5 and DC6 as seperate power wells since
they are mutually exclusive. As Ville pointed out we don't use DC5 for anything
so we could get away for now with just DC6 as a power well.

As I see it there are three ways to go about this:

A. Add AUX A to Power well 2.
This would power up PW2 during DP Aux A even though we don't need it but since
we get the side effect of DC6 being disabled it should work.

B. Add DC6 off as a power well and remove DC5 off.
Fairly straight forward but assumes we don't need DC5 control.

C. Add multi-state support for the DC power well.
Would be the nice way but perhaps a bit overkill. Good thing about this would be
that we can incorporate DC9 control for BXT and unify more of the DC code.

So A, B or C?

-Patrik

> > -- 
> > 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 mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] lib/tests: explicitly raise SIGSEGV

2015-09-24 Thread Morton, Derek J
This relies on signal.h being included by wait.h. Would it be better to include 
it explicitly?

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Thomas Wood
Sent: Thursday, September 24, 2015 11:30 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH i-g-t] lib/tests: explicitly raise SIGSEGV

Dereferencing a NULL pointer is undefined behaviour and may not always result 
in a segmentation fault. Explicitly raise the SIGSEGV signal to test handling 
of this signal.

Signed-off-by: Thomas Wood 
---
 lib/tests/igt_segfault.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/tests/igt_segfault.c b/lib/tests/igt_segfault.c index 
b420b1a..bc7641d 100644
--- a/lib/tests/igt_segfault.c
+++ b/lib/tests/igt_segfault.c
@@ -57,11 +57,15 @@ bool runc;
 char test[] = "test";
 char *argv_run[] = { test };
 
+static void crashme(void)
+{
+   raise(SIGSEGV);
+}
+
 static int do_fork(void)
 {
int pid, status;
int argc;
-   void (*crashme)(void) = NULL;
 
switch (pid = fork()) {
case -1:
--
1.9.1

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


Re: [Intel-gfx] [PATCH 1/2] drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2

2015-09-24 Thread Jani Nikula
On Wed, 23 Sep 2015, Daniel Vetter  wrote:
> On Wed, Sep 23, 2015 at 04:13:00PM +0200, Egbert Eich wrote:
>> drm_kms_helper_poll_enable() was converted to lock the mode_config
>> mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
>> ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").
>> 
>> This disregarded the cases where this function is called from a context
>> where this mutex is already locked.
>> 
>> Add a non-locking version as well.
>> 
>> Changes since v1:
>> - use function name suffix '_locked' for the function that
>>   is to be called from a locked context.
>> 
>> Signed-off-by: Egbert Eich 
>
> Reviewed-by: Daniel Vetter 
>
> Jani can you please pick these two up for -fixes since the 2nd patch fixes
> a regression?
>
> Thanks, Daniel
>
>> ---
>>  drivers/gpu/drm/drm_probe_helper.c | 19 ---
>>  include/drm/drm_crtc_helper.h  |  1 +
>>  2 files changed, 17 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index d734780..2b9ce37 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -93,8 +93,19 @@ static int drm_helper_probe_add_cmdline_mode(struct 
>> drm_connector *connector)
>>  return 1;
>>  }
>>  
>> +/**
>> + * drm_kms_helper_poll_enable_locked - re-enable output polling.
>> + * @dev: drm_device
>> + *
>> + * This function re-enables the output polling work without
>> + * locking the mode_config mutex.
>> + *
>> + * This is like drm_kms_helper_poll_enable() however it is to be
>> + * called from a context where the mode_config mutex is locked
>> + * already.
>> + */
>>  #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
>> -static void __drm_kms_helper_poll_enable(struct drm_device *dev)
>> +void drm_kms_helper_poll_enable_locked(struct drm_device *dev)

Shouldn't this be _unlocked?

I thought the convention was that functions that do not acquire locks
are called _unlocked (although they may require a lock to be held when
called). And you might have foo() that grabs locks around a call to
foo_unlocked().

BR,
Jani.



>>  {
>>  bool poll = false;
>>  struct drm_connector *connector;
>> @@ -113,6 +124,8 @@ static void __drm_kms_helper_poll_enable(struct 
>> drm_device *dev)
>>  if (poll)
>>  schedule_delayed_work(>mode_config.output_poll_work, 
>> DRM_OUTPUT_POLL_PERIOD);
>>  }
>> +EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>> +
>>  
>>  static int drm_helper_probe_single_connector_modes_merge_bits(struct 
>> drm_connector *connector,
>>uint32_t maxX, 
>> uint32_t maxY, bool merge_type_bits)
>> @@ -174,7 +187,7 @@ static int 
>> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
>>  
>>  /* Re-enable polling in case the global poll config changed. */
>>  if (drm_kms_helper_poll != dev->mode_config.poll_running)
>> -__drm_kms_helper_poll_enable(dev);
>> +drm_kms_helper_poll_enable_locked(dev);
>>  
>>  dev->mode_config.poll_running = drm_kms_helper_poll;
>>  
>> @@ -428,7 +441,7 @@ EXPORT_SYMBOL(drm_kms_helper_poll_disable);
>>  void drm_kms_helper_poll_enable(struct drm_device *dev)
>>  {
>>  mutex_lock(>mode_config.mutex);
>> -__drm_kms_helper_poll_enable(dev);
>> +drm_kms_helper_poll_enable_locked(dev);
>>  mutex_unlock(>mode_config.mutex);
>>  }
>>  EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
>> index 2a747a9..3febb4b 100644
>> --- a/include/drm/drm_crtc_helper.h
>> +++ b/include/drm/drm_crtc_helper.h
>> @@ -240,5 +240,6 @@ extern void drm_kms_helper_hotplug_event(struct 
>> drm_device *dev);
>>  
>>  extern void drm_kms_helper_poll_disable(struct drm_device *dev);
>>  extern void drm_kms_helper_poll_enable(struct drm_device *dev);
>> +extern void drm_kms_helper_poll_enable_locked(struct drm_device *dev);
>>  
>>  #endif
>> -- 
>> 1.8.4.5
>> 
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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: set proper N/CTS in modeset

2015-09-24 Thread Yang, Libin
Hi Takashi,

Currently, our testing environment seems not to work. I will setup the test 
environment and send the patch after doing the test.

Regards,
Libin


> -Original Message-
> From: Yang, Libin
> Sent: Wednesday, September 23, 2015 10:20 PM
> To: Takashi Iwai; Jani Nikula
> Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; ville.syrj...@linux.intel.com
> Subject: RE: [PATCH] drm/i915: set proper N/CTS in modeset
> 
> Hi Takashi,
> 
> 
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Wednesday, September 23, 2015 4:41 PM
> > To: Jani Nikula
> > Cc: Yang, Libin; alsa-de...@alsa-project.org; intel-
> > g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> > ville.syrj...@linux.intel.com
> > Subject: Re: [PATCH] drm/i915: set proper N/CTS in modeset
> >
> > On Wed, 16 Sep 2015 15:03:15 +0200,
> > Jani Nikula wrote:
> > >
> > > > diff --git a/include/drm/i915_component.h
> > b/include/drm/i915_component.h
> > > > index e6d35d7..89dc7d6 100644
> > > > --- a/include/drm/i915_component.h
> > > > +++ b/include/drm/i915_component.h
> > > > @@ -24,8 +24,18 @@
> > > >  #ifndef _I915_COMPONENT_H_
> > > >  #define _I915_COMPONENT_H_
> > > >
> > > > +/* MAX_PORT is the number of port
> > > > + * It must be sync with I915_MAX_PORTS defined i915_drv.h
> > > > + * 5 should be enough as only HSW, BDW, SKL need such fix.
> > >
> > > You should probably add BUILD_BUG_ON(MAX_PORTS !=
> > I915_MAX_PORTS)
> > > somewhere near the loop above. Or at least change
> > I915_MAX_PORTS to
> > > ARRAY_SIZE(acomp->aud_sample_rate) in the loop to not run over
> > the array
> > > if MAX_PORTS gets out of sync.
> > >
> > > With that addressed one way or another, this is
> > >
> > > Reviewed-by: Jani Nikula 
> >
> > Libin, could you resubmit the patch with fixes Jani suggested?
> > Then I'm going to merge it to the existing topic/drm-sync-audio-rate
> > branch.
> 
> OK, I will send it tomorrow.
> 
> Regards,
> Libin
> 
> >
> >
> > thanks,
> >
> > Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Don't call intel_prepare_ddi when encoder list isn't yet initialized.

2015-09-24 Thread Imre Deak
On ke, 2015-09-23 at 11:32 -0700, Rodrigo Vivi wrote:
> In case something goes wrong with power well initialization we were calling
> intel_prepare_ddi during boot while encoder list isnt't initilized.
> 
> [9.618747] i915 :00:02.0: Invalid ROM contents
> [9.631446] [drm] failed to find VBIOS tables
> [9.720036] BUG: unable to handle kernel NULL pointer dereference at 
> 
> 0058
> [9.721986] IP: [] ddi_get_encoder_port+0x82/0x190 [i915]
> [9.723736] PGD 0
> [9.724286] Oops:  [#1] PREEMPT SMP
> [9.725386] Modules linked in: intel_powerclamp snd_hda_intel(+) coretemp 
> crc
> 32c_intel snd_hda_codec snd_hda_core serio_raw snd_pcm snd_timer i915(+) 
> parport
> _pc parport pinctrl_sunrisepoint pinctrl_intel nfsd nfs_acl
> [9.730635] CPU: 0 PID: 497 Comm: systemd-udevd Not tainted 
> 4.3.0-rc2-eywa-10
> 967-g72de2cfd-dirty #2
> [9.732785] Hardware name: Intel Corporation Cannonlake Client 
> platform/Skyla
> ke DT DDR4 RVP8, BIOS CNLSE2R1.R00.X021.B00.1508040310 08/04/2015
> [9.735785] task: 88008a704700 ti: 88016a1ac000 task.ti: 
> 88016a1a
> c000
> [9.737584] RIP: 0010:[]  [] 
> ddi_get_enco
> der_port+0x82/0x190 [i915]
> [9.739934] RSP: :88016a1af710  EFLAGS: 00010296
> [9.741184] RAX: 004e RBX: 88008a9edc98 RCX: 
> 0001
> [9.742934] RDX: 004e RSI: 81fc1e82 RDI: 
> 
> [9.744634] RBP: 88016a1af730 R08:  R09: 
> 0578
> [9.746333] R10: 1065 R11: 0578 R12: 
> fff8
> [9.748033] R13: 88016a1af7a8 R14: 88016a1af794 R15: 
> 
> [9.749733] FS:  7eff2e1e07c0() GS:88016fc0() 
> knlGS:0
> 000
> [9.751683] CS:  0010 DS:  ES:  CR0: 80050033
> [9.753083] CR2: 0058 CR3: 00016922b000 CR4: 
> 003406f0
> [9.754782] Stack:
> [9.755332]  88008a9edc98 88008a9ed800 a01d07b0 
> fffb9
> 09e
> [9.757232]  88016a1af7d8 a0154ea7 0246 
> 88016a370
> 080
> [9.759182]  88016a370080 88008a9ed800 0246 
> 88008a9ed
> c98
> [9.761132] Call Trace:
> [9.761782]  [] intel_prepare_ddi+0x67/0x860 [i915]
> [9.763332]  [] ? _raw_spin_unlock_irqrestore+0x26/0x40
> [9.765031]  [] ? gen9_read32+0x141/0x360 [i915]
> [9.766531]  [] skl_set_power_well+0x431/0xa80 [i915]
> [9.768181]  [] skl_power_well_enable+0x13/0x20 [i915]
> [9.769781]  [] intel_power_well_enable+0x28/0x50 [i915]
> [9.771481]  [] intel_display_power_get+0x92/0xc0 [i915]
> [9.773180]  [] intel_display_set_init_power+0x3b/0x40 
> [i91
> 5]
> [9.774980]  [] intel_power_domains_init_hw+0x120/0x520 
> [i9
> 15]
> [9.776780]  [] i915_driver_load+0xb21/0xf40 [i915]
> 
> So let's protect this case.
> 
> My first attempt was to remove the intel_prepare_ddi, but Daniel had pointed 
> out
> this is really needed to restore those registers values. And Imre pointed out
> that this case was without the flag protection and this was actually where 
> things
> were going bad. So I've just checked and this indeed solves my issue.
> 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Signed-off-by: Rodrigo Vivi 

I think this is a good solution for now, so:
Reviewed-by: Imre Deak 

About removing the DDI initialization from here:
At the moment DDI is initialized on all DDI platforms whenever we toggle
on/off some power well, or exit some power saving state. It's also
reinitialized for (e)DP where we have to change the settings during link
training. I'm not sure if we really need to initialize it before
modesetting at all though, I can't see why DDI functionality would be
needed before that. If it's not needed then the ideal would be to remove
it from every power well/power state handling path and to make sure we
call it during modesetting in all cases.

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 85c35fd..d194492 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -246,7 +246,8 @@ static void skl_power_well_post_enable(struct 
> drm_i915_private *dev_priv,
>   }
>  
>   if (power_well->data == SKL_DISP_PW_1) {
> - intel_prepare_ddi(dev);
> + if (!dev_priv->power_domains.initializing)
> + intel_prepare_ddi(dev);
>   gen8_irq_power_well_post_enable(dev_priv, 1 << PIPE_A);
>   }
>  }


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


Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

2015-09-24 Thread Daniel Vetter
On Thu, Sep 24, 2015 at 02:24:36PM +0300, Jani Nikula wrote:
> On Thu, 24 Sep 2015, "Winiarski, Michal"  wrote:
> > On Thu, 2015-09-24 at 11:57 +0100, Chris Wilson wrote:
> >> When preallocating a stolen object during early initialisation, we
> >> may
> >> be running before we have setup the the global GTT VM state, in
> >> particular before we have initialised the range manager and
> >> associated
> >> lists. As this is the case, we defer binding the stolen object until
> >> we
> >> call i915_gem_setup_global_gtt(). Not only should we defer the
> >> binding,
> >> but we should also defer the VM list manipulation.
> >> 
> >> Fixes regression uncovered by commit
> >> a2cad9dff4dd44d0244b966d980de9d602d87593
> >> Author: Michał Winiarski 
> >> Date:   Wed Sep 16 11:49:00 2015 +0200
> >> 
> >> drm/i915/gtt: Do not initialize drm_mm twice.
> 
> I confirm reverting the above works.
> 
> This patch is
> 
> Tested-by: Jani Nikula 
> 
> on a BWD GT2 ULT.

Queued for -next, thanks for the patch.
-Daniel

> 
> >> 
> >> Whilst I am here remove the duplicate work leaving dangling pointers
> >> from the error path...
> >> 
> >> v2: Typos galore before coffee.
> >> 
> >> Reported-by: Jesse Barnes 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099
> >> Signed-off-by: Chris Wilson 
> >> Cc: Jesse Barnes 
> >> Cc: Michel Thierry 
> >> Cc: Mika Kuoppala 
> >> Cc: Michał Winiarski 
> >> Cc: Daniel Vetter 
> >> Cc: Jani Nikula 
> >
> > Reviewed-by: Michał Winiarski 
> >
> > -Michał
> >
> >> ---
> >>  drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
> >>  drivers/gpu/drm/i915/i915_gem_stolen.c | 16 ++--
> >>  2 files changed, 7 insertions(+), 11 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> index 01f3521e77d3..291305fb2f3c 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> @@ -2533,7 +2533,6 @@ static int ggtt_bind_vma(struct i915_vma *vma,
> >> * the bound flag ourselves.
> >> */
> >>vma->bound |= GLOBAL_BIND;
> >> -
> >>}
> >>  
> >>if (dev_priv->mm.aliasing_ppgtt && flags & LOCAL_BIND) {
> >> @@ -2657,6 +2656,7 @@ static int i915_gem_setup_global_gtt(struct
> >> drm_device *dev,
> >>return ret;
> >>}
> >>vma->bound |= GLOBAL_BIND;
> >> +  list_add_tail(>mm_list, _vm
> >> ->inactive_list);
> >>}
> >>  
> >>/* Clear any non-preallocated blocks */
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> index 55df6ce34751..15207796e1b3 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> >> @@ -584,7 +584,7 @@
> >> i915_gem_object_create_stolen_for_preallocated(struct drm_device
> >> *dev,
> >>vma = i915_gem_obj_lookup_or_create_vma(obj, ggtt);
> >>if (IS_ERR(vma)) {
> >>ret = PTR_ERR(vma);
> >> -  goto err_out;
> >> +  goto err;
> >>}
> >>  
> >>/* To simplify the initialisation sequence between KMS and
> >> GTT,
> >> @@ -598,23 +598,19 @@
> >> i915_gem_object_create_stolen_for_preallocated(struct drm_device
> >> *dev,
> >>ret = drm_mm_reserve_node(>mm, >node);
> >>if (ret) {
> >>DRM_DEBUG_KMS("failed to allocate stolen GTT
> >> space\n");
> >> -  goto err_vma;
> >> +  goto err;
> >>}
> >> -  }
> >>  
> >> -  vma->bound |= GLOBAL_BIND;
> >> +  vma->bound |= GLOBAL_BIND;
> >> +  list_add_tail(>mm_list, >inactive_list);
> >> +  }
> >>  
> >>list_add_tail(>global_list, _priv->mm.bound_list);
> >> -  list_add_tail(>mm_list, >inactive_list);
> >>i915_gem_object_pin_pages(obj);
> >>  
> >>return obj;
> >>  
> >> -err_vma:
> >> -  i915_gem_vma_destroy(vma);
> >> -err_out:
> >> -  i915_gem_stolen_remove_node(dev_priv, stolen);
> >> -  kfree(stolen);
> >> +err:
> >>drm_gem_object_unreference(>base);
> >>return NULL;
> >>  }
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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 i-g-t] kms_crash: Check that KMS client crashes are properly handled

2015-09-24 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Check that frame buffers are torn down when a client dies.

Later could be extended with a CRC based test to check whether a later
client can inherit a plane left from an earlier one. There could be
some interesting data or images on that plane.

Signed-off-by: Tvrtko Ursulin 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/kms_crash.c  | 146 +
 3 files changed, 148 insertions(+)
 create mode 100644 tests/kms_crash.c

diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb539a754..a7dc10713b42 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -125,6 +125,7 @@ gen3_render_tiledy_blits
 gen7_forcewake_mt
 kms_3d
 kms_addfb_basic
+kms_crash
 kms_crtc_background_color
 kms_cursor_crc
 kms_draw_crc
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2e2e088a3aa1..8a2119d3df8f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -63,6 +63,7 @@ TESTS_progs_M = \
gem_userptr_blits \
gem_write_read_ring_switch \
kms_addfb_basic \
+   kms_crash \
kms_cursor_crc \
kms_draw_crc \
kms_fbc_crc \
diff --git a/tests/kms_crash.c b/tests/kms_crash.c
new file mode 100644
index ..121bad121922
--- /dev/null
+++ b/tests/kms_crash.c
@@ -0,0 +1,146 @@
+/*
+ * 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:
+ *   Tvrtko Ursulin 
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+
+
+IGT_TEST_DESCRIPTION("Test that crash of KMS clients is handled properly");
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   int gen;
+} data_t;
+
+static void
+fill_fb(struct igt_fb *fb, data_t *data, drmModeModeInfo *mode)
+{
+   cairo_t *cr;
+
+   cr = igt_get_cairo_ctx(data->drm_fd, fb);
+   igt_paint_test_pattern(cr, mode->hdisplay, mode->vdisplay);
+   cairo_destroy(cr);
+}
+
+static int count_framebuffers(void)
+{
+   FILE *fh;
+   int cnt = 0;
+   size_t n = 0;
+   char *line = NULL;
+
+   fh = igt_debugfs_fopen("i915_gem_framebuffer", O_RDONLY);
+   igt_assert(fh);
+
+   while (getline(, , fh) >= 0)
+   cnt++;
+
+   free(line)
+   fclose(fh);
+
+   return cnt;
+}
+
+static void
+crash_child(data_t *data)
+{
+   drmModeModeInfo *mode;
+   igt_output_t *output = NULL;
+   igt_plane_t *primary, *secondary;
+   struct igt_fb fb[2];
+   int fb_id, pipe;
+
+   data->drm_fd = drm_open_driver_master(DRIVER_INTEL);
+   igt_assert(data->drm_fd >= 0);
+   data->gen = intel_gen(intel_get_drm_devid(data->drm_fd));
+
+   igt_display_init(>display, data->drm_fd);
+
+   for_each_connected_output(>display, output)
+   break;
+   igt_require(output);
+
+   pipe = output->config.pipe;
+   igt_output_set_pipe(output, pipe);
+
+   mode = igt_output_get_mode(output);
+   primary = igt_output_get_plane(output, 0);
+   secondary = igt_output_get_plane(output, 1);
+   igt_assert(primary);
+   igt_require(secondary);
+
+   fb_id = igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE,
+ [0]);
+   igt_assert(fb_id);
+
+   fb_id = igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE,
+ [1]);
+   igt_assert(fb_id);
+
+   fill_fb([0], data, mode);
+   fill_fb([1], data, mode);
+
+   igt_plane_set_fb(primary, [0]);
+   igt_plane_set_fb(secodary, [1]);
+   igt_display_commit(>display);
+
+   _exit(0);
+}
+
+static data_t data;
+

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

2015-09-24 Thread Dave Gordon

On 22/09/15 21:48, yu@intel.com wrote:

From: Alex Dai 

By using information from GuC css header, we can eliminate some
hard code w.r.t size of some components of firmware.

v2: Add indent into DOC to make fixed-width format rather than
change the tmpl.

v1: 1) guc_css_header is defined as __packed now
 2) Add and correct GuC related topics in kernel/Doc

Signed-off-by: Alex Dai 
---
  Documentation/DocBook/drm.tmpl  |   9 ++-
  drivers/gpu/drm/i915/intel_guc.h|   2 +-
  drivers/gpu/drm/i915/intel_guc_fwif.h   |  36 +++
  drivers/gpu/drm/i915/intel_guc_loader.c | 107 ++--
  4 files changed, 117 insertions(+), 37 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 66bc646..116332f 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4155,14 +4155,19 @@ int num_ioctls;
GuC-based Command Submission

  GuC
-!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
+!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC
  !Idrivers/gpu/drm/i915/intel_guc_loader.c


  GuC Client
-!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
+!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC Client
  !Idrivers/gpu/drm/i915/i915_guc_submission.c

+  
+GuC Firmware Layout
+!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC Firmware Layout
+!Idrivers/gpu/drm/i915/intel_guc_loader.c
+  
  

  
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 4ec2d27..e1389fc 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -71,6 +71,7 @@ struct intel_guc_fw {
struct drm_i915_gem_object *guc_fw_obj;
enum intel_guc_fw_statusguc_fw_fetch_status;
enum intel_guc_fw_statusguc_fw_load_status;
+   struct guc_css_header   guc_fw_header;

uint16_tguc_fw_major_wanted;
uint16_tguc_fw_minor_wanted;
@@ -80,7 +81,6 @@ struct intel_guc_fw {

  struct intel_guc {
struct intel_guc_fw guc_fw;
-
uint32_t log_flags;
struct drm_i915_gem_object *log_obj;

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index e1f47ba..006dc0d 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -122,6 +122,42 @@

  #define GUC_CTL_MAX_DWORDS(GUC_CTL_RSRVD + 1)

+struct guc_css_header {
+   uint32_t module_type;
+   uint32_t header_len; /* header length plus size of all other keys */
+   uint32_t header_version;
+   uint32_t module_id;
+   uint32_t module_vendor;
+   union {
+   struct {
+   uint8_t day;
+   uint8_t month;
+   uint16_t year;
+   };
+   uint32_t date;
+   };
+   uint32_t size; /* uCode size plus header_len */
+   uint32_t key_size;
+   uint32_t modulus_size;
+   uint32_t exponent_size;
+   union {
+   struct {
+   uint8_t hour;
+   uint8_t min;
+   uint16_t sec;
+   };
+   uint32_t time;
+   };
+
+   char username[8];
+   char buildnumber[12];
+   uint32_t device_id;
+   uint32_t guc_sw_version;
+   uint32_t prod_preprod_fw;
+   uint32_t reserved[12];
+   uint32_t header_info;
+} __packed;
+
  struct guc_doorbell_info {
u32 db_status;
u32 cookie;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 40241f3..a6703b4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -215,18 +215,29 @@ static inline bool guc_ucode_response(struct 
drm_i915_private *dev_priv,
((val & GS_MIA_CORE_STATE) && uk_val == GS_UKERNEL_LAPIC_DONE));
  }

-/*
- * Transfer the firmware image to RAM for execution by the microcontroller.
+/**
+ * DOC: GuC Firmware Layout
   *
- * GuC Firmware layout:
- * +---+  
- * |  CSS header   |  128B
- * | contains major/minor version  |
- * +---+  
- * | uCode |
- * +---+  
- * | RSA signature |  256B
- * +---+  
+ * The GuC firmware layout looks like this:
+ *
+ * +---+
+ * |guc_css_header |
+ * | contains major/minor version  |
+ * +---+
+ * | uCode |
+ * +---+
+ * | RSA signature |
+ * +---+
+ * 

Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well

2015-09-24 Thread Ville Syrjälä
On Thu, Sep 24, 2015 at 02:50:16PM +0200, Patrik Jakobsson wrote:
> On Wed, Sep 23, 2015 at 01:18:00PM +0200, Patrik Jakobsson wrote:
> > On Wed, Sep 23, 2015 at 10:43:00AM +0200, Daniel Vetter wrote:
> > > On Mon, Sep 21, 2015 at 10:00:45AM +0200, Patrik Jakobsson wrote:
> > > > On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> > > > > On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> > > > > > We need to be able to control if DC6 is allowed or not. Much like
> > > > > > requesting power to a specific piece of the hardware we need to be 
> > > > > > able
> > > > > > to request that we don't enter DC6 during certain hw access.
> > > > > > 
> > > > > > To solve this without introducing too much infrastructure I'm 
> > > > > > hooking
> > > > > > into the power well / power domain framework. DC6 prevention is 
> > > > > > modeled
> > > > > > much like an enabled power well. Thus I'm using the terminology 
> > > > > > on/off
> > > > > > for DC states instead of enable/disable.
> > > > > > 
> > > > > > The problem that started this work is the need for DC6 to be 
> > > > > > disabled
> > > > > > when accessing DP_AUX_A during CRTC on/off. That is also fixed in 
> > > > > > this
> > > > > > patch.
> > > > > > 
> > > > > > This is posted as an RFC since DMC and DC state handling is being
> > > > > > reworked and will possibly affect the outcome of this patch. The 
> > > > > > patch
> > > > > > has known warnings.
> > > > > > 
> > > > > > Signed-off-by: Patrik Jakobsson 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_ddi.c|  9 +
> > > > > >  drivers/gpu/drm/i915/intel_drv.h|  2 +
> > > > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 69 
> > > > > > +
> > > > > >  3 files changed, 64 insertions(+), 16 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > index 4823184..c2c1ad2 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct 
> > > > > > intel_encoder *intel_encoder)
> > > > > > if (type == INTEL_OUTPUT_DISPLAYPORT || type == 
> > > > > > INTEL_OUTPUT_EDP) {
> > > > > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > > >  
> > > > > > +   intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > > > > +
> > > > > 
> > > > > These I think shouldn't be necessary with my
> > > > > intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() 
> > > > > will
> > > > > itself grab the appropriate power domain.
> > > > > 
> > > > > That's of course assuming that AUX is the only reason why we need to
> > > > > keep DC6 disabled here.
> > > > > 
> > > > 
> > > > The upside with having get/put around bigger aux transfers is that we 
> > > > don't get
> > > > tons of enable/disable lines in the log. My vote is that we keep this 
> > > > but also
> > > > have your fine-grained get/puts.
> > > 
> > > Imo the correct solution to avoid this is by adding a slight bit of
> > > hystersis to the power well code. Which means that yes, we reinvent
> > > another feature of the core power_domain code in our home-grown solution -
> > > I hate it when my years old predictions come true ;-)
> > > 
> > > Sprinkling higher-level get/put calls all over the place is imo just
> > > leaking the abstraction, which isn't good.
> > > -Daniel
> > 
> > With Ville's patches the problem is not as bad as I first thought. We can 
> > add
> > hysteresis later if needed.
> > 
> > -Patrik
> 
> So I discovered that we cannot have DC5 and DC6 as seperate power wells since
> they are mutually exclusive. As Ville pointed out we don't use DC5 for 
> anything
> so we could get away for now with just DC6 as a power well.
> 
> As I see it there are three ways to go about this:
> 
> A. Add AUX A to Power well 2.
> This would power up PW2 during DP Aux A even though we don't need it but since
> we get the side effect of DC6 being disabled it should work.
> 
> B. Add DC6 off as a power well and remove DC5 off.
> Fairly straight forward but assumes we don't need DC5 control.
> 
> C. Add multi-state support for the DC power well.
> Would be the nice way but perhaps a bit overkill. Good thing about this would 
> be
> that we can incorporate DC9 control for BXT and unify more of the DC code.
> 
> So A, B or C?

After some spitballing with Imre we came up with the following power well 
layout,
which I think matches the documented seuqences in the spec the best:

display well:
domains: 
all
enable:
init display sequence
enable pch reset handshake
enable pw1 and miscio
enable cdclk pll
enable dbuf
dc_state_en = up_to_dc6
disable:
dc_state_en = disable
uninit display sequence

Re: [Intel-gfx] [RFC][PATCH 43/43] WIP: drm/i915: Type safe register read/write

2015-09-24 Thread Ville Syrjälä
On Wed, Sep 23, 2015 at 05:23:27PM +0200, Daniel Vetter wrote:
> On Fri, Sep 18, 2015 at 08:03:56PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Make I915_READ and I915_WRITE more type safe by wrapping the register
> > offset in a struct. This should eliminate most of the fumbles we've had
> > with misplaced parens.
> > 
> > This only takes care of normal mmio registers. We could extend the idea
> > to other register types and define each with its own struct. That way
> > you wouldn't be able to accidentally pass the wrong thing to a specific
> > register access function.
> > 
> > There are a few uglies left:
> > - switch statements don't like structs as case values, even if
> >   you case 'case DEADBEEF.reg:'. Fortunately we don't have too many
> >   of those so can maybe switch them to use some port enums or such,
> >   or if all else fails if ladders
> > - cmd parser is still iffed out. I was just tool lazy to do that
> >   for an RFC
> > - the vgpu stuff is ugly cause I didn't spend any time figuring out
> >   what it really wants to do
> > - maybe something else I'm overlooking?
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> I like this very much, which is also why I started pulling in prep patches 
> already.
> 
> One bikeshed though: I think this is one of the very few exceptions where
> coding style says typedefs are ok, since this really is just an opaque
> datatype that gets passed around and only opened-up in low-level code
> similar to ptes. So my vote is on i915_reg_t. And since we might want to
> extend this to other register io functions maybe call it i915_mmio_reg_t.

Chris wanted the same, and so I've made the change already. If you want to
take sneak peek, it's available in the update branch I mentioned in my earlier
reply to the cover letter.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: fixup runtime PM handling v2

2015-09-24 Thread Jesse Barnes
Forgot to cc Rafael.

On 09/23/2015 02:37 PM, Jesse Barnes wrote:
> According to the PCI docs and Rafael, we don't need to be doing explicit
> enables and disables in our init and teardown routines, as they're taken
> care of by the PCI core.  So drop the pm_runtime_disable() at teardown
> and pm_runtime_set_active() at init.
> 
> This fixes one failure of the basic-pci-d3-state test on my BYT.
> 
> v2: drop extra get_noresume() and put_noidle() (Rafael)
> 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 85c35fd..824e7b0 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1822,7 +1822,6 @@ static void intel_runtime_pm_disable(struct 
> drm_i915_private *dev_priv)
>  
>   /* Make sure we're not suspended first. */
>   pm_runtime_get_sync(device);
> - pm_runtime_disable(device);
>  }
>  
>  /**
> @@ -2114,8 +2113,6 @@ void intel_runtime_pm_enable(struct drm_i915_private 
> *dev_priv)
>   if (!HAS_RUNTIME_PM(dev))
>   return;
>  
> - pm_runtime_set_active(device);
> -
>   /*
>* RPM depends on RC6 to save restore the GT HW context, so make RC6 a
>* requirement.
> 

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


Re: [Intel-gfx] [PATCH 3/4] drm/i915: Support NV12 in rotated GGTT mapping

2015-09-24 Thread Ville Syrjälä
On Mon, Sep 21, 2015 at 10:45:34AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Just adding the rotated UV plane at the end of the rotated Y plane.
> 
> v2: Rebase.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c  | 37 
> ++--
>  drivers/gpu/drm/i915/i915_gem_gtt.h  |  3 +++
>  drivers/gpu/drm/i915/intel_display.c | 12 
>  3 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 59c934fb9230..2df9d16dcefd 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3272,10 +3272,13 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view 
> *ggtt_view,
>  {
>   struct intel_rotation_info *rot_info = _view->rotation_info;
>   unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
> + unsigned int size_pages_uv;
>   struct sg_page_iter sg_iter;
>   unsigned long i;
>   dma_addr_t *page_addr_list;
>   struct sg_table *st;
> + unsigned int uv_start_page;
> + struct scatterlist *sg;
>   int ret = -ENOMEM;
>  
>   /* Allocate a temporary list of source pages for random access. */
> @@ -3284,12 +3287,18 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view 
> *ggtt_view,
>   if (!page_addr_list)
>   return ERR_PTR(ret);
>  
> + /* Account for UV plane with NV12. */
> + if (rot_info->pixel_format == DRM_FORMAT_NV12)
> + size_pages_uv = rot_info->size_uv >> PAGE_SHIFT;
> + else
> + size_pages_uv = 0;
> +
>   /* Allocate target SG list. */
>   st = kmalloc(sizeof(*st), GFP_KERNEL);
>   if (!st)
>   goto err_st_alloc;
>  
> - ret = sg_alloc_table(st, size_pages, GFP_KERNEL);
> + ret = sg_alloc_table(st, size_pages + size_pages_uv, GFP_KERNEL);
>   if (ret)
>   goto err_sg_alloc;
>  
> @@ -3301,15 +3310,30 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view 
> *ggtt_view,
>   }
>  
>   /* Rotate the pages. */
> - rotate_pages(page_addr_list, 0,
> + sg = rotate_pages(page_addr_list, 0,
>rot_info->width_pages, rot_info->height_pages,
>st, NULL);
>  
> + /* Append the UV plane if NV12. */
> + if (rot_info->pixel_format == DRM_FORMAT_NV12) {
> + uv_start_page = size_pages;
> +
> + /* Check for tile-row un-alignment. */
> + if (offset_in_page(rot_info->uv_offset))
> + uv_start_page--;
> +
> + rotate_pages(page_addr_list, uv_start_page,
> +  rot_info->width_pages_uv,
> +  rot_info->height_pages_uv,
> +  st, sg);
> + }
> +
>   DRM_DEBUG_KMS(
> -   "Created rotated page mapping for object size %zu 
> (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages).\n",
> +   "Created rotated page mapping for object size %zu 
> (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane 
> 0)).\n",
> obj->base.size, rot_info->pitch, rot_info->height,
> rot_info->pixel_format, rot_info->width_pages,
> -   rot_info->height_pages, size_pages);
> +   rot_info->height_pages, size_pages + size_pages_uv,
> +   size_pages);
>  
>   drm_free_large(page_addr_list);
>  
> @@ -3321,10 +3345,11 @@ err_st_alloc:
>   drm_free_large(page_addr_list);
>  
>   DRM_DEBUG_KMS(
> -   "Failed to create rotated mapping for object size %zu! 
> (%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages)\n",
> +   "Failed to create rotated mapping for object size %zu! 
> (%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane 
> 0))\n",
> obj->base.size, ret, rot_info->pitch, rot_info->height,
> rot_info->pixel_format, rot_info->width_pages,
> -   rot_info->height_pages, size_pages);
> +   rot_info->height_pages, size_pages + size_pages_uv,
> +   size_pages);
>   return ERR_PTR(ret);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 82750073d5b3..197183d5c543 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -138,10 +138,13 @@ enum i915_ggtt_view_type {
>  struct intel_rotation_info {
>   unsigned int height;
>   unsigned int pitch;
> + unsigned int uv_offset;
>   uint32_t pixel_format;
>   uint64_t fb_modifier;
>   unsigned int width_pages, height_pages;
>   uint64_t size;
> + unsigned int width_pages_uv, height_pages_uv;
> + uint64_t size_uv;
>  };
>  
>  struct i915_ggtt_view {
> diff --git 

Re: [Intel-gfx] [PATCH] drm/i915: Detect virtual south bridge

2015-09-24 Thread Jesse Barnes
On 08/28/2015 05:10 AM, robert.beck...@intel.com wrote:
> From: Robert Beckett 
> 
> Virtualized systems often use a virtual P2X4 south bridge.
> Detect this in intel_detect_pch and make a best guess as to which PCH
> we should be using.
> 
> This was seen on vmware esxi hypervisor. When passing the graphics device
> through to a guest, it can not pass through the PCH. Instead it simulates
> a P2X4 southbridge.
> 
> Signed-off-by: Robert Beckett 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |   30 ++
>  drivers/gpu/drm/i915/i915_drv.h |1 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ce3bd0c..8e158b3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -443,6 +443,34 @@ static const struct pci_device_id pciidlist[] = {
> /* aka */
>  
>  MODULE_DEVICE_TABLE(pci, pciidlist);
>  
> +static enum intel_pch intel_virt_detect_pch(struct drm_device *dev)
> +{
> + enum intel_pch ret = PCH_NOP;
> +
> + /*
> +  * In a virtualized passthrough environment we can be in a
> +  * setup where the ISA bridge is not able to be passed through.
> +  * In this case, a south bridge can be emulated and we have to
> +  * make an educated guess as to which PCH is really there.
> +  */
> +
> + if (IS_GEN5(dev)) {
> + ret = PCH_IBX;
> + DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
> + } else if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
> + ret = PCH_CPT;
> + DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> + } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> + ret = PCH_LPT;
> + DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> + } else if (IS_SKYLAKE(dev)) {
> + ret = PCH_SPT;
> + DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> + }
> +
> + return ret;
> +}
> +
>  void intel_detect_pch(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -503,6 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
>   dev_priv->pch_type = PCH_SPT;
>   DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
>   WARN_ON(!IS_SKYLAKE(dev));
> + } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
> + dev_priv->pch_type = intel_virt_detect_pch(dev);
>   } else
>   continue;
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8c93845..6eb0230 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2584,6 +2584,7 @@ struct drm_i915_cmd_table {
>  #define INTEL_PCH_LPT_LP_DEVICE_ID_TYPE  0x9c00
>  #define INTEL_PCH_SPT_DEVICE_ID_TYPE 0xA100
>  #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE  0x9D00
> +#define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
>  
>  #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
>  #define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
> 

Assuming Kevin is ok with this:
Reviewed-by: Jesse Barnes 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: fixup runtime PM handling v2

2015-09-24 Thread Rafael J. Wysocki
On Thursday, September 24, 2015 08:40:28 AM Jesse Barnes wrote:
> Forgot to cc Rafael.
> 
> On 09/23/2015 02:37 PM, Jesse Barnes wrote:
> > According to the PCI docs and Rafael, we don't need to be doing explicit
> > enables and disables in our init and teardown routines, as they're taken
> > care of by the PCI core.  So drop the pm_runtime_disable() at teardown
> > and pm_runtime_set_active() at init.
> > 
> > This fixes one failure of the basic-pci-d3-state test on my BYT.
> > 
> > v2: drop extra get_noresume() and put_noidle() (Rafael)
> > 
> > Signed-off-by: Jesse Barnes 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 85c35fd..824e7b0 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1822,7 +1822,6 @@ static void intel_runtime_pm_disable(struct 
> > drm_i915_private *dev_priv)
> >  
> > /* Make sure we're not suspended first. */
> > pm_runtime_get_sync(device);
> > -   pm_runtime_disable(device);
> >  }
> >  
> >  /**
> > @@ -2114,8 +2113,6 @@ void intel_runtime_pm_enable(struct drm_i915_private 
> > *dev_priv)
> > if (!HAS_RUNTIME_PM(dev))
> > return;
> >  
> > -   pm_runtime_set_active(device);
> > -
> > /*
> >  * RPM depends on RC6 to save restore the GT HW context, so make RC6 a
> >  * requirement.
> > 
> 

Looks good to me, thanks!

Rafael

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


Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

2015-09-24 Thread Dave Gordon

On 24/09/15 19:34, Yu Dai wrote:



On 09/24/2015 07:23 AM, Dave Gordon wrote:

On 22/09/15 21:48, yu@intel.com wrote:
> From: Alex Dai 
>
> By using information from GuC css header, we can eliminate some
> hard code w.r.t size of some components of firmware.
>
> v2: Add indent into DOC to make fixed-width format rather than
> change the tmpl.
>
> v1: 1) guc_css_header is defined as __packed now
>  2) Add and correct GuC related topics in kernel/Doc
>
> Signed-off-by: Alex Dai 
> ---
>   Documentation/DocBook/drm.tmpl  |   9 ++-
>   drivers/gpu/drm/i915/intel_guc.h|   2 +-
>   drivers/gpu/drm/i915/intel_guc_fwif.h   |  36 +++
>   drivers/gpu/drm/i915/intel_guc_loader.c | 107
++--
>   4 files changed, 117 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl
b/Documentation/DocBook/drm.tmpl
> index 66bc646..116332f 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -4155,14 +4155,19 @@ int num_ioctls;
> GuC-based Command Submission
> 
../linux-image-4.3.0-rc2-dsg-11022-g9765caf-dsg-intel-nightly_4.3.0-rc2-dsg-11022-g9765caf-dsg-intel-nightly-7_amd64.deb
>   GuC
> -!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
> +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC
>   !Idrivers/gpu/drm/i915/intel_guc_loader.c
> 
> 
>   GuC Client
> -!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command
submissison
> +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC Client
>   !Idrivers/gpu/drm/i915/i915_guc_submission.c
> 
> +  
> +GuC Firmware Layout
> +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC Firmware Layout
> +!Idrivers/gpu/drm/i915/intel_guc_loader.c
> +  
>   
>
>   
> diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
> index 4ec2d27..e1389fc 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -71,6 +71,7 @@ struct intel_guc_fw {
>   struct drm_i915_gem_object *guc_fw_obj;
>   enum intel_guc_fw_statusguc_fw_fetch_status;
>   enum intel_guc_fw_statusguc_fw_load_status;
> +struct guc_css_headerguc_fw_header;
>
>   uint16_tguc_fw_major_wanted;
>   uint16_tguc_fw_minor_wanted;
> @@ -80,7 +81,6 @@ struct intel_guc_fw {
>
>   struct intel_guc {
>   struct intel_guc_fw guc_fw;
> -
>   uint32_t log_flags;
>   struct drm_i915_gem_object *log_obj;
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index e1f47ba..006dc0d 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -122,6 +122,42 @@
>
>   #define GUC_CTL_MAX_DWORDS(GUC_CTL_RSRVD + 1)
>
> +struct guc_css_header {
> +uint32_t module_type;
> +uint32_t header_len; /* header length plus size of all other
keys */
> +uint32_t header_version;
> +uint32_t module_id;
> +uint32_t module_vendor;
> +union {
> +struct {
> +uint8_t day;
> +uint8_t month;
> +uint16_t year;
> +};
> +uint32_t date;
> +};
> +uint32_t size; /* uCode size plus header_len */
> +uint32_t key_size;
> +uint32_t modulus_size;
> +uint32_t exponent_size;
> +union {
> +struct {
> +uint8_t hour;
> +uint8_t min;
> +uint16_t sec;
> +};
> +uint32_t time;
> +};
> +
> +char username[8];
> +char buildnumber[12];
> +uint32_t device_id;
> +uint32_t guc_sw_version;
> +uint32_t prod_preprod_fw;
> +uint32_t reserved[12];
> +uint32_t header_info;
> +} __packed;
> +
>   struct guc_doorbell_info {
>   u32 db_status;
>   u32 cookie;
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 40241f3..a6703b4 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -215,18 +215,29 @@ static inline bool guc_ucode_response(struct
drm_i915_private *dev_priv,
>   ((val & GS_MIA_CORE_STATE) && uk_val ==
GS_UKERNEL_LAPIC_DONE));
>   }
>
> -/*
> - * Transfer the firmware image to RAM for execution by the
microcontroller.
> +/**
> + * DOC: GuC Firmware Layout
>*
> - * GuC Firmware layout:
> - * +---+  
> - * |  CSS header   |  128B
> - * | contains major/minor version  |
> - * +---+  
> - * | uCode |
> - * +---+  
> - * | RSA signature |  256B
> - * +---+  
> + * The GuC firmware layout looks like this:
> + *
> + * +---+
> + * |guc_css_header |
> + * | contains major/minor 

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

2015-09-24 Thread Yu Dai



On 09/24/2015 07:23 AM, Dave Gordon wrote:

On 22/09/15 21:48, yu@intel.com wrote:
> From: Alex Dai 
>
> By using information from GuC css header, we can eliminate some
> hard code w.r.t size of some components of firmware.
>
> v2: Add indent into DOC to make fixed-width format rather than
> change the tmpl.
>
> v1: 1) guc_css_header is defined as __packed now
>  2) Add and correct GuC related topics in kernel/Doc
>
> Signed-off-by: Alex Dai 
> ---
>   Documentation/DocBook/drm.tmpl  |   9 ++-
>   drivers/gpu/drm/i915/intel_guc.h|   2 +-
>   drivers/gpu/drm/i915/intel_guc_fwif.h   |  36 +++
>   drivers/gpu/drm/i915/intel_guc_loader.c | 107 
++--
>   4 files changed, 117 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 66bc646..116332f 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -4155,14 +4155,19 @@ int num_ioctls;
> GuC-based Command Submission
> 
>   GuC
> -!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
> +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC
>   !Idrivers/gpu/drm/i915/intel_guc_loader.c
> 
> 
>   GuC Client
> -!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
> +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC Client
>   !Idrivers/gpu/drm/i915/i915_guc_submission.c
> 
> +  
> +GuC Firmware Layout
> +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC Firmware Layout
> +!Idrivers/gpu/drm/i915/intel_guc_loader.c
> +  
>   
>
>   
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h
> index 4ec2d27..e1389fc 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -71,6 +71,7 @@ struct intel_guc_fw {
>struct drm_i915_gem_object *guc_fw_obj;
>enum intel_guc_fw_statusguc_fw_fetch_status;
>enum intel_guc_fw_statusguc_fw_load_status;
> +  struct guc_css_header   guc_fw_header;
>
>uint16_tguc_fw_major_wanted;
>uint16_tguc_fw_minor_wanted;
> @@ -80,7 +81,6 @@ struct intel_guc_fw {
>
>   struct intel_guc {
>struct intel_guc_fw guc_fw;
> -
>uint32_t log_flags;
>struct drm_i915_gem_object *log_obj;
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index e1f47ba..006dc0d 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -122,6 +122,42 @@
>
>   #define GUC_CTL_MAX_DWORDS   (GUC_CTL_RSRVD + 1)
>
> +struct guc_css_header {
> +  uint32_t module_type;
> +  uint32_t header_len; /* header length plus size of all other keys */
> +  uint32_t header_version;
> +  uint32_t module_id;
> +  uint32_t module_vendor;
> +  union {
> +  struct {
> +  uint8_t day;
> +  uint8_t month;
> +  uint16_t year;
> +  };
> +  uint32_t date;
> +  };
> +  uint32_t size; /* uCode size plus header_len */
> +  uint32_t key_size;
> +  uint32_t modulus_size;
> +  uint32_t exponent_size;
> +  union {
> +  struct {
> +  uint8_t hour;
> +  uint8_t min;
> +  uint16_t sec;
> +  };
> +  uint32_t time;
> +  };
> +
> +  char username[8];
> +  char buildnumber[12];
> +  uint32_t device_id;
> +  uint32_t guc_sw_version;
> +  uint32_t prod_preprod_fw;
> +  uint32_t reserved[12];
> +  uint32_t header_info;
> +} __packed;
> +
>   struct guc_doorbell_info {
>u32 db_status;
>u32 cookie;
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 40241f3..a6703b4 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -215,18 +215,29 @@ static inline bool guc_ucode_response(struct 
drm_i915_private *dev_priv,
>((val & GS_MIA_CORE_STATE) && uk_val == GS_UKERNEL_LAPIC_DONE));
>   }
>
> -/*
> - * Transfer the firmware image to RAM for execution by the microcontroller.
> +/**
> + * DOC: GuC Firmware Layout
>*
> - * GuC Firmware layout:
> - * +---+  
> - * |  CSS header   |  128B
> - * | contains major/minor version  |
> - * +---+  
> - * | uCode |
> - * +---+  
> - * | RSA signature |  256B
> - * +---+  
> + * The GuC firmware layout looks like this:
> + *
> + * +---+
> + * |guc_css_header |
> + * | contains major/minor version  |
> + * +---+
> + * | uCode |
> + * 

Re: [Intel-gfx] [PATCH] drm/i915: Only disable visible planes in intel_crtc_disable_planes

2015-09-24 Thread João Paulo Rechi Vita
On 21 September 2015 at 09:05, Maarten Lankhorst
 wrote:
> This is fix for a regression introduced by 27321ae88c70104df
> "drm/i915: Use the disable callback for disabling planes."
>
> Disabling invisible planes may cause recalculation of
> watermarks, which is a problem because the software state
> is not yet in sync with the hardware state.
> This may result in a black screen during kernel boot and
> plymouth splash until any input action is performed in X.
>
> Explicitly checking for plane visibility fixes the regression.
> This is a patch for v4.2 only, v4.3 needs a different fix because
> it was fixed by d032ffa04cf7c6f
> "drm/i915: Handle disabling planes better, v2."
>
> but later broken again in
> 4cf0ebbd4fafbdf "drm/i915: Rework plane readout."
>
> This will be fixed in v4.3 by:
> "drm/i915: Add .get_hw_state() method for planes"
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91952
> Cc: João Paulo Rechi Vita 
> Cc: sta...@vger.kernel.org # v4.2 only

Tested-by: João Paulo Rechi Vita 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 3/4] drm/i915: Simplify vlv/chv rc6 residency calculation

2015-09-24 Thread ville . syrjala
From: Ville Syrjälä 

We have the czclk freqeuency in dev_priv now, so let's just use it
when converting the rc6 counters to milliseconds. This elimiantes
a bunch of hairy code that essentially tries to extract the czclk
frequency using yet another method.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_sysfs.c | 31 +++
 1 file changed, 3 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 55bd04c..74086eb 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -39,7 +39,7 @@ static u32 calc_residency(struct drm_device *dev, const u32 
reg)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
u64 raw_time; /* 32b value may overflow during fixed point math */
-   u64 units = 128ULL, div = 10ULL, bias = 100ULL;
+   u64 units = 128ULL, div = 10ULL;
u32 ret;
 
if (!intel_enable_rc6(dev))
@@ -49,41 +49,16 @@ static u32 calc_residency(struct drm_device *dev, const u32 
reg)
 
/* On VLV and CHV, residency time is in CZ units rather than 1.28us */
if (IS_VALLEYVIEW(dev)) {
-   u32 clk_reg, czcount_30ns;
-
-   if (IS_CHERRYVIEW(dev))
-   clk_reg = CHV_CLK_CTL1;
-   else
-   clk_reg = VLV_CLK_CTL2;
-
-   czcount_30ns = I915_READ(clk_reg) >> 
CLK_CTL2_CZCOUNT_30NS_SHIFT;
-
-   if (!czcount_30ns) {
-   WARN(!czcount_30ns, "bogus CZ count value");
-   ret = 0;
-   goto out;
-   }
-
-   if (IS_CHERRYVIEW(dev) && czcount_30ns == 1) {
-   /* Special case for 320Mhz */
-   div = 1000ULL;
-   units = 3125ULL;
-   } else {
-   czcount_30ns += 1;
-   div = 100ULL;
-   units = DIV_ROUND_UP_ULL(30ULL * bias, czcount_30ns);
-   }
+   units = 1;
+   div = dev_priv->czclk_freq;
 
if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
units <<= 8;
-
-   div = div * bias;
}
 
raw_time = I915_READ(reg) * units;
ret = DIV_ROUND_UP_ULL(raw_time, div);
 
-out:
intel_runtime_pm_put(dev_priv);
return ret;
 }
-- 
2.4.6

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


[Intel-gfx] [PATCH 2/4] drm/i915: Read czclk from CCK on vlv/chv

2015-09-24 Thread ville . syrjala
From: Ville Syrjälä 

As with the cdclk, read out czclk from CCK as well. This gives us the
real current value and avoids having to decode fuses and whatnot.

Also store it in kHz under dev_priv like we do for cdlck since it's not
just an rps related clock, and having it in kHz is more
standard/convenient for some things.

Imre also pointed out that we currently fail to read czclk on VLV, which
means the PFI credit programming isn't working as expected.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 88 ++--
 drivers/gpu/drm/i915/intel_pm.c  | 25 ++
 4 files changed, 60 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b5d587..77c9312 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1146,7 +1146,6 @@ struct intel_gen6_power_mgmt {
u8 efficient_freq;  /* AKA RPe. Pre-determined balanced frequency */
u8 rp1_freq;/* "less than" RP0 power/freqency */
u8 rp0_freq;/* Non-overclocked max frequency. */
-   u32 cz_freq;
 
u8 up_threshold; /* Current %busy required to uplock */
u8 down_threshold; /* Current %busy required to downclock */
@@ -1810,6 +1809,7 @@ struct drm_i915_private {
unsigned int cdclk_freq, max_cdclk_freq;
unsigned int max_dotclk_freq;
unsigned int hpll_freq;
+   unsigned int czclk_freq;
 
/**
 * wq - Driver workqueue for GEM.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f22fb80..83218032 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -728,6 +728,7 @@ enum skl_disp_power_wells {
 #define  DSI_PLL_N1_DIV_MASK   (3 << 16)
 #define  DSI_PLL_M1_DIV_SHIFT  0
 #define  DSI_PLL_M1_DIV_MASK   (0x1ff << 0)
+#define CCK_CZ_CLOCK_CONTROL   0x62
 #define CCK_DISPLAY_CLOCK_CONTROL  0x6b
 #define  CCK_TRUNK_FORCE_ON(1 << 17)
 #define  CCK_TRUNK_FORCE_OFF   (1 << 16)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8567b46..d668897 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -132,6 +132,42 @@ struct intel_limit {
intel_p2_t  p2;
 };
 
+/* returns HPLL frequency in kHz */
+static int valleyview_get_vco(struct drm_i915_private *dev_priv)
+{
+   int hpll_freq, vco_freq[] = { 800, 1600, 2000, 2400 };
+
+   /* Obtain SKU information */
+   mutex_lock(_priv->sb_lock);
+   hpll_freq = vlv_cck_read(dev_priv, CCK_FUSE_REG) &
+   CCK_FUSE_HPLL_FREQ_MASK;
+   mutex_unlock(_priv->sb_lock);
+
+   return vco_freq[hpll_freq] * 1000;
+}
+
+static int vlv_get_cck_clock_hpll(struct drm_i915_private *dev_priv,
+ const char *name, u32 reg)
+{
+   u32 val;
+   int divider;
+
+   if (dev_priv->hpll_freq == 0)
+   dev_priv->hpll_freq = valleyview_get_vco(dev_priv);
+
+   mutex_lock(_priv->sb_lock);
+   val = vlv_cck_read(dev_priv, reg);
+   mutex_unlock(_priv->sb_lock);
+
+   divider = val & CCK_FREQUENCY_VALUES;
+
+   WARN((val & CCK_FREQUENCY_STATUS) !=
+(divider << CCK_FREQUENCY_STATUS_SHIFT),
+"%s change in progress\n", name);
+
+   return DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, divider + 1);
+}
+
 int
 intel_pch_rawclk(struct drm_device *dev)
 {
@@ -175,6 +211,17 @@ int intel_hrawclk(struct drm_device *dev)
}
 }
 
+static void intel_update_czclk(struct drm_i915_private *dev_priv)
+{
+   if (!IS_VALLEYVIEW(dev_priv))
+   return;
+
+   dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
+ CCK_CZ_CLOCK_CONTROL);
+
+   DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
+}
+
 static inline u32 /* units of 100MHz */
 intel_fdi_link_freq(struct drm_device *dev)
 {
@@ -5749,20 +5796,6 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
DRM_ERROR("DBuf power enable timeout\n");
 }
 
-/* returns HPLL frequency in kHz */
-static int valleyview_get_vco(struct drm_i915_private *dev_priv)
-{
-   int hpll_freq, vco_freq[] = { 800, 1600, 2000, 2400 };
-
-   /* Obtain SKU information */
-   mutex_lock(_priv->sb_lock);
-   hpll_freq = vlv_cck_read(dev_priv, CCK_FUSE_REG) &
-   CCK_FUSE_HPLL_FREQ_MASK;
-   mutex_unlock(_priv->sb_lock);
-
-   return vco_freq[hpll_freq] * 1000;
-}
-
 /* Adjust CDclk dividers to allow high res or save power if possible */
 static void valleyview_set_cdclk(struct 

[Intel-gfx] [PATCH 4/4] drm/i915: Use czclk_freq in vlv c0 residency calculations

2015-09-24 Thread ville . syrjala
From: Ville Syrjälä 

Replace the use of mem_freq/4 with czclk_freq in the vlv c0 residency
calculations.

Also deal with VLV_COUNT_RANGE_HIGH which affects all RCx residency
counters. We have just enough bits to do this without intermediate
divisions.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 07c87e0..d78ef64 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -998,12 +998,16 @@ static bool vlv_c0_above(struct drm_i915_private 
*dev_priv,
 int threshold)
 {
u64 time, c0;
+   unsigned int mul = 100;
 
if (old->cz_clock == 0)
return false;
 
+   if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
+   mul <<= 8;
+
time = now->cz_clock - old->cz_clock;
-   time *= threshold * dev_priv->mem_freq;
+   time *= threshold * dev_priv->czclk_freq;
 
/* Workload can be split between render + media, e.g. SwapBuffers
 * being blitted in X after being rendered in mesa. To account for
@@ -1011,7 +1015,7 @@ static bool vlv_c0_above(struct drm_i915_private 
*dev_priv,
 */
c0 = now->render_c0 - old->render_c0;
c0 += now->media_c0 - old->media_c0;
-   c0 *= 100 * VLV_CZ_CLOCK_TO_MILLI_SEC * 4 / 1000;
+   c0 *= mul * VLV_CZ_CLOCK_TO_MILLI_SEC;
 
return c0 >= time;
 }
-- 
2.4.6

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


Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

2015-09-24 Thread Yu Dai



On 09/24/2015 12:04 PM, Dave Gordon wrote:

On 24/09/15 19:34, Yu Dai wrote:
>
>
> On 09/24/2015 07:23 AM, Dave Gordon wrote:
>> On 22/09/15 21:48, yu@intel.com wrote:
>> > From: Alex Dai 
>> >
>> > By using information from GuC css header, we can eliminate some
>> > hard code w.r.t size of some components of firmware.
>> >
>> > v2: Add indent into DOC to make fixed-width format rather than
>> > change the tmpl.
>> >
>> > v1: 1) guc_css_header is defined as __packed now
>> >  2) Add and correct GuC related topics in kernel/Doc
>> >
>> > Signed-off-by: Alex Dai 
>> > ---
>> >   Documentation/DocBook/drm.tmpl  |   9 ++-
>> >   drivers/gpu/drm/i915/intel_guc.h|   2 +-
>> >   drivers/gpu/drm/i915/intel_guc_fwif.h   |  36 +++
>> >   drivers/gpu/drm/i915/intel_guc_loader.c | 107
>> ++--
>> >   4 files changed, 117 insertions(+), 37 deletions(-)
>> >
>> > diff --git a/Documentation/DocBook/drm.tmpl
>> b/Documentation/DocBook/drm.tmpl
>> > index 66bc646..116332f 100644
>> > --- a/Documentation/DocBook/drm.tmpl
>> > +++ b/Documentation/DocBook/drm.tmpl
>> > @@ -4155,14 +4155,19 @@ int num_ioctls;
>> > GuC-based Command Submission
>> > 
../linux-image-4.3.0-rc2-dsg-11022-g9765caf-dsg-intel-nightly_4.3.0-rc2-dsg-11022-g9765caf-dsg-intel-nightly-7_amd64.deb
>> >   GuC
>> > -!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
>> > +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC
>> >   !Idrivers/gpu/drm/i915/intel_guc_loader.c
>> > 
>> > 
>> >   GuC Client
>> > -!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command
>> submissison
>> > +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC Client
>> >   !Idrivers/gpu/drm/i915/i915_guc_submission.c
>> > 
>> > +  
>> > +GuC Firmware Layout
>> > +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC Firmware Layout
>> > +!Idrivers/gpu/drm/i915/intel_guc_loader.c
>> > +  
>> >   
>> >
>> >   
>> > diff --git a/drivers/gpu/drm/i915/intel_guc.h
>> b/drivers/gpu/drm/i915/intel_guc.h
>> > index 4ec2d27..e1389fc 100644
>> > --- a/drivers/gpu/drm/i915/intel_guc.h
>> > +++ b/drivers/gpu/drm/i915/intel_guc.h
>> > @@ -71,6 +71,7 @@ struct intel_guc_fw {
>> >   struct drm_i915_gem_object *guc_fw_obj;
>> >   enum intel_guc_fw_statusguc_fw_fetch_status;
>> >   enum intel_guc_fw_statusguc_fw_load_status;
>> > +struct guc_css_headerguc_fw_header;
>> >
>> >   uint16_tguc_fw_major_wanted;
>> >   uint16_tguc_fw_minor_wanted;
>> > @@ -80,7 +81,6 @@ struct intel_guc_fw {
>> >
>> >   struct intel_guc {
>> >   struct intel_guc_fw guc_fw;
>> > -
>> >   uint32_t log_flags;
>> >   struct drm_i915_gem_object *log_obj;
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
>> b/drivers/gpu/drm/i915/intel_guc_fwif.h
>> > index e1f47ba..006dc0d 100644
>> > --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
>> > +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
>> > @@ -122,6 +122,42 @@
>> >
>> >   #define GUC_CTL_MAX_DWORDS(GUC_CTL_RSRVD + 1)
>> >
>> > +struct guc_css_header {
>> > +uint32_t module_type;
>> > +uint32_t header_len; /* header length plus size of all other
>> keys */
>> > +uint32_t header_version;
>> > +uint32_t module_id;
>> > +uint32_t module_vendor;
>> > +union {
>> > +struct {
>> > +uint8_t day;
>> > +uint8_t month;
>> > +uint16_t year;
>> > +};
>> > +uint32_t date;
>> > +};
>> > +uint32_t size; /* uCode size plus header_len */
>> > +uint32_t key_size;
>> > +uint32_t modulus_size;
>> > +uint32_t exponent_size;
>> > +union {
>> > +struct {
>> > +uint8_t hour;
>> > +uint8_t min;
>> > +uint16_t sec;
>> > +};
>> > +uint32_t time;
>> > +};
>> > +
>> > +char username[8];
>> > +char buildnumber[12];
>> > +uint32_t device_id;
>> > +uint32_t guc_sw_version;
>> > +uint32_t prod_preprod_fw;
>> > +uint32_t reserved[12];
>> > +uint32_t header_info;
>> > +} __packed;
>> > +
>> >   struct guc_doorbell_info {
>> >   u32 db_status;
>> >   u32 cookie;
>> > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
>> b/drivers/gpu/drm/i915/intel_guc_loader.c
>> > index 40241f3..a6703b4 100644
>> > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
>> > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
>> > @@ -215,18 +215,29 @@ static inline bool guc_ucode_response(struct
>> drm_i915_private *dev_priv,
>> >   ((val & GS_MIA_CORE_STATE) && uk_val ==
>> GS_UKERNEL_LAPIC_DONE));
>> >   }
>> >
>> > -/*
>> > - * Transfer the firmware image to RAM for execution by the
>> microcontroller.
>> > +/**
>> > + * DOC: GuC Firmware Layout
>> >*
>> > - * GuC Firmware layout:
>> > - * +---+  
>> > - * |  CSS 

[Intel-gfx] [PATCH 13/15] drm/i915: Calculate watermark configuration during atomic check (v2)

2015-09-24 Thread Matt Roper
v2: Don't forget to actually check the cstate->active value when
tallying up the number of active CRTC's.  (Ander)

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  | 10 ++
 drivers/gpu/drm/i915/intel_display.c | 52 +++--
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 64 +++-
 4 files changed, 72 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 156bcfe..8b7c8f9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1702,6 +1702,13 @@ struct i915_execbuffer_params {
struct drm_i915_gem_request *request;
 };
 
+/* used in computing the new watermarks state */
+struct intel_wm_config {
+   unsigned int num_pipes_active;
+   bool sprites_enabled;
+   bool sprites_scaled;
+};
+
 struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *objects;
@@ -1921,6 +1928,9 @@ struct drm_i915_private {
 */
uint16_t skl_latency[8];
 
+   /* Committed wm config */
+   struct intel_wm_config config;
+
/*
 * The skl_wm_values structure is a bit too big for stack
 * allocation, so we keep the staging struct where we store
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 573198c..e2a0777 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13016,6 +13016,45 @@ static int intel_modeset_checks(struct 
drm_atomic_state *state)
return 0;
 }
 
+/*
+ * Handle calculation of various watermark data at the end of the atomic check
+ * phase.  The code here should be run after the per-crtc and per-plane 'check'
+ * handlers to ensure that all derived state has been updated.
+ */
+static void calc_watermark_data(struct drm_atomic_state *state)
+{
+   struct drm_device *dev = state->dev;
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *cstate;
+   struct drm_plane *plane;
+   struct drm_plane_state *pstate;
+
+   /*
+* Calculate watermark configuration details now that derived
+* plane/crtc state is all properly updated.
+*/
+   drm_for_each_crtc(crtc, dev) {
+   cstate = drm_atomic_get_existing_crtc_state(state, crtc) ?:
+   crtc->state;
+
+   if (cstate->active)
+   intel_state->wm_config.num_pipes_active++;
+   }
+   drm_for_each_legacy_plane(plane, dev) {
+   pstate = drm_atomic_get_existing_plane_state(state, plane) ?:
+   plane->state;
+
+   if (!to_intel_plane_state(pstate)->visible)
+   continue;
+
+   intel_state->wm_config.sprites_enabled = true;
+   if (pstate->crtc_w != pstate->src_w >> 16 ||
+   pstate->crtc_h != pstate->src_h >> 16)
+   intel_state->wm_config.sprites_scaled = true;
+   }
+}
+
 /**
  * intel_atomic_check - validate state object
  * @dev: drm device
@@ -13024,6 +13063,7 @@ static int intel_modeset_checks(struct drm_atomic_state 
*state)
 static int intel_atomic_check(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
int ret, i;
@@ -13087,10 +13127,15 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
return ret;
} else
-   to_intel_atomic_state(state)->cdclk =
-   to_i915(state->dev)->cdclk_freq;
+   intel_state->cdclk = to_i915(state->dev)->cdclk_freq;
 
-   return drm_atomic_helper_check_planes(state->dev, state);
+   ret = drm_atomic_helper_check_planes(state->dev, state);
+   if (ret)
+   return ret;
+
+   calc_watermark_data(state);
+
+   return 0;
 }
 
 /**
@@ -13130,6 +13175,7 @@ static int intel_atomic_commit(struct drm_device *dev,
return ret;
 
drm_atomic_helper_swap_state(dev, state);
+   dev_priv->wm.config = to_intel_atomic_state(state)->wm_config;
 
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 598c4b1..07d5500 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -240,6 +240,7 @@ struct intel_atomic_state {
unsigned int cdclk;
bool 

[Intel-gfx] [PATCH 11/15] drm/i915: Calculate ILK-style watermarks during atomic check (v3)

2015-09-24 Thread Matt Roper
Calculate pipe watermarks during atomic calculation phase, based on the
contents of the atomic transaction's state structure.  We still program
the watermarks at the same time we did before, but the computation now
happens much earlier.

While this patch isn't too exciting by itself, it paves the way for
future patches.  The eventual goal (which will be realized in future
patches in this series) is to calculate multiple sets up watermark
values up front, and then program them at different times (pre- vs
post-vblank) on the platforms that need a two-step watermark update.

While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since
this function only applies to ILK-style watermarks and we have a
completely different function for SKL-style watermarks.

Note that the original code had a memcmp() in ilk_update_wm() to avoid
calling ilk_program_watermarks() if the watermarks hadn't changed.  This
memcmp vanishes here, which means we may do some unnecessary result
generation and merging in cases where watermarks didn't change, but the
lower-level function ilk_write_wm_values already makes sure that we
don't actually try to program the watermark registers again.

v2: Squash a few commits from the original series together; no longer
leave pre-calculated wm's in a separate temporary structure since
it's easier to follow the logic if we just cut over to using the
pre-calculated values directly.

v3:
 - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint
   and use intel_atomic_get_crtc_state() to avoid need for extra
   casting.  (Ander)
 - Drop unused intel_check_crtc() function prototype.  (Ander)

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/intel_display.c |  6 +++
 drivers/gpu/drm/i915/intel_pm.c  | 88 ++--
 3 files changed, 51 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2baa308..156bcfe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -627,6 +627,8 @@ struct drm_i915_display_funcs {
  int target, int refclk,
  struct dpll *match_clock,
  struct dpll *best_clock);
+   int (*compute_pipe_wm)(struct intel_crtc *crtc,
+  struct drm_atomic_state *state);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a8d781a..edfd3d8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11805,6 +11805,12 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
}
 
ret = 0;
+   if (dev_priv->display.compute_pipe_wm) {
+   ret = dev_priv->display.compute_pipe_wm(intel_crtc, state);
+   if (ret)
+   return ret;
+   }
+
if (INTEL_INFO(dev)->gen >= 9) {
if (mode_changed)
ret = skl_update_scaler_crtc(pipe_config);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 852a115..133a54e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2051,9 +2051,11 @@ static void ilk_compute_wm_level(const struct 
drm_i915_private *dev_priv,
 const struct intel_crtc *intel_crtc,
 int level,
 struct intel_crtc_state *cstate,
+struct intel_plane_state *pristate,
+struct intel_plane_state *sprstate,
+struct intel_plane_state *curstate,
 struct intel_wm_level *result)
 {
-   struct intel_plane *intel_plane;
uint16_t pri_latency = dev_priv->wm.pri_latency[level];
uint16_t spr_latency = dev_priv->wm.spr_latency[level];
uint16_t cur_latency = dev_priv->wm.cur_latency[level];
@@ -2065,29 +2067,11 @@ static void ilk_compute_wm_level(const struct 
drm_i915_private *dev_priv,
cur_latency *= 5;
}
 
-   for_each_intel_plane_on_crtc(dev_priv->dev, intel_crtc, intel_plane) {
-   struct intel_plane_state *pstate =
-   to_intel_plane_state(intel_plane->base.state);
-
-   switch (intel_plane->base.type) {
-   case DRM_PLANE_TYPE_PRIMARY:
-   result->pri_val = ilk_compute_pri_wm(cstate, pstate,
-pri_latency,
-level);
- 

[Intel-gfx] [PATCH 10/15] drm/i915: Calculate pipe watermarks into CRTC state (v3)

2015-09-24 Thread Matt Roper
A future patch will calculate these during the atomic 'check' phase
rather than at WM programming time, so let's store the watermark
values we're planning to use in the CRTC state; the values actually
active on the hardware remains in intel_crtc.

While we're at it, do some minor restructuring to keep ILK and SKL
values in a union.

v2: Don't move cxsr_allowed to state (Maarten)

v3: Only calculate watermarks in state.  Still keep active watermarks in
intel_crtc itself.  (Ville)

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_drv.h | 48 +---
 drivers/gpu/drm/i915/intel_pm.c  | 44 ++--
 2 files changed, 57 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1b98210..598c4b1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -324,6 +324,21 @@ struct intel_crtc_scaler_state {
 /* drm_mode->private_flags */
 #define I915_MODE_FLAG_INHERITED 1
 
+struct intel_pipe_wm {
+   struct intel_wm_level wm[5];
+   uint32_t linetime;
+   bool fbc_wm_enabled;
+   bool pipe_enabled;
+   bool sprites_enabled;
+   bool sprites_scaled;
+};
+
+struct skl_pipe_wm {
+   struct skl_wm_level wm[8];
+   struct skl_wm_level trans_wm;
+   uint32_t linetime;
+};
+
 struct intel_crtc_state {
struct drm_crtc_state base;
 
@@ -461,6 +476,17 @@ struct intel_crtc_state {
 
/* IVB sprite scaling w/a (WaCxSRDisabledForSpriteScaling:ivb) */
bool disable_lp_wm;
+
+   struct {
+   /*
+* optimal watermarks, programmed post-vblank when this state
+* is committed
+*/
+   union {
+   struct intel_pipe_wm ilk;
+   struct skl_pipe_wm skl;
+   } optimal;
+   } wm;
 };
 
 struct vlv_wm_state {
@@ -472,15 +498,6 @@ struct vlv_wm_state {
bool cxsr;
 };
 
-struct intel_pipe_wm {
-   struct intel_wm_level wm[5];
-   uint32_t linetime;
-   bool fbc_wm_enabled;
-   bool pipe_enabled;
-   bool sprites_enabled;
-   bool sprites_scaled;
-};
-
 struct intel_mmio_flip {
struct work_struct work;
struct drm_i915_private *i915;
@@ -488,12 +505,6 @@ struct intel_mmio_flip {
struct intel_crtc *crtc;
 };
 
-struct skl_pipe_wm {
-   struct skl_wm_level wm[8];
-   struct skl_wm_level trans_wm;
-   uint32_t linetime;
-};
-
 /*
  * Tracking of operations that need to be performed at the beginning/end of an
  * atomic commit, outside the atomic section where interrupts are disabled.
@@ -561,9 +572,10 @@ struct intel_crtc {
/* per-pipe watermark state */
struct {
/* watermarks currently being used  */
-   struct intel_pipe_wm active;
-   /* SKL wm values currently in use */
-   struct skl_pipe_wm skl_active;
+   union {
+   struct intel_pipe_wm ilk;
+   struct skl_pipe_wm skl;
+   } active;
/* allow CxSR on this pipe */
bool cxsr_allowed;
} wm;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 17f7353..852a115 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2353,7 +2353,7 @@ static void ilk_compute_wm_config(struct drm_device *dev,
 
/* Compute the currently _active_ config */
for_each_intel_crtc(dev, intel_crtc) {
-   const struct intel_pipe_wm *wm = _crtc->wm.active;
+   const struct intel_pipe_wm *wm = _crtc->wm.active.ilk;
 
if (!wm->pipe_enabled)
continue;
@@ -2450,7 +2450,9 @@ static void ilk_merge_wm_level(struct drm_device *dev,
ret_wm->enable = true;
 
for_each_intel_crtc(dev, intel_crtc) {
-   const struct intel_pipe_wm *active = _crtc->wm.active;
+   const struct intel_crtc_state *cstate =
+   to_intel_crtc_state(intel_crtc->base.state);
+   const struct intel_pipe_wm *active = >wm.optimal.ilk;
const struct intel_wm_level *wm = >wm[level];
 
if (!active->pipe_enabled)
@@ -2598,14 +2600,15 @@ static void ilk_compute_wm_results(struct drm_device 
*dev,
 
/* LP0 register values */
for_each_intel_crtc(dev, intel_crtc) {
+   const struct intel_crtc_state *cstate =
+   to_intel_crtc_state(intel_crtc->base.state);
enum pipe pipe = intel_crtc->pipe;
-   const struct intel_wm_level *r =
-   _crtc->wm.active.wm[0];
+   const struct intel_wm_level *r = >wm.optimal.ilk.wm[0];
 
if 

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Update Promotion timer for RC6 TO Mode

2015-09-24 Thread O'Rourke, Tom
This change looks good and is necessary, but the
commit message should have more detail.

I would add:
"When using RC6 timeout mode, the timeout value
should be written to GEN6_RC6_THRESHOLD."

With that,
Reviewed-by: Tom O'Rourke 

On Wed, Sep 23, 2015 at 03:06:42PM +0530, Sagar Arun Kamble wrote:
> Signed-off-by: Sagar Arun Kamble 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a878147..ebde43d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4842,7 +4842,6 @@ static void gen9_enable_rc6(struct drm_device *dev)
>   for_each_ring(ring, dev_priv, unused)
>   I915_WRITE(RING_MAX_IDLE(ring->mmio_base), 10);
>   I915_WRITE(GEN6_RC_SLEEP, 0);
> - I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
>  
>   /* 2c: Program Coarse Power Gating Policies. */
>   I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 25);
> @@ -4854,15 +4853,19 @@ static void gen9_enable_rc6(struct drm_device *dev)
>   DRM_INFO("RC6 %s\n", (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
>   "on" : "off");
>  
> + /* WaRsUseTimeoutMode */
>   if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) ||
> - (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0))
> + (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0)) {
> + I915_WRITE(GEN6_RC6_THRESHOLD, 625); /* 800us */
>  I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
>  GEN7_RC_CTL_TO_MODE |
>  rc6_mask);
> -else
> + } else {
> + I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
>  I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
>  GEN6_RC_CTL_EI_MODE(1) |
>  rc6_mask);
> + }
>  
>   /*
>* 3b: Enable Coarse Power Gating only when RC6 is enabled.
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 0/4] drm/i915: Read czclk from cck on vlv/chv

2015-09-24 Thread ville . syrjala
From: Ville Syrjälä 

This series replaces the czclk readout using a fuse on chv with reading
it directly from the horse's mouth ie. cck. It also adds czclk readout
for vlv, which means it also fixes the PFI credit programming on that
platform.

As a bonus we can simplify the gpu residency calculations quite a bit.

The whole series us available here:
git://github.com/vsyrjala/linux.git czclk_cck

Vandana Kannan (1):
  drm/i915: Renaming CCK related reg definitions

Ville Syrjälä (3):
  drm/i915: Read czclk from CCK on vlv/chv
  drm/i915: Simplify vlv/chv rc6 residency calculation
  drm/i915: Use czclk_freq in vlv c0 residency calculations

 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_irq.c  |  8 +++-
 drivers/gpu/drm/i915/i915_reg.h  | 11 +++--
 drivers/gpu/drm/i915/i915_sysfs.c| 31 ++---
 drivers/gpu/drm/i915/intel_display.c | 88 ++--
 drivers/gpu/drm/i915/intel_pm.c  | 25 ++
 6 files changed, 74 insertions(+), 91 deletions(-)

-- 
2.4.6

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add max DOT clock frequency to debugfs

2015-09-24 Thread Ville Syrjälä
On Thu, Sep 24, 2015 at 02:28:41PM +0300, Mika Kahola wrote:
> Information on maximum supported pixel clock frequency to
> i915_frequency_info.
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6882455..b418d9b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1311,6 +1311,7 @@ static int i915_frequency_info(struct seq_file *m, void 
> *unused)
>  
>   seq_printf(m, "Current CD clock freq: %dkHz\n", dev_priv->cdclk_freq);
>   seq_printf(m, "Max CD clock freq: %dkHz\n", dev_priv->max_cdclk_freq);
> + seq_printf(m, "Max pixel clock freq: %dkHz\n", 
> dev_priv->max_dotclk_freq);

I would put a space between the number and units.

The rest of the stuff in there is about the gt stuff, so not sure if
this is the best place for it. But if no one else objects, I won't either.

Could probably squash all three patches into just one, since they're all
doing the same thing anyway.

With that these are:
Reviewed-by: Ville Syrjälä 

>  
>  out:
>   intel_runtime_pm_put(dev_priv);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 15/15] drm/i915: Add two-stage ILK-style watermark programming (v5)

2015-09-24 Thread Matt Roper
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time.  These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means they can be programmed immediately when we commit the
atomic state (without waiting for a vblank).  Once the vblank does
happen, we can then re-program watermarks to the more optimal final
value.

v2: Significant rebasing/rewriting.

v3:
 - Move 'need_postvbl_update' flag to CRTC state (Daniel)
 - Don't forget to check intermediate watermark values for validity
   (Maarten)
 - Don't due async watermark optimization; just do it at the end of the
   atomic transaction, after waiting for vblanks.  We do want it to be
   async eventually, but adding that now will cause more trouble for
   Maarten's in-progress work.  (Maarten)
 - Don't allocate space in crtc_state for intermediate watermarks on
   platforms that don't need it (gen9+).
 - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
   now that ilk_update_wm is gone.

v4:
 - Add a wm_mutex to cover updates to intel_crtc->active and the
   need_postvbl_update flag.  Since we don't have async yet it isn't
   terribly important yet, but might as well add it now.
 - Change interface to program watermarks.  Platforms will now expose
   .initial_watermarks() and .optimize_watermarks() functions to do
   watermark programming.  These should lock wm_mutex, copy the
   appropriate state values into intel_crtc->active, and then call
   the internal program watermarks function.

v5:
 - Skip intermediate watermark calculation/check during initial hardware
   readout since we don't trust the existing HW values (and don't have
   valid values of our own yet).
 - Don't try to call .optimize_watermarks() on platforms that don't have
   atomic watermarks yet.  (Maarten)

Signed-off-by: Matt Roper 
Reviewed-by(v4): Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_atomic.c  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  91 +++-
 drivers/gpu/drm/i915/intel_drv.h |  31 ++-
 drivers/gpu/drm/i915/intel_pm.c  | 160 ---
 5 files changed, 233 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9bac1e..e9d9a47 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -629,7 +629,11 @@ struct drm_i915_display_funcs {
  struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
   struct drm_atomic_state *state);
-   void (*program_watermarks)(struct intel_crtc_state *cstate);
+   int (*compute_intermediate_wm)(struct drm_device *dev,
+  struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *newstate);
+   void (*initial_watermarks)(struct intel_crtc_state *cstate);
+   void (*optimize_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 05b1203..28630f8 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -95,6 +95,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
 
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
+   crtc_state->wm.need_postvbl_update = false;
 
return _state->base;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0c3783c..fb32800 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11650,6 +11650,12 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
intel_crtc->atomic.update_wm_pre = true;
}
 
+   /* Pre-gen9 platforms need two-step watermark updates */
+   if ((intel_crtc->atomic.update_wm_pre || 
intel_crtc->atomic.update_wm_post) &&
+   INTEL_INFO(dev)->gen < 9 &&
+   dev_priv->display.optimize_watermarks)
+   to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
+
if (visible || was_visible)
intel_crtc->atomic.fb_bits |=
to_intel_plane(plane)->frontbuffer_bit;
@@ -11807,8 +11813,29 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(intel_crtc, state);
-   if (ret)
+   if (ret) 

[Intel-gfx] [PATCH 05/15] drm/i915/skl: Simplify wm structures slightly (v2)

2015-09-24 Thread Matt Roper
A bunch of SKL watermark-related structures have the cursor plane as a
separate entry from the rest of the planes.  Since a previous patch
updated I915_MAX_PLANES such that those plane arrays now have a slot for
the cursor, update the code to use the new slot in the existing plane
arrays and kill off the cursor-specific structures.

There shouldn't be any functional change here; this is just shuffling
around how the data is stored in some of the data structures.  The whole
patch is generated with Coccinelle via the following semantic patch:

@@ struct skl_pipe_wm_parameters WMP; @@
- WMP.cursor
+ WMP.plane[PLANE_CURSOR]

@@ struct skl_pipe_wm_parameters *WMP; @@
- WMP->cursor
+ WMP->plane[PLANE_CURSOR]

@@ @@
struct skl_pipe_wm_parameters {
...
- struct intel_plane_wm_parameters cursor;
...
};

@@
struct skl_ddb_allocation DDB;
expression E;
@@
- DDB.cursor[E]
+ DDB.plane[E][PLANE_CURSOR]

@@
struct skl_ddb_allocation *DDB;
expression E;
@@
- DDB->cursor[E]
+ DDB->plane[E][PLANE_CURSOR]

@@ @@
struct skl_ddb_allocation {
...
- struct skl_ddb_entry cursor[I915_MAX_PIPES];
...
};

@@
struct skl_wm_values WMV;
expression E1, E2;
@@
(
- WMV.cursor[E1][E2]
+ WMV.plane[E1][PLANE_CURSOR][E2]
|
- WMV.cursor_trans[E1]
+ WMV.plane_trans[E1][PLANE_CURSOR]
)

@@
struct skl_wm_values *WMV;
expression E1, E2;
@@
(
- WMV->cursor[E1][E2]
+ WMV->plane[E1][PLANE_CURSOR][E2]
|
- WMV->cursor_trans[E1]
+ WMV->plane_trans[E1][PLANE_CURSOR]
)

@@ @@
struct skl_wm_values {
...
- uint32_t cursor[I915_MAX_PIPES][8];
...
- uint32_t cursor_trans[I915_MAX_PIPES];
...
};

@@ struct skl_wm_level WML; @@
(
- WML.cursor_en
+ WML.plane_en[PLANE_CURSOR]
|
- WML.cursor_res_b
+ WML.plane_res_b[PLANE_CURSOR]
|
- WML.cursor_res_l
+ WML.plane_res_l[PLANE_CURSOR]
)

@@ struct skl_wm_level *WML; @@
(
- WML->cursor_en
+ WML->plane_en[PLANE_CURSOR]
|
- WML->cursor_res_b
+ WML->plane_res_b[PLANE_CURSOR]
|
- WML->cursor_res_l
+ WML->plane_res_l[PLANE_CURSOR]
)

@@ @@
struct skl_wm_level {
...
- bool cursor_en;
...
- uint16_t cursor_res_b;
- uint8_t cursor_res_l;
...
};

v2: Use a PLANE_CURSOR enum entry rather than making the code reference
I915_MAX_PLANES or I915_MAX_PLANES+1, which was confusing.  (Ander)

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  8 +---
 drivers/gpu/drm/i915/intel_display.c |  4 +-
 drivers/gpu/drm/i915/intel_pm.c  | 93 +++-
 4 files changed, 52 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5615d3d..03c196e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3144,7 +3144,7 @@ static int i915_ddb_info(struct seq_file *m, void *unused)
   skl_ddb_entry_size(entry));
}
 
-   entry = >cursor[pipe];
+   entry = >plane[pipe][PLANE_CURSOR];
seq_printf(m, "  %-13s%8u%8u%8u\n", "Cursor", entry->start,
   entry->end, skl_ddb_entry_size(entry));
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eac9414..bd542cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1588,8 +1588,7 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 struct skl_ddb_allocation {
struct skl_ddb_entry pipe[I915_MAX_PIPES];
struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
-   struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
y-plane */
-   struct skl_ddb_entry cursor[I915_MAX_PIPES];
+   struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_wm_values {
@@ -1597,18 +1596,13 @@ struct skl_wm_values {
struct skl_ddb_allocation ddb;
uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
-   uint32_t cursor[I915_MAX_PIPES][8];
uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
-   uint32_t cursor_trans[I915_MAX_PIPES];
 };
 
 struct 

[Intel-gfx] [PATCH 14/15] drm/i915: Sanitize watermarks after hardware state readout

2015-09-24 Thread Matt Roper
Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them.  We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we think WM's should be programmed and then shove those
values into the hardware.

We can do this pretty easily by creating a dummy top-level state,
running it through the check process to calculate all the values, and
then just programming the watermarks for each CRTC.

Cc: Maarten Lankhorst 
Signed-off-by: Matt Roper 
---
Maarten, does this solve the problem you were seeing on Ironlake?  You
indicated that your firmware had sprite watermarks programmed even though
sprites themselves were off and I don't have any kind of system that can
reproduce that setup.  I'm hoping this will patch will do the trick.

 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 51 
 drivers/gpu/drm/i915/intel_pm.c  | 14 +-
 3 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8b7c8f9..a9bac1e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -629,6 +629,7 @@ struct drm_i915_display_funcs {
  struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
   struct drm_atomic_state *state);
+   void (*program_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2a0777..0c3783c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15310,6 +15310,54 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
}
 }
 
+/*
+ * Calculate what we think the watermarks should be for the state we've read
+ * out of the hardware and then immediately program those watermarks so that
+ * we ensure the hardware settings match our internal state.
+ */
+static void sanitize_watermarks(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_atomic_state *state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *cstate;
+   int ret;
+   int i;
+
+   /* Only supported on platforms that use atomic watermark design */
+   if (!dev_priv->display.program_watermarks)
+   return;
+
+   /*
+* Calculate what we think WM's should be by creating a dummy state and
+* running it through the atomic check code.
+*/
+   state = drm_atomic_helper_duplicate_state(dev,
+ dev->mode_config.acquire_ctx);
+   if (WARN_ON(IS_ERR(state)))
+   return;
+
+   ret = intel_atomic_check(dev, state);
+   if (ret) {
+   /*
+* Just give up and leave watermarks untouched if we get an
+* error back from 'check'
+*/
+   DRM_DEBUG_KMS("Could not determine valid watermarks for 
inherited state\n");
+   return;
+   }
+
+   /* Write calculated watermark values back */
+   to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
+
+   dev_priv->display.program_watermarks(cs);
+   }
+
+   drm_atomic_state_free(state);
+}
+
 /* Scan out the current hw modeset state,
  * and sanitizes it to the current state
  */
@@ -15365,6 +15413,9 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
modeset_put_power_domains(dev_priv, put_domains);
}
intel_display_set_init_power(dev_priv, false);
+
+   /* Make sure hardware watermarks really match the state we read out */
+   sanitize_watermarks(dev);
 }
 
 void intel_display_resume(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f3652bb..988893e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3664,15 +3664,19 @@ static void skl_update_wm(struct drm_crtc *crtc)
dev_priv->wm.skl_hw = *results;
 }
 
-static void ilk_program_watermarks(struct drm_i915_private *dev_priv)
+static void ilk_program_watermarks(struct intel_crtc_state *cstate)
 {
-   struct drm_device *dev = dev_priv->dev;
+   struct drm_crtc *crtc = cstate->base.crtc;
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private 

[Intel-gfx] [PATCH 07/15] drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check

2015-09-24 Thread Matt Roper
Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.

Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just ensure that ilk_update_wm() is called whenever a
sprite plane is updated in a way that would affect watermarks.

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic.c  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 39 +---
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_pm.c  | 35 +++-
 4 files changed, 48 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index f1975f2..05b1203 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -94,6 +94,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
__drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
 
crtc_state->update_pipe = false;
+   crtc_state->disable_lp_wm = false;
 
return _state->base;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a3e62bc..7631cb4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11551,18 +11551,32 @@ retry:
 static bool intel_wm_need_update(struct drm_plane *plane,
 struct drm_plane_state *state)
 {
-   /* Update watermarks on tiling changes. */
+   struct intel_plane_state *new = to_intel_plane_state(state);
+   struct intel_plane_state *cur = to_intel_plane_state(plane->state);
+
+   /* Update watermarks on tiling or size changes. */
if (!plane->state->fb || !state->fb ||
plane->state->fb->modifier[0] != state->fb->modifier[0] ||
-   plane->state->rotation != state->rotation)
-   return true;
-
-   if (plane->state->crtc_w != state->crtc_w)
+   plane->state->rotation != state->rotation ||
+   drm_rect_width(>src) != drm_rect_width(>src) ||
+   drm_rect_height(>src) != drm_rect_height(>src) ||
+   drm_rect_width(>dst) != drm_rect_width(>dst) ||
+   drm_rect_height(>dst) != drm_rect_height(>dst))
return true;
 
return false;
 }
 
+static bool needs_scaling(struct intel_plane_state *state)
+{
+   int src_w = drm_rect_width(>src) >> 16;
+   int src_h = drm_rect_height(>src) >> 16;
+   int dst_w = drm_rect_width(>dst);
+   int dst_h = drm_rect_height(>dst);
+
+   return (src_w != dst_w || src_h != dst_h);
+}
+
 int intel_plane_atomic_calc_changes(struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
 {
@@ -11578,7 +11592,6 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
bool mode_changed = needs_modeset(crtc_state);
bool was_crtc_enabled = crtc->state->active;
bool is_crtc_enabled = crtc_state->active;
-
bool turn_off, turn_on, visible, was_visible;
struct drm_framebuffer *fb = plane_state->fb;
 
@@ -11696,11 +11709,23 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
case DRM_PLANE_TYPE_CURSOR:
break;
case DRM_PLANE_TYPE_OVERLAY:
-   if (turn_off && !mode_changed) {
+   /*
+* WaCxSRDisabledForSpriteScaling:ivb
+*
+* cstate->update_wm was already set above, so this flag will
+* take effect when we commit and program watermarks.
+*/
+   if (IS_IVYBRIDGE(dev) &&
+   needs_scaling(to_intel_plane_state(plane_state)) &&
+   !needs_scaling(old_plane_state)) {
+   to_intel_crtc_state(crtc_state)->disable_lp_wm = true;
+   } else if (turn_off && !mode_changed) {
intel_crtc->atomic.wait_vblank = true;
intel_crtc->atomic.update_sprite_watermarks |=
1 << i;
}
+
+   break;
}
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c96289d..a2a0301 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -458,6 +458,9 @@ struct intel_crtc_state {
 
/* w/a for waiting 2 vblanks during crtc enable */
enum pipe hsw_workaround_pipe;
+
+   /* IVB sprite scaling w/a (WaCxSRDisabledForSpriteScaling:ivb) */
+   bool disable_lp_wm;
 };
 
 struct vlv_wm_state {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7bfcc98..4681f02 100644
--- 

[Intel-gfx] [PATCH 12/15] drm/i915: Don't set plane visible during HW readout if CRTC is off

2015-09-24 Thread Matt Roper
We already ensure that pstate->visible = false when crtc->active = false
during runtime programming; make sure we follow the same logic when
reading out initial hardware state.

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 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 edfd3d8..573198c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15146,7 +15146,7 @@ static void readout_plane_state(struct intel_crtc *crtc)
struct intel_plane_state *plane_state =
to_intel_plane_state(crtc->base.primary->state);
 
-   plane_state->visible =
+   plane_state->visible = crtc->active &&
primary_get_hw_state(to_intel_plane(crtc->base.primary));
 }
 
-- 
2.1.4

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


[Intel-gfx] [PATCH 08/15] drm/i915: Drop intel_update_sprite_watermarks

2015-09-24 Thread Matt Roper
The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update.  However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call.  Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 ---
 drivers/gpu/drm/i915/intel_display.c |  5 
 drivers/gpu/drm/i915/intel_drv.h |  6 
 drivers/gpu/drm/i915/intel_pm.c  | 58 
 drivers/gpu/drm/i915/intel_sprite.c  | 15 --
 5 files changed, 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bd542cb..2baa308 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -628,10 +628,6 @@ struct drm_i915_display_funcs {
  struct dpll *match_clock,
  struct dpll *best_clock);
void (*update_wm)(struct drm_crtc *crtc);
-   void (*update_sprite_wm)(struct drm_plane *plane,
-struct drm_crtc *crtc,
-uint32_t sprite_width, uint32_t sprite_height,
-int pixel_size, bool enable, bool scaled);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
/* Returns the active state of the crtc, and if the crtc is active,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7631cb4..a8d781a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4757,7 +4757,6 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
struct intel_crtc_atomic_commit *atomic = >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)
intel_wait_for_vblank(dev, crtc->pipe);
@@ -4776,10 +4775,6 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
if (atomic->post_enable_primary)
intel_post_enable_primary(>base);
 
-   drm_for_each_plane_mask(plane, dev, atomic->update_sprite_watermarks)
-   intel_update_sprite_watermarks(plane, >base,
-  0, 0, 0, false, false);
-
memset(atomic, 0, sizeof(*atomic));
 }
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a2a0301..1b98210 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1390,12 +1390,6 @@ void intel_init_clock_gating(struct drm_device *dev);
 void intel_suspend_hw(struct drm_device *dev);
 int ilk_wm_max_level(const struct drm_device *dev);
 void intel_update_watermarks(struct drm_crtc *crtc);
-void intel_update_sprite_watermarks(struct drm_plane *plane,
-   struct drm_crtc *crtc,
-   uint32_t sprite_width,
-   uint32_t sprite_height,
-   int pixel_size,
-   bool enabled, bool scaled);
 void intel_init_pm(struct drm_device *dev);
 void intel_pm_setup(struct drm_device *dev);
 void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4681f02..218ee02 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3170,18 +3170,9 @@ static void skl_compute_wm_global_parameters(struct 
drm_device *dev,
 struct intel_wm_config *config)
 {
struct drm_crtc *crtc;
-   struct drm_plane *plane;
 
list_for_each_entry(crtc, >mode_config.crtc_list, head)
config->num_pipes_active += to_intel_crtc(crtc)->active;
-
-   /* FIXME: I don't think we need those two global parameters on SKL */
-   list_for_each_entry(plane, >mode_config.plane_list, head) {
-   struct intel_plane *intel_plane = to_intel_plane(plane);
-
-   config->sprites_enabled |= intel_plane->wm.enabled;
-   config->sprites_scaled |= intel_plane->wm.scaled;
-   }
 }
 
 static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
@@ -3704,39 +3695,6 @@ static void skl_update_wm(struct drm_crtc *crtc)
dev_priv->wm.skl_hw = *results;
 }
 
-static void

[Intel-gfx] [PATCH 01/15] drm/i915: Drop redundant watermark programming

2015-09-24 Thread Matt Roper
In commit

commit e4ca061275ec6a48b66c6edebe08644e666994c0
Author: Patrik Jakobsson 
Date:   Wed Jul 8 15:31:52 2015 +0200

drm/i915: Don't forget to mark crtc as inactive after disable

we added extra watermark updates to all of the .crtc_disable()
entrypoints to avoid problems problems with system resume on SKL.  Those
disable entrypoints are currently called in just two places in the
driver: intel_atomic_commit (i.e., during a modeset) and
intel_crtc_disable_noatomic (which is called during hardware readout).
It seems that this extra watermark recalculation should only be
important in the latter case (which happens during a resume operation);
the former case should always have appropriate watermark programming
happening at other points in the modeset sequence.

Let's move the watermark update out of the .crtc_disable() entrypoints
and place it directly in intel_crtc_disable_noatomic() so that it only
happens on S3 resume and not during a regular modeset (since the
existing watermark handling should properly update watermarks during
normal atomic commits).

Cc: Patrik Jakobsson 
Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1847257..dea1f23 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5067,9 +5067,6 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 
ironlake_fdi_pll_disable(intel_crtc);
}
-
-   intel_crtc->active = false;
-   intel_update_watermarks(crtc);
 }
 
 static void haswell_crtc_disable(struct drm_crtc *crtc)
@@ -5113,9 +5110,6 @@ 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_crtc->active = false;
-   intel_update_watermarks(crtc);
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
@@ -6214,9 +6208,6 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
 
if (!IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
-
-   intel_crtc->active = false;
-   intel_update_watermarks(crtc);
 }
 
 static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
@@ -6236,6 +6227,8 @@ static void intel_crtc_disable_noatomic(struct drm_crtc 
*crtc)
 
intel_crtc_disable_planes(crtc, crtc->state->plane_mask);
dev_priv->display.crtc_disable(crtc);
+   intel_crtc->active = false;
+   intel_update_watermarks(crtc);
intel_disable_shared_dpll(intel_crtc);
 
domains = intel_crtc->enabled_power_domains;
-- 
2.1.4

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


[Intel-gfx] [PATCH 09/15] drm/i915: Refactor ilk_update_wm (v3)

2015-09-24 Thread Matt Roper
From: Ville Syrjälä 

Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.

v2: Fix typo in commit message

v3 (by Matt): Heavily rebased for current codebase.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 64 ++---
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 218ee02..17f7353 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3695,39 +3695,14 @@ static void skl_update_wm(struct drm_crtc *crtc)
dev_priv->wm.skl_hw = *results;
 }
 
-static void ilk_update_wm(struct drm_crtc *crtc)
+static void ilk_program_watermarks(struct drm_i915_private *dev_priv)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_device *dev = dev_priv->dev;
+   struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
struct ilk_wm_maximums max;
+   struct intel_wm_config config = {};
struct ilk_wm_values results = {};
enum intel_ddb_partitioning partitioning;
-   struct intel_pipe_wm pipe_wm = {};
-   struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
-   struct intel_wm_config config = {};
-
-   WARN_ON(cstate->base.active != intel_crtc->active);
-
-   /*
-* IVB workaround: must disable low power watermarks for at least
-* one frame before enabling scaling.  LP watermarks can be re-enabled
-* when scaling is disabled.
-*
-* WaCxSRDisabledForSpriteScaling:ivb
-*/
-   if (cstate->disable_lp_wm) {
-   ilk_disable_lp_wm(dev);
-   intel_wait_for_vblank(dev, intel_crtc->pipe);
-   }
-
-   intel_compute_pipe_wm(cstate, _wm);
-
-   if (!memcmp(_crtc->wm.active, _wm, sizeof(pipe_wm)))
-   return;
-
-   intel_crtc->wm.active = pipe_wm;
 
ilk_compute_wm_config(dev, );
 
@@ -3753,6 +3728,37 @@ static void ilk_update_wm(struct drm_crtc *crtc)
ilk_write_wm_values(dev_priv, );
 }
 
+static void ilk_update_wm(struct drm_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+   struct intel_pipe_wm pipe_wm = {};
+
+   WARN_ON(cstate->base.active != intel_crtc->active);
+
+   /*
+* IVB workaround: must disable low power watermarks for at least
+* one frame before enabling scaling.  LP watermarks can be re-enabled
+* when scaling is disabled.
+*
+* WaCxSRDisabledForSpriteScaling:ivb
+*/
+   if (cstate->disable_lp_wm) {
+   ilk_disable_lp_wm(crtc->dev);
+   intel_wait_for_vblank(crtc->dev, intel_crtc->pipe);
+   }
+
+   intel_compute_pipe_wm(cstate, _wm);
+
+   if (!memcmp(_crtc->wm.active, _wm, sizeof(pipe_wm)))
+   return;
+
+   intel_crtc->wm.active = pipe_wm;
+
+   ilk_program_watermarks(dev_priv);
+}
+
 static void skl_pipe_wm_active_state(uint32_t val,
 struct skl_pipe_wm *active,
 bool is_transwm,
-- 
2.1.4

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


Re: [Intel-gfx] [BXT MIPI PATCH v4 14/14] drm/i915: Added BXT DSI backlight support

2015-09-24 Thread Ville Syrjälä
On Wed, Sep 23, 2015 at 11:30:43PM +0530, Uma Shankar wrote:
> DSI backlight support for bxt is added.
> 
> TODO: There is no support for backlight control in drm panel
>   framework. This will be added as part of VBT version patches
>   fixing the backlight sequence.
> 
> v2: Fixed Jani's review comments from previous patch. Added the
> BXT DSI backlight code in this patch. Backlight setup and
> enable/disable code for backlight is added in intel_dsi.c.
> 
> v3: Rebased on latest drm-nightly. Fixed Jani's review comments.
> 
> v4: Making backlight calls generic as per Jani's suggestion.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c |   20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 08bade2..3e7f796 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -438,6 +438,7 @@ static void intel_dsi_enable(struct intel_encoder 
> *encoder)
>   struct drm_device *dev = encoder->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + struct intel_connector *intel_connector = intel_dsi->attached_connector;
>   enum port port;
>  
>   DRM_DEBUG_KMS("\n");
> @@ -458,6 +459,9 @@ static void intel_dsi_enable(struct intel_encoder 
> *encoder)
>  
>   intel_dsi_port_enable(encoder);
>   }
> +
> + msleep(intel_dsi->backlight_on_delay);
> + intel_panel_enable_backlight(intel_connector);
>  }
>  
>  static void intel_dsi_pre_enable(struct intel_encoder *encoder)
> @@ -623,10 +627,14 @@ static void intel_dsi_post_disable(struct intel_encoder 
> *encoder)
>  {
>   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + struct intel_connector *intel_connector = intel_dsi->attached_connector;
>   u32 val;
>  
>   DRM_DEBUG_KMS("\n");
>  
> + intel_panel_disable_backlight(intel_connector);
> + msleep(intel_dsi->backlight_off_delay);
> +
>   intel_dsi_disable(encoder);
>  
>   intel_dsi_clear_device_ready(encoder);
> @@ -1226,8 +1234,18 @@ void intel_dsi_init(struct drm_device *dev)
>  
>   intel_panel_init(_connector->panel, fixed_mode, NULL);
>  
> - return;
> + /*
> +  * Pipe parameter is not used for BXT.
> +  * Passing INVALID_PIPE to adher to API requirement.
> +  */
> + if (IS_BROXTON(dev))
> + intel_panel_setup_backlight(connector, INVALID_PIPE);
> + else
> + intel_panel_setup_backlight(connector,
> + intel_encoder->crtc_mask == (1 << PIPE_A) ?
> + PIPE_A : PIPE_B);

Is this aganst some ancient kernel version? We have 
backlight calls in the dsi code already.

>  
> + return;
>  err:
>   drm_encoder_cleanup(_encoder->base);
>   kfree(intel_dsi);
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/7] drm/i915: fix CFB size calculation

2015-09-24 Thread Ville Syrjälä
On Wed, Sep 23, 2015 at 12:52:21PM -0300, Paulo Zanoni wrote:
> We were considering the whole framebuffer height, but the spec clearly
> says that we should only consider the active display height size.
> 
> On my current testing machine, this moves us from 124 successes and
> 502 skips to 209 successes and 417 skips on "kms_frontbuffer_tracking
> --fbc-only". The high amount of skips is due to the --fbc-only
> argument. We had those skips due to not enough stolen memory for the
> tests. We're now passing the maximum possible amount: 209.
> 
> Note: when this patch was written, the amount of tests we had for FBC
> was different than what we have now.
> 
> v2: Use the clipped src size instead of pipe_src_h (Ville).
> 
> Testcase: igt/kms_frontbuffer_tracking/fbc-*
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index d38f464..0a6b454 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -693,9 +693,15 @@ void intel_fbc_cleanup_cfb(struct drm_i915_private 
> *dev_priv)
>   mutex_unlock(_priv->fbc.lock);
>  }
>  
> -static int intel_fbc_setup_cfb(struct drm_i915_private *dev_priv, int size,
> -int fb_cpp)
> +static int intel_fbc_setup_cfb(struct intel_crtc *crtc)
>  {
> + struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> + struct drm_framebuffer *fb = crtc->base.primary->fb;
> + int size, fb_cpp;
> +
> + size = (crtc->base.primary->state->src_h >> 16) * fb->pitches[0];

That's what the user asked for. The clipped size is drm_rect_height(>src)

As mentioned in my last review, the docs aren't really clear on whether we
need to consider the plane src height or dst height, or if we're even
allowed to use FBC with scaled planes.

> + fb_cpp = drm_format_plane_cpp(fb->pixel_format, 0);
> +
>   if (size <= dev_priv->fbc.uncompressed_size)
>   return 0;
>  
> @@ -883,8 +889,7 @@ static void __intel_fbc_update(struct drm_i915_private 
> *dev_priv)
>   goto out_disable;
>   }
>  
> - if (intel_fbc_setup_cfb(dev_priv, obj->base.size,
> - drm_format_plane_cpp(fb->pixel_format, 0))) {
> + if (intel_fbc_setup_cfb(intel_crtc)) {
>   set_no_fbc_reason(dev_priv, FBC_STOLEN_TOO_SMALL);
>   goto out_disable;
>   }
> -- 
> 2.5.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too

2015-09-24 Thread Ville Syrjälä
On Wed, Sep 23, 2015 at 12:52:26PM -0300, Paulo Zanoni wrote:
> The trick is not strictly necessary on SKL because the offset
> registers allow more bits. But for FBC, doing this changes how the
> hardware tracking works - it starts at the surface address we provide
> - so there's a higher chance that the CRTC will be pointing to an area
> of the frontbuffer that is actually being covered by the hardware
> tracking mechanism. This fixes fbc-farfromfence on SKL.
> 
> Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 24b8a72..d40ae71 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3031,6 +3031,7 @@ static void skylake_update_primary_plane(struct 
> drm_crtc *crtc,
>   int src_x = 0, src_y = 0, src_w = 0, src_h = 0;
>   int dst_x = 0, dst_y = 0, dst_w = 0, dst_h = 0;
>   int scaler_id = -1;
> + int pixel_size;
>  
>   plane_state = to_intel_plane_state(plane->state);
>  
> @@ -3079,6 +3080,12 @@ static void skylake_update_primary_plane(struct 
> drm_crtc *crtc,
>   src_h = intel_crtc->config->pipe_src_h;
>   }
>  
> + pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
> + intel_crtc->dspaddr_offset = intel_gen4_compute_page_offset(dev_priv,
> + , , obj->tiling_mode,
> + pixel_size, fb->pitches[0]);
> + surf_addr += intel_crtc->dspaddr_offset;

It's not that simple. I have a branch that tries to make the required
changes to make it work properly:
git://github.com/vsyrjala/linux.git tile_size

> +
>   if (intel_rotation_90_or_270(rotation)) {
>   /* stride = Surface height in tiles */
>   tile_height = intel_tile_height(dev, fb->pixel_format,
> -- 
> 2.5.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Detect virtual south bridge

2015-09-24 Thread Tian, Kevin
> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
> Sent: Friday, September 25, 2015 12:41 AM
> 
> On 08/28/2015 05:10 AM, robert.beck...@intel.com wrote:
> > From: Robert Beckett 
> >
> > Virtualized systems often use a virtual P2X4 south bridge.
> > Detect this in intel_detect_pch and make a best guess as to which PCH
> > we should be using.
> >
> > This was seen on vmware esxi hypervisor. When passing the graphics device
> > through to a guest, it can not pass through the PCH. Instead it simulates
> > a P2X4 southbridge.
> >
> > Signed-off-by: Robert Beckett 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c |   30
> ++
> >  drivers/gpu/drm/i915/i915_drv.h |1 +
> >  2 files changed, 31 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index ce3bd0c..8e158b3 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -443,6 +443,34 @@ static const struct pci_device_id pciidlist[] = {  
> > /* aka
> */
> >
> >  MODULE_DEVICE_TABLE(pci, pciidlist);
> >
> > +static enum intel_pch intel_virt_detect_pch(struct drm_device *dev)
> > +{
> > +   enum intel_pch ret = PCH_NOP;
> > +
> > +   /*
> > +* In a virtualized passthrough environment we can be in a
> > +* setup where the ISA bridge is not able to be passed through.
> > +* In this case, a south bridge can be emulated and we have to
> > +* make an educated guess as to which PCH is really there.
> > +*/
> > +
> > +   if (IS_GEN5(dev)) {
> > +   ret = PCH_IBX;
> > +   DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
> > +   } else if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
> > +   ret = PCH_CPT;
> > +   DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> > +   } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> > +   ret = PCH_LPT;
> > +   DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> > +   } else if (IS_SKYLAKE(dev)) {
> > +   ret = PCH_SPT;
> > +   DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  void intel_detect_pch(struct drm_device *dev)
> >  {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -503,6 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
> > dev_priv->pch_type = PCH_SPT;
> > DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> > WARN_ON(!IS_SKYLAKE(dev));
> > +   } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
> > +   dev_priv->pch_type = intel_virt_detect_pch(dev);
> > } else
> > continue;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8c93845..6eb0230 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2584,6 +2584,7 @@ struct drm_i915_cmd_table {
> >  #define INTEL_PCH_LPT_LP_DEVICE_ID_TYPE0x9c00
> >  #define INTEL_PCH_SPT_DEVICE_ID_TYPE   0xA100
> >  #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
> > +#define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
> >
> >  #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
> >  #define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
> >
> 
> Assuming Kevin is ok with this:
> Reviewed-by: Jesse Barnes 

Yes, I'm OK with this change. Just one comment. Does it make
sense to always have the guess as the fallback, instead of only
for P2X? If native side is OK with this, it will remove the need 
to add more IDs for different hypervisors in the future...

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


[Intel-gfx] [PATCH 02/15] drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)

2015-09-24 Thread Matt Roper
Just pull the info out of the plane state structure rather than staging
it in an additional structure.

v2: Add 'visible' condition to sprites_scaled so that we don't limit the
WM level when the sprite isn't enabled.  (Ville)

Signed-off-by: Matt Roper 
Reviewed-by(v1): Ander Conselvan de Oliveira 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 133 +---
 1 file changed, 70 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ab5ac5e..bfea446 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1799,9 +1799,6 @@ struct ilk_pipe_wm_parameters {
bool active;
uint32_t pipe_htotal;
uint32_t pixel_rate;
-   struct intel_plane_wm_parameters pri;
-   struct intel_plane_wm_parameters spr;
-   struct intel_plane_wm_parameters cur;
 };
 
 struct ilk_wm_maximums {
@@ -1823,25 +1820,25 @@ struct intel_wm_config {
  * mem_value must be in 0.1us units.
  */
 static uint32_t ilk_compute_pri_wm(const struct ilk_pipe_wm_parameters *params,
+  const struct intel_plane_state *pstate,
   uint32_t mem_value,
   bool is_lp)
 {
+   int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
uint32_t method1, method2;
 
-   if (!params->active || !params->pri.enabled)
+   if (!params->active || !pstate->visible)
return 0;
 
-   method1 = ilk_wm_method1(params->pixel_rate,
-params->pri.bytes_per_pixel,
-mem_value);
+   method1 = ilk_wm_method1(params->pixel_rate, bpp, mem_value);
 
if (!is_lp)
return method1;
 
method2 = ilk_wm_method2(params->pixel_rate,
 params->pipe_htotal,
-params->pri.horiz_pixels,
-params->pri.bytes_per_pixel,
+drm_rect_width(>dst),
+bpp,
 mem_value);
 
return min(method1, method2);
@@ -1852,20 +1849,20 @@ static uint32_t ilk_compute_pri_wm(const struct 
ilk_pipe_wm_parameters *params,
  * mem_value must be in 0.1us units.
  */
 static uint32_t ilk_compute_spr_wm(const struct ilk_pipe_wm_parameters *params,
+  const struct intel_plane_state *pstate,
   uint32_t mem_value)
 {
+   int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
uint32_t method1, method2;
 
-   if (!params->active || !params->spr.enabled)
+   if (!params->active || !pstate->visible)
return 0;
 
-   method1 = ilk_wm_method1(params->pixel_rate,
-params->spr.bytes_per_pixel,
-mem_value);
+   method1 = ilk_wm_method1(params->pixel_rate, bpp, mem_value);
method2 = ilk_wm_method2(params->pixel_rate,
 params->pipe_htotal,
-params->spr.horiz_pixels,
-params->spr.bytes_per_pixel,
+drm_rect_width(>dst),
+bpp,
 mem_value);
return min(method1, method2);
 }
@@ -1875,28 +1872,32 @@ static uint32_t ilk_compute_spr_wm(const struct 
ilk_pipe_wm_parameters *params,
  * mem_value must be in 0.1us units.
  */
 static uint32_t ilk_compute_cur_wm(const struct ilk_pipe_wm_parameters *params,
+  const struct intel_plane_state *pstate,
   uint32_t mem_value)
 {
-   if (!params->active || !params->cur.enabled)
+   int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
+
+   if (!params->active || !pstate->visible)
return 0;
 
return ilk_wm_method2(params->pixel_rate,
  params->pipe_htotal,
- params->cur.horiz_pixels,
- params->cur.bytes_per_pixel,
+ drm_rect_width(>dst),
+ bpp,
  mem_value);
 }
 
 /* Only for WM_LP. */
 static uint32_t ilk_compute_fbc_wm(const struct ilk_pipe_wm_parameters *params,
+  const struct intel_plane_state *pstate,
   uint32_t pri_val)
 {
-   if (!params->active || !params->pri.enabled)
+   int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
+
+   if (!params->active || !pstate->visible)
return 0;
 
-   return ilk_wm_fbc(pri_val,
- 

[Intel-gfx] [PATCH 06/15] drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)

2015-09-24 Thread Matt Roper
Just pull the info out of the state structures rather than staging
it in an additional set of structures.  To make this more
straightforward, we change the signature of several internal WM
functions to take the crtc state as a parameter.

v2:
 - Don't forget to skip cursor planes on a loop in the DDB allocation
   function to match original behavior.  (Ander)
 - Change a use of intel_crtc->active to cstate->active.  They should
   be identical, but it's better to be consistent.  (Ander)
 - Rework more function signatures to pass states rather than crtc for
   consistency. (Ander)

v3:
  - Add missing "+ 1" to skl_wm_plane_id()'s 'overlay' case. (Maarten)
  - Packed formats should pass '0' to drm_format_plane_cpp(), not 1.
(Maarten)
  - Drop unwanted WARN_ON() for disabled planes when calculating data
rate for SKL.  (Maarten)

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 326 +++-
 1 file changed, 151 insertions(+), 175 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8829047..7bfcc98 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1787,13 +1787,6 @@ static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t 
horiz_pixels,
return DIV_ROUND_UP(pri_val * 64, horiz_pixels * bytes_per_pixel) + 2;
 }
 
-struct skl_pipe_wm_parameters {
-   bool active;
-   uint32_t pipe_htotal;
-   uint32_t pixel_rate; /* in KHz */
-   struct intel_plane_wm_parameters plane[I915_MAX_PLANES];
-};
-
 struct ilk_wm_maximums {
uint16_t pri;
uint16_t spr;
@@ -2834,18 +2827,40 @@ static bool ilk_disable_lp_wm(struct drm_device *dev)
 #define SKL_DDB_SIZE   896 /* in blocks */
 #define BXT_DDB_SIZE   512
 
+/*
+ * Return the index of a plane in the SKL DDB and wm result arrays.  Primary
+ * plane is always in slot 0, cursor is always in slot I915_MAX_PLANES-1, and
+ * other universal planes are in indices 1..n.  Note that this may leave unused
+ * indices between the top "sprite" plane and the cursor.
+ */
+static int
+skl_wm_plane_id(const struct intel_plane *plane)
+{
+   switch (plane->base.type) {
+   case DRM_PLANE_TYPE_PRIMARY:
+   return 0;
+   case DRM_PLANE_TYPE_CURSOR:
+   return PLANE_CURSOR;
+   case DRM_PLANE_TYPE_OVERLAY:
+   return plane->plane + 1;
+   default:
+   MISSING_CASE(plane->base.type);
+   return plane->plane;
+   }
+}
+
 static void
 skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
-  struct drm_crtc *for_crtc,
+  const struct intel_crtc_state *cstate,
   const struct intel_wm_config *config,
-  const struct skl_pipe_wm_parameters *params,
   struct skl_ddb_entry *alloc /* out */)
 {
+   struct drm_crtc *for_crtc = cstate->base.crtc;
struct drm_crtc *crtc;
unsigned int pipe_size, ddb_size;
int nth_active_pipe;
 
-   if (!params->active) {
+   if (!cstate->base.active) {
alloc->start = 0;
alloc->end = 0;
return;
@@ -2911,19 +2926,29 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
 }
 
 static unsigned int
-skl_plane_relative_data_rate(const struct intel_plane_wm_parameters *p, int y)
+skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
+const struct drm_plane_state *pstate,
+int y)
 {
+   struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+   struct drm_framebuffer *fb = pstate->fb;
 
/* for planar format */
-   if (p->y_bytes_per_pixel) {
+   if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y)  /* y-plane data rate */
-   return p->horiz_pixels * p->vert_pixels * 
p->y_bytes_per_pixel;
+   return intel_crtc->config->pipe_src_w *
+   intel_crtc->config->pipe_src_h *
+   drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
-   return (p->horiz_pixels/2) * (p->vert_pixels/2) * 
p->bytes_per_pixel;
+   return (intel_crtc->config->pipe_src_w/2) *
+   (intel_crtc->config->pipe_src_h/2) *
+   drm_format_plane_cpp(fb->pixel_format, 1);
}
 
/* for packed formats */
-   return p->horiz_pixels * p->vert_pixels * p->bytes_per_pixel;
+   return intel_crtc->config->pipe_src_w *
+   intel_crtc->config->pipe_src_h *
+   drm_format_plane_cpp(fb->pixel_format, 0);
 }
 
 /*
@@ -2932,46 

[Intel-gfx] [PATCH 04/15] drm/i915: Determine I915_MAX_PLANES from plane enum

2015-09-24 Thread Matt Roper
Let the compiler figure out what I915_MAX_PLANES is from 'enum plane' so
that we don't need a separate #define.

While we're at it, add the cursor plane to the enum.  This will cause
I915_MAX_PLANES to now include the cursor plane in its count (it didn't
previously).   This change is safe since we currently only use this
value in array declarations (never in the actual code logic); we just
wind up allocating slightly more memory than we need to.  A followup
patch will cause various parts of the code to start using the extra
array element where appropriate.

(This patch probably should have been squashed with the followup patch,
but I couldn't figure out how to get Coccinelle to modify enum
declarations...)

Suggested-by: Ander Conselvan De Oliveira 
Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b5d587..eac9414 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -131,17 +131,17 @@ enum transcoder {
 #define transcoder_name(t) ((t) + 'A')
 
 /*
- * This is the maximum (across all platforms) number of planes (primary +
- * sprites) that can be active at the same time on one pipe.
- *
- * This value doesn't count the cursor plane.
+ * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
+ * number of planes per CRTC.  Not all platforms really have this many planes,
+ * which means some arrays of size I915_MAX_PLANES may have unused entries
+ * between the topmost sprite plane and the cursor plane.
  */
-#define I915_MAX_PLANES4
-
 enum plane {
PLANE_A = 0,
PLANE_B,
PLANE_C,
+   PLANE_CURSOR,
+   I915_MAX_PLANES,
 };
 #define plane_name(p) ((p) + 'A')
 
-- 
2.1.4

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


[Intel-gfx] [PATCH 00/15] Atomic watermark updates (v5)

2015-09-24 Thread Matt Roper
Previous version of the series was here:
  http://lists.freedesktop.org/archives/intel-gfx/2015-September/075883.html

Pretty minimal changes since the last series:
 * General rebasing on di-nightly
 * Some minor SKL-specific bugfixes on patch #6 based on Maarten's review of
   v4 of this series.
 * Added a new patch #14 to try to sanitize watermarks after hardware state
   readout.  Once we've read general state out of the hardware, we should
   recalculate what we think the watermarks for that state should be and not
   just trust whatever the system firmware happens to have programmed them to.
 * Added Maarten's r-b to all patches except the new #14; he gave it on his
   feedback to patch #6 of the last revision of the series and I didn't notice
   that it applied to the whole series until I re-read his feedback.  :-)

Matt Roper (14):
  drm/i915: Drop redundant watermark programming
  drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM
code (v2)
  drm/i915: Eliminate usage of pipe_wm_parameters from ILK-style WM (v2)
  drm/i915: Determine I915_MAX_PLANES from plane enum
  drm/i915/skl: Simplify wm structures slightly (v2)
  drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM
(v3)
  drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check
  drm/i915: Drop intel_update_sprite_watermarks
  drm/i915: Calculate pipe watermarks into CRTC state (v3)
  drm/i915: Calculate ILK-style watermarks during atomic check (v3)
  drm/i915: Don't set plane visible during HW readout if CRTC is off
  drm/i915: Calculate watermark configuration during atomic check (v2)
  drm/i915: Sanitize watermarks after hardware state readout
  drm/i915: Add two-stage ILK-style watermark programming (v5)

Ville Syrjälä (1):
  drm/i915: Refactor ilk_update_wm (v3)

 drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  41 +-
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +
 drivers/gpu/drm/i915/intel_display.c | 255 +--
 drivers/gpu/drm/i915/intel_drv.h |  85 +++-
 drivers/gpu/drm/i915/intel_pm.c  | 855 ---
 drivers/gpu/drm/i915/intel_sprite.c  |  15 -
 7 files changed, 707 insertions(+), 548 deletions(-)

-- 
2.1.4

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


[Intel-gfx] [PATCH 03/15] drm/i915: Eliminate usage of pipe_wm_parameters from ILK-style WM (v2)

2015-09-24 Thread Matt Roper
Just pull the info out of the CRTC state structure rather than staging
it in an additional structure.

Note that we use cstate->active rather than intel_crtc->active which may
appear to be a change in behavior.  However since we're no longer trying
to recalculate watermarks during the "pipe off" stage of a modeset,
intel_crtc->active and cstate->active should always be identical when
watermarks are calculated (at least for ILK-style platforms).

v2: Clarify reasoning for cstate->active and add a WARN_ON to the code
to assert that it really is always identical to intel_crtc->active
as expected.

Signed-off-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 84 ++---
 1 file changed, 29 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bfea446..9e6e9c2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1795,12 +1795,6 @@ struct skl_pipe_wm_parameters {
struct intel_plane_wm_parameters cursor;
 };
 
-struct ilk_pipe_wm_parameters {
-   bool active;
-   uint32_t pipe_htotal;
-   uint32_t pixel_rate;
-};
-
 struct ilk_wm_maximums {
uint16_t pri;
uint16_t spr;
@@ -1819,7 +1813,7 @@ struct intel_wm_config {
  * For both WM_PIPE and WM_LP.
  * mem_value must be in 0.1us units.
  */
-static uint32_t ilk_compute_pri_wm(const struct ilk_pipe_wm_parameters *params,
+static uint32_t ilk_compute_pri_wm(const struct intel_crtc_state *cstate,
   const struct intel_plane_state *pstate,
   uint32_t mem_value,
   bool is_lp)
@@ -1827,16 +1821,16 @@ static uint32_t ilk_compute_pri_wm(const struct 
ilk_pipe_wm_parameters *params,
int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
uint32_t method1, method2;
 
-   if (!params->active || !pstate->visible)
+   if (!cstate->base.active || !pstate->visible)
return 0;
 
-   method1 = ilk_wm_method1(params->pixel_rate, bpp, mem_value);
+   method1 = ilk_wm_method1(ilk_pipe_pixel_rate(cstate), bpp, mem_value);
 
if (!is_lp)
return method1;
 
-   method2 = ilk_wm_method2(params->pixel_rate,
-params->pipe_htotal,
+   method2 = ilk_wm_method2(ilk_pipe_pixel_rate(cstate),
+cstate->base.adjusted_mode.crtc_htotal,
 drm_rect_width(>dst),
 bpp,
 mem_value);
@@ -1848,19 +1842,19 @@ static uint32_t ilk_compute_pri_wm(const struct 
ilk_pipe_wm_parameters *params,
  * For both WM_PIPE and WM_LP.
  * mem_value must be in 0.1us units.
  */
-static uint32_t ilk_compute_spr_wm(const struct ilk_pipe_wm_parameters *params,
+static uint32_t ilk_compute_spr_wm(const struct intel_crtc_state *cstate,
   const struct intel_plane_state *pstate,
   uint32_t mem_value)
 {
int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
uint32_t method1, method2;
 
-   if (!params->active || !pstate->visible)
+   if (!cstate->base.active || !pstate->visible)
return 0;
 
-   method1 = ilk_wm_method1(params->pixel_rate, bpp, mem_value);
-   method2 = ilk_wm_method2(params->pixel_rate,
-params->pipe_htotal,
+   method1 = ilk_wm_method1(ilk_pipe_pixel_rate(cstate), bpp, mem_value);
+   method2 = ilk_wm_method2(ilk_pipe_pixel_rate(cstate),
+cstate->base.adjusted_mode.crtc_htotal,
 drm_rect_width(>dst),
 bpp,
 mem_value);
@@ -1871,30 +1865,30 @@ static uint32_t ilk_compute_spr_wm(const struct 
ilk_pipe_wm_parameters *params,
  * For both WM_PIPE and WM_LP.
  * mem_value must be in 0.1us units.
  */
-static uint32_t ilk_compute_cur_wm(const struct ilk_pipe_wm_parameters *params,
+static uint32_t ilk_compute_cur_wm(const struct intel_crtc_state *cstate,
   const struct intel_plane_state *pstate,
   uint32_t mem_value)
 {
int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
 
-   if (!params->active || !pstate->visible)
+   if (!cstate->base.active || !pstate->visible)
return 0;
 
-   return ilk_wm_method2(params->pixel_rate,
- params->pipe_htotal,
+   return ilk_wm_method2(ilk_pipe_pixel_rate(cstate),
+ cstate->base.adjusted_mode.crtc_htotal,
  drm_rect_width(>dst),
  bpp,
   

[Intel-gfx] [PATCH v2] drm/i915: set proper N/CTS in modeset

2015-09-24 Thread libin . yang
From: Libin Yang 

When modeset occurs and the TMDS frequency is set to some
speical values, the N/CTS need to be set manually if audio
is playing.

Signed-off-by: Libin Yang 
---
 drivers/gpu/drm/i915/intel_audio.c | 57 --
 include/drm/i915_component.h   | 10 +++
 2 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index e3c32ce..642dfbd 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -128,6 +128,20 @@ static int audio_config_get_n(const struct 
drm_display_mode *mode, int rate)
return 0;
 }
 
+static uint32_t audio_config_setup_n_reg(int n, uint32_t val)
+{
+   int n_low, n_up;
+   uint32_t tmp = val;
+
+   n_low = n & 0xfff;
+   n_up = (n >> 12) & 0xff;
+   tmp &= ~(AUD_CONFIG_UPPER_N_MASK | AUD_CONFIG_LOWER_N_MASK);
+   tmp |= ((n_up << AUD_CONFIG_UPPER_N_SHIFT) |
+   (n_low << AUD_CONFIG_LOWER_N_SHIFT) |
+   AUD_CONFIG_N_PROG_ENABLE);
+   return tmp;
+}
+
 /* check whether N/CTS/M need be set manually */
 static bool audio_rate_need_prog(struct intel_crtc *crtc,
struct drm_display_mode *mode)
@@ -262,9 +276,14 @@ static void hsw_audio_codec_enable(struct drm_connector 
*connector,
struct drm_i915_private *dev_priv = connector->dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+   struct i915_audio_component *acomp = dev_priv->audio_component;
const uint8_t *eld = connector->eld;
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(>base);
+   enum port port = intel_dig_port->port;
uint32_t tmp;
int len, i;
+   int n, rate;
 
DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
  pipe_name(pipe), drm_eld_size(eld));
@@ -302,12 +321,29 @@ static void hsw_audio_codec_enable(struct drm_connector 
*connector,
/* Enable timestamps */
tmp = I915_READ(HSW_AUD_CFG(pipe));
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
-   tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
else
tmp |= audio_config_hdmi_pixel_clock(mode);
+
+   tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
+   if (audio_rate_need_prog(intel_crtc, mode)) {
+   if (!acomp)
+   rate = 0;
+   else if (port >= PORT_A && port <= PORT_E)
+   rate = acomp->aud_sample_rate[port];
+   else {
+   DRM_ERROR("invalid port: %d\n", port);
+   rate = 0;
+   }
+   n = audio_config_get_n(mode, rate);
+   if (n != 0)
+   tmp = audio_config_setup_n_reg(n, tmp);
+   else
+   DRM_DEBUG_KMS("no suitable N value is found\n");
+   }
+
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
 
mutex_unlock(_priv->av_mutex);
@@ -594,9 +630,10 @@ static int i915_audio_component_sync_audio_rate(struct 
device *dev,
struct intel_digital_port *intel_dig_port;
struct intel_crtc *crtc;
struct drm_display_mode *mode;
+   struct i915_audio_component *acomp = dev_priv->audio_component;
enum pipe pipe = -1;
u32 tmp;
-   int n_low, n_up, n;
+   int n;
 
/* HSW, BDW SKL need this fix */
if (!IS_SKYLAKE(dev_priv) &&
@@ -630,6 +667,9 @@ static int i915_audio_component_sync_audio_rate(struct 
device *dev,
  pipe_name(pipe), port_name(port));
mode = >config->base.adjusted_mode;
 
+   /* port must be valid now, otherwise the pipe will be invalid */
+   acomp->aud_sample_rate[port] = rate;
+
/* 2. check whether to set the N/CTS/M manually or not */
if (!audio_rate_need_prog(crtc, mode)) {
tmp = I915_READ(HSW_AUD_CFG(pipe));
@@ -649,15 +689,10 @@ static int i915_audio_component_sync_audio_rate(struct 
device *dev,
mutex_unlock(_priv->av_mutex);
return 0;
}
-   n_low = n & 0xfff;
-   n_up = (n >> 12) & 0xff;
 
-   /* 4. set the N/CTS/M */
+   /* 3. set the N/CTS/M */
tmp = I915_READ(HSW_AUD_CFG(pipe));
-   tmp &= ~(AUD_CONFIG_UPPER_N_MASK | AUD_CONFIG_LOWER_N_MASK);
-   tmp |= ((n_up << AUD_CONFIG_UPPER_N_SHIFT) |
-   (n_low << AUD_CONFIG_LOWER_N_SHIFT) |
-   AUD_CONFIG_N_PROG_ENABLE);
+   tmp = audio_config_setup_n_reg(n, tmp);
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
 
mutex_unlock(_priv->av_mutex);
@@ -678,6 

Re: [Intel-gfx] [regression] Re: Linux 4.3-rc1

2015-09-24 Thread Sedat Dilek
On Wed, Sep 23, 2015 at 11:37 PM, Sedat Dilek  wrote:
> On Wed, Sep 23, 2015 at 10:48 PM, Sedat Dilek  wrote:
>> On Wed, Sep 23, 2015 at 3:31 PM, Shuah Khan  wrote:
>>> On 09/23/2015 02:56 AM, Daniel Vetter wrote:
 Another regression for Jairo to track.
 -Daniel
>>>
>>> Saw the same problem in 4.3-rc2 as well. Not a one time
>>> deal and easily reproducible.
>>>
>>
>> Looks like the patch "drm/i915: Add primary plane to mask if it's
>> visible" is the correct fix.
>> Did not try it.
>>
>> - sed@ -
>>
>> [1] 
>> http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a
>>
>
> Pulled in d-i-f [1] on top of Linux v4.3-rc2 and the issue is gone.
>

The patch is now in Linus tree.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=721a09f7393de6c28a07516dccd654c6e995944a

> - sed@ -
>
> [1] http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-fixes
>
>>> thanks,
>>> -- Shuah

 On Tue, Sep 15, 2015 at 03:26:13AM +0200, Sedat Dilek wrote:
> Hi,
>
> I have reported the same issue in [0]...
>
> You write in [1]...
>
> [ cut here ]
> WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377
> assert_planes_disabled+0xe4/0x150 [i915]()
> plane A assertion failure, should be disabled but not
> ...
>
> I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64.
>
> Regards,
> - Sedat -
>
> [0] http://marc.info/?t=14417666342=1=2
> [1] http://marc.info/?l=linux-kernel=144227950327112=2

>>>
>>>
>>> --
>>> Shuah Khan
>>> Sr. Linux Kernel Developer
>>> Open Source Innovation Group
>>> Samsung Research America (Silicon Valley)
>>> shua...@osg.samsung.com | (970) 217-8978
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx