On 20 June 2014 02:09, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Jun 18, 2014 at 12:14:55PM -0400, Theodore Ts'o wrote:
Is this a known problem?
On my T540p, occasionally the display will go black and then be
completely locked. One time when this happened, the display started
glitching
Can we get these merged or even looked at?, they are blocking the whole MST
progress,
and I don't have any insight to secret Intel review process. :-)
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
From: Daniel Vetter daniel.vet...@ffwll.ch
For no reason at all the public docs lack them, and Dave needs them
for his hpd interrupt rework.
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm
From: Dave Airlie airl...@redhat.com
The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.
However with DP 1.2
On 7 June 2014 05:54, Jani Nikula jani.nik...@linux.intel.com wrote:
On Fri, 06 Jun 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
On 06/06/2014 02:41 AM, Jani Nikula wrote:
On Thu, 05 Jun 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Jun 04, 2014 at 03:29:41PM -0700,
From: Dave Airlie airl...@redhat.com
for MST I need to reuse these, so split them out early.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_ddi.c | 27 ---
drivers/gpu/drm/i915/intel_display.c | 31 ++-
2
Another round of the MST support for i915 haswell.
This relies on the aux locking and i915 irq rework patches I posted
already.
this also splits out some more i915 rework into earlier patches.
The main fix is not talking to devices if HPD isn't asserted, at
least on the dock I have it will
From: Dave Airlie airl...@redhat.com
This is required to get fbcon probing to work on new connectors,
callers should acquire the mode config lock before calling these.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c | 53
From: Dave Airlie airl...@redhat.com
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm
From: Dave Airlie airl...@redhat.com
this is just prep work for mst support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_ddi.c | 18 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git
From: Dave Airlie airl...@redhat.com
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c
From: Dave Airlie airl...@redhat.com
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff
From: Dave Airlie airl...@redhat.com
use the mst helper code to dump the topology in debugfs.
v0.2: drop is_mst check - as we want to dump other info
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23
From: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_dp_mst.c | 10 ++
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a7db741
On 3 June 2014 21:56, Jani Nikula jani.nik...@intel.com wrote:
Hi all, this is v2 of [1] to remove drm_get_connector_name() and
drm_get_encoder_name(), adding patch 1 for imx in staging and making
some dereferences less of an eye sore. This is based on Dave's drm-next
branch.
I pushed these,
On 4 June 2014 03:30, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.
v2: Don't break the build for vmwgfx, spotted by Matt.
v3:
From: Dave Airlie airl...@redhat.com
The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.
However with DP 1.2
Hi,
Just wondering what the point of the WARN(!encoder-crtc) in that function is,
I hit this with MST and I can't see what it should matter, where I hit
it is if I dock MST while X is running and VT switch, I get it,
I first wondered when encoder would ever be false in non-MST world
anyways,
From: Dave Airlie airl...@redhat.com
If some outputs go away we race with this call and apps
get X errors and fall over. Do what SNA does and don't
bother trying.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/uxa/intel_dri.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Hey,
So this set is pretty close to what I think we should be merging initially,
Since the last set, it makes fbcon and suspend/resume work a lot better,
I've also fixed a couple of bugs in -intel that make things work a lot
better.
I've bashed on this a bit using kms-flip from
From: Dave Airlie airl...@redhat.com
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm
From: Dave Airlie airl...@redhat.com
These are just from the Haswell spec.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915
From: Dave Airlie airl...@redhat.com
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include
From: Dave Airlie airl...@redhat.com
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff
From: Dave Airlie airl...@redhat.com
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c
From: Dave Airlie airl...@redhat.com
use the mst helper code to dump the topology in debugfs.
v0.2: drop is_mst check - as we want to dump other info
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23
From: Dave Airlie airl...@redhat.com
This is required to get fbcon probing to work on new connectors,
callers should acquire the mode config lock before calling these.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c | 53
From: Dave Airlie airl...@redhat.com
this is just prep work for mst support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git
From: Dave Airlie airl...@redhat.com
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm
From: Dave Airlie airl...@redhat.com
While fixing up UXA for MST I eventually fell over this bug.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/uxa/intel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/uxa/intel.h b/src/uxa/intel.h
index 6ac770e..f9dbd96 100644
So we leak all dynamically created objects? There's no
kfree(intel_connector) here and we cannot add it because
drm_mode_object_find() is not ref-counted. So we keep the connector in
the mode_group and wait until the final drm_mode_config_cleanup()? But
drm_connector_cleanup() already
From: Dave Airlie airl...@redhat.com
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm
From: Dave Airlie airl...@redhat.com
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff
From: Dave Airlie airl...@redhat.com
this is just prep work for mst support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git
Hi,
A repost of the current state of the displayport MST support for
i915, mainly targetted the Lenovo docks.
Major changes since last posting:
add a path blob property for userspace to use to track topology
provide reference counting, locking and lookups for branch and port structs.
some
From: Dave Airlie airl...@redhat.com
These are just from the Haswell spec.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915
From: Dave Airlie airl...@redhat.com
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm
From: Dave Airlie airl...@redhat.com
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c
From: Dave Airlie airl...@redhat.com
use the mst helper code to dump the topology in debugfs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
From: Dave Airlie airl...@redhat.com
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie airl...@redhat.com
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include
If we decide to go for property documentation inside the source code then I
believe we'll have to create our own format, as creating a properties table
from kerneldoc information extracted from comments is probably not possible.
Can comeone pick up the ball here and figure out what needs to
On 12 May 2014 16:46, Dave Airlie airl...@gmail.com wrote:
Hi,
A repost of the current state of the displayport MST support for
i915, mainly targetted the Lenovo docks.
Also in git at
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support
Dave
On 11 May 2014 18:28, Thomas Meyer tho...@m3y3r.de wrote:
Hi,
3.14.3 works as expected.
3.15-rc5 shows a strange behaviour: When resuming from ram the X server
seems to be disfunctional.
I see this WARNING in the kernel log before suspend to ram in the early
boot process:
- Fresh boot
On 10 May 2014 03:03, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote:
On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote:
Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
then attach the complete
As discussed on irc this contains a (not yet fully tuned and also not yet
in granting mode) cmd parser for gen7. Performance is still a bit rough,
but not quite as bad as originally feared (Ken later on discovered that he
also changed something in his glamour setup which made things worse). If
On 30 April 2014 00:00, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because the docs say ULX doesn't support it on HSW.
i read the exact same thing,
Reviewed-by: Dave Airlie airl...@redhat.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
From: Dave Airlie airl...@redhat.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
tools/intel_reg_dumper.c | 127 ++-
1 file changed, 115 insertions(+), 12 deletions(-)
diff --git a/tools/intel_reg_dumper.c b/tools/intel_reg_dumper.c
index
The docs don't mention the regs
PIPE_CLK_SEL_A-C at 0x46140-46148, is there any more info on these of
if they exist?
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Dave Airlie airl...@redhat.com
this is defined in the hsw docs, for the hdmi/dvi multiplier.
Signed-off-by: Dave Airlie airl...@redhat.com
---
lib/intel_reg.h | 3 +++
tools/intel_reg_dumper.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/lib/intel_reg.h b/lib
I just ran drm-next on my ILK box and ran piglit inside gnome-shell
and got this oops
ernel: BUG: unable to handle kernel NULL pointer dereference at 0030
ernel: IP: [a00a3828] i915_gem_free_request+0x58/0xa0 [i915]
ernel: PGD 19152067 PUD 50ef4067 PMD 0
ernel: Oops: [#1]
On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman dan...@quora.org wrote:
On 9 April 2014 11:41, Dave Airlie airl...@gmail.com wrote:
On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman dan...@quora.org wrote:
On 8 April 2014 15:14, Jani Nikula jani.nik...@linux.intel.com wrote:
On Tue, 08 Apr
On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman dan...@quora.org wrote:
On 8 April 2014 15:14, Jani Nikula jani.nik...@linux.intel.com wrote:
On Tue, 08 Apr 2014, Daniel J Blueman dan...@quora.org wrote:
Ville et al,
It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
another
On Mon, Mar 31, 2014 at 5:43 PM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Sun, 30 Mar 2014, Kenneth de Mello kdemello1...@gmail.com wrote:
What about dual-link DVI? I though the additional link addressed the
pixel clock limitation. Has it only been using a single link this entire
On Wed, Mar 19, 2014 at 12:13 PM, Chang, Junxiao
junxiao.ch...@intel.com wrote:
Hi Jesse,
I just registered patchwork account in freedesktop.org, but I don't know how
to add reviewed by to the patch
http://patchwork.freedesktop.org/patch/21324/.
Could you tell me how to add reviewed by to
On Tue, Mar 4, 2014 at 11:49 PM, Jani Nikula jani.nik...@intel.com wrote:
Hi Dave -
Small fixes all around, mostly stable material. Please pull.
BR,
Jani.
The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
are
On Wed, Jan 8, 2014 at 7:12 PM, Jani Nikula jani.nik...@linux.intel.com wrote:
On Tue, 07 Jan 2014, Lu, Ran hepho...@gmail.com wrote:
Hi Jani,
As a matter of fact, I tried kernel from 3.9 to 3.13-rc6, all of them cannot
read the pci information from 0:2.0, and lspci do not have Iris Pro as a
On Tue, Dec 17, 2013 at 10:14 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
If we fail to remove a conflicting fb driver, we need to abort the
loading of the
On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick i...@freedesktop.org wrote:
On 11/07/2013 10:32 PM, Daniel Vetter wrote:
On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie airl...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 29, 2013 at 11:29 PM, Ian
On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick i...@freedesktop.org wrote:
On 10/27/2013 05:30 AM, Daniel Vetter wrote:
On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote:
Since the Mesa merge window is closing
On Wed, Oct 30, 2013 at 4:06 AM, ville.syrj...@linux.intel.com wrote:
So I took another look at the vblank timestamping code, and got a bit
excited. The result is this patchset.
I'd like to merge this, I was hoping Mario could ack it at least as it
seems mostly sane to my eyes.
Dave.
On Tue, Oct 1, 2013 at 5:38 PM, Jani Nikula jani.nik...@intel.com wrote:
v2: duplicate intel_connector-edid, not uninitialized edid (Dave Airlie).
Okay I merged this one,
Thanks,
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Tue, Oct 1, 2013 at 4:37 AM, Alex Williamson
alex.william...@redhat.com wrote:
On Mon, 2013-09-30 at 15:24 +0100, Chris Wilson wrote:
On Mon, Sep 30, 2013 at 05:08:31PM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have several
Did you compile or boot this? I get a warning since you are using edid
uninitialised, I guess you meant to duplicate intel_connector-edid.
Dave.
drivers/gpu/drm/i915/intel_dp.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote:
[ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ]
Hi,
saw your
On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Thursday, September 19, 2013 11:21 AM
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Wednesday, September 18, 2013 7:40
On Fri, Sep 20, 2013 at 7:13 AM, Paul Zimmerman
paul.zimmer...@synopsys.com wrote:
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Thursday, September 19, 2013 1:15 PM
On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Sep 19, 2013 at 06:32:47PM +, Paul
On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman
paul.zimmer...@synopsys.com wrote:
I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card.
With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works
fine.
Bisecting this, I found
On Fri, Aug 16, 2013 at 8:43 AM, Alex Williamson
alex.william...@redhat.com wrote:
This is intended to add VGA arbiter support for Intel HD graphics on
Core processors. The old GMCH registers no longer exist, so even
though it appears that i915 participates in VGA arbitration, it doesn't
In the same exaggerated view, Jesse's premises:
- Actual user/developer testing is more valuable than review and refactoring
- Colorary: merging code with bugs is acceptable, we want the bug reports
- Endless code churn due to review/refactoring may actually introduce
bugs not present in
From: Dave Airlie airl...@redhat.com
Otherwise we'd fail saying DRI1 wasn't possible, when that
is exactly what we asked for.
Signed-off-by: Dave Airlie airl...@redhat.com
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index
On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Dave,
On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie airl...@gmail.com wrote:
Trying to fetch the drm-intel-fixes tree
(git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
morning
I do agree that QA is really important for a fastpaced process, but
it's also not the only peace to get something in. Review (both of the
patch itself but also of the test coverage) catches a lot of issues,
and in many cases not the same ones as QA would. Especially if the
testcoverage
Hey,
so I put a patch into intel driver a while ago to avoid doing a bo
flush using map/unmap for output slave device if the kernel has vmap
flushing
However on reflection I realised this only works for CPU accessing
devices like UDL but doesn't work for GPU accessing devices like
Trying to fetch the drm-intel-fixes tree
(git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
morning produced this error:
There is some issue with personal fdo repos at the moment and anon git,
I'll ask admin to look into it.
Dave.
Its an fd.o problem, none of the personal repos are operating over
anon git at the moment.
I've asked Keith/Tollef to look, though Keith is a bit connectivity
challenged, so we may have to wait until Europe wakes up.
Dave.
On Mon, Jul 29, 2013 at 12:11 PM, Yang, Guang A guang.a.y...@intel.com
On Sat, Jul 27, 2013 at 10:05 AM, Ben Widawsky b...@bwidawsk.net wrote:
On Sat, Jul 27, 2013 at 09:13:38AM +1000, Dave Airlie wrote:
Hey, overall it's actually quite a bit of fun.
I do agree that QA is really important for a fastpaced process, but
it's also not the only peace to get
Hey, overall it's actually quite a bit of fun.
I do agree that QA is really important for a fastpaced process, but
it's also not the only peace to get something in. Review (both of the
patch itself but also of the test coverage) catches a lot of issues,
and in many cases not the same ones
[ CC wq and drm(-intel) folks ]
Already know the commit which caused it, mentioned on dri-devel,
waiting for danvet to wake up and look, before I revert it later.
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Wed, Jun 19, 2013 at 10:53 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Ville,
On Friday 07 June 2013 18:43:07 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The structures and strings involved with various pretty-print functions
On Sat, Jun 8, 2013 at 1:43 AM, ville.syrj...@linux.intel.com wrote:
From: Foo Bar f...@bar.com
^ ??
git config error?
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sat, Jun 8, 2013 at 6:35 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
On Sat, Jun 8, 2013 at 1:43 AM, ville.syrj...@linux.intel.com wrote:
From: Foo Bar f...@bar.com
^ ??
git config error?
Whoops. Sorry about
Please forgive me if I post my questions to the wrong place, but I don't know
where else to post.
Probably dri-de...@lists.freedesktop.org might get more non-Intel people.
I am new to graphic programming. I found that the Linux graphic architecture
is very complicated. Luckily I found an
Why does this exist anymore?
Seriously this project is duplicating functionality we already have
implemented in Mesa/Gallium projects. Its also duplicating code in the
Mesa Intel driver I assume.
So why not just write a gallium ivybridge compute only driver? that
uses the current open source
It is not really true to say that the code is duplicated.
Beignet maps OpenCL into GPGPU pipeline of IvyBridge+ hardware.
So this is real GPGPU other than mimic GPGPU with 3D functions.
Nobody mimics GPGPU now with 3D functions. This hasn't been necessary
since DX11
Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a newly exported buffer.
I sent a bunch of patches to
On Mon, Mar 25, 2013 at 8:02 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Mon, Mar 25, 2013 at 3:49 AM, Dave Airlie airl...@gmail.com wrote:
Just stuck 3.9.0-rc4 on my MBP today, got this throwing up.
Is the bad stuff just the WARN (bad locking in our init code,
surprise!) or did i915
Just stuck 3.9.0-rc4 on my MBP today, got this throwing up.
Dave.
[3.482355] [drm] Memory usable by graphics device = 2048M
[3.482381] i915 :00:02.0: setting latency timer to 64
[3.482768] sdhci-pci :03:00.1: SDHCI controller found
[14e4:16bc] (rev 10)
[3.482825]
Because of the delayed fput in recent kernels, it is possible for plymouth to
exit and not drop master right away.
It's put onto a workqueue to be freed slightly later. Xorg-server starts in
the meantime, opens a fd, but because the fd
hasn't been closed by plymouth yet, it didn't get
On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl
On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote:
On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
The Intel PRM says the M1 and M2 divisors must be in the range of 10-20
and 5-9.
Since we
On Thu, Jan 10, 2013 at 11:07 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 9 Jan 2013 16:40:25 -0800, Greg KH gre...@linuxfoundation.org wrote:
On Wed, Jan 09, 2013 at 02:12:04PM -0600, Dave Kleikamp wrote:
On 01/09/2013 01:44 PM, Dave Kleikamp wrote:
I can easily reproduce
Hi all,
I've hit this 3 times today on Linus's latest 3.8-rc2+ tree:
[11868.414648] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed...
GPU hung
[11868.414655] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[11870.408342]
On Wed, Jan 9, 2013 at 2:25 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, Jan 09, 2013 at 01:42:39PM +1000, Dave Airlie wrote:
Hi all,
I've hit this 3 times today on Linus's latest 3.8-rc2+ tree:
[11868.414648] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU
As the shrinker may be invoked for the allocation, and it may reap
neighbouring objects in the offset range mm, we need to be careful in
the order in which we allocate the node, search for free space and then
insert the node into the mmap offset range manager.
Maybe I'm being a bit stupid
On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl h...@fancy-poultry.org wrote:
On 03.12.2012, devendra.aaru wrote:
Add more CC's
Thanks!
This is a real showstopper for me, it occurs in every session now.
Booting with i915.i915_enable_rc6=0 doesn't help
On Mon, Oct 15, 2012 at 2:49 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 15 Oct 2012 12:32:05 +1000
Dave Airlie airl...@gmail.com wrote:
The console lock can be contended, so rather than prevent other drivers
after us from being held up, queue the console suspend
it working, I suppose if it can
successfully light up most of its output, since I know we'll always be
plagued with eDP randomly not working.
Reviewed-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files
The console lock can be contended, so rather than prevent other drivers
after us from being held up, queue the console suspend into the global
work queue that can happen anytime. I've measured this to take around
200ms on my T420. Combined with the ring freq/turbo change, we should
save
On Thu, Oct 11, 2012 at 7:54 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 11 Oct 2012 20:29:47 -0300
Paulo Zanoni przan...@gmail.com wrote:
Hi
2012/10/11 Jesse Barnes jbar...@virtuousgeek.org:
I've only lightly tested this so far, but the corruption seems to be
gone if I
On Thu, Oct 11, 2012 at 5:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 11 Oct 2012 14:30:29 +1000, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
While playing with MPX and sw cursor I noticed page flips won't
end up misrendering some bits, so the sw
601 - 700 of 781 matches
Mail list logo
