On Tue, Feb 10, 2015 at 05:11:36PM +0800, Zhi Wang wrote:
> This patch introduces 2 bit definitions of context save/restore
> control register.
>
> Thanks comments from David/Thomas/Daniel.
Instead of Thanks just add the usual Suggested-by: lines. And please Cc:
everyone from the previous discuss
Thanks Daniel! :)
于 2015年02月11日 16:03, Daniel Vetter 写道:
On Tue, Feb 10, 2015 at 05:11:36PM +0800, Zhi Wang wrote:
This patch introduces 2 bit definitions of context save/restore
control register.
Thanks comments from David/Thomas/Daniel.
Instead of Thanks just add the usual Suggested-by: li
On Tue, Feb 10, 2015 at 12:11:02PM +, Tvrtko Ursulin wrote:
> On 02/10/2015 11:05 AM, Yu Zhang wrote:
> >This patch set includes necessary code changes when i915 driver
> >runs inside a VM. Though ideally we can run an unmodified i915
> >driver in VM, adding such enlightenments can greatly redu
On Tue, Feb 10, 2015 at 07:32:15PM +, Damien Lespiau wrote:
> Ran my cleanup script again and caught a few tiny oversights.
Fixed three tiny spelling things and merged them all.
Thanks, Daniel
>
> --
> Damien
>
> Damien Lespiau (10):
> drm/i915: Garbage collect orphaned prototypes
> dr
On Tue, Feb 10, 2015 at 05:17:34PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just a few basic tests to make sure fb modifiers can be used and
> behave sanely when mixed with the old set_tiling API.
>
> v2:
>* Review feedback from Daniel Vetter:
> 1. Move cap detection int
On 2/11/2015 4:06 PM, Daniel Vetter wrote:
On Tue, Feb 10, 2015 at 12:11:02PM +, Tvrtko Ursulin wrote:
On 02/10/2015 11:05 AM, Yu Zhang wrote:
This patch set includes necessary code changes when i915 driver
runs inside a VM. Though ideally we can run an unmodified i915
driver in VM, addin
Forgotten ever since, but luckily we're at least good at memset.
Testecase: igt/gem_ctx_create/invalid-pad
Testecase: igt/gem_ctx_bad_destroy/invalid-pad
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_context.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drive
On Tue, Feb 10, 2015 at 10:19:10AM -0200, Paulo Zanoni wrote:
> 2015-02-09 17:05 GMT-02:00 Daniel Vetter :
> > Ok, here comes the gist of what needs to be changed.
> > - You need to check the fbc-private copy of busy bits, otherwise the
> > filtering for the GTT origin won't work. We want to keep
On Wed, 11 Feb 2015, Tom.O'rou...@intel.com wrote:
> From: Tom O'Rourke
>
> The efficient frequency (RPe) should stay in the range
> RPn <= RPe <= RP0. The pcode clamps the returned value
> internally on Broadwell but not on Haswell.
>
> Fix for missing range check in
> commit 93ee29203f506582cca
On Tue, 10 Feb 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Return IRQ_HANDLED from intel_dp_hpd_pulse() to properly
> ignore the long HPD pulse on eDP to avoid the never ending
> VDD off->HPD->VDD on->VDD off->HPD... cycle.
>
> This fixes a regression intoduced by
> commi
On Mon, Feb 09, 2015 at 07:41:17PM +0100, Daniel Vetter wrote:
> On Mon, Feb 09, 2015 at 02:46:31PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > We need this for FBC, and possibly for PSR too.
> >
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/g
Hi All,
I went through Ville's changes and it seems to be lacking support for
our one main user experience requirement in Android. Which is as follows
"Ux Restrictions: Flash/flicker should be avoided as much as possible( i.e
during unplug of HDMI avoid immediately lowering the CD clock
On Tue, Feb 10, 2015 at 09:58:37PM +, Chris Wilson wrote:
> On Tue, Feb 10, 2015 at 07:05:46PM +0100, Daniel Vetter wrote:
> > We stick to the overall prefix even for magic require functions.
>
> That seems a bit perverse. Move the #define to a new header perhaps, but
> the require is a functi
On Tue, Feb 10, 2015 at 09:54:46PM +, Chris Wilson wrote:
> On Tue, Feb 10, 2015 at 07:05:48PM +0100, Daniel Vetter wrote:
> > We have separate require checks already, so these failing is a bug in
> > the test logic.
>
> That makes it impossible to use the wrappers to test the ioctl though.
Y
On Tue, Feb 10, 2015 at 09:53:32PM +, Chris Wilson wrote:
> On Tue, Feb 10, 2015 at 07:05:56PM +0100, Daniel Vetter wrote:
> > Yeah, historically grown but we should try to be somewhat consistent.
> > It helps with filtering testcases.
>
> I think you are going the wrong way, since the current
On Tue, Feb 10, 2015 at 10:50:33PM +, Chris Wilson wrote:
> On Tue, Feb 10, 2015 at 11:45:12PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 10, 2015 at 11:39:45PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 10, 2015 at 11:37:42PM +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 10, 2015 at 10:2
On Wed, Feb 11, 2015 at 08:32:59AM +, Thulasimani, Sivakumar wrote:
> Hi All,
> I went through Ville's changes and it seems to be lacking support for
> our one main user experience requirement in Android. Which is as follows
> "Ux Restrictions: Flash/flicker should be avoided as much a
On Wed, Feb 11, 2015 at 09:51:53AM +0100, Daniel Vetter wrote:
> On Wed, Feb 11, 2015 at 08:32:59AM +, Thulasimani, Sivakumar wrote:
> > Hi All,
> > I went through Ville's changes and it seems to be lacking support for
> > our one main user experience requirement in Android. Which is as f
On Wed, 11 Feb 2015, Rodrigo Vivi wrote:
> When users face a issue that bother/matter he would enabled debug and
> than we would receive the report. And QA/OSVs/Devs should always let
> drm.debug enabled in certain level anyway.
Judging by the bug reports, most users won't enable drm.debug when t
On Tue, 10 Feb 2015, Damien Lespiau wrote:
> This header has been unusued since:
>
> commit 063c86f60ad4064b2cf62041bee8c6389e180b76
> Author: Jani Nikula
> Date: Fri Jan 16 14:27:27 2015 +0200
>
> drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein
>
> Signed-off-
On 2014-11-01 18:08, Christian Kastner wrote:
> I have a Macbook Air (2013) (6,2) which until recently was working
> flawlessly with Debian unstable, which I use almost exclusively on that
> machine. I did keep the OSX installation, mainly because it's the only
> way to get firmware updates.
>
> R
On 02/11/2015 08:15 AM, Daniel Vetter wrote:
On Tue, Feb 10, 2015 at 05:17:34PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
v2:
* Review feedback from Daniel Vette
On 02/11/2015 07:58 AM, Daniel Vetter wrote:
On Tue, Feb 10, 2015 at 05:16:16PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Let the DRM core know we can handle it.
v2: Change to boolean true. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
All merged exc
On 02/11/2015 07:40 AM, Daniel Vetter wrote:
On Tue, Feb 10, 2015 at 05:16:12PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Therefore remove dead code.
Commit message should state that skl requires execlist, otherwise it's not
really clear why this is dead code. I've added that.
Ah
On Wed, Feb 11, 2015 at 08:44:47AM +0100, Daniel Vetter wrote:
> Forgotten ever since, but luckily we're at least good at memset.
>
> Testecase: igt/gem_ctx_create/invalid-pad
> Testecase: igt/gem_ctx_bad_destroy/invalid-pad
> Signed-off-by: Daniel Vetter
I wonder if we used mbz instead of pad,
On Wed, Feb 11, 2015 at 09:51:22AM +, Tvrtko Ursulin wrote:
>
> On 02/11/2015 08:15 AM, Daniel Vetter wrote:
> >On Tue, Feb 10, 2015 at 05:17:34PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Just a few basic tests to make sure fb modifiers can be used and
> >>behave sanely
On Wed, Feb 11, 2015 at 09:57:09AM +, Tvrtko Ursulin wrote:
>
> On 02/11/2015 07:58 AM, Daniel Vetter wrote:
> >On Tue, Feb 10, 2015 at 05:16:16PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Let the DRM core know we can handle it.
> >>
> >>v2: Change to boolean true. (Danie
Thanks for the suggestion Daniel, this seems simpler solution to the problem.
I'll check for corner cases and get back if any more changes are needed.
regards,
Sivakumar
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, Fe
Hi Dave -
Here's a batch of i915 fixes for drm-next, with more cc: stable material
than fixes specific to drm-next.
BR,
Jani.
The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1:
drm/i915: Update DRIVER_DATE to 20150130 (2015-01-30 22:37:54 +0100)
are available in th
On Wed, Feb 11, 2015 at 10:01:33AM +, Chris Wilson wrote:
> On Wed, Feb 11, 2015 at 08:44:47AM +0100, Daniel Vetter wrote:
> > Forgotten ever since, but luckily we're at least good at memset.
> >
> > Testecase: igt/gem_ctx_create/invalid-pad
> > Testecase: igt/gem_ctx_bad_destroy/invalid-pad
>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5752
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV +7 275/283
drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol
'intel_ring_setup_status_page' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
intel_ringbuffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: db275e69533f74b3d5cf2884cb8bba9d7640724d
commit: 64a008c61c4615ba0fffd1cdae7d39b4246048f8 [161/168] drm/i915: Make
intel_ring_setup_status_page() static
reproduce:
# apt-get install sparse
git checkout 64a008c61c4615
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Signed-off-by: Daniel Vetter
---
intel/intel_bufmgr_gem.c | 68
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/i
Well just core drm. All the other callers in there that still use
direct calls to ioctl have some custom retry logic already, so should
be good already.
freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do
about that.
Signed-off-by: Daniel Vetter
---
xf86drm.c | 4 ++--
1 file
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Signed-off-by: Daniel Vetter
---
xf86drmMode.c | 55 ---
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/xf86d
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
A bit overkill to update all the old legacy ioctl wrappers, but can't
hurt really either.
Signed-off-by: Daniel Vetter
---
xf86drm.c | 112 ++
On Wed, Feb 11, 2015 at 01:09:51PM +0200, Jani Nikula wrote:
>
> Hi Dave -
>
> Here's a batch of i915 fixes for drm-next, with more cc: stable material
> than fixes specific to drm-next.
>
> BR,
> Jani.
>
> The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1:
>
> drm/
These all moved to igt meanwhile.
Signed-off-by: Daniel Vetter
---
.gitignore| 4 --
tests/Makefile.am | 9
tests/gem_basic.c | 102
tests/gem_flink.c | 137 -
tests/gem_mmap.c
Hi Dave -
Another go, with "drm/i915: Do not invalidate obj->pages under
mempressure" dropped.
Here's a batch of i915 fixes for drm-next, with more cc: stable material
than fixes specific to drm-next.
BR,
Jani.
The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1:
drm
On Wed, Feb 11, 2015 at 6:42 AM, Daniel Vetter wrote:
> Well just core drm. All the other callers in there that still use
> direct calls to ioctl have some custom retry logic already, so should
> be good already.
>
> freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do
> about tha
Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards
we have only one M_N register set. To support DRRS on both scenarios
a input parameter to intel_dp_set_m_n is added.
In case of DRRS, When platform provides two set of M_N registers for dp,
we can program them with two different divid
From: Vandana Kannan
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will b
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-file of the debugfs
1. Encoder output type
2. DRRS Support on this CRTC
3. DRRS current state
4
On Wed, Feb 11, 2015 at 1:55 AM, Sean V Kelley wrote:
> No corruption seen. I will add reloc domains to my growing audit list.
One more for the libva audit list:
If you do any ioctl directly, please make sure that you clear the
ioctl structure with memset(&arg, 0, sizeof(arg)); or similar.
Othe
Hi,
This is preparation patch for "[PATCH] drm/i915/bdw: Add support for
DRRS to switch RR".
My bad that I have misplaced this in the thread.
On Wednesday 11 February 2015 06:13 PM, Ramalingam C wrote:
Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards
we have only one M_N regist
On 11 February 2015 at 11:42, Daniel Vetter wrote:
> Well just core drm. All the other callers in there that still use
> direct calls to ioctl have some custom retry logic already, so should
> be good already.
>
Afaics intel/intel_bufmgr_gem.c has one instance, plus most of the tests.
> freedreno
On 11 February 2015 at 11:42, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> A bit overkill to update all the old legacy ioctl wrappers, but can't
> hurt really either.
>
> Signed-off-by: Daniel Vet
On Tue, Feb 10, 2015 at 07:32:17PM +, Damien Lespiau wrote:
> This function is only used in intel_ringbuffer.c, so restrict it to that
> file. The function was moved around to avoid a forward declaration and
> group it with its user.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/
From: Tvrtko Ursulin
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
v2:
* Review feedback from Daniel Vetter:
1. Move cap detection into the subtest so skipping works.
2. Added some gtkdoc comments.
3. T
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5757
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 281/281
Reuse existing DP link training values i.e. voltage swing
and pre-emphasis levels, if DP port that we are connected
to hasn't changed. If we are unable to re-initialize DP
link, the fallback is to reset the link training values,
and restart.
modified: intel_dp.c
modified: intel_
On Wed, Feb 11, 2015 at 01:13:26PM +, Emil Velikov wrote:
> On 11 February 2015 at 11:42, Daniel Vetter wrote:
> > Well just core drm. All the other callers in there that still use
> > direct calls to ioctl have some custom retry logic already, so should
> > be good already.
> >
> Afaics intel
On 09/02/2015 19:33, Damien Lespiau wrote:
When enabling new platforms, we may not have any W/A to apply,
especially that, now, a bunch of them have to be done from the ring.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file change
intel-gpu-tools currently has a bunch of tests for suspend,
but currently none (that I could find) for hibernate.
Attached is a rudimentary patch to add said test. It does so
by repurposing the drv_suspend driver to handle both suspend
and hibernate, since the difference is miniscule.
I decided
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d4c82d7..4a60c6a 100644
--- a/drivers/gp
We use the pid of the process which opened our device when
we track which was the culprit of the gpu hang. But as that
file descriptor might get inherited, we might blame the
wrong process when we record the error state.
Track process identifiers in requests to always find
the correct offender.
C
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a3b979d..6fd6f26 100644
--- a
On Wed, 11 Feb 2015, Mika Kahola wrote:
> Reuse existing DP link training values i.e. voltage swing
> and pre-emphasis levels, if DP port that we are connected
> to hasn't changed. If we are unable to re-initialize DP
> link, the fallback is to reset the link training values,
> and restart.
Sorry
On 09/02/2015 19:33, Damien Lespiau wrote:
We'll gather cross-gen9 W/A in a separate function later.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
On 09/02/2015 19:33, Damien Lespiau wrote:
Let's also take the opportunity the remove the comment telling it's a
pre-prod W/A, it should be obvious from the stepping test.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i9
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5754
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -4 275/275
From: Ville Syrjälä
Set up the chv display PHY lane stagger registers according to
"Programming Guide for 1273 CHV eDP/DP/HDMI Display PHY" v1.04
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 13 +
drivers/gpu/drm/i915/intel_dp.c | 35 ++
From: Ville Syrjälä
For some reason link training fails when port B is being driven by pipe
A, and was previously driven by port B or the common lane was previously
powered off.
After staring at some register dumps I noticed some oddness with the DCC
calibration status bits, and after some exper
From: Ville Syrjälä
Here's the second part of my CHV display fixes pile. There are some really
weird things going on with the PHY, and this series includes whatever
workaround I managed to invent to overcome those issues.
The lane stagger setup I just gleaned from one of the docs, although I'm
n
From: Ville Syrjälä
With recent hardware/firmware there don't appear to be any glitches
on the other PHY when we toggle the cmnreset for the other PHY. So
detangle the cmnlane power wells from one another and let them be
controlled independently.
This reverts commit 3dd7b97458e8aa2d8985b46622d22
From: Ville Syrjälä
Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to
get corrupted. The values I've managed to read from it seem to have some
pattern but vary quite a lot. The corruption doesn't seem to just happen
when the register is accessed, but can also happen spontan
On 09/02/2015 19:33, Damien Lespiau wrote:
WaDisableAsyncFlipPerfMode isn't listed for SKL and
INSTPM_FORCE_ORDERING is MBZ so let's make a gen9 specific render init
function.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_lrc.c | 16 +++-
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_uncore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index c47a3ba..ad71575 1
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2043e82..a457c2
On 09/02/2015 19:33, Damien Lespiau wrote:
This function will host SKL-only W/As.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_
Dear Jani!
Thank you for the quick replay.
I tried and tried the v3.18 and v3.19-rv7 kernels, but thx X can't start.
Do you have any other idea?
BR,
Gergő
Üdvözlettel:
Nógrádi Gergely
gergely.nogr...@idata.hu
2015-02-04 14:34 GMT+01:00 Jani Nikula :
> On Mon, 02 Feb 2015, Gergely Nógrádi wr
2015-02-03 12:25 GMT-02:00 Damien Lespiau :
> At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value
> to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe
> eDRAM capabilities).
>
> To be more future proof, only look at bit 0 to detect eDRAM presence.
>
> Sign
On Wed, Feb 11, 2015 at 04:50:14PM +0200, Mika Kuoppala wrote:
> We use the pid of the process which opened our device when
> we track which was the culprit of the gpu hang. But as that
> file descriptor might get inherited, we might blame the
> wrong process when we record the error state.
>
> Tr
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/g
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 5 +
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/driv
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/
On Wed, Feb 11, 2015 at 01:27:14PM -0200, Paulo Zanoni wrote:
> 2015-02-03 12:25 GMT-02:00 Damien Lespiau :
> > At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value
> > to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe
> > eDRAM capabilities).
> >
> > To b
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drive
On Wed, Feb 11, 2015 at 03:42:16PM +, Nick Hoath wrote:
> On 09/02/2015 19:33, Damien Lespiau wrote:
> >Signed-off-by: Damien Lespiau
>
> Reviewed-by: Nick Hoath
Merged all the ones Nick has reviewd already.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 3
On Wed, Feb 11, 2015 at 04:57:06PM +0200, Jani Nikula wrote:
> On Wed, 11 Feb 2015, Mika Kahola wrote:
> > -
> > Intel Finland Oy
> > Registered Address: PL 281, 00181 Helsinki
> > Business Identity Code: 0357606 - 4
> > Domicil
On Wed, Feb 11, 2015 at 01:46:19PM +, Damien Lespiau wrote:
> On Tue, Feb 10, 2015 at 07:32:17PM +, Damien Lespiau wrote:
> > This function is only used in intel_ringbuffer.c, so restrict it to that
> > file. The function was moved around to avoid a forward declaration and
> > group it with
On Wed, Feb 11, 2015 at 10:57:08AM -0500, Jan Vesely wrote:
> On Wed, 2015-02-11 at 12:42 +0100, Daniel Vetter wrote:
> > We really have to do this to avoid surprises when extending the ABI
> > later on. Especially when growing the structures.
> >
> > A bit overkill to update all the old legacy io
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5755
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 275/275
On Wed, Feb 11, 2015 at 08:30:44AM +0100, Daniel Vetter wrote:
> On Tue, Feb 10, 2015 at 10:26:02PM -0800, O'Rourke, Tom wrote:
> > On Thu, Jan 29, 2015 at 08:56:06PM -0500, Michael Auchter wrote:
> > > On Thu, Jan 29, 2015 at 06:12:31PM +0100, Daniel Vetter wrote:
> > > > On Wed, Jan 28, 2015 at 1
v2: Use the recently introduced INTEL_REVID() and SKL_REVID defines
(Nick Hoath)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d
On Wed, Feb 11, 2015 at 03:29:51PM +, Nick Hoath wrote:
> On 09/02/2015 19:33, Damien Lespiau wrote:
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 8
> > 2 files changed, 11 insertions(+),
I have no idea how that crept in, but we need to do the write from the
ring and this is a masked register. Two fixes in 1!
Cc: Nick Hoath
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/driv
It's always a good idea to keep static analysis happy (also because it
prompts doing the check like I proposed :), this time smatch complains:
drivers/gpu/drm/i915/intel_ringbuffer.c:891 gen9_init_workarounds() warn:
always true condition '((->dev->pdev->revision) >= (0)) => (0-255 >= 0)'
That'
The first one is minor, while it's puzzling I managed to give my r-b tag for
the the second one. Oh Well.
--
Damien
Damien Lespiau (2):
drm/i915/skl: Fix always true comparison in a revision id check
drm/i915/skl: Use a LRI for WaDisableDgMirrorFixInHalfSliceChicken5
drivers/gpu/drm/i915/i
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> intel/intel_bufmgr_gem.c | 68
>
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> xf86drmMode.c | 55 ++
Under what product should I submit the bug? dmr.debug=14 doesn't show much.
[jon@localhost]~% dmesg | grep drm
[1.936241] [drm] Initialized drm 1.1.0 20060810
[2.193043] [drm] Memory usable by graphics device = 2048M
[2.193046] [drm] Replacing VGA console driver
[2.18] [drm] S
On Wed, 2015-02-11 at 12:42 +0100, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> A bit overkill to update all the old legacy ioctl wrappers, but can't
> hurt really either.
>
> Signed-off-by: Dani
From: "Lu, Han"
This patch adds support for dumping audio registers of Skylake.
Signed-off-by: Lu, Han
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 945b136..d447902 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -362,6 +362,21 @@ static const
On Wed, 11 Feb 2015, jon wrote:
> Under what product should I submit the bug? dmr.debug=14 doesn't show much.
The link I provided has those filled in. Product DRI, component
DRM/Intel.
Jani.
>
> [jon@localhost]~% dmesg | grep drm
> [1.936241] [drm] Initialized drm 1.1.0 20060810
> [2.19
On Wed, 11 Feb 2015, jon wrote:
> Under what product should I submit the bug? dmr.debug=14 doesn't show much.
Oh, and drm.debug will be more helpful than dmr.debug. ;)
Jani.
>
> [jon@localhost]~% dmesg | grep drm
> [1.936241] [drm] Initialized drm 1.1.0 20060810
> [2.193043] [drm] Memor
1 - 100 of 102 matches
Mail list logo
