Hi,
For IVB, I just checked the 3.18-rc1, it has the following patch:
commit c9224faa59c3071ecfa2d4b24592f4eb61e57069
Author: Brad Volkin
Date: Tue Jun 17 14:10:34 2014 -0700
drm/i915: Add some L3 registers to the parser whitelist
Beignet needs these in order to program the L3 cache c
Actually, I just realized today I had booted the wrong kernel ()
My mistake, sorry about that.
Here is the right drm.debug output, after recompiling (vanilla kernel).
Options :
nohz=on nmi_watchdog=0 pcie=aspm i915.semaphores=1 i915.i915_enable_rc6=1
i915.i915_enable_fbc=1 i915.lvds_downcloc
Signed-off-by: Chris Wilson
---
tests/gem_concurrent_blit.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/gem_concurrent_blit.c b/tests/gem_concurrent_blit.c
index 7d8d628..9a9169e 100644
--- a/tests/gem_concurrent_blit.c
+++ b/tests/gem_concurrent_blit.c
@@ -159,6 +15
Signed-off-by: Chris Wilson
---
lib/ioctl_wrappers.c | 76 ++
lib/ioctl_wrappers.h | 7 +-
tests/.gitignore | 1 +
tests/Makefile.am | 2 +
tests/Makefile.sources | 1 +
tests/gem_mmap_wc.c| 365 +
6 files changed
These are not the igt I was looking for.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Chris Wilson
---
tests/gem_gtt_speed.c | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/tests/gem_gtt_speed.c b/tests/gem_gtt_speed.c
index c858103..7e1e5f9 100644
--- a/tests/gem_gtt_speed.c
+++ b/tests/gem_gtt
At the end of a subtest, check for any WARNs or ERRORs (or worse!)
emitted since the start of our test and FAIL the subtest if any are
found. This will prevent silent false test positives due to oops being
missed or being falsely reported as TIMEOUTs.
Signed-off-by: Chris Wilson
---
lib/igt_core
---
tools/intel_reg_read.c | 50 ++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c
index 3b91291..77fd21b 100644
--- a/tools/intel_reg_read.c
+++ b/tools/intel_reg_read.c
@@ -46,13 +46,
This will allow us to consult more info before deciding whether to flip
or do a full mode set.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
This only affects the fastboot path as-is. In that case, we simply need
to make sure that we update the pipe size at the first mode set. Rather
than putting it off until we decide to flip (if indeed we do end up
flipping), update the pipe size as appropriate a bit earlier in the
set_config call.
If these change (e.g. after a modeset following a fastboot), we need to
do a full mode set.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_disp
This is useful for checking things later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h | 4 +++
drivers/gpu/drm/i915/intel_hdmi.c | 61 +++
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm
This allows us to calculate the full pipe config before we do any mode
setting work.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 93 +---
1 file changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.
This should allow us to avoid mode sets for some panel fitter config
changes.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i91
On Thu, 23 Oct 2014 19:28:18 +0100
Chris Wilson wrote:
> On Thu, Oct 23, 2014 at 06:59:14PM +0200, Jesse Barnes wrote:
> > This will allow us to consult more info before deciding whether to flip
> > or do a full mode set.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/int
On Thu, Oct 23, 2014 at 06:59:14PM +0200, Jesse Barnes wrote:
> This will allow us to consult more info before deciding whether to flip
> or do a full mode set.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 36
> ++--
> 1 file cha
On Thu, Oct 23, 2014 at 08:35:24PM +0300, Mika Kuoppala wrote:
> because it is handy to direct bug reporters to do things like:
> 'grep -i suspend /sys/kernel/debug/dri/0/i915_gpu_state'
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 42
> ++
because it is handy to direct bug reporters to do things like:
'grep -i suspend /sys/kernel/debug/dri/0/i915_gpu_state'
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 +++
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/dr
If these change (e.g. after a modeset following a fastboot), we need to
do a full mode set.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_disp
So we can call it earlier for use in computing mode config changes.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 63 +++-
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/
This will allow us to consult more info before deciding whether to flip
or do a full mode set.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
This is useful for checking things later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h | 4 +++
drivers/gpu/drm/i915/intel_hdmi.c | 61 +++
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm
Version 2 in process now. Responses in line below.
On 10/20/2014 10:48 AM, Paulo Zanoni wrote:
Hi
Since I already commented about the coding style on the previous
reviews, I'll ignore that aspect for the comments below.
I think all the style issues have been resolved. Checkpatch.pl has 0
erro
On 10/22/2014 7:22 AM, Jani Nikula wrote:
On Thu, 09 Oct 2014, Todd Previte wrote:
Link training for Displayport can fail in many ways and at multiple different
points
during the training process. Previously, errors were logged but no additional
action
was taken based on them. Consequently,
From: Akash Goel
This patch provides support to create write-combining virtual mappings of
GEM object. It intends to provide the same funtionality of 'mmap_gtt'
interface without the constraints and contention of a limited aperture
space, but requires clients handles the linear to tile conversion
On Thu, Oct 23, 2014 at 08:34:27AM -0700, armin.c.re...@intel.com wrote:
> From: Armin Reese
>
> The file drivers/gpu/drm/i915/intel_renderstate_gen8.c is
> updated to the version created by IGT null_state_gen
>
> Signed-off-by: Armin Reese
For the first 3 patches:
Reviewed-by: Damien Lespiau
We already disable everything during S4 freeze, except the PCI device
itself. There is no reason why we couldn't disable that too and doing
so allows us to unify these handlers in the next patch with the
corresponding S3 suspend/resume handlers.
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
By now we handle switcheroo and legacy suspend/resume the same way, so
no need to keep separate functions for them.
No functional change.
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 11 +++
drivers
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 56c7570..524c3df 100644
--- a/drivers/gpu/drm/i915/i915_drv
This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.
v2:
- add a comment that the freeze handler is also called after rebooting
- add a comment that the thaw handler is also called to recover from
errors (Ville)
- add the PM event names (
The suspend_late handler saves some registers and powers off the device,
so it doesn't have a big overhead. Calling it at S4 poweroff_late time
makes the power off handling identical to the S3 suspend and S4 freeze
handling, so do this for consistency.
Signed-off-by: Imre Deak
Reviewed-by: Ville
To avoid processing hotplug events we disable connector polling for the
duration of S3 suspend. We also disable it for S4 freeze, and keep it
disabled after S4 thaw. This won't prevent though hotplug processing,
since we re-enable interrupts anyway. There is also no need to prevent
it at that time,
Checking for GT faults is not specific in any way to S4 thaw, so do it
also during S3 resume, S4 restore and driver load time. This allows us to
unify the Sx handlers in an upcoming patch.
v2:
- move the check to intel_uncore_early_sanitize(), so we check at driver
load time too (Chris)
Signed-
i915_suspend() is called from the DRM legacy S3 suspend/S4 freeze paths
and the switcheroo suspend path. For switcheroo we only ever need to
perform a full suspend (PM_EVENT_SUSPEND) and for the DRM legacy path
we can handle the S4 freeze (PM_EVENT_FREEZE) the same way as S3
suspend. The only diffe
By now the S4 freeze/thaw and S3 suspend/resume events are handled the
same way, so we can rename the freeze/thaw internal helpers to
suspend/resume accordingly to make clearer what the helpers do. Also
rename i915_resume_early to i915_drm_resume_early aligning it with the
rest of the helper names.
During switcheroo/legacy suspend we don't call the suspend_late handler
but when resuming afterwards we call resume_early. This happened to work
so far, since suspend_late only disabled the PCI device. This changed in
commit 016970beb05da6285c2f3ed2bee1c676cb75972e
Author: Sagar Kamble
Date: We
If the device is suspended already through the switcheroo interface we
shouldn't suspend it again or resume it after suspend. We have the
corresponding check for S3 suspend already, add it for all the other
S3 and S4 handlers. Also move the check from i915_resume_early() to
i915_resume_legacy(), so
The S3 and S4 events are now handled the same way internally, there is no
need to keep separate wrapper functions around them. Simply reuse the
suspend/resume versions everywhere.
No functional change.
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 10
The logic to skip restoring GTT mappings was added to speed up
suspend/resume, but not on old GENs where not restoring them caused
problems. The check for old GENs is based on the existence of OpRegion,
but this doesn't work since opregion is initialized only after
the check. So we end up always re
This is v2 of [1]. I addressed Chris' and Ville's comments in it and
rebased it against the latest -nightly kernel.
[1]
http://lists.freedesktop.org/archives/intel-gfx/2014-September/052199.html
Imre Deak (14):
drm/i915: factor out i915_drm_suspend_late
drm/i915: unify legacy S3 suspend and S
This is needed by an upcoming patch fixing the switcheroo/legacy suspend
paths.
No functional change.
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/d
On 23/10/2014 16:51, Daniel Vetter wrote:
On Thu, Oct 23, 2014 at 04:29:30PM +0100, Arun Siluvery wrote:
We would want to apply some of the workarounds based on a condition to a
particular platform or Gen but we may not know all possible controlling
parameters in advance hence allow to define op
Signed-off-by: Daniel Vetter
---
tests/gem_bad_reloc.c| 8 +++-
tests/kms_psr_sink_crc.c | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/tests/gem_bad_reloc.c b/tests/gem_bad_reloc.c
index d0eb45cbc7cd..df0100fa419f 100644
--- a/tests/gem_bad_reloc.c
+++ b/tests/gem
On Thu, Oct 23, 2014 at 05:31:12AM -0700, Daniel Vetter wrote:
> On Wed, Oct 22, 2014 at 09:04:32AM -0700, Volkin, Bradley D wrote:
> > [snip]
> >
> > On Tue, Oct 21, 2014 at 08:50:33AM -0700, Daniel Vetter wrote:
> > > On Thu, Oct 16, 2014 at 12:24:42PM -0700, bradley.d.vol...@intel.com
> > > wr
On Thu, Oct 23, 2014 at 04:29:30PM +0100, Arun Siluvery wrote:
> We would want to apply some of the workarounds based on a condition to a
> particular platform or Gen but we may not know all possible controlling
> parameters in advance hence allow to define open conditions; a WA makes
> it to the l
On Thu, Oct 23, 2014 at 05:42:47PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Thu, Oct 23, 2014 at 01:42:38PM +0100, Damien Lespiau wrote:
> >> On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote:
> >> > On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
> >
From: Sonika Jindal
v2: Slight rebasing onto latest i-g-t codebase (Matt).
Signed-off-by: Sonika Jindal
Reviewed-by: Matt Roper
Signed-off-by: Matt Roper
---
tests/kms_rotation_crc.c | 79 ++--
1 file changed, 57 insertions(+), 22 deletions(-)
dif
On Thu, Oct 23, 2014 at 04:24:46PM +0100, Thomas Daniel wrote:
> Write HWS_PGA address even in execlists mode as the global hardware status
> page is still required. This address was previously uninitialized and
> HWSP writes would clobber whatever buffer happened to reside at GGTT
> address 0.
I
From: Armin Reese
The file drivers/gpu/drm/i915/intel_renderstate_gen8.c is
updated to the version created by IGT null_state_gen
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/intel_renderstate_gen8.c | 802 --
1 file changed, 640 insertions(+), 162 deletions(-)
d
On Thu, Oct 23, 2014 at 07:41:34AM -0700, Matt Roper wrote:
> From: Ville Syrjälä
>
> The cursor plane also supports 180 degree rotation. Add a new
> "cursor-rotation" property on the crtc which controls this.
>
> Unlike sprites, the cursor has a fixed size, so if you have a small
> cursor image
From: Armin Reese
Existing Gen6, 7, 8, and 9 golden context source files are
currently generated without the copyright header. Adding
them manually here.
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/intel_renderstate_gen6.c | 23 +++
drivers/gpu/drm/i915/intel_rende
From: Armin Reese
The new 'i915_context_dump' file generates a hex dump of the
entire logical context DRM object. It is useful for
validating the contents of the default context set up by
the golden state batch buffer.
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/i915_debugfs.c | 64 ++
We would want to apply some of the workarounds based on a condition to a
particular platform or Gen but we may not know all possible controlling
parameters in advance hence allow to define open conditions; a WA makes
it to the list only if the condition is true.
With the appropriate conditions we
Write HWS_PGA address even in execlists mode as the global hardware status
page is still required. This address was previously uninitialized and
HWSP writes would clobber whatever buffer happened to reside at GGTT
address 0.
Issue: VIZ-2020
Signed-off-by: Thomas Daniel
---
drivers/gpu/drm/i915/
Chris Wilson writes:
> On Thu, Oct 23, 2014 at 01:42:38PM +0100, Damien Lespiau wrote:
>> On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote:
>> > On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
>> > > The number of DWords should be even when doing ring emits as
>> > > c
From: Ville Syrjälä
The cursor plane also supports 180 degree rotation. Add a new
"cursor-rotation" property on the crtc which controls this.
Unlike sprites, the cursor has a fixed size, so if you have a small
cursor image with the rest of the bo filled by transparent pixels,
simply flipping the
Cc Jani for notifying the patch update:
Add missing v2 changelog:
Take Jani's comment: remove BUG_ON in i915_driver_load
Take Daniel's comment: extract the VED setup related functions to
i915_ved.c
Take Daniel's comment: add kerneldoc to describe i915_ved.c
Take Da
On Thu, Oct 23, 2014 at 02:39:41PM +0100, Damien Lespiau wrote:
> On Thu, Oct 23, 2014 at 03:28:24PM +0200, Daniel Vetter wrote:
> > On Mon, Sep 29, 2014 at 3:31 PM, Daniel Vetter
> > wrote:
> > > Not having checks for this isn't good.
> > >
> > > I've checked igt and libdrm and they all already
On 10/21/2014 7:45 AM, Daniel Vetter wrote:
On Thu, Oct 09, 2014 at 09:39:01AM -0700, Todd Previte wrote:
Link training for Displayport can fail in many ways and at multiple different
points
during the training process. Previously, errors were logged but no additional
action
was taken based o
On 23/10/2014 14:41, Ville Syrjälä wrote:
On Thu, Oct 23, 2014 at 01:50:23PM +0100, Chris Wilson wrote:
On Thu, Oct 23, 2014 at 01:42:38PM +0100, Damien Lespiau wrote:
On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote:
On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
On Thu, Oct 23, 2014 at 01:50:23PM +0100, Chris Wilson wrote:
> On Thu, Oct 23, 2014 at 01:42:38PM +0100, Damien Lespiau wrote:
> > On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
> > > > The number of DWords should
On Thu, Oct 23, 2014 at 03:28:24PM +0200, Daniel Vetter wrote:
> On Mon, Sep 29, 2014 at 3:31 PM, Daniel Vetter wrote:
> > Not having checks for this isn't good.
> >
> > I've checked igt and libdrm and they all already clear flags properly.
> > So we're lucky and should be able to sneak this ABI c
On Mon, Sep 29, 2014 at 3:31 PM, Daniel Vetter wrote:
> Not having checks for this isn't good.
>
> I've checked igt and libdrm and they all already clear flags properly.
> So we're lucky and should be able to sneak this ABI clarification in.
>
> Testcase: igt/gem_wait/invalid-flags
> Signed-off-by
On Thu, Oct 23, 2014 at 12:56:46PM +0100, Chris Wilson wrote:
> On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> >
>
> > This is for improving the CPU write operation performance, as with such
> > mapping, writes are almost 50% faster than with mmap_gt
2014-10-23 10:50 GMT-02:00 Daniel Vetter :
> Hi Tood,
>
> Paulo already mentioned it, so I'll just rehash quickly: I think the
> points from the internal pre-review first need to be address before we can
> dig into details. I know that the discussion there pettered out a bit, but
> imo it's the pat
Hi Tood,
Paulo already mentioned it, so I'll just rehash quickly: I think the
points from the internal pre-review first need to be address before we can
dig into details. I know that the discussion there pettered out a bit, but
imo it's the patch authors responsibility to pick that up again and pi
On Thu, Oct 23, 2014 at 01:42:38PM +0100, Damien Lespiau wrote:
> On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
> > > The number of DWords should be even when doing ring emits as
> > > command sequences require QWor
On 10/23/2014 8:28 PM, Daniel Vetter wrote:
On Thu, Oct 23, 2014 at 03:28:24PM +0800, Yu Zhang wrote:
Empty commit messages aren't good. Even for really simple refactoring
please explain in 1-2 sentences the motivation for the patch, since the
change itself doesn't really say that. For this on
On Thu, Oct 23, 2014 at 02:21:02PM +0200, Daniel Vetter wrote:
> On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
> > The number of DWords should be even when doing ring emits as
> > command sequences require QWord alignment.
> >
> > v2: user LRI variant that can write multiple regs
Hi,
> I guess from a really high level this boils down to having a xen-like
> design (where the hypervisor and dom0 driver are separate, but cooperate
> somewhat) or kvm (where the virtualization sits on top of a normal
> kernel). Afaics the kvm model seems to have a lot more momentum overall.
On Wed, Oct 22, 2014 at 09:04:32AM -0700, Volkin, Bradley D wrote:
> [snip]
>
> On Tue, Oct 21, 2014 at 08:50:33AM -0700, Daniel Vetter wrote:
> > On Thu, Oct 16, 2014 at 12:24:42PM -0700, bradley.d.vol...@intel.com wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > b/driv
On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
> The number of DWords should be even when doing ring emits as
> command sequences require QWord alignment.
>
> v2: user LRI variant that can write multiple regs in one go (Damien).
> We can simply insert one NOP at the end instead of
On Wed, Oct 22, 2014 at 09:32:23PM +0300, Jani Nikula wrote:
> On Tue, 21 Oct 2014, Mika Kuoppala wrote:
> > Regression from:
> >
> > commit be4710a541b517b5f8663448bffed5656d59b47b
> > Author: Thomas Wood
> > Date: Fri Oct 10 11:20:35 2014 +0100
> >
> > lib: add common min and max macros
>
On Wed, Oct 22, 2014 at 05:01:54PM -0200, Paulo Zanoni wrote:
> 2014-10-22 9:20 GMT-02:00 Imre Deak :
> > On Tue, 2014-10-21 at 19:05 +0200, Daniel Vetter wrote:
> >> On Mon, Oct 20, 2014 at 01:20:50PM +0300, Imre Deak wrote:
> >> > On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote:
> >> > > Fr
On Thu, Oct 23, 2014 at 08:56:44AM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to run intel_uncore_early_sanitize() before we touch any
> registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit
> is set, so we need to clear it - through intel_uncore_early_sanitize()
On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This is for improving the CPU write operation performance, as with such
> mapping, writes are almost 50% faster than with mmap_gtt. Also it avoids the
I doubt it is the actual write that is faster. For
2014-10-22 6:56 GMT-02:00 Siluvery, Arun :
> On 22/10/2014 08:35, Ville Syrjälä wrote:
>>
>> On Tue, Oct 21, 2014 at 07:40:35PM +0200, Daniel Vetter wrote:
>>>
>>> On Tue, Oct 21, 2014 at 02:58:08PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni
Otherwise, a simple "cat" to the
On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
> drivers/gpu/drm/i915/i915_dma.c | 3 +++
> drivers/gpu/drm/i915/i915_gem.c | 17 +
> include/uapi/drm/i915_drm.h | 4
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_d
Hi,
> Stuf like driver load/unload, suspend/resume, runtime pm and gpu reset are
> already supre-fragile as-is. Every time we change something in there, a
> bunch of related things fall apart. With vgt we'll have even more
> complexity in there, and I really think we need to make that complexity
From: Paulo Zanoni
We want to run intel_uncore_early_sanitize() before we touch any
registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit
is set, so we need to clear it - through intel_uncore_early_sanitize()
- before we do anything else. With the current code, we don't clear
the
From: Paulo Zanoni
Because, really, the abstraction is not working for us. It is nice for
VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change
this code due to a recently-discovered bug, but we can't seem to find
a nice solution that repects the current abstraction. So let's kil
On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This patch provides support to create uncached virtual mappings for a Gem
> object. It intends to provide the same funtionality of 'mmap_gtt' interface
> without the constraints of a limited aperture spac
From: Akash Goel
A new libdrm interface 'drm_intel_gem_bo_map_uc' is provided
by this patch. Through this interface Gfx clients can create
uncached virtual mappings of the Gem object. It will provide the
same funtionality of 'mmap_gtt' interface without the constraints
of limited aperture space,
From: Akash Goel
This patch provides support to create uncached virtual mappings for a Gem
object. It intends to provide the same funtionality of 'mmap_gtt' interface
without the constraints of a limited aperture space, but provided clients
handles the linear to tile conversion on their own.
This
On Wed, Oct 22, 2014 at 08:42:32AM -0700, Jesse Barnes wrote:
> On Tue, 21 Oct 2014 16:53:02 +0200
> Daniel Vetter wrote:
>
> > On Thu, Oct 09, 2014 at 12:57:45PM -0700, Jesse Barnes wrote:
> > > From: Kristian Høgsberg
> > >
> > > The BIOS may set a native mode that doesn't quite match the pre
On Thu, Oct 23, 2014 at 11:13:51AM +0800, Jike Song wrote:
> On 10/22/2014 05:48 PM, Daniel Vetter wrote:
> >So on a very high level I don't understand this design. For the guest side
> >it's completely clear that we need a bunch of hooks over the driver to
> >make paravirtualization work.
> >
> >B
On Wed, Oct 22, 2014 at 05:29:24PM -0700, Matt Roper wrote:
> On Tue, Oct 07, 2014 at 08:43:46AM +, Jindal, Sonika wrote:
> > Hi,
> >
> > Did anybody get a chance to look at this patch?
> >
> > Thanks,
> > Sonika
>
> Looks like we waited a bit too long and the codebase has evolved, so I
> ne
Signed-off-by: Yu Zhang
---
drivers/gpu/drm/i915/intel_uncore.c | 76 ++---
1 file changed, 28 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 0b0f4f8..9b228e3 100644
--- a/drivers/gpu/dr
On 10/22/2014 11:33 PM, Daniel Vetter wrote:
On Wed, Oct 22, 2014 at 08:27:50PM +0800, Yu, Zhang wrote:
On 10/22/2014 12:40 AM, Daniel Vetter wrote:
On Thu, Oct 16, 2014 at 02:24:27PM +0800, Yu Zhang wrote:
In the virtualized environment, forcewake operations are not
necessory for the driv
> > >
> > > With that out of the way some high-level review:
> > > - I think we need the full libva implementation to review the interfaces
> > > properly. At least the little libdrm test program doesn't seem to fully
> > > exercise it all.
> >
> > The libva driver need some time to be fully op
90 matches
Mail list logo