Is this a known issue ?
IP: [] intel_prepare_ddi+0x14e/0x770 [i915]
May 13 22:57:37 linux-mei kernel: [3.065237] PGD 2ffd067 PUD 0
May 13 22:57:37 linux-mei kernel: [3.065238] Oops: [#1] SMP
May 13 22:57:37 linux-mei kernel: [3.065240] Modules linked in: i915(+)
intel_rapl iosf_
Reviewed-by: Chandra Konduru
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Damien Lespiau
> Sent: Tuesday, May 12, 2015 8:13 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/10] drm/i915/skl: Support the adv
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Damien Lespiau
> Sent: Tuesday, May 12, 2015 8:13 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/10] drm/i915/skl: Replace BUG() by
> MISSING_CASE() in skl_pla
Reviewed-by: Chandra Konduru
> -Original Message-
> From: Lespiau, Damien
> Sent: Tuesday, May 12, 2015 8:13 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra
> Subject: [PATCH 03/10] drm/i915/skl: Rename a local variable to fit in 80
> chars
>
> No reason to not follow t
Reviewed-by: Chandra Konduru
> -Original Message-
> From: Lespiau, Damien
> Sent: Tuesday, May 12, 2015 8:13 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra
> Subject: [PATCH 02/10] drm/i915/skl: Add a new line before return
>
> We usually use a new line before those kind
Reviewed-by: Chandra Konduru
> -Original Message-
> From: Lespiau, Damien
> Sent: Tuesday, May 12, 2015 8:13 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra
> Subject: [PATCH 01/10] drm/i915/skl: Leave a new line between variable
> declarations and code
>
> Cc: Chandra Ko
Hi,
I have seen review comments from you and addressed/responded to them.
Can you please give R-b tag?
-Chandra
> -Original Message-
> From: Konduru, Chandra
> Sent: Thursday, April 30, 2015 8:43 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra; Vetter, Daniel; Lespiau, Dam
Hey guys,
The impact of disabling batch buffer security for Intel Haswell
platform on Linux for OpenCL kernels that need local shared memory
access is massive.
On a native kernel with and without the patch, the performance boost
is massive, especially ijn the Lu decomposition benchmark.
Do the m
On Tue, May 12, 2015 at 09:54:07PM +0200, Thomas Gummerer wrote:
>
> Hi,
>
> I noticed that on my machine the screen starts to flicker after I
> suspend and resume my machine, on the main laptop display if an external
> display is attached with kernel v4.1-rc1. I tracked the regression down
> to
I'm still experiencing video lockups even though I'm currently running
the kernel shown in my sig along with Module intel: vendor="X.Org
Foundation compiled for 1.15.1, module version = 2.99.917. I thought I'd
narrowed the problem down to X-Screensaver as each time I start it
running I'd get the lo
On 12 May 2015 at 13:27, Dave Airlie wrote:
> On 12 May 2015 at 11:50, Dave Airlie wrote:
>> Hi,
>>
>> So I have a branch that makes no sound,
>> http://cgit.freedesktop.org/~airlied/linux/log/?h=dp-mst-audio
>>
>> and I'm not sure where I need to turn to next,
>>
>> The Intel docs I've read are
This needs to be a global check because at the time of crtc checking
not all modesets have to be calculated yet. Use intel_crtc->atomic
because there's no reason to keep it in state.
Changes since v1:
- Use intel_crtc->atomic as a place to put hsw_workaround_pipe.
- Make sure quirk only applies
From: Ander Conselvan de Oliveira
It makes more sense there, since these are computation steps that can
fail.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 70 ++--
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/dri
intel_crtc->config will be removed eventually, so use crtc->hwmode.
drm_atomic_helper_update_legacy_modeset_state updates hwmode,
but crtc->active will eventually be gone too. Set dotclock to zero
to indicate the crtc is inactive.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_ir
From: Ander Conselvan de Oliveira
A follow up patch will make intel_modeset_compute_config() deal with
multiple crtcs, so move crtc specific stuff into the lower level crtc
specific function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 51 ---
crtc->config is a pointer to the current crtc->state, and will be
removed eventually. Same for crtc->active, instead use crtc->state->active.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 -
1 file changed, 27 insertions(+), 15
Having a single path for everything makes it a lot easier to keep
crtc_state->active in sync with intel_crtc->active.
A crtc cannot be changed to active when not enabled, because it means
no mode is set and no connectors are connected.
This should also make intel_crtc->active match crtc_state->ac
From: Ander Conselvan de Oliveira
To make this work we load the new hardware state into the
atomic_state, then swap it with the sw state.
This lets us change the force restore path in setup_hw_state()
to use a single call to intel_mode_set() to restore all the
previous state.
As a nice bonus th
This is useful when calculating vblank in drivers that support it.
During a modeset the atomic state may not match the hardware state,
so if the driver wants to wait on a vblank they'll want to use
crtc->hwmode rather than crtc->state->adjusted_mode.
Signed-off-by: Maarten Lankhorst
---
drivers/
Now that the dpll updates are (mostly) atomic, the .off() code is a noop,
and intel_crtc_disable does mostly the same as intel_modeset_update_state.
Move all logic for connectors_active and setting dpms to that function.
Changes since v1:
- Move drm_atomic_helper_swap_state up.
Changes since v2:
Now that the pll updates are staged the put_shared_dpll function
consists only of checks that are done in check_shared_dpll_state
after a modeset too.
The changes to pll->config are overwritten by
intel_shared_dpll_commit, so this entire function is a noop.
Signed-off-by: Maarten Lankhorst
---
Now that the helper is exported there's no need to duplicate
this code any more.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 61 +++-
1 file changed, 4 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.
Drivers may need to store the state of shared resources, such as PLLs
or FIFO space, into the atomic state. Allow this by making it possible
to subclass drm_atomic_state.
Changes since v1:
- Change member names for functions to atomic_state_(alloc,clear)
- Change __drm_atomic_state_new to drm_atom
crtc_state->enable means a crtc is configured, but it may be turned
off for dpms. Until the previous commit crtc_state->active was not
updated on crtc off, but now that we do we should use that for tracking
whether a crtc is scanning out or not.
At this point crtc->active should mirror crtc_state-
From: Ander Conselvan de Oliveira
Now that we can subclass drm_atomic_state we can also use it to keep
track of all the pll settings. atomic_state is a better place to hold
all shared state than keeping pll->new_config everywhere.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_
From: Ander Conselvan de Oliveira
Compute new pipe_configs for all crtcs in the atomic state. The commit
part of the mode set (__intel_set_mode()) is already enabled to support
multiple pipes, the only thing missing was calculating a new pipe_config
for every crtc.
Signed-off-by: Maarten Lankhor
From: Ander Conselvan de Oliveira
The last remaining portion that required the modeset_crtc argument is
converted to deal with all crtcs in the state that need_modeset(). By
doing that, __intel_set_mode() is generic enough, behaving like a commit
function for the atomic state.
Signed-off-by: Maa
I made a small mistake in the original ordering of this series.
This resulted in patches trying to do too much, and things became
too confusing. I removed the atomic plane conversion patches,
and changed ordering.
The new ordering should be more logical, instead of converting planes
to atomic firs
Assume the callers lock everything with drm_modeset_lock_all.
This change had to be done after converting suspend/resume to
use atomic_state so the atomic state is preserved, otherwise
all transitional state is erased.
Now all callers of .crtc_enable and .crtc_disable go through
atomic modeset! :
> With some debugging, I was able to resolve this problem. The bug here is
> that the bios of the X30 apparently forgets to re-initialize the registers
> of the DVO; especially, the PLL remains uninitialized and the
> panel output timing remains unitialized. No miracle the panel remains blank.
The
On Wed, May 13, 2015 at 05:56:17PM +0100, Damien Lespiau wrote:
> On Wed, May 13, 2015 at 05:40:44PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Since commit 4978cc93d9ac240b435ce60431aef24239b4c270 started clearing
> > dpll state and recomputing it via crtc_compute_clock (and p
On Wed, May 13, 2015 at 05:40:44PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Since commit 4978cc93d9ac240b435ce60431aef24239b4c270 started clearing
> dpll state and recomputing it via crtc_compute_clock (and probably some
> other commit which triggered pipe config checking), modeset
Added docbook info regarding context save and restore (CSR)
firmware support added from gen9 onwards to drive newly added
DMC (Display microcontroller) in display engine.
v1: Initial version as RFC.
v2: Used "DOC:" tag for csr description based on review comment from Daniel.
Signed-off-by: Anime
On 12 May 2015 at 13:09, Derek Morton wrote:
> On android with small memory footprints gem_cpu_reloc can fail
> due to OOM.
>
> Refactor gem_cpu_reloc into 2 tests, a basic test which performs
> 10 relocations and a full test which skips if there is insufficient
> memory.
>
> Changed the memory re
On Wed, May 13, 2015 at 04:51:07PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tried to get the platform split right, please shout if I failed.
>
> Signed-off-by: Tvrtko Ursulin
So, previously, we used to dump the whole list of states, even when the
platform didn't care about all o
From: Tvrtko Ursulin
Since commit 4978cc93d9ac240b435ce60431aef24239b4c270 started clearing
dpll state and recomputing it via crtc_compute_clock (and probably some
other commit which triggered pipe config checking), modesetting is now
constantly triggering warnings about dpll_hw_state.ctrl1 misma
On Wed, May 13, 2015 at 04:51:08PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just so it is grouped logically in line with other data and makes a
> rather verbose output a bit shorter.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chandra Konduru
Reviewed-by: Damien Lespiau
--
Damie
From: Tvrtko Ursulin
Tried to get the platform split right, please shout if I failed.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i
From: Tvrtko Ursulin
Just so it is grouped logically in line with other data and makes a
rather verbose output a bit shorter.
Signed-off-by: Tvrtko Ursulin
Cc: Chandra Konduru
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/d
On 5/12/2015 1:59 PM, Daniel Vetter wrote:
On Tue, May 12, 2015 at 01:02:08PM +0530, Animesh Manna wrote:
Specifically csr mutex lock is to protect csr-related data structures
so declaration moved intel_csr structure.
Signed-off-by: Animesh Manna
Signed-off-by: A.Sunil Kamath
---
drivers/
On Wed, May 13, 2015 at 03:54:32PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
Hi Tvrtko,
> >+static bool
> >+skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> >+ struct intel_encoder *intel_encoder,
> >+ int clock)
> >+{
> >+struct intel_shared_dpll *pll;
> >+uint
Hi,
drm-intel-nightly @ 2015y-05m-12d-17h-21m-03s.
Warnings (27 each boot, here's three different ones) have been there for
a few days already. No noticeable effect.
Haswell 4770, two HDMI monitors to its IGP.
[0.636075] [drm:check_crtc_state [i915]] *ERROR* mismatch in ddi_pll_sel
(expec
On Tue, May 12, 2015 at 07:37:59PM +0200, Gabriel Laskar wrote:
> On Tue, 12 May 2015 14:35:28 +0200, Patrik Jakobsson wrote:
> > On Mon, May 11, 2015 at 08:08:19PM +0200, Gabriel Laskar wrote:
> > > On Mon, 11 May 2015 15:54:24 +0200, Patrik Jakobsson wrote:
> > > > On Mon, May 11, 2015 at 12:50:3
Hi,
On 09/04/2014 12:27 PM, Damien Lespiau wrote:
From: Satheeshakrishna M
This patch implements SKL DPLL programming that includes:
- DPLL allocation
- wide range PLL calculation and programming
- DP link rate programming
- DDI to DPLL mapping
v2: Incorpo
Hi Dave, one i915 gpu hang fix on resume.
BR,
Jani.
The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736:
Linux 4.1-rc3 (2015-05-10 15:12:29 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-05-13
for y
Add one explicit discard of __iomem address space qualifier in
validate_vbt(), and respect it otherwise. This adds clarity in the code,
and reduces the sparse warnings from the module to just one.
Quoting Daniel, "The vbt really is plain old memory. Except that it's
reserved in the e820 table as s
We never pass a non-NULL vbt to validate_vbt, and we can safely expect
the callers to not change.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index
Improve clarity. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index d39c41cf45a7..
From: Rodrigo Vivi
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only t
From: Ankitprasad Sharma
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question
From: Ankitprasad Sharma
This patch extends the GET_APERTURE ioctl to add support
for getting total size and available size of the stolen region
as well as single largest block available in the stolen region.
Also adds debugfs support to retieve the size information of the
stolen area.
v2: respi
From: Ankitprasad Sharma
This test validates the two parameters (size and flags) GEM_CREATE ioctl.
Signed-off-by: Ankitprasad Sharma
---
tests/Makefile.sources | 1 +
tests/gem_create.c | 177 +
2 files changed, 178 insertions(+)
create mo
From: Ankitprasad Sharma
This patch adds the testcases for verifying the new extended
gem_create ioctl. By means of this extended ioctl, memory
placement of the GEM object can be specified, i.e. either
shmem or stolen memory.
These testcases include functional tests and interface tests for
testin
From: Ankitprasad Sharma
This patch adds support to verify pread/pwrite for non-shmem backed
objects. It also shows the pread/pwrite speed.
It also tests speeds for pread with and without user side page faults
Signed-off-by: Ankitprasad Sharma
---
tests/gem_pread.c | 100 +
From: Ankitprasad Sharma
This new set of tests verifies the old and the new extended GEM_CREATE ioctl
gem_stolen tries to verify the new extended GEM_CREATE ioctl, which tries to
create an object backed by stolen memory and performs basic operations on it.
It verifies the creation as well as the
On Wed, May 13, 2015 at 01:27:06PM +0200, Thomas Gummerer wrote:
> Sudip Mukherjee writes:
>
> > On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
> > http://patchwork.freedesktop.org/patch/46071/
>
> Thank you for the pointer, but this seems to be an unrelated issue. I
> tried ap
On Wed, May 13, 2015 at 01:10:11PM +0200, Jan Niehusmann wrote:
> On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
> > > What I'm missing in the report, are some log entries I'm seeing on my
> > > notebook:
> > >
> > > Apr 30 08:50:23 localhost kernel:
> > > [drm:intel_cpu_fifo_un
Sudip Mukherjee writes:
> On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote:
>> Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler
>> [i915]] *ERROR* CPU pipe B FIFO underrun
>> Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler
>> [i
Jan Niehusmann writes:
> Hi,
>
> On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
>> Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
>
> The visible effect in the video is similar to what I see on the LVDS
> display. I also see some influence of the mouse point
On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote:
> > What I'm missing in the report, are some log entries I'm seeing on my
> > notebook:
> >
> > Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler
> > [i915]] *ERROR* CPU pipe B FIFO underrun
> > Apr 30 08:50
> -Original Message-
> From: Morton, Derek J
> Sent: Tuesday, May 12, 2015 1:10 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Wood, Thomas; Gore, Tim; Morton, Derek J
> Subject: [PATCH i-g-t] tests/gem_cpu_reloc: Fix gem_cpu_reloc OOM failure
>
> On android with small memory footprints
On Wed, May 13, 2015 at 11:13:24AM +0300, Abdiel Janulgue wrote:
> Adds support for executing the resource streamer on BDW and HSW
>
> v2: Add support for Execlists (Minu Mathai )
>
> Signed-off-by: Abdiel Janulgue
I would have liked to have seen the comments for HSW_CTX_TOTAL_SIZE
updated to i
Hi,
On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote:
> Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ?
The visible effect in the video is similar to what I see on the LVDS
display. I also see some influence of the mouse pointer position on the
blanked areas.
T
On Wed, May 13, 2015 at 09:19:09AM +0200, Daniel Vetter wrote:
> On Wed, May 13, 2015 at 07:54:48AM +0100, Peter Antoine wrote:
> > As these functions are only used by one driver and there are security holes
> > in these functions. Make the functions optional.
> >
> > These changes are based on th
On 5/13/2015 3:13 PM, Vandana Kannan wrote:
Changes for BXT - added a IS_BROXTON check to use the macro related to PPS
registers for BXT.
BXT does not have PP_DIV register. Making changes to handle this.
Second set of PPS registers have been defined but will be used when VBT
provides a selectio
Changes for BXT - added a IS_BROXTON check to use the macro related to PPS
registers for BXT.
BXT does not have PP_DIV register. Making changes to handle this.
Second set of PPS registers have been defined but will be used when VBT
provides a selection between the 2 sets of registers.
v2:
[Jani] A
On Wed, May 13, 2015 at 10:35:25AM +0300, Jani Nikula wrote:
> Currently DSI PLL N1 is hardcoded off. Make it possible to use it
> later. This should have no functional changes for now.
>
> v2: s/ffz(~(n))/ffs(n) - 1/ (Ville)
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
>
On Tue, 12 May 2015, Thomas Gummerer wrote:
> Hi,
>
> I noticed that on my machine the screen starts to flicker after I
> suspend and resume my machine, on the main laptop display if an external
> display is attached with kernel v4.1-rc1. I tracked the regression down
> to commit c9f038a1a592 ("d
On Wed, May 13, 2015 at 10:37:25AM +0200, Maarten Lankhorst wrote:
> There are cases where we want to test if a given object is
> part of the state, but don't want to add them if they're not.
>
> Signed-off-by: Maarten Lankhorst
Yeah makes sense to wrap these. Applied to topic/drm-misc, thanks.
On Wed, May 13, 2015 at 09:56:02AM +0200, Maarten Lankhorst wrote:
> Drivers may need to store the state of shared resources, such as PLLs
> or FIFO space, into the atomic state. Allow this by making it possible
> to subclass drm_atomic_state.
>
> Changes since v1:
> - Change member names for func
There are cases where we want to test if a given object is
part of the state, but don't want to add them if they're not.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 18 +++-
include/drm/drm_atomic.h | 50
2 file
Ensures that the batch buffer is executed by the resource streamer
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++
drivers/gpu/drm/i915/intel_ringbuffer.h| 1 +
include/uapi/drm/i915_drm.h| 7 ++-
3 files changed, 22 i
Adds support for executing the resource streamer on BDW and HSW
v2: Add support for Execlists (Minu Mathai )
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
3 f
Changes since initial posting:
- Don't split the conversion from args->flags to ring from its
subsequent EINVAL check (Chris Wilson )
- Execlists support (Minu Mathai )
--
Abdiel Janulgue (2):
drm/i915/hsw/bdw: Expose I915_EXEC_RESOURCE_STREAMER flag
drm/i915/hsw/bdw: Enable resourc
Drivers may need to store the state of shared resources, such as PLLs
or FIFO space, into the atomic state. Allow this by making it possible
to subclass drm_atomic_state.
Changes since v1:
- Change member names for functions to atomic_state_(alloc,clear)
- Change __drm_atomic_state_new to drm_atom
This results in a warning when building out of tree:
"cc1: warning: include/drm: No such file or directory [enabled by default]"
Most code already uses #include correctly, so fix the
instances that don't.
Reported-by: Ville Syrjälä
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/Mak
This results in a warning when building out of tree:
"cc1: warning: include/drm: No such file or directory [enabled by default]"
Most code already uses #include correctly, so fix the
instances that don't.
Reported-by: Ville Syrjälä
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Makefile
On 05/12/2015 12:49 PM, Chris Wilson wrote:
> On Mon, May 11, 2015 at 12:01:11PM +0300, Abdiel Janulgue wrote:
>> Ensures that the batch buffer is executed by the resource streamer
>>
>> Signed-off-by: Abdiel Janulgue
>> ---
>> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++
>>
Currently DSI PLL N1 is hardcoded off. Make it possible to use it
later. This should have no functional changes for now.
v2: s/ffz(~(n))/ffs(n) - 1/ (Ville)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(
On Tue, 12 May 2015, Ville Syrjälä wrote:
> On Tue, May 12, 2015 at 05:20:38PM +0300, Jani Nikula wrote:
>> Nuke three copies of the same switch case.
>>
>> Hopefully we can switch to a drm generic function later on, but that
>> will require us to swich to enum mipi_dsi_pixel_format first.
>>
>>
Adding dri-devel, I've forgotten to do that ...
-Daniel
On Wed, May 13, 2015 at 09:14:29AM +0200, Daniel Vetter wrote:
> On Wed, May 13, 2015 at 07:54:47AM +0100, Peter Antoine wrote:
> > As these functions are only used by one driver and there are security holes
> > in these functions. Make the f
On Tue, May 12, 2015 at 09:07:37PM +0300, Dan Carpenter wrote:
> There is an extra semi-colon on the if statement so the debug output
> always says "Failed to write EDID checksum" even when it didn't fail.
>
> Fixes: 559be30cb74d ('drm/i915: Implement the intel_dp_autotest_edid function
> for DP
On Tue, May 12, 2015 at 10:20:11AM -0700, Rodrigo Vivi wrote:
> Hi all,
>
> drm-intel-collector is now deprecated.
>
> It was started in an attempt to collect single patches or small series
> of 2 patches that was staying behind and forgotten. So we would
> minimize the amount of lost patches and
On Wed, May 13, 2015 at 07:54:48AM +0100, Peter Antoine wrote:
> As these functions are only used by one driver and there are security holes
> in these functions. Make the functions optional.
>
> These changes are based on the two patches:
> commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
> Au
On Wed, May 13, 2015 at 07:54:47AM +0100, Peter Antoine wrote:
> As these functions are only used by one driver and there are security holes
> in these functions. Make the functions optional.
Is there a reference for why nouveau needs hw locks too? Also have you
done an audit of mesa history and X
On Wed, May 13, 2015 at 07:54:46AM +0100, Peter Antoine wrote:
> This is a resubmission of the security fixed for a Kernel Crash found in the
> drm part of the driver. It was caused by a attempt to Lock/Unlock a HW_LOCK
> that was uninitialised. As this feature is only required on some legacy
> d
On Mon, May 11, 2015 at 4:24 PM, Maarten Lankhorst
wrote:
> This patch makes this happen by consolidating all modeset paths
> and getting rid of most transitional state.
>
> This happens first by unifying all paths so all code that
> disables a crtc goes through either intel_crtc_toggle or
> __int
87 matches
Mail list logo
