On Thu, Aug 8, 2013 at 6:32 AM, Ben Widawsky wrote:
> You killed a BUG in i915_gem_retire_requests_ring, shouldn't that be a WARN
> or are you in the business of completely killing assertions now :p?
Yeah, and my little commit message annotation even explained that it's
fully redundant since the
On Thu, Aug 8, 2013 at 1:25 AM, Chris Wilson wrote:
> On Thu, Aug 08, 2013 at 01:18:18AM +0200, Daniel Vetter wrote:
>> Afaict the request holds a ref on the context, and that a ref on the hw
>> context bo. But the active list itself (thanks to the move_to_active)
>> should also hold a ref to the
On Thu, Aug 8, 2013 at 6:32 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Thursday, August 08, 2013 8:21 AM
>> To: Inki Dae
>> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
>> Sub
Hi, Daniel. You can repost your patch set including the below my patch. And
my patch numbering is wrong. Sorry about that.
[PATCH 1/4] -> [PATCH 4/4]
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Thursday, August 08, 2013 1:40 PM
> To: dan.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, August 08, 2013 8:21 AM
> To: Inki Dae
> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
> Subject: Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_relea
On Wed, Aug 07, 2013 at 10:52:14PM +0200, Daniel Vetter wrote:
> On Tue, Aug 06, 2013 at 05:28:06PM -0700, Ben Widawsky wrote:
> > On Tue, Aug 06, 2013 at 09:38:41PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 31, 2013 at 05:00:14PM -0700, Ben Widawsky wrote:
> > > > formerly: "drm/i915: Create V
On Wed, Aug 07, 2013 at 08:50:20PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> > This fixes a WARN in i915_gem_free_object when the
> > obj->pages_pin_count isn't 0.
> >
> > v2: Add locking to unmap, noticed by Chris Wilson. Note that even
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> though we call unmap with our own dev->struct_mutex held that won't
> result i
On Thu, Aug 08, 2013 at 01:18:18AM +0200, Daniel Vetter wrote:
> Afaict the request holds a ref on the context, and that a ref on the hw
> context bo. But the active list itself (thanks to the move_to_active)
> should also hold a ref to the hw context bo, so I don't think we really
> need full requ
On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote:
> 2013/8/7 Daniel Vetter
>
> > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
> > >
> > >
> > > 2013/8/7 Daniel Vetter
> > >>
> > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> > >> > On 08/07/2013 06:55 PM, Daniel
On Thu, Aug 08, 2013 at 12:10:22AM +0100, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 11:58:21PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 07, 2013 at 10:29:05PM +0100, Chris Wilson wrote:
> > > We use the request to ensure we hold a reference to the context for the
> > > duration that it remai
On Wed, Aug 07, 2013 at 11:58:21PM +0200, Daniel Vetter wrote:
> On Wed, Aug 07, 2013 at 10:29:05PM +0100, Chris Wilson wrote:
> > We use the request to ensure we hold a reference to the context for the
> > duration that it remains in use by the ring. Each request only holds a
> > reference to the
On Wed, Aug 07, 2013 at 10:29:05PM +0100, Chris Wilson wrote:
> We use the request to ensure we hold a reference to the context for the
> duration that it remains in use by the ring. Each request only holds a
> reference to the current context, hence we emit a request after
> switching contexts wit
On Wed, Aug 07, 2013 at 06:30:54PM +0100, Chris Wilson wrote:
> I was curious as to what objects were currently allocated from stolen
> memory, and so exported it from debugfs.
>
> Signed-off-by: Chris Wilson
I liike this, but since I've just merged Ben's exec_list vma conversion it
doesn't appl
We use the request to ensure we hold a reference to the context for the
duration that it remains in use by the ring. Each request only holds a
reference to the current context, hence we emit a request after
switching contexts with the final reference to the old context. However,
the extra interrupt
On Wed, Jul 31, 2013 at 05:00:17PM -0700, Ben Widawsky wrote:
> In order to transition more of our code over to using a VMA instead of
> an 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 h
On Tue, Aug 06, 2013 at 05:28:06PM -0700, Ben Widawsky wrote:
> On Tue, Aug 06, 2013 at 09:38:41PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 31, 2013 at 05:00:14PM -0700, Ben Widawsky wrote:
> > > formerly: "drm/i915: Create VMAs (part 5) - move mm_list"
> > >
> > > The mm_list is used for the a
This patch avoids the calculation of next points if unnecessary.
Is this correct??
If yes, can someone commit??
Thanks
Raul Fernandes
rgfernan...@gmail.com
opt-of-intersect-functions.patch
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@
On Wed, Aug 07, 2013 at 11:37:04AM -0700, Ben Widawsky wrote:
> On Tue, Aug 06, 2013 at 09:11:54PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 31, 2013 at 05:00:13PM -0700, Ben Widawsky wrote:
> > > formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable
> > > tracking"
> > >
> > > The map
Chris's machine would be a good regression test for this. If it works
for him too, I think we should push it.
Thanks,
Jesse
On Wed, 7 Aug 2013 19:15:10 +
"Matsumura, Ryan" wrote:
> Awesome, that worked thanks Jesse! Will this be just a hack or will you
> push this as a fix in future rel
In truly crazy circumstances shmem might give us the wrong type of
page. So be a bit paranoid and double check this.
Cc: Rob Clark
References: http://lkml.org/lkml/2011/7/11/238
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Wed, Aug 07, 2013 at 07:39:13PM +0100, Damien Lespiau wrote:
> A few styles issues have creept in here, fix them before touching this
> code again.
You could also sprinke a bit of constness into these functions while
you're touching them.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gp
On Wed, Aug 07, 2013 at 07:39:14PM +0100, 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.
>
> Signed-off-by: Damien Lespiau
> Tested-by: Cancan Feng
> Bugzil
Awesome, that worked thanks Jesse! Will this be just a hack or will you push
this as a fix in future releases?
-Ryan
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Wednesday, August 07, 2013 8:49 AM
To: Daniel Vetter
Cc: Matsumura, Ryan; intel-gfx@lists.f
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.
Signed-off-by: Damien Lespiau
Tested-by: Cancan Feng
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
---
drivers/gpu/drm/drm_
A few styles issues have creept in here, fix them before touching this
code again.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95d6f4b..51
This series parses one of the dark corners of the EDID to expose "4k x 2k"
modes to userspace. Those modes are part of HDMI 1.4.
To complete the 4k HDMI support, one needs:
* Hardware able to output a 300 MHz TMDS clock (Haswell can do that) and
Daniel's patch to bump that limit in the kern
On Tue, Aug 06, 2013 at 09:11:54PM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 05:00:13PM -0700, Ben Widawsky wrote:
> > formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable
> > tracking"
> >
> > The map_and_fenceable tracking is per object. GTT mapping, and fences
> > only ap
On Wed, Aug 07, 2013 at 01:44:58AM +0200, Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 1:25 AM, Ben Widawsky wrote:
> > On Wed, Aug 07, 2013 at 12:59:29AM +0200, Daniel Vetter wrote:
> >> On Wed, Aug 7, 2013 at 12:57 AM, Ben Widawsky wrote:
> >> >> > We need evict_everything for #1. For #2, we c
I was curious as to what objects were currently allocated from stolen
memory, and so exported it from debugfs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 63 +
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_
On 08/07/2013 07:21 PM, Daniel Vetter wrote:
On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
On 08/07/2013 06:55 PM, Daniel Vetter wrote:
On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Wedne
On 08/07/2013 06:55 PM, Daniel Vetter wrote:
On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Wednesday, August 07, 2013 6:15 PM
To: DRI Development
Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
Subje
On Wed, Aug 07, 2013 at 03:20:09PM +0100, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 10:38:19AM -0300, Paulo Zanoni wrote:
> > 2013/8/6 Chris Wilson :
> > > On Tue, Aug 06, 2013 at 06:57:17PM -0300, Paulo Zanoni wrote:
> > >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > >> b/drivers
On Wed, 7 Aug 2013 09:41:39 +0200
Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 5:10 AM, Matsumura, Ryan
> wrote:
> > I have a BayTrail board with two HDMI ports and running the default Tizen
> > 3.0M1 release. The first HDMI shows up just fine but I can't get the
> > second screen to display
v2: Fix rebase fail that removed a necessary hunk
Signed-off-by: Damien Lespiau
---
edid-decode.c | 67 +++
1 file changed, 67 insertions(+)
diff --git a/edid-decode.c b/edid-decode.c
index 5061228..083ddd9 100644
--- a/edid-decode.c
+++ b
On Wed, Aug 07, 2013 at 10:38:19AM -0300, Paulo Zanoni wrote:
> 2013/8/6 Chris Wilson :
> > On Tue, Aug 06, 2013 at 06:57:17PM -0300, Paulo Zanoni wrote:
> >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> index 2ef4335..7f6ec9e 100644
> >>
On Wed, Aug 07, 2013 at 10:34:11AM -0300, Paulo Zanoni wrote:
> 2013/8/6 Chris Wilson :
> > On Tue, Aug 06, 2013 at 06:57:14PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> I did some brief tests and the "new_val = pmimr" condition usually
> >> happens a few times after exiting game
Signed-off-by: Damien Lespiau
---
edid-decode.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/edid-decode.c b/edid-decode.c
index 7aed3c6..58297c9 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -861,6 +861,44 @@ cea_hdmi_block(unsigned char *x)
Signed-off-by: Damien Lespiau
---
edid-decode.c | 69 +--
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 5061228..7aed3c6 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -32,8 +32,6 @@
#
---
data/samsung-UE40D8000YU-hmdi | Bin 0 -> 256 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data/samsung-UE40D8000YU-hmdi
diff --git a/data/samsung-UE40D8000YU-hmdi b/data/samsung-UE40D8000YU-hmdi
new file mode 100644
index
Signed-off-by: Damien Lespiau
---
edid-decode.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 55e48a7..5061228 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -659,6 +659,13 @@ cea_video_block(unsigned char *x)
Signed-off-by: Damien Lespiau
---
edid-decode.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 7515181..55e48a7 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -705,7 +705,7 @@ cea_hdmi_block(unsigned char *x)
Signed-off-by: Damien Lespiau
---
data/skyworth-50e780u-hdmi | Bin 0 -> 256 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data/skyworth-50e780u-hdmi
diff --git a/data/skyworth-50e780u-hdmi b/data/skyworth-50e780u-hdmi
new file mode 100644
index
0
Signed-off-by: Damien Lespiau
---
edid-decode.c | 84 +--
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 9840db6..7515181 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -32,6 +32,8 @@
#
A bit more context than the previous patch that was a bit alone. This series
parses yet a bit more of the EDID:
- The HDMI VICs in the HDMI vendor specific block (HDMI 1.4, 4k modes)
- The CEA Video Capability Data Block
It also includes 2 EDIDs of TVs that have those bits.
--
Damien
__
2013/8/6 Chris Wilson :
> On Tue, Aug 06, 2013 at 06:57:17PM -0300, Paulo Zanoni wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 2ef4335..7f6ec9e 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i9
2013/8/6 Chris Wilson :
> On Tue, Aug 06, 2013 at 06:57:14PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> I did some brief tests and the "new_val = pmimr" condition usually
>> happens a few times after exiting games.
>>
>> Signed-off-by: Paulo Zanoni
>
> I'm not sure of the value of thi
2013/8/6 Daniel Vetter :
> On Tue, Aug 06, 2013 at 06:57:10PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Hi
>>
>> Here's my next attempt at the Haswell PC8+ feature.
>>
>> What's new?
>>
>> 1. I hope I implemented the feedback from Chris. Many function renames, a
>> few
>> style
2013/8/7 Daniel Vetter
> On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
> >
> >
> > 2013/8/7 Daniel Vetter
> >>
> >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> >> > On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> >> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae
> wrote:
>
On Wed, Aug 07, 2013 at 03:11:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> drivers/gpu/drm/i915/i915_debugfs.c:2136:3: warning: symbol
> 'i915_debugfs_files' was not declared. Should it be static?
>
> Signed-off-by: Ville Syrjälä
Queued for -next, thanks for the pa
From: Ville Syrjälä
drivers/gpu/drm/i915/i915_debugfs.c:2136:3: warning: symbol
'i915_debugfs_files' was not declared. Should it be static?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i
On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
>
>
> 2013/8/7 Daniel Vetter
>>
>> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
>> > On 08/07/2013 06:55 PM, Daniel Vetter wrote:
>> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
>> > >>>-Original Message-
>> > >>>F
2013/8/7 Daniel Vetter
> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> > On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
> > >>>-Original Message-
> > >>>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> > >>>Sent
On Wed, Aug 07, 2013 at 01:56:58PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 06, 2013 at 08:32:16PM +0100, Damien Lespiau wrote:
> > If the user if this API is providing a bigger buffer than the infoframe
> > size, it could be for a could reason. For instance it could be because
> > it gives the bu
On Tue, Aug 06, 2013 at 08:32:19PM +0100, Damien Lespiau wrote:
> Let's use the drivers/video/hmdi.c and drm infoframe helpers to build
> our infoframes.
>
> v2: Simplify the logic to compute the buffer size. We can just take the
> maximum infoframe size rounded to 32, which happens to be what the
On Tue, Aug 06, 2013 at 08:32:18PM +0100, Damien Lespiau wrote:
> First step in the move to the shared infoframe infrastructure, let's
> move the different infoframe helpers and the write_infoframe() vfunc to
> a type (enum hdmi_infoframe_type) and a buffer + len instead of using
> our struct dip_i
On Tue, Aug 06, 2013 at 08:32:16PM +0100, Damien Lespiau wrote:
> If the user if this API is providing a bigger buffer than the infoframe
> size, it could be for a could reason. For instance it could be because
> it gives the buffer that will be written to the hardware, up to the
> maximum of an in
On Wed, Aug 7, 2013 at 12:30 PM, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 12:09:33PM +0200, Daniel Vetter wrote:
>> It's unclear whether ->map is allowed to fail with -EINTR, but
>> looking at current callers it's pretty clear that they don't
>> expect this to happen. So use a blocking mutex_
On Wed, Aug 07, 2013 at 09:41:39AM +0200, Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 5:10 AM, Matsumura, Ryan
> wrote:
> > I have a BayTrail board with two HDMI ports and running the default Tizen
> > 3.0M1 release. The first HDMI shows up just fine but I can't get the
> > second screen to d
Op 07-08-13 12:09, Daniel Vetter schreef:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> though we call unmap with our own dev->struct_mutex held that won't
> result in an immediate deadloc
On Wed, 2013-08-07 at 09:44 +0200, Borislav Petkov wrote:
> Background is that on my x230, I needed to connect the
> Fn-Fx backlight hotkey presses to a script to write to
> /sys/class/backlight/intel_backlight/brightness because Fluxbox doesn't
> do that (and maybe doesn't have to).
>
> So, with
From: Ville Syrjälä
Check plane->fb in intel_disable_plane() to determine if the plane
is already disabled.
If the plane has an fb, then it must also have a crtc, so we can drop
the plane->crtc check and just call intel_enable_primary() directly.
v2: WARN and bail if the plane doesn't have a cr
On Wed, Aug 07, 2013 at 12:09:33PM +0200, Daniel Vetter wrote:
> It's unclear whether ->map is allowed to fail with -EINTR, but
> looking at current callers it's pretty clear that they don't
> expect this to happen. So use a blocking mutex_lock call. Since
> we don't wait for the gpu in our ->map c
From: Ville Syrjälä
Give a name to the plane watermark related data we have currently
stored under intel_plane->wm.
We also observe that this data is more or less the same that we have
in the hsw_pipe_wm_parameters structure, so use it there as well.
v2: Make pahole happier
Reviewed-by: Chris
From: Ville Syrjälä
There is a bunch of global state that needs to be considered when
checking watermarks for validity. Move most of that to a new
structure intel_wm_config, to avoid having to pass around so
many variables.
One notable thing left out is the DDB partitioning information,
since we
From: Ville Syrjälä
There are quite a few variables we need to take into account to
determine the maximum watermark levels, so it feels a bit cleaner
to calculate those rather than just have a bunch of what look like
magic numbers.
v2: s/pipes_active/num_pipes_active
s/othwewise/otherwise
R
From: Ville Syrjälä
Refactor the code a bit to split the watermark level validity check into
a separate function.
Also add hack there that allows us to use it even for LP0 watermarks.
ATM we don't pre-compute/check the LP0 watermarks, so we just have to
clamp them to the maximum and hope things
On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
> >>>-Original Message-
> >>>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> >>>Sent: Wednesday, August 07, 2013 6:15 PM
It's unclear whether ->map is allowed to fail with -EINTR, but
looking at current callers it's pretty clear that they don't
expect this to happen. So use a blocking mutex_lock call. Since
we don't wait for the gpu in our ->map callback the lack of the
gpu hang checks doesn't matter.
Furthermore th
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.
v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces fo
On Tue, Aug 06, 2013 at 09:45:11PM +0100, Chris Wilson wrote:
> On Tue, Aug 06, 2013 at 10:24:03PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We don't need to store the FBC WM enabled status in each watermark
> > level. We anyway have to reduce it down to a single
On Tue, Aug 06, 2013 at 09:56:31PM +0100, Chris Wilson wrote:
> On Tue, Aug 06, 2013 at 10:24:02PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Refactor the watermarks computation for one level to a separate
> > function. This function will now set the ->enable flat
On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
>> Sent: Wednesday, August 07, 2013 6:15 PM
>> To: DRI Development
>> Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
>> Subject: [PATCH 1/3] drm: use commo
On Wed, Aug 7, 2013 at 11:29 AM, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 11:15:07AM +0200, Daniel Vetter wrote:
>> This fixes a WARN in i915_gem_free_object when the
>> obj->pages_pin_count isn't 0.
>>
>> Reported-by: Maarten Lankhorst
>> Cc: Maarten Lankhorst
>> Signed-off-by: Daniel Vett
On Wed, Aug 07, 2013 at 11:15:08AM +0200, Daniel Vetter wrote:
> Makes it more obviously correct what tricks we play by reusing the drm
> prime release helper.
>
> Signed-off-by: Daniel Vetter
I do like these little typesafe cast helpers.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Inte
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
> Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos
> drivers
>
>
On Wed, Aug 07, 2013 at 11:15:06AM +0200, Daniel Vetter wrote:
> 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 nee
On Wed, Aug 07, 2013 at 11:15:07AM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> Reported-by: Maarten Lankhorst
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
Papers over the WARN with iffy locking. Not all callers
There are a few simple operations that we would like to offload onto the
GPU for the benefit of running asynchronously. The first is to clear the
backing storage for an object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_drv.h |
Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIOS and reserved
for igfx use. Stolen memory is required for some functions of the GPU
and display engine,
On Wed, Aug 07, 2013 at 11:15:07AM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> Reported-by: Maarten Lankhorst
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=6
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.
Reported-by: Maarten Lankhorst
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dm
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
Cc: Intel Graphics Development
Signe
Hi all,
I need to get my prime fixes in since they're blocking QA from running -nightly
prime tests. Which is a prerequisite of mine before I start touching dma-buf for
real to look at fencing and ww-mutex integration for i915.
These three patches are just a bit of prep cleanup and one bugfix tha
On Tue, Aug 06, 2013 at 04:19:00PM +0200, Daniel Vetter wrote:
> Thinking about this some more we already cancel the rps work items
> (with the exception of the vlv_work) in intel_disable_gt_powersave,
> which is called already from i915_save_state. So I think we just need
> to add the cancel_work
On 08/07/2013 03:44 PM, Borislav Petkov wrote:
> On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote:
>> Windows 8 introduced new policy for backlight control by pushing it out to
>> graphics drivers. This appears to have coincided with a range of vendors
>> adding Windows 8 checks to t
On Tue, Aug 06, 2013 at 09:31:33PM +0100, Chris Wilson wrote:
> On Tue, Aug 06, 2013 at 10:24:04PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We're going to use the 1/2 vs. 5/6 split option already on IVB so the
> > HSW name is not proper. Just give it an intel_ p
On Tue, Aug 06, 2013 at 10:06:16PM -0400, Alex Deucher wrote:
> Patches 1-5, 10, 11 are:
>
> Reviewed-by: Alex Deucher
Entire series merged to drm-intel-next-queue with Dave's irc ack. Thanks
for the patches and review.
-Daniel
>
> On Tue, Aug 6, 2013 at 3:32 PM, Damien Lespiau
> wrote:
> >
On Wed, Aug 07, 2013 at 09:26:34AM +0300, Jani Nikula wrote:
> On Thu, 25 Jul 2013, Jani Nikula wrote:
> > On muxed systems, the other vgaswitcheroo client may depend on i915 to
> > handle the backlight. We began switching off the backlight since
> >
> > commit a261b246ebd552fd5d5a8ed84cc931bb821c
On Wed, Aug 07, 2013 at 10:27:35AM +1000, Dave Airlie wrote:
> On Mon, Aug 5, 2013 at 5:35 AM, Daniel Vetter wrote:
> > Hi Dave,
>
> Okay since I missed this, then I merged patches from the list from
> David Herrmann
> fixing up drm_mm usage, then I merged this and it all fell to pieces.
>
> C
On Wed, Aug 7, 2013 at 5:10 AM, Matsumura, Ryan
wrote:
> I have a BayTrail board with two HDMI ports and running the default Tizen
> 3.0M1 release. The first HDMI shows up just fine but I can't get the second
> screen to display anything. I tried enabling the second screen through the
> kerne
93 matches
Mail list logo
