On pe, 2016-02-12 at 18:55 +0200, Imre Deak wrote:
> We have many places in the code where we check if a given display power
> domain is enabled and if so access registers backed by this power
> domain. We assumed that some modeset lock will prevent the power
> reference from vanishing in the middl
13.02.2016 01:23, Ville Syrjälä wrote:
- Do you have another monitor to try?
- Do you have another cable to try?
More on this.
Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working
Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not
working
Computer DVI —— DVI-D
+ mailing-list
Original Message
Subject: Discuss GVT context hacks in i915
Date: Mon, 15 Feb 2016 17:11:12 +0800
From: Zhi Wang
To: Joonas Lahtinen , Chris Wilson
, Daniel Vetter ,
Zhiyuan Lv , "Tian, Kevin"
Hi Guys:
Previously we have sent our GVT-g device model RFC c
Hi,
I'm positive it does. Are you sure you've re-compiled? (check or
distcheck targets do not re-compile the tests).
On Fri, Feb 12, 2016 at 03:38:27PM -0200, Tiago Vignatti wrote:
> I'm not sure this actually fix the root problem. With or without your patch
> applied, I'm seeing the fol
On Thu, Feb 11, 2016 at 01:01:34PM +, Tvrtko Ursulin wrote:
> On 29/01/16 16:49, Chris Wilson wrote:
> >As we add the VMA to the request early, it may be cancelled during
> >execbuf reservation. This will leave the context object pointing to a
>
> I don't get it, request is created after the r
On Thu, Feb 11, 2016 at 12:12:26PM +, Tvrtko Ursulin wrote:
>
> On 29/01/16 16:49, Chris Wilson wrote:
> >intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait
> >upon a full ring to advance). Don't emit an error for this.
> >
> >Testcase: igt/gem_concurrent_blit
> >Signed-off
On Fri, 12 Feb 2016 17:47:21 +0100,
Gabriel Feceoru wrote:
>
> !!! This caused a regression in the i-g-t drv_module_reload_basic test.
>
>
> Reproducible easily on HSW (i5-4460) with:
> #rmmod snd_hda_intel
I couldn't reproduce this on my HSW machine. Does it happen always
without without the
This reverts commit 1b39a917a9e00378c02c50ad86632ed3d872bfad.
Chris retracted his reviewed-by (which I failed to notice) and somehow
it blows up (I did it again!) as reported by Mika with the below
backtrace on module reload:
[ 58.170374] IP: []
intel_logical_ring_cleanup+0x83/0x100 [i915]
...
The MIPI clock calculations for the addtional clock
are revised from B0 stepping onwards, the bit definitions
have changed compared to old stepping.
v2: Fixing compilation warning.
v3: Retained the old Macros (Jani)
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/i915_reg.h | 96 +
On 11/02/16 08:47, Daniel Vetter wrote:
On Mon, Feb 01, 2016 at 09:45:25AM +, Dave Gordon wrote:
On 30/01/16 11:28, Chris Wilson wrote:
On Sat, Jan 30, 2016 at 10:56:27AM +, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 07:19:27PM +, Dave Gordon wrote:
1. add call to i915_gem_contex
On 11/02/16 15:02, Mika Kuoppala wrote:
Chris Wilson writes:
On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote:
From: Nick Hoath
Swap the order of context & engine cleanup, so that contexts are cleaned
up first, and *t
On 12/02/16 16:31, Martin Peres wrote:
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/intel_device.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel
Hi,
According to scripts/get_maintainer.pl Ingo or Peter would be more
appropriate to merge.
Added them as To:
On ke, 2016-02-03 at 22:42 +0530, Gautham R Shenoy wrote:
> Hello Joonas,
>
> On Wed, Feb 03, 2016 at 04:24:28PM +0200, Joonas Lahtinen wrote:
> > Use distinctive name for cpu_hotplug.
Op 09-02-16 om 15:58 schreef Ville Syrjälä:
> On Tue, Feb 09, 2016 at 03:05:51PM +0100, Maarten Lankhorst wrote:
>> Op 09-02-16 om 14:37 schreef Ville Syrjälä:
>>> On Tue, Feb 09, 2016 at 01:52:22PM +0100, Maarten Lankhorst wrote:
Instead of duplicating the functionality now that we no longer
Instead of implementing a custom locked reference counting, use lockref.
Current implementation leads to a deadlock splat on Intel SKL platforms
when lockdep debugging is enabled.
This is due to few of CPUfreq drivers (including Intel P-state) having this;
policy->rwsem is locked during driver in
Op 12-02-16 om 11:34 schreef Pratik Vishwakarma:
> From: Mayuresh Gharpure
>
> Co-Author : Marius Vlad
> Co-Author : Pratik Vishwakarma
>
> So far we have had only two commit styles, COMMIT_LEGACY
> and COMMIT_UNIVERSAL. This patch adds another commit style
> COMMIT_ATOMIC which makes use of drm
On 15.02.2016 12:23, Takashi Iwai wrote:
On Fri, 12 Feb 2016 17:47:21 +0100,
Gabriel Feceoru wrote:
!!! This caused a regression in the i-g-t drv_module_reload_basic test.
Reproducible easily on HSW (i5-4460) with:
#rmmod snd_hda_intel
I couldn't reproduce this on my HSW machine. Does it
On Mon, 15 Feb 2016 13:57:00 +0100,
Gabriel Feceoru wrote:
>
>
>
> On 15.02.2016 12:23, Takashi Iwai wrote:
> > On Fri, 12 Feb 2016 17:47:21 +0100,
> > Gabriel Feceoru wrote:
> >>
> >> !!! This caused a regression in the i-g-t drv_module_reload_basic test.
> >>
> >>
> >> Reproducible easily on H
On 15.02.2016 14:57, Takashi Iwai wrote:
On Mon, 15 Feb 2016 13:57:00 +0100,
Gabriel Feceoru wrote:
On 15.02.2016 12:23, Takashi Iwai wrote:
On Fri, 12 Feb 2016 17:47:21 +0100,
Gabriel Feceoru wrote:
!!! This caused a regression in the i-g-t drv_module_reload_basic test.
Reproducible e
On Fri, Feb 12, 2016 at 06:06:10PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Set cdclk based on the max required pixel clock based on VCO
> selected. Track boot vco instead of boot cdclk.
>
> The vco is now tracked at the atomic level and all CRTCs updated if
> the requir
Because we record connector_mask using 1 << drm_connector_index now
the connector_mask should stay the same even when other connectors
are removed. This was not the case with MST, in that case when removing
a connector all other connectors may change their index.
This is fixed by waiting until the
Imre Deak writes:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference f
On Mon, Feb 15, 2016 at 06:55:07AM +, R, Durgadoss wrote:
> Hi Ville,
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Friday, February 12, 2016 10:43 PM
> >To: R, Durgadoss
> >Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, An
== Summary ==
Series 77v8 Kill off intel_crtc->atomic!
http://patchwork.freedesktop.org/api/1.0/series/77/revisions/8/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (skl-i5k-2)
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
On 15/02/16 14:24, Dave Gordon wrote:
On 12/02/16 16:31, Martin Peres wrote:
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/intel_device.c | 5 -
1 file changed, 4 insertions(+)
On Mon, 15 Feb 2016 14:20:46 +0100,
Gabriel Feceoru wrote:
>
>
>
> On 15.02.2016 14:57, Takashi Iwai wrote:
> > On Mon, 15 Feb 2016 13:57:00 +0100,
> > Gabriel Feceoru wrote:
> >>
> >>
> >>
> >> On 15.02.2016 12:23, Takashi Iwai wrote:
> >>> On Fri, 12 Feb 2016 17:47:21 +0100,
> >>> Gabriel Fece
On 11/02/16 13:36, Chris Wilson wrote:
On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote:
From: Nick Hoath
Swap the order of context & engine cleanup, so that contexts are cleaned
up first, and *then* engines. This is a m
On Mon, Feb 15, 2016 at 12:24:04PM +, Dave Gordon wrote:
> On 12/02/16 16:31, Martin Peres wrote:
> >This is not a big issue to return -1 since the only codepath that uses
> >it is for display purposes.
> >
> >Caught by Klockwork.
> >
> >Signed-off-by: Martin Peres
> >---
> > src/intel_device
On 15/02/16 13:40, Martin Peres wrote:
On 15/02/16 14:24, Dave Gordon wrote:
On 12/02/16 16:31, Martin Peres wrote:
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/intel_device.c | 5
== Summary ==
Series 2906v2 Capture more useful details in error state
http://patchwork.freedesktop.org/api/1.0/series/2906/revisions/2/mbox/
Test gem_sync:
Subgroup basic-bsd:
pass -> DMESG-FAIL (hsw-brixbox)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
Imre Deak writes:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference f
== Summary ==
Series 3243v1 drm/i915: Fix hpd live status bits for g4x
http://patchwork.freedesktop.org/api/1.0/series/3243/revisions/1/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgro
On 15/02/16 13:43, David Weinehall wrote:
On Mon, Feb 15, 2016 at 12:24:04PM +, Dave Gordon wrote:
On 12/02/16 16:31, Martin Peres wrote:
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Martin Peres
--
On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote:
> Instead of implementing a custom locked reference counting, use lockref.
>
> Current implementation leads to a deadlock splat on Intel SKL platforms
> when lockdep debugging is enabled.
>
> This is due to few of CPUfreq drivers (i
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold
== Summary ==
Series 3265v1 CRTC background color support for i915
http://patchwork.freedesktop.org/api/1.0/series/3265/revisions/1/mbox/
Test gem_sync:
Subgroup basic-default:
pass -> DMESG-FAIL (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup suspend-read-cr
Hi Maarten,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.5-rc4 next-20160215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/drm-atomic-Allow-for
Op 12-02-16 om 14:56 schreef Zanoni, Paulo R:
> Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
>> Factor out intel_fbc_supports_rotation
> ^ not anymore
>
>
>> and use it in
>> pre_plane_update as well. This leaves intel_crtc->atomic
>> empty, so remove it too.
>>
>> Changes since
== Summary ==
Series 3276v1 drm/i915/gen9: Check for DC state mismatch
http://patchwork.freedesktop.org/api/1.0/series/3276/revisions/1/mbox/
Test drv_module_reload_basic:
pass -> DMESG-WARN (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-small-copy:
On 12/02/16 13:03, Tvrtko Ursulin wrote:
On 11/02/16 23:09, yu@intel.com wrote:
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the kmap of its first page, which includes guc_process_desc and
doorbell. By doing so, we can simplify the code where we read f
On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> 13.02.2016 01:23, Ville Syrjälä wrote:
> > - Do you have another monitor to try?
> > - Do you have another cable to try?
>
> More on this.
>
> Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working
> Computer DV
== Summary ==
Series 3277v1 Assorted reviewed patches for CI run
http://patchwork.freedesktop.org/api/1.0/series/3277/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass -> DMESG-WARN (skl-i5k-2)
Subgroup suspend-read-crc-pipe-b:
On 10/02/16 20:31, Yu Dai wrote:
On 02/10/2016 09:30 AM, Tvrtko Ursulin wrote:
Hi,
On 10/02/16 00:05, yu@intel.com wrote:
> From: Alex Dai
>
> The cached work queue header pointer is set to last byte of work
> queue buffer. It will make sure the whole work queue buffer is
> available aft
== Summary ==
Series 3278v1 drm/i915/guc: Keep the previous context pinned until the next one
has been completed
http://patchwork.freedesktop.org/api/1.0/series/3278/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass -> INCOMPLETE (hsw
== Summary ==
Series 3292v1 drm/i915: Add missing 'else' to intel_digital_port_connected()
http://patchwork.freedesktop.org/api/1.0/series/3292/revisions/1/mbox/
Test gem_mmap_gtt:
Subgroup basic-small-copy-xy:
pass -> DMESG-FAIL (ilk-hp8440p)
Test kms_pipe_crc_basic
On 12/02/16 13:03, Tvrtko Ursulin wrote:
On 11/02/16 23:09, yu@intel.com wrote:
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the kmap of its first page, which includes guc_process_desc and
doorbell. By doing so, we can simplify the code where we read f
On Mon, Feb 15, 2016 at 04:42:35PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> > 13.02.2016 01:23, Ville Syrjälä wrote:
> > > - Do you have another monitor to try?
> > > - Do you have another cable to try?
> >
> > More on this.
> >
> > Comp
On 15/02/16 15:47, Dave Gordon wrote:
On 15/02/16 13:40, Martin Peres wrote:
On 15/02/16 14:24, Dave Gordon wrote:
On 12/02/16 16:31, Martin Peres wrote:
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Mar
Hi Daniel:
Thanks for shedding the light! See my comments below. :)
-Original Message-
From: Vetter, Daniel
Sent: Monday, February 15, 2016 5:32 PM
To: Wang, Zhi A; Joonas Lahtinen; Chris Wilson; Lv, Zhiyuan; Tian, Kevin
Subject: Re: Discuss GVT context hacks in i915
Am 15/02/2016
On 15/02/16 14:53, Patchwork wrote:
== Summary ==
Series 3277v1 Assorted reviewed patches for CI run
http://patchwork.freedesktop.org/api/1.0/series/3277/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass -> DMESG-WARN (skl-i5k-2)
On Thu, Feb 11, 2016 at 10:13:30AM +, Chris Wilson wrote:
> On Tue, Feb 02, 2016 at 02:46:19PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > VMA creation and GEM list management need the big lock.
> >
> > v2:
> >
> > Mutex unlock ended on the wrong path somehow. (0-day, Juli
On Wed, Feb 03, 2016 at 02:59:11PM +0200, Mika Kahola wrote:
> On Wed, 2016-02-03 at 11:28 +0200, Jani Nikula wrote:
> > On Tue, 02 Feb 2016, Ramalingam C wrote:
> > > We need to enable DSI PLL before configuring the DSI registers.
> > >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > drivers/
On Tue, Feb 02, 2016 at 11:24:16PM +0530, Ramalingam C wrote:
> From: Uma Shankar
>
> During Charging OS mode, mipi display was blanking.This is
> because during driver load, though encoder, connector were
> active but crtc returned inactive. This caused sanitize
> function to disable the DSI pan
On Wed, Feb 03, 2016 at 11:44:03AM +0200, Jani Nikula wrote:
> On Tue, 02 Feb 2016, Ramalingam C wrote:
> > From: Uma Shankar
> >
> > During Charging OS mode, mipi display was blanking.This is
> > because during driver load, though encoder, connector were
> > active but crtc returned inactive. Th
On Fri, Feb 05, 2016 at 03:58:31PM +0100, Lukas Wunner wrote:
> Hi Chris,
>
> On Fri, Feb 05, 2016 at 11:09:27AM +, Chris Wilson wrote:
> > On Fri, Feb 05, 2016 at 01:27:10AM +0100, Lukas Wunner wrote:
> > > On Thu, Feb 04, 2016 at 09:21:17AM +, Li, Weinan Z wrote:
> > > > We still need th
On Thu, Feb 04, 2016 at 10:41:33AM +0200, Jani Nikula wrote:
> On Thu, 04 Feb 2016, Matt Roper wrote:
> > On Thu, Feb 04, 2016 at 07:17:08AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >>
> >> On 2/4/2016 6:19 AM, Matt Roper wrote:
> >> >From: Bob Paauwe
> >> >
> >> >Broxton has some additional
On Fri, Feb 05, 2016 at 06:51:53AM +0530, Thulasimani, Sivakumar wrote:
> not sure how this can be pushed separately even if approved at present.
> why not push this as part of new patch set of the RC patches ?
Yes, please don't send around patches which need depencies. Instead squash
them into th
On Thu, Feb 04, 2016 at 06:36:22PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 04, 2016 at 06:21:23PM +0200, Jani Nikula wrote:
> > On Thu, 04 Feb 2016, Ville Syrjälä wrote:
> > > On Thu, Feb 04, 2016 at 12:50:51PM +0200, Jani Nikula wrote:
> > >> From: vkorjani
> > >>
> > >> New sequence element
On Mon, Feb 15, 2016 at 03:21:54PM -, Patchwork wrote:
> == Summary ==
>
> Series 3292v1 drm/i915: Add missing 'else' to intel_digital_port_connected()
> http://patchwork.freedesktop.org/api/1.0/series/3292/revisions/1/mbox/
>
> Test gem_mmap_gtt:
> Subgroup basic-small-copy-xy:
>
On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
> Added extended wildcard support when specifying --run-subtest.
>
> Wildcard format is as specified in rfc3977 and the uwildmat() implementation
> is taken from libinn.
> See https://tools.ietf.org/html/rfc3977#section-4 for a descript
On Thu, Feb 04, 2016 at 04:25:41PM +0200, Marius Vlad wrote:
> suspend-read-crc-pipe will perform a suspend and then skip the test in case
> the
> pipe is not present on the platform. Skip the test before doing the suspend.
>
>
> Signed-off-by: Marius Vlad
> ---
> tests/kms_pipe_crc_basic.c |
On Fri, Feb 05, 2016 at 04:45:59PM +, Chris Wilson wrote:
> Unknown parameters, especially structure padding, are expected to invoke
> rejection with -EINVAL.
>
> v2: similar issue exists for context-create
>
> Testcase: igt/gem_ctx_create/invalid-pad
> Testcase: igt/gem_ctx_bad_destroy/inval
On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote:
> > Instead of implementing a custom locked reference counting, use lockref.
> >
> > Current implementation leads to a deadlock splat on Intel SKL platforms
> > when l
On Mon, Feb 08, 2016 at 05:08:03PM +0200, Jani Nikula wrote:
> On Mon, 08 Feb 2016, Imre Deak wrote:
> >> > Thanks for the patch, I pushed it to -dinq.
> >>
> >> The rule is, we should wait for the CI results before pushing.
> >
> > Yes, I forgot to wait for the result for this version of the pat
The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.
We might likewise receive hotplug events or be suspended before
we've had a chance to fully set up the fbdev.
Fix by waiting for the asynchronous threa
Originally submitted inline with <20160205145831.ga14...@wunner.de>,
hereby resubmitted standalone for CI as requested by Daniel with
<20160215163251.GR11240@phenom.ffwll.local>.
Above-mentioned message contained the following important note:
> However AFAICT a corner case remains where we're sti
On Fri, Feb 12, 2016 at 08:26:27AM +0200, Jani Nikula wrote:
> On Thu, 11 Feb 2016, Daniel Vetter wrote:
> > On Wed, Feb 10, 2016 at 07:59:05PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> Looks like g4x hpd live status bits actually agree with the spec. At
On Mon, Feb 15, 2016 at 06:52:52PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 15, 2016 at 03:21:54PM -, Patchwork wrote:
> > == Summary ==
> >
> > Series 3292v1 drm/i915: Add missing 'else' to intel_digital_port_connected()
> > http://patchwork.freedesktop.org/api/1.0/series/3292/revisions/1/mb
On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote:
> > Instead of implementing a custom locked reference counting, use lockref.
> >
> > Current implementation leads to a deadlock splat on Intel SKL platforms
> > when l
On Mon, Feb 15, 2016 at 04:03:49PM +, Wang, Zhi A wrote:
> Hi Daniel:
> Thanks for shedding the light! See my comments below. :)
>
> -Original Message-
> From: Vetter, Daniel
> Sent: Monday, February 15, 2016 5:32 PM
> To: Wang, Zhi A; Joonas Lahtinen; Chris Wilson; Lv, Zhiyuan;
On Wed, Feb 10, 2016 at 07:14:36AM -, Patchwork wrote:
> == Summary ==
>
> Series 3145v2 drm/i915: Check for get_pages instead of shmem (filp)
> http://patchwork.freedesktop.org/api/1.0/series/3145/revisions/2/mbox/
>
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> fai
On Wed, Feb 10, 2016 at 09:39:33AM -0800, Ben Widawsky wrote:
> On Wed, Feb 10, 2016 at 04:23:08PM +, Chris Wilson wrote:
> > On Wed, Feb 10, 2016 at 07:42:23AM -0800, Ben Widawsky wrote:
> > > Do you guys get the CI mails? This version has regressions. v1 did not. I
> > > don't
> > > know wha
On 10/02/16 17:39, Ben Widawsky wrote:
On Wed, Feb 10, 2016 at 04:23:08PM +, Chris Wilson wrote:
On Wed, Feb 10, 2016 at 07:42:23AM -0800, Ben Widawsky wrote:
Do you guys get the CI mails? This version has regressions. v1 did not. I don't
know what to trust.
I didn't even see v2 itself!
On 15/02/16 16:55, Daniel Vetter wrote:
On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
Added extended wildcard support when specifying --run-subtest.
Wildcard format is as specified in rfc3977 and the uwildmat() implementation
is taken from libinn.
See https://tools.ietf.org/html
Hello,
Since upgrading to the Fedora 4.3 kernel package, the picture on my the
BenQ M2700 HD monitor I've got connected to my HP EliteBook Folio 9470m
laptop began having issues. The monitor is connected with a DP+-to-HDMI
cable (HDMI in the monitor end), and the resolution I'm using is
1920x1080.
On Mon, Feb 15, 2016 at 08:17:23PM +0100, Tore Anderson wrote:
> Hello,
>
> Since upgrading to the Fedora 4.3 kernel package, the picture on my the
> BenQ M2700 HD monitor I've got connected to my HP EliteBook Folio 9470m
> laptop began having issues. The monitor is connected with a DP+-to-HDMI
>
From: Ville Syrjälä
The size of the rotated ggtt mapping ought to include the size of the
chroma plane as well. Not a huge deal since we don't expose NV12 (or any
pother planar format for that matter) yet.
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Fixes: 9e759ff1f4a0 ("drm/i915: Return correct si
From: Ville Syrjälä
Throw out a bunch of unnecessary stuff from struct intel_rotation_info,
and pull most of the remaining stuff to live under an array of
per-color plane sub-structures.
What still remains outside the sub-structure will be reorgranized later
as well, but that requires more work
From: Ville Syrjälä
SKL+ needs >4K alignment for tiled surfaces, so make
intel_compute_page_offset() handle it.
The way we do it is first we compute the closest tile boundary
as before, and then figure out how many tiles we need to go
to reach the desired alignment. The difference in the offset
From: Ville Syrjälä
Make if clear whether we're talking tile widths in bytes or in pixels.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dis
From: Ville Syrjälä
The page aligned surface address calculation needs to know which way
things are rotated. The contract now says that the caller must pass the
rotate x/y coordinates, as well as the tile_height aligned stride in
the tile_height direction. This will make it fairly simple to deal
From: Ville Syrjälä
intel_compute_page_offset() can dig up the correct pitch from the fb
itself, no need for the caller to pass it in.
A bit of extra care is needed for the lower level
_intel_compute_page_offset() since that one gets called before the
rotated pitch under intel_fb is populated. N
From: Ville Syrjälä
Redo the fb rotation handling in order to:
- eliminate the NV12 special casing
- handle fb->offsets[] properly
- make the rotation handling reasier for the plane code
To achieve these goals we reduce intel_rotation_info to only contain
(for each plane) the rotated view width,
From: Ville Syrjälä
We repeat the SKL stride register value calculations a several places.
Move it into a small helper function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 52 +---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
driver
From: Ville Syrjälä
Another iteration of the fb offset stuff. Unfortunately this seems
to be one of those things that just keeps on growing when you're
not looking. But I'm hoping we're starting to approach the limit.
Changes from the last time [1]:
* split the chrome plane vma size fix from one
From: Ville Syrjälä
Soon the fence tiling mode may not always match the fb modifier
even for X tiled buffers. So let's use the fb modifier
consistently for all display tiling decisions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 33 ++---
From: Ville Syrjälä
intel_pin_and_fence_fb_obj() only needs the framebuffer, and the desird
rotation (to find the right GTT view for it), so no need to pass all
kinds of plane stuff.
The main motivation is to get rid of the uggy NULL plane_state handling
due to fbdev.
v2: Add a note why I reall
From: Ville Syrjälä
Instead of repopulatin the rotation_info struct for the fb every time
we try to use the fb, we can just populate it once when creating the fb,
and later we can just copy the pre-populate struct into the gtt_view.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
From: Ville Syrjälä
If there's a fence on the object it will be aligned to the start
of the object, and hence CPU rendering to any fb that straddles
the fence edge will come out wrong due to lines wrapping at the
wrong place.
We have no API to manage fences on a sub-object level, so we can't
rea
From: Ville Syrjälä
rotate_pages() checks to see if it got called with a NULL sg, and then
goes to extract it from sg->sgl. It always gets called with a NULL sg
for the first plane, so moving the initial 'sg=st->sgl' assignment out
into intel_rotate_fb_obj_pages() seems less special-casey.
Signe
From: Ville Syrjälä
intel_compute_page_offsets() gets passed a bunch of the framebuffer
metadate sepearately. Just pass the framebuffer itself to make life
simpler for the caller, and make it less likely they would make a
mistake in the order of the arguments (as most as just unsigned ints and
su
From: Ville Syrjälä
SKL has nasty limitations with the display surface offsets:
* source x offset + width must be less than the stride for X tiled
surfaces or the display engine falls over
* the surface offset requires lots of alignment (256K or 1M)
These facts mean that we can't just pick any
From: Ville Syrjälä
Currently we requite the object to be X tiled if the fb is X
tiled. The argument is supposedly FBC GTT tracking. But
actually that no longer holds water since FBC supports
Y tiling as well on SKL+.
A better rule IMO is to require that if there is a fence, the
fb modifier matc
From: Ville Syrjälä
We convert the fb->offsets[] into x/y offsets, so they must be
(macro)pixel aligned. Check for this, and if things look good
allow fb->offsets[] != 0 when creating fbs since we now handle
them correctly.
v2: Move to last place in the series and improve the commit message
Sig
From: Ville Syrjälä
With NV12 we have two color planes to deal with so we must compute the
surface and x/y offsets for the second plane as well.
What makes this a bit nasty is that the hardware expects the surface
offset to be specified as a distance from the main surface offset.
What's worse, t
From: Ville Syrjälä
intel_compute_tile_offset() and intel_add_fb_offsets() get passed the fb
and the rotation. As both of those come from the plane state we can just
pass that in instead.
For extra consitency pass the plane state to intel_fb_xy_to_linear() as
well even though it only really need
From: Ville Syrjälä
To make life less surprising we can make intel_adjust_tile_offset()
deal with linear buffers as well. Currently it doesn't seem like there's
a real need for this since only X tiling and NV12 (which would always
be tiled currently) should need it. But I've used it for some debu
From: Ville Syrjälä
Minimize the resulting X coordinate after intel_adjust_tile_offset() is
done with it's offset adjustment. This allows calling
intel_adjust_tile_offset() multiple times in case we need to adjust
the offset several times.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/
On Mon, Feb 15, 2016 at 02:11:24PM +0800, Zhi Wang wrote:
> From SKL, i915 will try to load DMC firmware when system is starting up. You
> can find it from 01.org. Personally, it looks without the firmware, the
> system is also able to work, except a lot warnings. :)
We pretty much require dmc, si
* Ville Syrjälä
> Could you test the following hack while using a 1920x1080 mode with
> 148.5 MHz dotclock, and see if there's any improvement?
I think it might be an improvement, that is, the blanking/flickers
seems to occur less often than it did with 8ed1804, but it is not
completely fixed. I'
1 - 100 of 121 matches
Mail list logo
