From: Sourab Gupta
Using MMIO based flips on Gen5+ for Media power well residency optimization.
The blitter ring is currently being used just for command streamer based
flip calls. For pure 3D workloads, with MMIO flips, there will be no use
of blitter ring and this will ensure the 100% residency
What I understood from the reviews comments from the experts, is having
a central color management at DRM kernel layer is not a good idea, and
we should create individual DRM properties for the color correction
methods, and let the control be there in the user space level, where an
atomic modes
On 15.05.2014 03:51, Daniel Vetter wrote:
> @@ -964,8 +1005,13 @@ EXPORT_SYMBOL(drm_vblank_off);
>
> /**
> * drm_vblank_on - enable vblank events on a CRTC
> - * @dev: DRM device
> + * @dev: drm device
> * @crtc: CRTC in question
> + *
> + * This functions restores the vblank interrupt state
On 5/15/2014 6:05 AM, Jon Pry wrote:
Do you know if the DSI patch set is being maintained? I noticed it is
not integrated into drm-intel-next, the patches don't apply cleanly to
anything, and there has been no activity in about a month on them.
The basic DSI sequence is merged already and the
On 15.05.2014 03:51, Daniel Vetter wrote:
> Leftover from the old days of ums and should be used any longer. Since
>
> commit 29935554b384b1b3a7377d6f0b03b21d18a61683
> Author: Laurent Pinchart
> Date: Wed May 30 00:58:09 2012 +0200
>
> drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
>
On 2014-04-19 22:19 (GMT-0400) Felix Miata composed:
Has no one opened a freedesktop.org bug for this? I couldn't find one for
i810 changed more recently than 18 months ago.
I have an openSUSE i810E rev03 test system with 1.16.0 RC 2. Newest changelog
entry 08 April. Last intel driver 2.99.91
Do you know if the DSI patch set is being maintained? I noticed it is
not integrated into drm-intel-next, the patches don't apply cleanly to
anything, and there has been no activity in about a month on them.
-Jon
On Sun, May 11, 2014 at 1:45 PM, Daniel Vetter wrote:
> Asus T100 has a mipi dsi pa
On Wed, May 14, 2014 at 03:43:53PM -0400, Josh Boyer wrote:
> On Wed, May 14, 2014 at 3:33 PM, Greg KH wrote:
> > On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
> >> On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
> >> > CCing intel-gfx as otherwise it will probably
On Wed, May 14, 2014 at 03:43:53PM -0400, Josh Boyer wrote:
> On Wed, May 14, 2014 at 3:33 PM, Greg KH wrote:
> > On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
> >> On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
> >> > CCing intel-gfx as otherwise it will probably
On Wed, May 14, 2014 at 3:33 PM, Greg KH wrote:
> On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
>> On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
>> > CCing intel-gfx as otherwise it will probably not get seen by developers.
>> >
>> > On Sun, 11 May 2014 Carbonated
On Wed, 2014-05-14 at 20:51 +0200, Daniel Vetter wrote:
> We don't have hardware based disable bits on gmch platforms, so need
> to block spurious underrun reports in software. Which means that we
> _must_ start out with fifo underrun reporting disabled everywhere.
>
> This is in big contrast to i
On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
> On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
> > CCing intel-gfx as otherwise it will probably not get seen by developers.
> >
> > On Sun, 11 May 2014 Carbonated Beverage
> > wrote:
> > > Bisecting from 3.13.6 (goo
On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
> CCing intel-gfx as otherwise it will probably not get seen by developers.
>
> On Sun, 11 May 2014 Carbonated Beverage
> wrote:
> > Bisecting from 3.13.6 (good) to 3.14.3 (bad) ended up with...
> >
> > commit b35684b8fa94e04f55fd38bf
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
This essentially undoes
commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
Author: Paulo Zanoni
Date: Tue Jul 23
If we want to use this functionality in generic helpers to make
sure that all drivers have somewhat sane vblank handling across
modesets/dpms, we need to make it work for all drivers. But some
don't support interrupts and hence also not vblank waits.
Just return early on such drivers.
Note that w
From: Ville Syrjälä
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during
On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> From: Ville Syrjälä
>
> drm_vblank_off() will turn off vblank interrupts, but as long as the
> refcount is elevated drm_vblank_get() will not re-enable them. This
> is a problem is someone is holding a vblank reference while a modes
CCing intel-gfx as otherwise it will probably not get seen by developers.
On Sun, 11 May 2014 Carbonated Beverage wrote:
> Hi all,
>
> I rarely upgrade kernels these days -- so when updating to 3.14.3, I found
> the X display was blank -- switching to a text console appears to work, but
> I stil
From: Ville Syrjälä
If there's a blocking vblank wait in progress while the vblank interrupt
gets disabled, the current code will just let the vblank wait time out.
Instead make it return immediately when vblank interrupts get disabled.
Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Originally these functions have been for user modesetting drivers to
ensure vblank processing doesn't fall over completely around modeset
changes. This has been carried over ever since then.
Now that Ville cleaned our vblank handling with an explicit
drm_vblank_off/on braket when disabling/enablin
Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.
This essentially undoes
commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
Author: Paulo Zanoni
Date: Tue Jul 23
It literally took us years in i915 to track down all the vblank
bogosity, which means that userspace has now code to deal with random
crap like stuck vblank waits, needless counter wraps and other
hilarity.
To make sure that all drivers are at least somewhat sane enforce
minimal standards in the c
From: Peter Hurley
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/driv
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms
From: Ville Syrjälä
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.
This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms
Hi all,
This is Ville's vblank rework series, slightly pimped. I've added kerneldoc,
some polish and also some additional nasty igt testcases for these crtc on/off
vs vblank issues. Seems all to hold together nicely.
Now one thing I wanted to do is roll this out across all drm drivers, but that
l
Leftover from the old days of ums and should be used any longer. Since
commit 29935554b384b1b3a7377d6f0b03b21d18a61683
Author: Laurent Pinchart
Date: Wed May 30 00:58:09 2012 +0200
drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
it is a complete no-Op for kms drivers.
Cc: Laurent Pin
We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c| 81
d
- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
comments explaining when drm_vblank_pre|post_modesets shouldn't be
used.
- General polish and OCD.
Signed-off-by: Daniel Vetter
---
Docum
If we want to use this functionality in generic helpers to make
sure that all drivers have somewhat sane vblank handling across
modesets/dpms, we need to make it work for all drivers. But some
don't support interrupts and hence also not vblank waits.
Just return early on such drivers.
Note that w
On Wed, May 14, 2014 at 08:34:03PM +0200, Daniel Vetter wrote:
> On Wed, May 14, 2014 at 06:50:27PM +0100, Damien Lespiau wrote:
> > On Wed, May 14, 2014 at 06:00:46PM +0200, Daniel Vetter wrote:
> > > I want to use them elsewhere ...
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > lib/
On Wed, May 14, 2014 at 06:50:27PM +0100, Damien Lespiau wrote:
> On Wed, May 14, 2014 at 06:00:46PM +0200, Daniel Vetter wrote:
> > I want to use them elsewhere ...
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > lib/igt_aux.c | 114
> > +++
On Mon, May 5, 2014 at 11:19 AM, Daniel Vetter wrote:
> Hi Dave,
>
> Update pull request with drm core patches. Mostly some polish for the
> primary plane stuff and a pile of patches all over from Thierry. Has
> survived a few days in drm-intel-nightly without causing ill.
>
> I've frobbed my scri
On Wed, May 14, 2014 at 06:00:46PM +0200, Daniel Vetter wrote:
> I want to use them elsewhere ...
>
> Signed-off-by: Daniel Vetter
> ---
> lib/igt_aux.c | 114
> +
> lib/igt_aux.h | 11 ++
> tests/pm_pc8.c | 96 ++--
We do have to continue the investigation on the link training side, but
since 76711 is a critical I'm completely in favor of this workaround for
now.
I just tested and it worked very well here, so:
Tested-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
On Wed, May 14, 2014 at 6:02 AM, Jani Nikula
These check whether everything is still ok wrt vblank handling after
runtime pm and system suspend-resume.
In addition to the usual checks they also ensure that the vblank frame
counter isn't totally ridiculous, something Keith complained about
aeons ago. With Ville's drm_vblank_on/off rework this
I want to use them elsewhere ...
Signed-off-by: Daniel Vetter
---
lib/igt_aux.c | 114 +
lib/igt_aux.h | 11 ++
tests/pm_pc8.c | 96 ++--
3 files changed, 128 insertions(+), 93 deletions(-
On Wed, May 14, 2014 at 05:37:39PM +0100, Damien Lespiau wrote:
> On Wed, May 14, 2014 at 05:02:16PM +0300, Mika Kuoppala wrote:
> > HW guys say that it is not a cool idea to let device
> > go into rc6 without proper 3d pipeline state.
> >
> > For each new uninitialized context, generate a
> > val
On Wed, May 14, 2014 at 07:14:13PM +0300, Ville Syrjälä wrote:
> On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
> > Otherwise we end up tearing down fences when e.g. the client quits
> > way too early. Might or might not fix a fence pin_count BUG Ville has
> > reported.
> >
> > Cc:
On Wed, May 14, 2014 at 05:02:16PM +0300, Mika Kuoppala wrote:
> HW guys say that it is not a cool idea to let device
> go into rc6 without proper 3d pipeline state.
>
> For each new uninitialized context, generate a
> valid null render state to be run on context
> creation.
>
> This patch introd
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
> Otherwise we end up tearing down fences when e.g. the client quits
> way too early. Might or might not fix a fence pin_count BUG Ville has
> reported.
>
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
For patches 1 and 3:
Revie
On Tue, May 13, 2014 at 09:18:45AM +0530, Sharma, Shashank wrote:
> Daniel,
> Please find my comments inline.
>
> Regards
> Shashank
> On 5/12/2014 8:58 PM, Daniel Vetter wrote:
> >On Mon, May 12, 2014 at 05:35:13PM +0530, Sharma, Shashank wrote:
> >>Thanks for your time and the comments David.
>
On Wed, May 14, 2014 at 09:07:53PM +0530, deepa...@linux.intel.com wrote:
> 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
> Interface.
>
> v2: Add (1<<31) mask (Ville)
>
> v3: Add
On Friday 09 May 2014 06:49 PM, Mika Kuoppala wrote:
Hi Deepak,
deepa...@linux.intel.com writes:
From: Deepak S
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC6 Enable flag set
v4: Fixup PCBR comment msg. (Chris)
Rebase against lates
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
Interface.
v2: Add (1<<31) mask (Ville)
v3: Add Gen check for the mask (ville)
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/i915_reg.
Conflict between me and Thomas pushing patches in parallel.
Cc: Thomas Wood
Signed-off-by: Daniel Vetter
---
lib/igt_core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 05bc19bca6fc..6e553cf20487 100644
--- a/lib/igt_core.c
+++
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this situation,
but prevent the underflow by returning early.
v2: Less co
These are generated with intel-gpu-tools/tools/null_state_gen
v2: Don't use header file for states (Daniel Vetter)
v3: Proper URB state size for gen8/GT3 (Damien Lespiau)
Tested-by: Kristen Carlson Accardi (v1)
Tested-by: Oscar Mateo (v2)
Acked-by: Damien Lespiau
Signed-off-by: Mika Kuoppala
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
-
On Wed, May 14, 2014 at 04:35:42PM +0300, Ville Syrjälä wrote:
> On Wed, May 14, 2014 at 04:18:02PM +0300, Mika Kuoppala wrote:
> > If we get the final value of zero as a count of free
> > entries available, we will underflow our own fifo_count
> > and then it will take a long time before we check
On Wed, May 14, 2014 at 04:18:02PM +0300, Mika Kuoppala wrote:
> If we get the final value of zero as a count of free
> entries available, we will underflow our own fifo_count
> and then it will take a long time before we check things again.
> Admittedly we are in trouble already if we get into thi
On Tue, May 13, 2014 at 03:28:27PM +0200, Daniel Vetter wrote:
> On Fri, May 09, 2014 at 01:08:36PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > In the upcoming patches, we plan to break the correlation between
> > engines (a.k.a. rings) and ringbuffers, so it makes sense to
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this situation,
but prevent the underflow by returning early.
v2: Less co
A single object may be referenced by multiple registers fundamentally
breaking the static allotment of ids in the current design. When the
object is used the second time, the physical address of the first
assignment is relinquished and a second one granted. However, the
hardware is still reading (a
On Wed, May 14, 2014 at 11:53:46AM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, May 13, 2014 2:27 PM
> > To: Mateo Lozano, Oscar
> > Cc: intel-gfx@lists.freedesktop.org; Be
If we get the final value of zero as a count of free
entries available, we will underflow our own fifo_count
and then it will take a long time before we check things again.
Admittedly we are in trouble already if we get into this situation,
but prevent the underflow by checking against zero before
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 13, 2014 2:27 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Widawsky, Benjamin
> Subject: Re: [Intel-gfx] [PATCH 04/50] drm/i915: Ex
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 13, 2014 2:36 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 26/50] drm/i915/bdw: Allow non-default, non-
> render
> -Original Message-
> From: Lespiau, Damien
> Sent: Wednesday, May 14, 2014 12:14 PM
> To: Mateo Lozano, Oscar
> Cc: Mika Kuoppala; intel-gfx@lists.freedesktop.org; b...@bwidawsk.net;
> m...@iki.fi; kris...@linux.intel.com
> Subject: Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: add render stat
On Wed, May 14, 2014 at 10:24:53AM +, Mateo Lozano, Oscar wrote:
> Hi Mika,
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Mika Kuoppala
> > Sent: Tuesday, May 06, 2014 3:30 PM
> > To: intel-gfx@lists.freedesktop.org
On Wed, May 14, 2014 at 11:04:03AM +0100, Damien Lespiau wrote:
> On Tue, May 13, 2014 at 10:21:59PM +0200, Daniel Vetter wrote:
> > Noticed while playing with coccinelle.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Damien Lespiau
Queued for -next, thanks for the review.
-Daniel
>
>
Hi Mika,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Mika Kuoppala
> Sent: Tuesday, May 06, 2014 3:30 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: b...@bwidawsk.net; m...@iki.fi; kris...@linux.intel.com
> Subject: [Intel-gfx] [PA
On Tue, May 06, 2014 at 04:26:04PM +0300, Mika Kuoppala wrote:
> Hi,
>
> V2 series of the render state initialization patches.
>
> I decided not to pursue the copying of the context object as the ctx
> is quite big, atleast on bdw. As discussed in irc, the copying
> could be done with blitter, on
On Tue, May 13, 2014 at 03:11:45PM +0100, Chris Wilson wrote:
> On Tue, May 13, 2014 at 04:02:40PM +0200, Daniel Vetter wrote:
> > On Tue, May 13, 2014 at 02:26:39PM +0100, Chris Wilson wrote:
> > > During initial probing of the modes to assign to the fbdev console, we
> > > use the CRTC and connec
On Tue, May 06, 2014 at 04:39:01PM +0300, Mika Kuoppala wrote:
> Generate valid (null) render state for each gen. Output
> it as a c source file with batch and relocations.
>
> Signed-off-by: Mika Kuoppala
With the GT3 URB allocation restriction added, this series is
Acked-by: Damien Lespiau
On Tue, May 13, 2014 at 10:21:59PM +0200, Daniel Vetter wrote:
> Noticed while playing with coccinelle.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/dr
There are certain BDW high res eDP machines that regressed due to
commit 38aecea0ccbb909d635619cba22f1891e589b434
Author: Daniel Vetter
Date: Mon Mar 3 11:18:10 2014 +0100
drm/i915: reverse dp link param selection, prefer fast over wide again
The commit lead to 2 lanes at 5.4 Gbps being u
Signed-off-by: Daniel Vetter
---
tests/prime_nv_pcopy.c | 121 +++--
1 file changed, 36 insertions(+), 85 deletions(-)
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index 74388349da3d..6aa48716348e 100644
--- a/tests/prime_nv_pcopy.c
+++
We now know that the hardware can't do this, and it's not designed to.
Signed-off-by: Daniel Vetter
---
tests/prime_nv_pcopy.c | 253 -
1 file changed, 253 deletions(-)
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index 6aa48716348
Signed-off-by: Daniel Vetter
---
tests/prime_nv_pcopy.c | 172 -
1 file changed, 71 insertions(+), 101 deletions(-)
diff --git a/tests/prime_nv_pcopy.c b/tests/prime_nv_pcopy.c
index d06c1eb205a1..74388349da3d 100644
--- a/tests/prime_nv_pcopy.c
++
Signed-off-by: Daniel Vetter
---
tests/kms_flip.c | 56
1 file changed, 24 insertions(+), 32 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 3032c8d9bcef..d2adc02c8476 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.
Now we even have more fine-grained checking and only skip if the
nouveau card isn't supported, but fail properly if something else goes
wrong.
Signed-off-by: Daniel Vetter
---
tests/prime_nv_pcopy.c | 93 ++
1 file changed, 25 insertions(+), 68 del
Signed-off-by: Daniel Vetter
---
tests/prime_nv_api.c | 325 +--
1 file changed, 81 insertions(+), 244 deletions(-)
diff --git a/tests/prime_nv_api.c b/tests/prime_nv_api.c
index 73c0a0d24f5f..99d5cf298537 100644
--- a/tests/prime_nv_api.c
+++ b/te
Often just folding together of the common if (cond) printf;
abort|igt_skip|igt_fail; pattern. But in a few cases I've ripped out
more since the igt macros will already print the condition and errno.
A few tests where more work (like ripping out return codes en masse)
is needed left as-is.
Signed-
Only tricky bit was a bit of debug output sprinkled all over, I've
moved it all to cmp_bo.
Signed-off-by: Daniel Vetter
---
tests/gem_seqno_wrap.c | 62 ++
1 file changed, 22 insertions(+), 40 deletions(-)
diff --git a/tests/gem_seqno_wrap.c b/tes
Step one to untangle the control flow in this test and replace it all
with igt assert magic.
Signed-off-by: Daniel Vetter
---
tests/prime_nv_pcopy.c | 82 ++
1 file changed, 22 insertions(+), 60 deletions(-)
diff --git a/tests/prime_nv_pcopy.c b/t
On Wed, 14 May 2014, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index edf7299..4006dfe 100644
> --- a/drivers/gpu/drm
On Wed, 14 May 2014, Jesse Barnes wrote:
> On Tue, 13 May 2014 22:22:00 +0200
> Daniel Vetter wrote:
>
>> coccinelle is seriously a tool I should have played around with much
>> earlier. Extremely powerful, and extremely dangerous in causing
>> massive conflict hell for everyone else since doing
On Wed, May 14, 2014 at 11:31:47AM +0300, Jani Nikula wrote:
> On Tue, 13 May 2014, Chris Wilson wrote:
> > i915.ko has a custom fbdev initialisation routine that aims to preserve
> > the current mode set by the BIOS, unless overruled by the user. The
> > user's wishes are determined by what, if a
On Tue, 13 May 2014, Chris Wilson wrote:
> i915.ko has a custom fbdev initialisation routine that aims to preserve
> the current mode set by the BIOS, unless overruled by the user. The
> user's wishes are determined by what, if any, mode is specified on the
> command line (via the video= parameter
On Wed, May 14, 2014 at 08:05:11AM +0200, David Herrmann wrote:
> Hi
>
> On Wed, May 14, 2014 at 2:03 AM, Dave Airlie wrote:
> > Since any objects you get with find are only valid under mode_config.mutex,
> > yes some drivers mess this up, but they should be fixed.
>
> Didn't know that we have s
On Tue, May 13, 2014 at 03:36:59PM -0700, Jesse Barnes wrote:
> On Tue, 25 Mar 2014 12:57:32 +
> Chris Wilson wrote:
>
> > 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 individu
On Tue, May 13, 2014 at 03:43:12PM -0700, Jesse Barnes wrote:
> On Wed, 14 May 2014 00:30:34 +0200
> Daniel Vetter wrote:
>
> > On Tue, May 13, 2014 at 03:05:24PM -0700, Jesse Barnes wrote:
> > > On Tue, 11 Feb 2014 14:19:03 +0530
> > > akash.g...@intel.com wrote:
> > >
> > > > @@ -810,6 +815,7
84 matches
Mail list logo
