On 15 May 2014 18:58, Jani Nikula wrote:
> On Wed, 14 May 2014, Rodrigo Vivi wrote:
>> We do have to continue the investigation on the link training side, but
>> since 76711 is a critical I'm completely in favor of this workaround for
>> now.
>>
>> I just tested and it worked very well here, so:
On 27 June 2014 07:54, Rémi Cardona wrote:
> Le jeudi 26 juin 2014 à 13:36 +0100, Steven Newbury a écrit :
>> Hi Hans!
>> Have you got to the bottom of this? I see the same thing, and also
>> possibly with GLX contexts under XWayland also with gnome-shell. If
>> it's the same thing, it points to
>
> Implemented a batch buffer submission scheduler for the i915 DRM driver.
>
While this seems very interesting, you might want to address in the commit msg
or the cover email
a) why this is needed,
b) any improvements in speed, power consumption or throughput it generates,
i.e. benchmarks.
als
On 25 June 2014 11:30, Ben Widawsky wrote:
> On Wed, Jun 18, 2014 at 12:04:46AM +0200, Daniel Vetter wrote:
>> On Tue, Jun 17, 2014 at 10:34:38PM +0200, Daniel Vetter wrote:
>> > A WARN_ON is perfectly fine.
>> >
>> > The BUG in here seems to be the cause behind hard-hangs when I cat the
>> > i915
On 23 June 2014 20:37, Wang, Quanxian wrote:
>
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Tuesday, June 17, 2014 11:38 PM
>> To: Wang, Quanxian
>> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
>> Subject: RE: [Intel-gfx] [PATCH] drm/i915
On 20 June 2014 02:09, Daniel Vetter 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 and te
From: Dave Airlie
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 MST we ne
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
http://lists.freedesktop.org/mailman
From: Daniel Vetter
For no reason at all the public docs lack them, and Dave needs them
for his hpd interrupt rework.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers
On 7 June 2014 05:54, Jani Nikula wrote:
> On Fri, 06 Jun 2014, Clint Taylor wrote:
>> On 06/06/2014 02:41 AM, Jani Nikula wrote:
>>> On Thu, 05 Jun 2014, Daniel Vetter wrote:
On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> R
From: Dave Airlie
---
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..ddac87f 100644
--- a
From: Dave Airlie
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
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h
From: Dave Airlie
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
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
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 a/drivers/gpu/drm/i915/intel_ddi.c b
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
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/i915_reg.h
index 5122254..60cfbb6
From: Dave Airlie
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b
From: Dave Airlie
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm
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 reply
From: Dave Airlie
for MST I need to reuse these, so split them out early.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 27 ---
drivers/gpu/drm/i915/intel_display.c | 31 ++-
2 files changed, 34 insertions(+), 24
From: Dave Airlie
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 MST we ne
On 4 June 2014 03:30, Daniel Vetter 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: Unbreak the depency lo
On 3 June 2014 21:56, Jani Nikula 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, after regeneratin
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, bu
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
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 a/drivers/gpu/drm/i915/intel_ddi.c b
From: Dave Airlie
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
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files
From: Dave Airlie
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
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b
From: Dave Airlie
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm
From: Dave Airlie
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
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/i915_reg.h
index 8f84555..557b37a
From: Dave Airlie
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm
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 intel-gpu-tools,
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
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/drm_crtc.c
index a3fe324..f1753e6
From: Dave Airlie
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
---
src/uxa/intel_dri.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/uxa/intel_dri.c
From: Dave Airlie
While fixing up UXA for MST I eventually fell over this bug.
Signed-off-by: Dave Airlie
---
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
--- a/src/uxa/intel.h
+++ b/src/uxa
>
> 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 r
On 12 May 2014 16:46, Dave Airlie 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-s
>>
>> 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
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
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 a/drivers/gpu/drm/i915/intel_ddi.c b
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 DocBook
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
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/i915_reg.h
index 8f84555..557b37a
From: Dave Airlie
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
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files
From: Dave Airlie
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm
From: Dave Airlie
use the mst helper code to dump the topology in debugfs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
From: Dave Airlie
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
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/drm_crtc.c
index a3fe324..f1753e6
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b
On 11 May 2014 18:28, Thomas Meyer 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 3.15-rc5
On 10 May 2014 03:03, Ville Syrjälä 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 dmesg? Please make
> 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).
From: Dave Airlie
this is defined in the hsw docs, for the hdmi/dvi multiplier.
Signed-off-by: Dave Airlie
---
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/intel_reg.h
index 4b3a102..82ea85f 100644
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
Signed-off-by: Dave Airlie
---
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 4bc299c..a482b5d 100644
--- a/tools
On 30 April 2014 00:00, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because the docs say ULX doesn't support it on HSW.
i read the exact same thing,
Reviewed-by: Dave Airlie
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> dr
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: [] i915_gem_free_request+0x58/0xa0 [i915]
ernel: PGD 19152067 PUD 50ef4067 PMD 0
ernel: Oops: [#1] SMP
ernel: Modul
On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman wrote:
> On 9 April 2014 11:41, Dave Airlie wrote:
>> On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman wrote:
>>> On 8 April 2014 15:14, Jani Nikula wrote:
>>>> On Tue, 08 Apr 2014, Daniel J Blueman wrote:
>
On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman wrote:
> On 8 April 2014 15:14, Jani Nikula wrote:
>> On Tue, 08 Apr 2014, Daniel J Blueman wrote:
>>> Ville et al,
>>>
>>> It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
>>> another commit in 3.13.7) broke modes which require D
On Mon, Mar 31, 2014 at 5:43 PM, Jani Nikula
wrote:
> On Sun, 30 Mar 2014, Kenneth de Mello 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
>> time, and it's only worked by ignoring the
On Wed, Mar 19, 2014 at 12:13 PM, Chang, Junxiao
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 the patch?
On Tue, Mar 4, 2014 at 11:49 PM, Jani Nikula 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 available i
On Wed, Jan 8, 2014 at 7:12 PM, Jani Nikula wrote:
> On Tue, 07 Jan 2014, "Lu, Ran" 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
>> video
>> controller. I put in t
On Tue, Dec 17, 2013 at 10:14 PM, Chris Wilson wrote:
> On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
>> On Mon, 16 Dec 2013, Chris Wilson wrote:
>> > If we fail to remove a conflicting fb driver, we need to abort the
>> > loading of the second driver to avoid likely kernel panics.
On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick wrote:
> On 11/07/2013 10:32 PM, Daniel Vetter wrote:
>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
>>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
>>>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanic
On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick 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 soon, I'm finally getting bac
On Wed, Oct 30, 2013 at 4:06 AM, 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 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.or
On Tue, Oct 1, 2013 at 4:37 AM, Alex Williamson
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ä
>> >
>> > We have several problems with out VGA handling:
>> > - We try to
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 b
On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin 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 p
On Fri, Sep 20, 2013 at 7:13 AM, Paul Zimmerman
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 wrote:
>> > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zi
On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter 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]
&g
On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman
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 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm:
> mark con
On Fri, Aug 16, 2013 at 8:43 AM, Alex Williamson
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
> work. On Intel HD graphics
>
> 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
From: Dave Airlie
Otherwise we'd fail saying DRI1 wasn't possible, when that
is exactly what we asked for.
Signed-off-by: Dave Airlie
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 104113e..88f29cc 10
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
nouveau/radeon,
>> > 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
>> >
On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell
wrote:
> Hi Dave,
>
> On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie wrote:
>>
>> > Trying to fetch the drm-intel-fixes tree
>> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
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 wrote:
> Hi all,
>
> We
>
> 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.
__
On Sat, Jul 27, 2013 at 10:05 AM, Ben Widawsky 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,
>
> 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
>
> [ 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
http://lists.freede
On Wed, Jun 19, 2013 at 10:53 AM, Laurent Pinchart
wrote:
> Hi Ville,
>
> On Friday 07 June 2013 18:43:07 ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> The structures and strings involved with various pretty-print functions
>> aren't meant to be modified, so make them all cons
On Sat, Jun 8, 2013 at 6:35 AM, Ville Syrjälä
wrote:
> On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
>> On Sat, Jun 8, 2013 at 1:43 AM, wrote:
>> > From: Foo Bar
>>
>> ^ ??
>>
>> git config error?
>
> Whoops. Sorry about that.
On Sat, Jun 8, 2013 at 1:43 AM, wrote:
> From: Foo Bar
^ ??
git config error?
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 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
> 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
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 infr
> 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 p
On Mon, Mar 25, 2013 at 8:02 PM, Daniel Vetter wrote:
> On Mon, Mar 25, 2013 at 3:49 AM, Dave Airlie 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.ko kill your eD
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] sdhci-pci
>
> 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 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
>> wrote:
>> > If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl
>> > command (which are seperate from the i
On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter 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 do al
On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote:
> On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Support for real RGB332 is a rarity, most hardware only really support
>> C8. So use C8 instead of RGB332 when determining the format
On Thu, Jan 10, 2013 at 11:07 AM, Chris Wilson wrote:
> On Wed, 9 Jan 2013 16:40:25 -0800, Greg KH 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 it running glxgears on 3.8-rc1 or 3.8-
On Wed, Jan 9, 2013 at 2:25 PM, Greg KH 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
>> 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
601 - 700 of 810 matches
Mail list logo
