[ Sending to intel-gfx only for 1st feedback ]
Hi,
while still digging into my next-20130813 issue, I have searched for
some defines:
$ egrep
'I915_CACHEING_CACHED|I915_CACHING_CACHED|I915_CACHEING_NONE|I915_CACHING_NONE'
-nr ~/src/linux-kernel/linux/drivers/gpu/drm/i915/
On Wed, Aug 14, 2013 at 8:45 AM, Sedat Dilek sedat.di...@gmail.com wrote:
[ Sending to intel-gfx only for 1st feedback ]
Hi,
while still digging into my next-20130813 issue, I have searched for
some defines:
$ egrep
On Wed, Aug 14, 2013 at 8:52 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Aug 14, 2013 at 8:45 AM, Sedat Dilek sedat.di...@gmail.com wrote:
[ Sending to intel-gfx only for 1st feedback ]
Hi,
while still digging into my next-20130813 issue, I have searched for
some defines:
$ egrep
On Wed, Aug 14, 2013 at 9:12 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 08:45:47AM +0200, Sedat Dilek wrote:
[ Sending to intel-gfx only for 1st feedback ]
Hi,
while still digging into my next-20130813 issue, I have searched for
some defines:
[snip]
I also
On Wed, Aug 14, 2013 at 08:45:47AM +0200, Sedat Dilek wrote:
[ Sending to intel-gfx only for 1st feedback ]
Hi,
while still digging into my next-20130813 issue, I have searched for
some defines:
[snip]
I also checked intel-gpu-tools which has also cach***e*** pattern in
some defines.
It appears that Valleyview shares its VGA encoder with more recent
siblings and requires the same forced detection cycle after a hardware
reset before we can rely on hotplugging.
Reported-and-tested-by: kobeqin kobe@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67733
On Tue, Aug 13, 2013 at 06:11:59PM -0700, Ben Widawsky wrote:
On Tue, Aug 13, 2013 at 06:09:09PM -0700, Ben Widawsky wrote:
From: Ben Widawsky b...@bwidawsk.net
In order to transition more of our code over to using a VMA instead of
an OBJ, VM pair - we must have the vma accessible at
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
configure.ac | 4 ++--
src/sna/kgem.c | 50 +-
src/sna/kgem.h | 2 +-
3 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/configure.ac b/configure.ac
index 43c33eb..211a086 100644
Use the standard inversely ordered goto label stack for everything.
Spotted while reviewing place where we might need to to call
vma_destroy but failed to do so.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +++--
1 file changed, 3
On Wed, Aug 14, 2013 at 10:01:13AM +0200, Sedat Dilek wrote:
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
Am I the only one who reads that as a hard 'ch' without the 'e'?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx
On Tue, Aug 13, 2013 at 06:09:06PM -0700, Ben Widawsky wrote:
VMAs can be created and not bound. One may think of it as lazy cleanup,
and safely gloss over the conditions which manufacture it. In either
case, when the object backing the i915 vma is destroyed, we must cleanup
the vma without
On Wed, Aug 14, 2013 at 10:05 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 10:01:13AM +0200, Sedat Dilek wrote:
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
Am I the only one who reads that as a hard 'ch' without the 'e'?
I am not an English native or teacher:
On Wed, Aug 14, 2013 at 10:09:23AM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 10:05 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 14, 2013 at 10:01:13AM +0200, Sedat Dilek wrote:
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
Am I the only one who reads that as a
On Wed, Aug 14, 2013 at 10:06:30AM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 06:09:06PM -0700, Ben Widawsky wrote:
VMAs can be created and not bound. One may think of it as lazy cleanup,
and safely gloss over the conditions which manufacture it. In either
case, when the object
AFAICS, there are more updates needed to be in sync with recent kernel-drm.
I fell over the misspelling when digging into an issue in Linux-next.
The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
Here, I had a look especially at the defined macros (defines).
Signed-off-by:
On Tue, Aug 13, 2013 at 06:09:06PM -0700, Ben Widawsky wrote:
VMAs can be created and not bound. One may think of it as lazy cleanup,
and safely gloss over the conditions which manufacture it. In either
case, when the object backing the i915 vma is destroyed, we must cleanup
the vma without
Use () to make for neater alignment of the split lines, too. With this
we ditch another jump through the obj_gtt_size/offset indirection
maze.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 9 -
1
On Tue, Aug 13, 2013 at 03:37:56PM +0300, Ville Syrjälä wrote:
On Tue, Aug 13, 2013 at 01:20:13PM +0100, Chris Wilson wrote:
On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrjälä wrote:
Thinking about this stuff a bit, I think I actually came up with a
scenario where we would currently
On Tue, Aug 13, 2013 at 06:09:08PM -0700, Ben Widawsky wrote:
The conditional is usually a recoverable driver bug, and so WARNing, and
preventing the drm_mm code from doing potential damage (BUG) is
desirable.
This issue was hit and fixed twice while developing the i915 multiple
address
On Wed, Aug 14, 2013 at 10:49:11AM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 03:37:56PM +0300, Ville Syrjälä wrote:
On Tue, Aug 13, 2013 at 01:20:13PM +0100, Chris Wilson wrote:
On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrjälä wrote:
Thinking about this stuff a bit, I
Hi Ben,
For my own review benefit I've slashed your patch into pieces and split out 3
prep patches. Overall diff is unchanged with the exception of a now stale FIXME
comment that I've killed. Still need to do the in-depth review of the last
patch, but looks good thus far.
Cheers, Daniel
From: Ben Widawsky b...@bwidawsk.net
To convert the execbuf code over to use vmas natively we need to
shuffle the exec_list a bit. This patch here just prepares things with
the debugfs code, which also uses the old exec_list list_head, newly
called obj_exec_link.
Signed-off-by: Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net
The execbuf wants to do relocations usings vmas, so we need a
vma-exec_list. The eviction code also uses the old obj execbuf list
for it's own book-keeping, but would really prefer to deal in vmas
only. So switch it over to the new list.
Again this is just a
From: Ben Widawsky b...@bwidawsk.net
In the new execbuf code we want to track buffers using the vmas even
before they're all properly mapped. Which means that bind_to_vm needs
to deal with buffers which have preallocated vmas which aren't yet
bound.
This patch implements this prep work and
From: Ben Widawsky b...@bwidawsk.net
In order to transition more of our code over to using a VMA instead of
an OBJ, VM pair - we must have the vma accessible at execbuf time. Up
until now, we've only had a VMA when actually binding an object.
The previous patch helped handle the distinction on
On Wed, Aug 14, 2013 at 11:38:33AM +0200, Daniel Vetter wrote:
From: Ben Widawsky b...@bwidawsk.net
To convert the execbuf code over to use vmas natively we need to
shuffle the exec_list a bit. This patch here just prepares things with
the debugfs code, which also uses the old exec_list
More typo fallout:
On Wednesday 14 August 2013 00:17:27 Damien Lespiau wrote:
This can then be used by DRM drivers to setup their vendor infoframes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 36
On Wednesday 14 August 2013 00:17:16 Damien Lespiau wrote:
Following up the first instance of this series:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
Here is a v2 with Ville's review pass and a few additions:
- Alternate clock modes for 4k resolutions
-
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
On Wednesday 14 August 2013 00:19:14 Damien Lespiau wrote:
The HDMI vendor infoframe can contain a HDMI VIC (as of HDMI 1.4, only
used for 4k formats).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
In the execbuf code we don't clean up any vmas which ended up not
getting bound for code simplicity. To make sure that we don't end up
creating multiple vma for the same vm kill the somewhat dangerous
vma_create function and inline it into lookup_or_create.
This is just a safety measure to
On Wed, Aug 14, 2013 at 09:54:05AM +0100, Chris Wilson wrote:
On Wed, Aug 14, 2013 at 10:49:11AM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 03:37:56PM +0300, Ville Syrjälä wrote:
On Tue, Aug 13, 2013 at 01:20:13PM +0100, Chris Wilson wrote:
On Tue, Aug 13, 2013 at 03:12:59PM
Minor typo - feel free to ignore:
On Wednesday 14 August 2013 00:17:19 Damien Lespiau wrote:
HDMI 1.4 adds 4 4k x 2k modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the 4096x2160 string (nice
On Wed, Aug 14, 2013 at 12:17:20AM +0100, Damien Lespiau wrote:
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 68
++
1 file changed, 62
On Wed, Aug 14, 2013 at 12:17:22AM +0100, Damien Lespiau wrote:
Just like:
Author: Damien Lespiau damien.lesp...@intel.com
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar
On Wed, Aug 14, 2013 at 12:17:23AM +0100, Damien Lespiau wrote:
Provide the programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses,
On Wed, Aug 14, 2013 at 10:13 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 10:09:23AM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 10:05 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 14, 2013 at 10:01:13AM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 12:17:26AM +0100, Damien Lespiau wrote:
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
On Wed, Aug 14, 2013 at 12:17:24AM +0100, Damien Lespiau wrote:
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Terje Bergström
On Wed, Aug 14, 2013 at 12:17:23AM +0100, Damien Lespiau wrote:
Provide the programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor
On Wed, Aug 14, 2013 at 12:17:16AM +0100, Damien Lespiau wrote:
Following up the first instance of this series:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
Here is a v2 with Ville's review pass and a few additions:
- Alternate clock modes for 4k resolutions
sedat.di...@gmail.com
---
Sedak, can you please apply this patch and then attach the contents of
/sys/kernel/debug/dri/0/i915_gem_gtt with the broken display?
Compiling... next-20130814 with drm-intel-nightly (up to commit
d93f59e86ae93066969fa8ae2a6c9ccc7fc4728d) plus this patch.
How do you want
On Wed, Aug 14, 2013 at 11:59:09AM +0200, Daniel Vetter wrote:
In the execbuf code we don't clean up any vmas which ended up not
getting bound for code simplicity. To make sure that we don't end up
creating multiple vma for the same vm kill the somewhat dangerous
vma_create function and inline
On Wed, Aug 14, 2013 at 12:49:04PM +0100, Chris Wilson wrote:
On Wed, Aug 14, 2013 at 11:59:09AM +0200, Daniel Vetter wrote:
In the execbuf code we don't clean up any vmas which ended up not
getting bound for code simplicity. To make sure that we don't end up
creating multiple vma for the
In the execbuf code we don't clean up any vmas which ended up not
getting bound for code simplicity. To make sure that we don't end up
creating multiple vma for the same vm kill the somewhat dangerous
vma_create function and inline it into lookup_or_create.
This is just a safety measure to
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote:
Requested output and dmesg files attached.
( Should I attach the one with BROKEN display - I mean w/o doing a
re-login and display REPAIRED? )
Yes
On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote:
Requested output and dmesg files attached.
( Should I attach the one with
Hi,
I'm trying to add support for device assignment of PCI VGA devices with
VFIO and QEMU. For normal, discrete discrete graphics the Linux VGA
arbiter works fairly well, disabling VGA on one bridge and adding it to
another (though I wish all the kernel VGA drivers made use of it). The
i915
On Wed, Aug 14, 2013 at 3:02 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 03:02:37PM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote:
Requested
On Wed, Aug 14, 2013 at 3:44 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 03:02:37PM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 04:29:43PM +0300, Jani Nikula wrote:
Add definitions for VLV MIPI DSI registers.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 409
+++
1 file changed, 409 insertions(+)
diff --git
On Mon, Aug 12, 2013 at 06:06:48PM +, Zanoni, Paulo R wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Sunday, August 04, 2013 4:50 PM
To: Paulo Zanoni
Cc: Ville Syrjälä; intel-gfx@lists.freedesktop.org; Zanoni,
On Wed, Aug 14, 2013 at 07:23:57AM -0600, Alex Williamson wrote:
Hi,
I'm trying to add support for device assignment of PCI VGA devices with
VFIO and QEMU. For normal, discrete discrete graphics the Linux VGA
arbiter works fairly well, disabling VGA on one bridge and adding it to
another
On Mon, Aug 05, 2013 at 05:46:12PM +0200, Daniel Vetter wrote:
On Fri, Aug 02, 2013 at 04:22:24PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If the power well is disabled VGA is guaranteed to be disabled.
This fixes unclaimed register messages that happen
Hi all,
So while wreaking havoc with igt tests and adding some nice
infrastructure to handle subtest status reporting a bit better I've
also added support to annotate the common test fixture code. And
rolled it out over all tests.
I plan to do a decent write up on all the new infrastructure and
On Wed, Aug 14, 2013 at 11:59:09AM +0200, Daniel Vetter wrote:
In the execbuf code we don't clean up any vmas which ended up not
getting bound for code simplicity. To make sure that we don't end up
creating multiple vma for the same vm kill the somewhat dangerous
vma_create function and inline
On Wed, 2013-08-14 at 17:47 +0300, Ville Syrjälä wrote:
On Wed, Aug 14, 2013 at 07:23:57AM -0600, Alex Williamson wrote:
Hi,
I'm trying to add support for device assignment of PCI VGA devices with
VFIO and QEMU. For normal, discrete discrete graphics the Linux VGA
arbiter works fairly
Follow up on v2:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html
With the quick and nice reviews from Ville and Simon, it's time for a v3:
- Fix embarrassing hmdi typo
- Fix the sending of vendor specific infoframes for side-by-side half modes
- Smaller changes
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git
A few styles issues have crept in here, fix them before touching this
code again.
v2: constify arguments that can be (Ville Syrjälä)
v3: constify, but better (Ville Syrjälä)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 12 +++-
1 file changed,
HDMI 1.4 adds 4 4k x 2k modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the 4096x2160 string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau damien.lesp...@intel.com
Just like:
Author: Damien Lespiau damien.lesp...@intel.com
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
v2: Fix the value of Side-by-side
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
This changes the length of the infoframe payload from 6 to 5, which is
enough for the frame packing stereo format.
v2: Pimp up the commit
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.
(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
On Wed, Aug 14, 2013 at 10:18:55AM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 06:09:07PM -0700, Ben Widawsky wrote:
Cleanup the map and fenceable setting during bind to make more sense,
and not check i915_is_ggtt() 2 unnecessary times
v2: Move the bools into the if block (Chris)
On Wed, Aug 14, 2013 at 06:47:00PM +0200, Daniel Vetter wrote:
On Wed, Aug 14, 2013 at 11:59:09AM +0200, Daniel Vetter wrote:
In the execbuf code we don't clean up any vmas which ended up not
getting bound for code simplicity. To make sure that we don't end up
creating multiple vma for the
From: Paulo Zanoni paulo.r.zan...@intel.com
Our driver initialization doesn't seem to be ready to load when the
power well is disabled: we hit a few Unclaimed register messages. So
do just like we already do for the suspend/resume path: enable the
power well before unloading.
At some point we'll
On Tue, Aug 13, 2013 at 1:11 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Aug 12, 2013 at 10:33:37AM -0700, Stéphane Marchesin wrote:
On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky b...@bwidawsk.net wrote:
On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
On Wed, Aug 14, 2013 at 10:27:42AM -0700, Ben Widawsky wrote:
On Wed, Aug 14, 2013 at 10:18:55AM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 06:09:07PM -0700, Ben Widawsky wrote:
Cleanup the map and fenceable setting during bind to make more sense,
and not check i915_is_ggtt() 2
On Wed, Aug 14, 2013 at 11:14:48AM -0600, Alex Williamson wrote:
On Wed, 2013-08-14 at 17:47 +0300, Ville Syrjälä wrote:
On Wed, Aug 14, 2013 at 07:23:57AM -0600, Alex Williamson wrote:
Hi,
I'm trying to add support for device assignment of PCI VGA devices with
VFIO and QEMU. For
On Fri, Aug 09, 2013 at 05:04:35PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
On SNB/IVB/VLV we only call gen6_rps_irq_handler if one of the IIR
bits set is part of GEN6_PM_RPS_EVENTS, but at gen6_rps_irq_handler we
add all the enabled IIR bits to the work queue,
On Wed, Aug 14, 2013 at 06:19:10PM +0100, Damien Lespiau wrote:
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor
On Wed, Aug 14, 2013 at 06:19:03PM +0100, Damien Lespiau wrote:
Follow up on v2:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html
With the quick and nice reviews from Ville and Simon, it's time for a v3:
- Fix embarrassing hmdi typo
- Fix the sending of vendor
On Fri, Aug 09, 2013 at 05:04:37PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because hsw_pm_irq_handler does exactly what gen6_rps_irq_handler does
and also processes the 2 additional VEBOX bits. So merge those
functions and wrap the VEBOX bits on an IS_HASWELL
On Wed, 2013-08-14 at 21:30 +0300, Ville Syrjälä wrote:
On Wed, Aug 14, 2013 at 11:14:48AM -0600, Alex Williamson wrote:
On Wed, 2013-08-14 at 17:47 +0300, Ville Syrjälä wrote:
On Wed, Aug 14, 2013 at 07:23:57AM -0600, Alex Williamson wrote:
Hi,
I'm trying to add support for
On Wed, Aug 14, 2013 at 01:39:55PM -0600, Alex Williamson wrote:
On Wed, 2013-08-14 at 21:30 +0300, Ville Syrjälä wrote:
On Wed, Aug 14, 2013 at 11:14:48AM -0600, Alex Williamson wrote:
On Wed, 2013-08-14 at 17:47 +0300, Ville Syrjälä wrote:
On Wed, Aug 14, 2013 at 07:23:57AM -0600, Alex
Un-masking all PM interrupts causes hardware to generate
interrupts regardless of whether the interrupts are enabled
on the DE side. Since turbo only need up/down threshold and
rc6 timeout interrupt, mask all other interrupts bits to avoid
unnecessary overhead/wake up.
Change-Id:
On Wed, Aug 14, 2013 at 10:34 PM, Vinit Azad vinit.a...@intel.com wrote:
Un-masking all PM interrupts causes hardware to generate
interrupts regardless of whether the interrupts are enabled
on the DE side. Since turbo only need up/down threshold and
rc6 timeout interrupt, mask all other
Our interrupt handler isn't being fired since we do set the IER bits properly
(IIR bits aren't set). The overhead isn't because our driver is reacting to
these interrupts, but because hardware keeps generating internal messages when
PMINTRMSK doesn't mask out the up/down EI interrupts (which
On Wed, Aug 14, 2013 at 09:01:22PM +, Azad, Vinit wrote:
Our interrupt handler isn't being fired since we do set the IER bits
properly (IIR bits aren't set). The overhead isn't because our driver is
reacting to these interrupts, but because hardware keeps generating
internal messages when
On Wed, Aug 14, 2013 at 11:03 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 10:33:42PM +0200, Sedat Dilek wrote:
Hi,
I am here on Ubuntu/precise and wanted to avoid to upgrade to a higher
cairo-version.
Daniel's position is that he wants to make it hard for QA to
From: Xiang, Haihao haihao.xi...@intel.com
predicate SEND execsize dst sendleadreg payload directsrcoperand instoptions
predicate SEND execsize dst sendleadreg payload imm32reg instoptions
predicate SEND execsize dst sendleadreg payload sndopr imm32reg instoptions
predicate SEND
On Thu, Aug 08, 2013 at 09:10:38AM +0200, Daniel Vetter wrote:
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Ok, to get things going I've
On Wed, Aug 14, 2013 at 11:25 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 14, 2013 at 11:14:05PM +0200, Sedat Dilek wrote:
On Wed, Aug 14, 2013 at 11:03 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 14, 2013 at 10:33:42PM +0200, Sedat Dilek wrote:
Hi,
I
Hi all,
So I've finally tracked down the last thing which I didn't really understand in
my earlier patches and made sure it won't ever break again by writing testcases.
The one thing still left to do (but I have tests for it already) is to make sure
we don't duplicate buffers when importing
Note that this is slightly tricky since both drivers store their
native objects in dma_buf-priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae inki@samsung.com
Cc: Intel
From: Inki Dae inki@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 file changed, 8 insertions(+), 4
Lifetime rules seem to be solid around -import_attach. So this patch
just properly documents them.
Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points.
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.
Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static
Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.
So scream into dmesg with a big WARN in case that ever happens.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1
This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a
1 - 100 of 119 matches
Mail list logo
