-Original Message-
From: Wu, Fengguang
Sent: Wednesday, September 05, 2012 1:30 PM
To: Wang, Xingchao
Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zhao, Yakui
Subject: Re: [PATCH] drm/i915: ELD info update during HDMI hot plug
Xingchao,
We have the
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.
In intel_hdmi_dpms(), if intel_hdmi-has_audio been true, the Audio enable
bit will
be set to trigger
Hello
Is SNA still under heavy developement? Is the performance still being worked on?
Regards,
Roberth Sjonøy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 12 Sep 2012 10:29:20 +0200, Roberth Sjonøy roberth.sjo...@gmail.com
wrote:
Hello
Is SNA still under heavy developement? Is the performance still being worked
on?
The more interesting question is what prompted you to ask? What is it
that you truly care about?
-Chris
--
Chris
Hello
Are you psychologist? /joke
I wonder if it's planned to be faster, because beside the performance
it works very good for me with the right settings regarding the
tearing issue. If performance is still under heavy developement?
On Wed, Sep 12, 2012 at 10:52 AM, Chris Wilson
Hello
Are you psychologist? /joke
I wonder if it's planned to be faster, because beside the performance
it works very good for me with the right settings regarding the
tearing issue. If performance is still under heavy developement?
Regards
Roberth Sjonøy
On Wed, Sep 12, 2012 at 10:52 AM,
On Thu, Sep 13, 2012 at 1:43 AM, Wang Xingchao xingchao.w...@intel.com wrote:
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.
In intel_hdmi_dpms(), if
On Wed, 12 Sep 2012 11:12:02 +0200, Roberth Sjonøy roberth.sjo...@gmail.com
wrote:
Hello
Are you psychologist? /joke
I just want to know the workloads that are important to you, to make
sure they are included in my benchmarking.
I wonder if it's planned to be faster, because beside the
On Tue, Sep 11, 2012 at 08:17:33AM +0200, Daniel Vetter wrote:
We need to check whether the _other plane is on our pipe, not whether
our plane is on the other pipe. Otherwise if not both pipes/planes are
active, we won't properly clean up the mess and set up our desired
plane-pipe mapping.
From: Paulo Zanoni paulo.r.zan...@intel.com
Every time I have to change ironlake_crtc_mode_set I get scared by the
fact that it has 404 lines. I feel way more confident when I'm changing
small functions that do specific self-contained things.
Thus, the goal of this patch series is to extract
From: Paulo Zanoni paulo.r.zan...@intel.com
Because ironlake_crtc_mode_set is a giant function that used to have
404 lines. Let's try to make it less complex/confusing.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 88
From: Paulo Zanoni paulo.r.zan...@intel.com
A next step would be to move this code to some of the encoder-specific
callbacks. But really, moving the function away is certainly the first
step.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 37
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 82 +++---
1 file changed, 46 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
From: Paulo Zanoni paulo.r.zan...@intel.com
The set_m_n code was spread all over the mode_set function.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 152 --
1 file changed, 89 insertions(+), 63 deletions(-)
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 95 +++---
1 file changed, 66 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
From: Paulo Zanoni paulo.r.zan...@intel.com
This is all the code responsible for setting the PCH PLLs.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 260 --
1 file changed, 153 insertions(+), 107 deletions(-)
From: Paulo Zanoni paulo.r.zan...@intel.com
They are actually set but not used [-Wunused-but-set-variable].
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff
On Thu, Sep 06, 2012 at 05:07:58PM -0700, Ben Widawsky wrote:
On Tue, 4 Sep 2012 21:02:55 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath
On Wed, Sep 12, 2012 at 03:13:27PM +0200, Daniel Vetter wrote:
On Thu, Sep 06, 2012 at 05:07:58PM -0700, Ben Widawsky wrote:
On Tue, 4 Sep 2012 21:02:55 +0100
@@ -742,7 +741,6 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
int hit_slowpath = 0;
int needs_clflush_after = 0;
On Mon, Sep 10, 2012 at 05:34:48PM +0100, Chris Wilson wrote:
On Thu, 6 Sep 2012 18:49:24 -0700, Ben Widawsky b...@bwidawsk.net wrote:
On Tue, 4 Sep 2012 21:02:57 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Rather than have multiple data structures for describing our page layout
On Tue, Sep 04, 2012 at 09:02:59PM +0100, Chris Wilson wrote:
To be used later by i915 to preallocate exact blocks of space from the
range manager.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Hi
2012/9/6 Daniel Vetter daniel.vet...@ffwll.ch:
The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.
LVDS has some similar funky hacks, but
On Tue, Sep 04, 2012 at 09:03:03PM +0100, Chris Wilson wrote:
This will be used i915 in forthcoming patches in order to measure the
largest contiguous chunk of memory available for enabling chipset
features.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie
On Wed, Sep 12, 2012 at 10:06:30AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
A next step would be to move this code to some of the encoder-specific
callbacks. But really, moving the function away is certainly the first
step.
Signed-off-by: Paulo Zanoni
On Wed, Sep 12, 2012 at 10:06:29AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because ironlake_crtc_mode_set is a giant function that used to have
404 lines. Let's try to make it less complex/confusing.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
On Wed, Sep 12, 2012 at 10:06:31AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Hm, I think we should extract the same code from i9xx_crtc_set_mode, too
and share it in a common intel_set_pipe_timings. Their almost
On Wed, Sep 12, 2012 at 10:06:32AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because declaring a variable in the beginning of the function, then
initializing it 100 lines later, then using it 100 lines later does
not make our code look good IMHO.
On Wed, Sep 12, 2012 at 10:06:33AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The set_m_n code was spread all over the mode_set function.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 152
On Wed, Sep 12, 2012 at 10:06:34AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Queued for -next, thanks for the patch. I've needed to resolve some
conflicts since I didn't pick up all previous patches, but nothing
On Wed, Sep 12, 2012 at 04:31:50PM +0200, Daniel Vetter wrote:
On Wed, Sep 12, 2012 at 10:06:34AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Queued for -next, thanks for the patch. I've needed to resolve some
On Wed, Sep 12, 2012 at 10:06:35AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This is all the code responsible for setting the PCH PLLs.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 260
On Fri, Sep 07, 2012 at 07:43:43PM -0700, Ben Widawsky wrote:
Provide a standardized sysfs interface for setting min, and max
frequencies. The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:
On Tue, 11 Sep 2012 12:37:55 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise things migt not work too well.
Breakage introduced in
commit eb1cbe4848b01f9f073064377875bc7d71eb401b
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Mar 28 23:12:16 2012 +0200
Hi Timo,
Timo Aaltonen wrote:
commit d698c826bb93663e4b349a78fbd30443654d37cd upstream.
Please pull this for v3.2.x, should be the last missing (kernel) piece
for https://bugs.freedesktop.org/show_bug.cgi?id=48838
[...]
It should be more reliable to wait for the pending
On Mon, 10 Sep 2012 21:58:29 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
This has been added in
commit de9a35abb3b343a25065449234e47a76c4f3454a
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Jun 5 11:03:40 2012 +0200
drm/i915: assert that the IBX port transcoder
On 12.09.2012 18:09, Jonathan Nieder wrote:
Hi Timo,
Timo Aaltonen wrote:
commit d698c826bb93663e4b349a78fbd30443654d37cd upstream.
oops, script-fail.. that's the local branch sha, real one is further
down (0f91128d88bbb8b0a8e7bb93df2c40680871d45a).
Please pull this for v3.2.x, should be
On Wed, Sep 12, 2012 at 08:04:42AM -0700, Jesse Barnes wrote:
On Tue, 11 Sep 2012 12:37:55 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise things migt not work too well.
Breakage introduced in
commit eb1cbe4848b01f9f073064377875bc7d71eb401b
Author: Daniel Vetter
On Mon, 10 Sep 2012 21:58:30 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
While reworking the modeset sequence, this got lost in
commit 25c5b2665fe4cc5a93edd29b62e7c05c1526
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun Jul 8 22:08:04 2012 +0200
drm/i915: implement
On Wed, Sep 12, 2012 at 08:20:12AM -0700, Jesse Barnes wrote:
On Mon, 10 Sep 2012 21:58:29 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
This has been added in
commit de9a35abb3b343a25065449234e47a76c4f3454a
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Jun 5 11:03:40
On Wed, Sep 12, 2012 at 08:29:21AM -0700, Jesse Barnes wrote:
On Mon, 10 Sep 2012 21:58:30 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
While reworking the modeset sequence, this got lost in
commit 25c5b2665fe4cc5a93edd29b62e7c05c1526
Author: Daniel Vetter
Timo Aaltonen wrote:
Well, these are usually hard to verify fixed. The commit is mentioned on
fdo bugs 45413 and 48838, should fix some GPU hangs.
The stable kernel rules are very clear about this:
- It must be obviously correct and tested.
Please ensure the backport gets tested on a
Daniel Vetter wrote:
On Wed, Sep 12, 2012 at 09:03:03AM -0700, Jonathan Nieder wrote:
An ack from someone on the i915 team would be welcome as well.
It's the right thing. The comment about hough we still have a window for
userspace to submit a broken command buffer during the modeset just
Hi,
This series introduces stereo 3D modes support and is split in 3 chunks:
1. 3 kernel patches to parse the 3D_present flag of the HDMI CEA vendor block,
to expose 3D formats flags in modes and to add a new property on connectors
supporting stereo 3D,
2. Sync the new mode flags in
From: Damien Lespiau damien.lesp...@intel.com
The select 3D mode property can be connected to connectors to signal
user space that 3D framebuffers can be scanned out to the said
connector.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 32
From: Damien Lespiau damien.lesp...@intel.com
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
From: Damien Lespiau damien.lesp...@intel.com
When scanning out a 3D framebuffer, send the corresponding infoframe to
the HDMI sink.
See http://www.hdmi.org/manufacturer/specification.aspx for details.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h
From: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/drm_mode.h | 35 +--
xf86drmMode.h | 35 +--
2 files changed, 42 insertions(+), 28 deletions(-)
diff
From: Damien Lespiau damien.lesp...@intel.com
When dumping the details of a mode, let's add the 3D formats the mode
supports.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/drmtest.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/lib/drmtest.c
This adds a module parameter, gtt_suspend_verify, that will enable a simple
GTT checksum across suspend and resume.
We currently spend a good amount of time (20ms) clearing all the GTT
PTEs at resume time, even though this may not be necessary on some
machines. This debug feature is intended to
Hi
2012/9/6 Daniel Vetter daniel.vet...@ffwll.ch:
By using the new pre_enabel/post_disable functions.
s/enabel/enable
To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.
This patch
It's bogus.
If I've followed the history of this piece of code correctly, i.e. the
initial register write with the following vblank wait, this goes all
the way back to the original enabling of DP support in
commit a4fc5ed69817c73e32571ad7837bb707f9890009
Author: Keith Packard kei...@keithp.com
On Sun, Sep 09, 2012 at 07:25:40PM +0100, Chris Wilson wrote:
On Fri, 7 Sep 2012 19:43:42 -0700, Ben Widawsky b...@bwidawsk.net wrote:
With the new standardized sysfs interfaces we need to be a bit more
careful about setting the RPS values.
Because the sysfs code and the rps workqueue
Provide a standardized sysfs interface for setting min, and max
frequencies. The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:
RP0 - ie. max frequency
RP1 - ie. preferred min frequency
RPn -
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.
In intel_enable_hdmi(), if intel_hdmi-has_audio been true, the Audio enable
bit will
be set to trigger
u32 enable_bits = SDVO_ENABLE;
- if (intel_hdmi-has_audio)
- enable_bits |= SDVO_AUDIO_ENABLE;
+ enable_bits |= SDVO_AUDIO_ENABLE;
The two lines can be combined:
u32 enable_bits = SDVO_ENABLE | SDVO_AUDIO_ENABLE;
Thanks,
Fengguang
Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.
In intel_enable_hdmi(), if intel_hdmi-has_audio been true, the Audio enable
bit will
be set to trigger
56 matches
Mail list logo
