On 27/03/2014 18:00, oscar.ma...@intel.com wrote:
From: Thomas Daniel
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to s
On Mon, Apr 21, 2014 at 01:34:14PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> On CHV, All the freq request should be even. S0, we need to make sure we
> request the opcode accordingly.
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 +
> drivers
On Mon, Apr 21, 2014 at 01:34:13PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Signed-off-by: Deepak S
> [vsyrjala: Fix merge fubmle where the code ended up in
> g4x_disable_trickle_feed() instead of cherryview_init_clock_gating()]
> Signed-off-by: Ville Syrjälä
> ---
> drivers
On Mon, Apr 21, 2014 at 01:34:12PM +0530, deepa...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CHV uses the gen8 shadow register mechanism so we shouldn't be
> checking the GT FIFO status.
>
> This effectively removes the posting read, so add an explicit
> posting read using FORCEWAKE_ACK_V
On Mon, Apr 21, 2014 at 01:34:10PM +0530, deepa...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Streamline the CHV forcewake functions just like was done for VLV.
>
> This will also fix a bug in accessing the common well registers,
> where we'd end up trying to wake up the wells too many tim
s/Cheeryview/Cherryview
On Mon, Apr 21, 2014 at 01:34:09PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> v2: Disable media turbo and Add DOWN_IDLE_AVG support (Ville)
>
> v3: Mass rename of the dev_priv->rps variables in upstream.
>
> Signed-off-by: Deepak S
> Signed-off-by: Dan
On Mon, Apr 21, 2014 at 01:34:08PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Support to individually control Media/Render well based on the register
> access.
> Add CHV specific write function to habdle difference between registers
> that are sadowed vs those that need forcewak
Also, s/Cheeryview/Cherryview
On Fri, Apr 25, 2014 at 02:42:26PM -0700, Ben Widawsky wrote:
> On Mon, Apr 21, 2014 at 01:34:07PM +0530, deepa...@linux.intel.com wrote:
> > From: Deepak S
> >
> > v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
> >
> > v3: Fix PCBR condition check during
On Mon, Apr 21, 2014 at 01:34:07PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
>
> v3: Fix PCBR condition check during CHV RC6 Enable flag set
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
>
On Mon, Apr 21, 2014 at 01:34:06PM +0530, deepa...@linux.intel.com wrote:
For backporters, putting drm/i915/bdw would be helpful.
> From: Deepak S
>
> In BDW, Apart from unmasking up/down threshold interrupts. we need
> to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
>
Thanks for the timely reply, Daniel.
The intention to bring debugfs for RPS boost and idle is when boost and
idle are disabled, we are able to have a clear vision of what normal
turbo algorithm.
It‘s very helpful to verify if the turbo algorithm is working as
expected, at least from the VPG va
On Mon, Apr 21, 2014 at 01:34:05PM +0530, deepa...@linux.intel.com wrote:
> From: Ben Widawsky
>
> Almost all of it is reusable from the existing code. The primary
> difference is we need to do even less in the interrupt handler, since
> interrupts are not shared in the same way.
>
> The patch i
2014-04-09 7:28 GMT-03:00 :
> From: Rafael Barbalho
>
> Cherryview also needs this WA.
At least on the chv_rebase tree, this WA is implemented for BDW but it
is not documented as pre-prod only, and its name is not there. We
should probably add a comment documenting the name and the fact that
it
2014-04-09 7:28 GMT-03:00 :
> From: Ville Syrjälä
>
> We implement the following workarounds:
> * WaDisableAsyncFlipPerfMode:chv
> * WaDisableSemaphoreAndSyncFlipWait:chv (at least partially)
In the rebased version (on your gitorious tree, chv_rebase branch),
the chunk for this WA got removed. I
On Fri, Apr 25, 2014 at 10:11:51PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have a struct_mutex deadlock during driver init on ILK
>
> [ 54.320273] =
> [ 54.320371] [ INFO: possible recursive locking detected ]
> [
On Fri, Apr 25, 2014 at 02:48:07PM -0300, Paulo Zanoni wrote:
> 2014-04-25 6:00 GMT-03:00 Jani Nikula :
> > On Fri, 25 Apr 2014, Daniel Vetter wrote:
> >> On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
> >>> From: Paulo Zanoni
> >>>
> >>> We still have way too many bugs with DP lin
From: Ville Syrjälä
We have a struct_mutex deadlock during driver init on ILK
[ 54.320273] =
[ 54.320371] [ INFO: possible recursive locking detected ]
[ 54.320471] 3.15.0-rc2-flip_race+ #2 Not tainted
[ 54.320567] -
From: Ville Syrjälä
assert_plane_enabled() is now triggering during FDI link train because
we no longer enable planes that early.
This problem got introduced in:
commit a5c4d7bc187bd13bc11ac06bb4ea3a0d4001aa4d
Author: Ville Syrjälä
Date: Fri Mar 7 18:32:13 2014 +0200
drm/i915: Disable
On Fri, Apr 25, 2014 at 11:37:18AM -0600, Bjorn Helgaas wrote:
> On Fri, Apr 25, 2014 at 11:35:21AM -0600, Bjorn Helgaas wrote:
> > [+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
> >
> > On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> > > After a CPU upgrade while keeping t
Poking around with those tracepoints, I don't see the i915 shrinker
getting run, only i915_gem_inactive_count() being called. It must be
returning 0 because we're never even _getting_ to the tracepoints
themselves after calling i915_gem_inactive_count().
This is on my laptop, and I haven't been a
2014-04-25 6:00 GMT-03:00 Jani Nikula :
> On Fri, 25 Apr 2014, Daniel Vetter wrote:
>> On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
>>> From: Paulo Zanoni
>>>
>>> We still have way too many bugs with DP link training. We keep
>>> switching between "narrow and fast" and "wide and
On Fri, Apr 25, 2014 at 7:14 PM, wrote:
> From: Ville Syrjälä
>
> Document the internal structure of the VLV display PHY a bit to help
> people understand how the different register blocks relate to each
> other.
>
> v2: Add a bit more text
> Make it a DOC: comment, but leave the ascii art o
On Fri, Apr 25, 2014 at 7:29 PM, Daisy Sun wrote:
> RP frequency request is affected by 2 modules: normal turbo
> algorithm and RPS boost algorithm. By adding RPS boost algorithm
> to the mix, the final frequency becomes relatively unpredictable.
> Add a switch to enable/disable RPS boost function
On Fri, Apr 25, 2014 at 11:35:21AM -0600, Bjorn Helgaas wrote:
> [+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
>
> On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> > After a CPU upgrade while keeping the same mainboard,
> > we faced "spurious interrupt" problems again.
> >
[+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> After a CPU upgrade while keeping the same mainboard,
> we faced "spurious interrupt" problems again.
>
> It turned out that the new CPU also featured a
> new GPU with a differen
RP frequency request is affected by 2 modules: normal turbo
algorithm and RPS boost algorithm. By adding RPS boost algorithm
to the mix, the final frequency becomes relatively unpredictable.
Add a switch to enable/disable RPS boost functionality. When
disabled, RP frequency will follow the normal t
On 04/25/2014 12:23 AM, Chris Wilson wrote:
> On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote:
>> On 04/24/2014 08:39 AM, Chris Wilson wrote:
>>> On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
Is it possible that there's still a get_page() reference that's holding
>>>
From: Ville Syrjälä
The comments in i915_reg.h aren't proper kernel-doc comments, so replace
the magic /** with just /*
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 246
1 file changed, 123 insertions(+), 123 deletions(-)
diff --g
From: Ville Syrjälä
The ascii art version of the DPIO diagram gets mangled by docbook, so
we can't use it there. Insted provide another version built using
.
Signed-off-by: Ville Syrjälä
---
Documentation/DocBook/drm.tmpl | 86 ++
1 file changed, 86 inse
From: Ville Syrjälä
Document the internal structure of the VLV display PHY a bit to help
people understand how the different register blocks relate to each
other.
v2: Add a bit more text
Make it a DOC: comment, but leave the ascii art out since
it would get mangled
Signed-off-by: Ville
On Fri, Apr 25, 2014 at 05:00:04PM +0200, Daniel Vetter wrote:
> Ville noticed that we have this nice kerneldoc but it's not integrated
> anywhere. Fix this asap!
>
> Cc: Ville Syrjälä
> Cc: Brad Volkin
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> Documentation/DocBook/
On Fri, Apr 25, 2014 at 05:28:00PM +0300, Imre Deak wrote:
> In recent dmesg logs reported for unrelated issues I noticed some power
> domain WARNs caused by the following.
>
> The workaround
>
> commit ce352550327b394f3072a07c9cd9d27af9276f15
> Author: Ville Syrjälä
> Date: Fri Sep 20 10:14:2
Also shut up warnings. Those revealed incorrect usage of local
variables in conjunction with igt_fixture/igt_subtest. Since those use
longjmps we need to move the out of the stackframe those magic blocks
are declared in.
Signed-off-by: Daniel Vetter
---
benchmarks/gem_userptr_benchmark.c | 12 ++
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
Minor formatting issue in this one, newline before ';'
And next one in series fixes it.
Patches 60 - 64
Reviewed-by: Mika Kuoppala
> All PCS groups access reads return 0x, so we can't use group
> access for RMW cycles. Instea
Ville noticed that we have this nice kerneldoc but it's not integrated
anywhere. Fix this asap!
Cc: Ville Syrjälä
Cc: Brad Volkin
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 5 +
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
2 files changed, 6 insertions(+),
From: Tim Gore
A static analysis of libdrm source code has identified several
potential bugs. This commit addresses the critical issues in
xf86drm.c, which are all possible null pointer dereferences.
NOTE: I have kept to the indenting style already used in this file,
which is a mixture of spaces
From: Tim Gore
A static analysis tool reported several "critical" issues in libdrm code.
This patchset addresses a subset of these in the xf86drm*** source files.
Most of these issues are potential null pointer dereferences and are
simply fixed by explicit null check.
Tim Gore (3):
libdrm: fix
From: Tim Gore
A static analysis of libdrm source code has identified several
potential bugs. This commit addresses the critical issues in
xf86drmHash.c, which are all potential null pointer dereferences.
NOTE: I have kept to the indenting style already used in this file,
which is a mixture of sp
From: Tim Gore
A static analysis of libdrm source code has identified several
potential bugs. This commit addresses the critical issues in
xf86drmSL.c, which are mostly potential null pointer dereferences.
NOTE: I have kept to the indenting style already used in this file,
which is a mixture of s
From: Tvrtko Ursulin
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized and synchronized userptr
From: Tvrtko Ursulin
No need for the old test case once the new one was added.
v2:
* Just rebase for lib/ reorganization.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Brad Volkin
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
tests/gem_vmap_blits.c | 345 ---
From: Tvrtko Ursulin
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers on common address space
operati
In recent dmesg logs reported for unrelated issues I noticed some power
domain WARNs caused by the following.
The workaround
commit ce352550327b394f3072a07c9cd9d27af9276f15
Author: Ville Syrjälä
Date: Fri Sep 20 10:14:23 2013 +0300
drm/i915: Fix unclaimed register access due to delayed VG
On Thu, Apr 24, 2014 at 09:20:35AM -0700, Volkin, Bradley D wrote:
> On Thu, Apr 24, 2014 at 02:22:39AM -0700, Chris Wilson wrote:
> > On Fri, Mar 28, 2014 at 03:58:25PM -0700, Volkin, Bradley D wrote:
> > > On Mon, Mar 17, 2014 at 05:21:55AM -0700, Chris Wilson wrote:
> > > > @@ -1949,58 +1956,58
On Tue, Mar 18, 2014 at 09:56:12AM +, Chris Wilson wrote:
> On Mon, Mar 17, 2014 at 06:08:57AM -0700, Michel Lespinasse wrote:
> > On Mon, Mar 17, 2014 at 5:31 AM, David Woodhouse
> > wrote:
> > > On Mon, 2014-03-17 at 12:21 +, Chris Wilson wrote:
> > >> +EXPORT_SYMBOL(interval_tree_inser
On Fri, Apr 25, 2014 at 04:10:10PM +0200, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 01:50:32PM +0100, arun.siluv...@linux.intel.com wrote:
> > +int main(int argc, char **argv)
> > +{
> > + igt_subtest_init(argc, argv);
> > +
> > + igt_fixture
> > + fd = drm_open_any();
> > +
> >
On Fri, Apr 25, 2014 at 01:50:32PM +0100, arun.siluv...@linux.intel.com wrote:
> +int main(int argc, char **argv)
> +{
> + igt_subtest_init(argc, argv);
> +
> + igt_fixture
> + fd = drm_open_any();
> +
> + igt_subtest("gem_falloc arguments validation")
> + test_g
On Fri, Apr 25, 2014 at 04:27:02PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 10, 2014 at 03:08:04PM +0300, Antti Koskipaa wrote:
> > This patch series enhances the cursor test to actually be useful.
> >
> > The old "black transparent cursor on black background" tests are
> > replaced with a visibl
On Mon, Apr 14, 2014 at 08:24:43PM +0300, Imre Deak wrote:
> I've seen latencies up to 15msec, so increase the timeout to 20msec.
>
> Signed-off-by: Imre Deak
Merged up to this patch here, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
On Fri, Apr 25, 2014 at 4:01 PM, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 3:32 PM, wrote:
>> From: Ville Syrjälä
>>
>> Document the internal structure of the VLV display PHY a bit to help
>> people understand how the different register blocks relate to each
>> other.
>>
>> Signed-off-by:
On Fri, Apr 25, 2014 at 3:32 PM, wrote:
> From: Ville Syrjälä
>
> Document the internal structure of the VLV display PHY a bit to help
> people understand how the different register blocks relate to each
> other.
>
> Signed-off-by: Ville Syrjälä
Can you please make this into a kerneldoc DOC: c
From: Ville Syrjälä
Document the internal structure of the VLV display PHY a bit to help
people understand how the different register blocks relate to each
other.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 40 +++-
1 file changed, 39
On Thu, Apr 10, 2014 at 03:08:04PM +0300, Antti Koskipaa wrote:
> This patch series enhances the cursor test to actually be useful.
>
> The old "black transparent cursor on black background" tests are
> replaced with a visible cursor and the framework is changed to
> be more flexible and extendabl
On Thu, 24 Apr 2014, Jani Nikula wrote:
> On Wed, 23 Apr 2014, Daniel Vetter wrote:
>> On Wed, Apr 23, 2014 at 11:37:46AM +0300, Jani Nikula wrote:
>>> On Tue, 22 Apr 2014, Daniel Vetter wrote:
>>> > Otherwise we'll end up spamming dmesg on every context creation on snb
>>> > with vt-d enabled.
On Fri, 25 Apr 2014, Jani Nikula wrote:
> On Fri, 25 Apr 2014, Jani Nikula wrote:
>> Daniel Vetter (3):
>> drm/i915: Sanitize the enable_ppgtt module option once
>
> Aww crap, our QA spotted a show stopper bug in this one, and I missed
> the bug report [1]. My bad, although I can't disagree
On Fri, 25 Apr 2014, Jani Nikula wrote:
> Daniel Vetter (3):
> drm/i915: Sanitize the enable_ppgtt module option once
Aww crap, our QA spotted a show stopper bug in this one, and I missed
the bug report [1]. My bad, although I can't disagree with Chris'
assessment in comment #1 of the bug.
From: "Siluvery, Arun"
This ioctl allows vary the effective size of the gem object.
User can mark certain range in object space as scratch thus
effectively modifying the size used.
Signed-off-by: Siluvery, Arun
---
tests/Makefile.sources | 1 +
tests/gem_bo_falloc.c | 469 ++
From: "Siluvery, Arun"
This patch adds support to have gem objects of variable size.
The size of the gem object obj->size is always constant and this fact
is tightly coupled in the driver; this implementation allows to vary
its effective size using an interface similar to fallocate().
A new ioct
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> Setup the pipe config dpll state correctly for CHV. Also add
> a assert_pipe_disabled() to chv_disable_pll(), and program the
> DPLL_MD registers in chv_enable_pll().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kuoppala
>
On Fri, 25 Apr 2014, Pavel Machek wrote:
>> On Thu, Apr 24, 2014 at 09:40:38PM +0200, Pavel Machek wrote:
>> > Hi!
>> >
>> > > And if you can indeed reliably reproduce this a bisect could be really
>> > > useful.
>> >
>> > And we have a winner here :-)
>> >
>> > Ok, it was not as painfull as I
On Fri, 25 Apr 2014, Egbert Eich wrote:
> Depending on the SDVO output_flags SDVO may have multiple connectors
> linking to the same encoder (in intel_connector->encoder->base).
> Only one of those connectors should be active (ie link to the encoder
> thru drm_connector->encoder).
> If intel_conne
Hi Dave, a batch of Intel fixes for 3.15.
BR,
Jani.
The following changes since commit a798c10faf62a505d24e5f6213fbaf904a39623f:
Linux 3.15-rc2 (2014-04-20 11:08:50 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-04-25
for
On 4/25/2014 2:58 PM, Chris Wilson wrote:
On Fri, Apr 25, 2014 at 11:12:06AM +0200, Daniel Vetter wrote:
On Fri, Apr 25, 2014 at 01:54:06PM +0530, Kumar, Shobhit wrote:
On 4/25/2014 1:32 PM, Daniel Vetter wrote:
I will then push a new patch on version check.
I've figured Chris could do it, bu
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Friday, April 25, 2014 10:19 AM
> To: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: add i915.dp_
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/i915_params.c | 8
> drivers/gpu/drm/i915/intel_dp.c| 39
> ++
> 3 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/driver
On Fri, 25 Apr 2014, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 12:00:34PM +0300, Jani Nikula wrote:
>> On Fri, 25 Apr 2014, Daniel Vetter wrote:
>> > On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> We still have way too many bugs with DP l
On Fri, Apr 25, 2014 at 12:19 PM, Chris Wilson wrote:
> On Fri, Apr 25, 2014 at 12:07:48PM +0200, Daniel Vetter wrote:
>> On Fri, Apr 25, 2014 at 10:24:45AM +0100, Chris Wilson wrote:
>> > On Fri, Apr 25, 2014 at 11:04:22AM +0200, Daniel Vetter wrote:
>> > > > Patch drm/i915: Upgrade execbuffe
From: Ville Syrjälä
Now that we've plugged the mmio vs. ring flip race, we shouldn't need
these vblank waits in the modeset codepaths anymore. So get rid of
them.
v2: gen2 needs to wait for planes to turn off before disabling pipe
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_di
On Fri, Apr 25, 2014 at 12:07:48PM +0200, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 10:24:45AM +0100, Chris Wilson wrote:
> > On Fri, Apr 25, 2014 at 11:04:22AM +0200, Daniel Vetter wrote:
> > > > Patch drm/i915: Upgrade execbuffer fail after resume failure to EIO
> > > > - Reviewer:
> >
During the initial power well enabling on the driver init/resume path
we can avoid initialzing part of the HW/SW state that will be
initialized anyway by the subsequent init/resume code. For some steps
like HPD initialization this redundancy is not only an overhead but an
actual problem, since they
For 50-58, with Jani's coding style fix:
Reviewed-by: Antti Koskipää
--
- Antti
On 04/09/2014 01:28 PM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 9
On Fri, Apr 25, 2014 at 10:24:45AM +0100, Chris Wilson wrote:
> On Fri, Apr 25, 2014 at 11:04:22AM +0200, Daniel Vetter wrote:
> > > Patch drm/i915: Upgrade execbuffer fail after resume failure to EIO -
> > > Reviewer:
> >
> > Do we still need this on top of what I've merged. Chris?
>
> Yes.
On Fri, Apr 25, 2014 at 11:12:06AM +0200, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 01:54:06PM +0530, Kumar, Shobhit wrote:
> > On 4/25/2014 1:32 PM, Daniel Vetter wrote:
> > I will then push a new patch on version check.
>
> I've figured Chris could do it, but if you can take this over I don
On Fri, Apr 25, 2014 at 11:04:22AM +0200, Daniel Vetter wrote:
> > Patch drm/i915: Upgrade execbuffer fail after resume failure to EIO -
> > Reviewer:
>
> Do we still need this on top of what I've merged. Chris?
Yes. We can still start the device without initializing all of the
available rin
On Fri, Apr 25, 2014 at 12:00:34PM +0300, Jani Nikula wrote:
> On Fri, 25 Apr 2014, Daniel Vetter wrote:
> > On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> We still have way too many bugs with DP link training. We keep
> >> switching between "narr
On Fri, Apr 25, 2014 at 01:54:06PM +0530, Kumar, Shobhit wrote:
> On 4/25/2014 1:32 PM, Daniel Vetter wrote:
> >On Thu, Apr 24, 2014 at 09:22:23PM +0530, Kumar, Shobhit wrote:
> >>On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
> >>>From: Chris Wilson
> >>>
> >>>Be we read and chase pointers from the VB
On Fri, Apr 25, 2014 at 11:14:26AM +0300, Imre Deak wrote:
> On Fri, 2014-04-25 at 09:59 +0200, Daniel Vetter wrote:
> > On Mon, Apr 14, 2014 at 08:24:29PM +0300, Imre Deak wrote:
> > > At least on VLV but probably on other platforms too we depend on RC6
> > > being enabled for RPM, so disable RPM
Review assignments and drop suggestions below. Reviewers please
complain if you can't do it in a timely fashion. Rodrigo: Can you
please add an overall -collector item with the names of these people
to the review board so that mangers can track this? Maybe discuss the
overall approach with Paul fir
On Fri, 25 Apr 2014, Daniel Vetter wrote:
> On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> We still have way too many bugs with DP link training. We keep
>> switching between "narrow and fast" and "wide and slow", we recently
>> added 5GHz support, and
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector->encoder->base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector->encoder).
If intel_connector_break_all_links() is called from intel_sanitiz
Ok, review assignements. Please complain if you don't have the
bandwidth so that I can find someone else.
On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter wrote:
>
> Daniel Vetter (66):
> drm/i915: Make encoder->mode_set callbacks optional
> drm/i915/dvo: Remove ->mode_set callback
> drm/i91
On 4/25/2014 1:32 PM, Daniel Vetter wrote:
On Thu, Apr 24, 2014 at 09:22:23PM +0530, Kumar, Shobhit wrote:
On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
From: Chris Wilson
Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MM
On Fri, 2014-04-25 at 09:59 +0200, Daniel Vetter wrote:
> On Mon, Apr 14, 2014 at 08:24:29PM +0300, Imre Deak wrote:
> > At least on VLV but probably on other platforms too we depend on RC6
> > being enabled for RPM, so disable RPM until the delayed RC6 enabling
> > completes.
> >
> > v2:
> > - ex
On Fri, Apr 25, 2014 at 10:06 AM, Daniel Vetter wrote:
> On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> We still have way too many bugs with DP link training. We keep
>> switching between "narrow and fast" and "wide and slow", we recently
>> added 5GHz s
On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote:
> The PC8 state won't be entered unless runtime PM is enabled, so support
> for PC8 residency counters alone is not enough to run this test.
>
> Signed-off-by: Imre Deak
Reviewed-by: Daniel Vetter
> ---
> tests/pm_pc8.c | 2 +-
> 1 fi
On Thu, Apr 24, 2014 at 06:22:59PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We still have way too many bugs with DP link training. We keep
> switching between "narrow and fast" and "wide and slow", we recently
> added 5GHz support, and whenever there's a bug report, we have to ask
> pe
On Thu, Apr 24, 2014 at 09:23:24PM +0530, Kumar, Shobhit wrote:
> On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
> >From: Chris Wilson
> >
> >Make sure that the whole BDB section is within the MMIO region prior to
> >accessing it contents. That we don't read outside of the secion is left
> >up to the i
On Thu, Apr 24, 2014 at 09:22:23PM +0530, Kumar, Shobhit wrote:
> On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
> >From: Chris Wilson
> >
> >Be we read and chase pointers from the VBT, it is prudent to make sure
> >that those accesses are wholly contained within the MMIO region, or else
> >we may caus
On Mon, Apr 14, 2014 at 08:24:29PM +0300, Imre Deak wrote:
> At least on VLV but probably on other platforms too we depend on RC6
> being enabled for RPM, so disable RPM until the delayed RC6 enabling
> completes.
>
> v2:
> - explain the reason for the _noresume version of RPM get (Daniel)
> - use
On Wed, Apr 23, 2014 at 10:52:10AM +0300, Imre Deak wrote:
> On Wed, 2014-04-23 at 09:07 +0200, Daniel Vetter wrote:
> > On Wed, Apr 23, 2014 at 01:13:40AM +0300, Imre Deak wrote:
> > > Atm we can end up in the GPU reset deferred work in D3 state if the last
> > > runtime PM reference is dropped be
On Mon, Apr 14, 2014 at 08:24:29PM +0300, Imre Deak wrote:
> At least on VLV but probably on other platforms too we depend on RC6
> being enabled for RPM, so disable RPM until the delayed RC6 enabling
> completes.
>
> v2:
> - explain the reason for the _noresume version of RPM get (Daniel)
> - use
Hi Dave,
Figured I might as well flush out my queue of random drm patches while I
throw drm-next pull requests at you ;-)
Mostly just polish for Matt Roper's primary planes work (nothing for
-fixes, that patch is already in Thierry's tree), plus two other things.
All nicely reviewed and also test
The PC8 state won't be entered unless runtime PM is enabled, so support
for PC8 residency counters alone is not enough to run this test.
Signed-off-by: Imre Deak
---
tests/pm_pc8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/pm_pc8.c b/tests/pm_pc8.c
index 010af44..
On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote:
> On 04/24/2014 08:39 AM, Chris Wilson wrote:
> > On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
> >> Is it possible that there's still a get_page() reference that's holding
> >> those pages in place from the graphics code?
On Fri, 25 Apr 2014, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Even if the panel claims it can support 4 lanes, there's the
> possibility that the HW can't, so consider this while selecting the
> max lane count.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_dp.c | 20 +++
95 matches
Mail list logo
