Reviewed-by: Rodrigo Vivi
On Tue, Aug 06, 2013 at 06:57:16PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If the error interrupts are already disabled, don't disable and
> reenable them. This is going to be needed when we're in PC8+, where
> all the interrupts are disabled so we won't ri
On Tue, Aug 06, 2013 at 06:57:15PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Just like irq_mask and gt_irq_mask, use it to track the status of
> GEN6_PMIMR so we don't need to read it again every time we call
> snb_update_pm_irq.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/dr
Reviewed-by: Rodrigo Vivi
I liked this very much... we should do this kind of check in more places...
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 ga
Reviewed-by: Rodrigo Vivi
On Tue, Aug 06, 2013 at 06:57:13PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Just like we're doing with the other IMR changes.
>
> One of the functional changes is that not every caller was doing the
> POSTING_READ.
>
> Signed-off-by: Paulo Zanoni
> ---
>
Reviewed-by: Rodrigo Vivi
.On Tue, Aug 06, 2013 at 06:57:12PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Just like the functions that touch DEIMR and SDEIMR, but for GTIMR.
> The new functions contain a POSTING_READ(GTIMR) which was not present
> at the 2 callers inside i915_irq.c.
>
Awesome! Daniel, I have checked the latest igt with piglit, it have 303
tests(including subtests).
Best Regards~~
Open Source Technology Center (OTC)
Terence Yang（杨光）
Tel: 86-021-61167360
iNet: 8821-7360
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent:
On Wed, Aug 14, 2013 at 11:43:58PM +0100, Chris Wilson wrote:
> These are my numbers for a beefy haswell box (note the really
> interesting numbers will be on Baytrail):
>
> unpatched:
>
> relocation: buffers= 1: old= 21945 + 34.4*reloc, lut= 21814 + 34.0*reloc
> (ns)
> relocation: buffers=
... and move it to the top of the function to avoid a forward
declaration.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 29 +++--
include/drm/drmP.h | 1 -
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_pri
... not only when the dma-buf is freshly created. In contrived
examples someone else could have exported/imported the dma-buf already
and handed us the gem object with a flink name. If such on object gets
reexported as a dma_buf we won't have it in the handle cache already,
which breaks the guarant
with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.
Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.
The export dma-buf cache is semantically similar to an flink name. So
semantically it makes sense to treat it the same and remove the name
(i.e. the dma_buf pointer) and its references when the last gem handle
disappears.
Again we need to be careful, but double so: Not just could someone
race and
The gem flink name holds a reference onto the object itself, and this
self-reference would prevent an flink'ed object from every being
freed. To break that loop we remove the flink name when the last
userspace handle disappears, i.e. when obj->handle_count reaches 0.
Now in gem_open we drop the de
I want to wrap the creation of a dma-buf from a gem object in it,
so that the obj->export_dma_buf cache can be atomically filled in.
Instead of creating a new mutex just for that variable I've figured
I can reuse the existing dev->object_name_lock, especially since
the new semantics will exactly m
if (!ret) implies that ret == 0, so no need to clear it again. And
explicitly check for ret == 0 to indicate that we're checking an errno
integer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/d
When exporting a gem object as a dma-buf the critical section for the
per-fd prime lock is just the adding (and in case of errors, removing)
of the handle to the per-fd lookup cache.
So restrict the critical section to just that part of the function.
This simplifies later reordering.
Signed-off-
Part of the function uses the properly-typed dmabuf variable, the
other an untyped void *buf. Kill the later.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gp
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for
No one outside of drm should use this, the official interfaces are
drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
is purely an implementation detail of gem.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
include/drm/drmP.h| 1 -
2 files change
handle_unreference only clears up the obj->name and the reference,
but would leave a dangling handle in the idr. The right thing
to do is to call handle_delete.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
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 z
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
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
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
---
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
index 77c7d19..b1d9e25
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 (and
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 need
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. Sim
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos
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,
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 forei
On Wed, Aug 14, 2013 at 11:25 PM, Chris Wilson 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
>> wrote:
>> > On Wed, Aug 14, 2013 at 10:33:42PM +0200, Sedat Dilek wrote:
>> >> Hi,
>> >>
>> >> I am here on Ubuntu/precise and
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
> Signed-off-by: Daniel Vetter
Ok, to get things going I've merged the two i915 patches to dinq.
-Daniel
From: "Xiang, Haihao"
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 execsize dst sendleadreg p
On Wed, Aug 14, 2013 at 11:03 PM, Chris Wilson 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 build the
> te
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 wh
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 hap
On Wed, Aug 14, 2013 at 10:34 PM, Vinit Azad 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 interrupts bits to avoi
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: I6c947df6fd5f6058
Hi,
I am here on Ubuntu/precise and wanted to avoid to upgrade to a higher
cairo-version.
[ configure.ac ]
...
# for testdisplay
PKG_CHECK_MODULES(CAIRO, [cairo >= 1.12.0])
PKG_CHECK_MODULES(LIBUDEV, [libudev], [udev=yes], [udev=no])
if test x"$udev" = xyes; then
AC_DEFINE(HAVE_UDEV,1,[Enable ude
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 -0
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 ad
On Fri, Aug 09, 2013 at 05:04:37PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 check. This HSW
> che
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 ven
Reviewed-by: Rodrigo Vivi
Thanks for pointing me the doc that explains why 800 MHz when using FCLK input.
;)
On Tue, Aug 06, 2013 at 06:57:11PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We already have code to disable LCPLL and switch to FCLK, so we need this too.
> We still don't
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 ve
On Fri, Aug 09, 2013 at 05:04:35PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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, not only the ones th
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 a
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_gg
On Tue, Aug 13, 2013 at 1:11 AM, Ville Syrjälä
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 wrote:
>> > On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
>> >> This is a partial revert of b4ae3f22d23
From: Paulo Zanoni
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 want to be able to sur
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 fo
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
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
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 28
2 file
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
Signed-off-by: Damien Lespiau
Reviewed-by: Simon Farnsworth
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 36
include/drm/drm_edid.h
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
detai
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
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 (ha
Just like:
Author: Damien Lespiau
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
Reviewed-by: Ville Syrjälä
---
drivers/video
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
Date: Tue Aug 6 20:3
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
Reviewed-by: Simon Farnsworth
---
drivers/gpu/drm/drm_edid.c | 68 ++
1 file changed, 62 insertions(+), 6 deleti
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
re
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
---
drivers/gpu/drm/drm_edid.c | 12 +++-
1 file changed, 7 insertions(+), 5 deleti
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid
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 here
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 wo
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 inl
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 h
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
> >
> > If the power well is disabled VGA is guaranteed to be disabled.
> >
> > This fixes unclaimed register messages that happen on suspend/resu
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
> anot
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.or
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
> ---
> drivers/gpu/drm/i915/i915_reg.h | 409
> +++
> 1 file changed, 409 insertions(+)
>
> diff --git a/drivers/gpu/d
On Wed, Aug 14, 2013 at 3:44 PM, Chris Wilson 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 wrote:
>> > On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson
>> > wrote:
>> >> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek w
On Wed, Aug 14, 2013 at 03:02:37PM +0200, Sedat Dilek wrote:
> On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote:
> > On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson
> > wrote:
> >> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote:
> >>> Requested output and dmesg files attached.
> >>>
On Wed, Aug 14, 2013 at 3:02 PM, Sedat Dilek wrote:
> On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote:
>> On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson
>> wrote:
>>> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote:
Requested output and dmesg files attached.
( Should I a
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 driv
On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote:
> On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson
> 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
>>>
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson 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 please.
Attached
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 please.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
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 prevent
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
On Wed, Aug 14, 2013 at 11:38:36AM +0200, Daniel Vetter wrote:
> From: Ben Widawsky
>
> + vma = i915_gem_obj_lookup_or_create_vma(obj, vm);
> + if (IS_ERR(vma)) {
> + /* XXX: We don't need an error path fro vma because if
> + * the
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 inl
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 your Doner-Kebap? (Go
Chasing wild speculation that we may be writing the wrong addresses
into the GTT for stolen objects, I would like to inspect those values.
Signed-off-by: Chris Wilson
Cc: Sedat Dilek
---
Sedak, can you please apply this patch and then attach the contents of
/sys/kernel/debug/dri/0/i915_gem_gtt
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 resolution
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: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
> Cc: Terje Bergström
> Cc: linux-te...@vger.
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
On Wed, Aug 14, 2013 at 10:13 AM, Chris Wilson 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
>> wrote:
>> > On Wed, Aug 14, 2013 at 10:01:13AM +0200, Sedat Dilek wrote:
>> >> Signed-off-by: Sedat Dilek
>> >
>> > Am I the
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, w
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
A few minor things:
On Wednesday 14 August 2013 00:17:20 Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 68
> ++
> 1 file changed, 62 insertions(+), 6 deletions(-)
>
> diff --
On Wed, Aug 14, 2013 at 12:17:22AM +0100, Damien Lespiau wrote:
> Just like:
>
> Author: Damien Lespiau
> 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
On Wed, Aug 14, 2013 at 12:17:20AM +0100, Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 68
> ++
> 1 file changed, 62 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gp
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 (nic
On Wed, Aug 14, 2013 at 12:17:18AM +0100, Damien Lespiau wrote:
> A few styles issues have crept in here, fix them before touching this
> code again.
>
> v2: constify arguments that can be (Ville Syrjälä)
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 15 ---
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
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 prevent
Reviewed-by: Simon Farnsworth
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
> ---
> tools/intel_infoframes.c | 26 ++
> 1 file
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
>
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
> ---
> drivers/gpu/drm/drm_edid.c | 36
> include/drm/drm_edid.h |
1 - 100 of 127 matches
Mail list logo
