> -Original Message-
> From: Wu, Fengguang
> Sent: Thursday, September 13, 2012 11:14 AM
> To: Wang, Xingchao
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> daniel.vet...@ffwll.ch; ti...@suse.de; Zhao, Yakui; Fu, Michael
> Subject: Re: [PATCH] drm/i915: HDMI - Clear
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 uns
> 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
__
Hi Daniel,
I tested this patch with drm-intel-next branch under ubuntu 12.04, the HDMI
hot plug could work correctly.
thanks
--xingchao
On Thu, Sep 13, 2012 at 10:56:16AM +0800, Wang Xingchao wrote:
> Clear Audio Enable bit to trigger unsolicated event to notify Audio
> Driver part the HDMI hot
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 uns
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 -
On Sun, Sep 09, 2012 at 07:25:40PM +0100, Chris Wilson wrote:
> On Fri, 7 Sep 2012 19:43:42 -0700, Ben Widawsky 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 can run
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
Date: Tue Apr 7 1
Hi
2012/9/6 Daniel Vetter :
> 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 does more than it say
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
Because this patch is adding a few test images, it's about 6MB
uncompressed, it can be downloaded from:
http://damien.lespiau.name/files/patches/0002-tests-testdisplay-Test-the-stereo-3D-modes.patch.bz2
--
Damien
___
Intel-gfx mailing list
Intel-gfx@li
From: Damien Lespiau
When dumping the details of a mode, let's add the 3D formats the mode
supports.
Signed-off-by: Damien Lespiau
---
lib/drmtest.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 8df9797..4d5a67c 100644
--
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
include/drm/drm_mode.h | 35 +--
xf86drmMode.h | 35 +--
2 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode
From: Damien Lespiau
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
---
drivers/gpu/drm/i915/intel_drv.h | 14
drivers/gpu/drm/i915/intel_hdmi.c
From: Damien Lespiau
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
Signed-off-by: Damien Les
From: Damien Lespiau
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
---
drivers/gpu/drm/drm_crtc.c | 32
include/drm/drm_crtc.h |
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 libdrm
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"
On Wed, Sep 12, 2012 at 09:03:03AM -0700, Jonathan Nieder wrote:
> 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
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 machi
On Wed, Sep 12, 2012 at 08:29:21AM -0700, Jesse Barnes wrote:
> On Mon, 10 Sep 2012 21:58:30 +0200
> Daniel Vetter wrote:
>
> > While reworking the modeset sequence, this got lost in
> >
> > commit 25c5b2665fe4cc5a93edd29b62e7c05c1526
> > Author: Daniel Vetter
> > Date: Sun Jul 8 22:08:04
On Wed, Sep 12, 2012 at 08:20:12AM -0700, Jesse Barnes wrote:
> On Mon, 10 Sep 2012 21:58:29 +0200
> Daniel Vetter wrote:
>
> > This has been added in
> >
> > commit de9a35abb3b343a25065449234e47a76c4f3454a
> > Author: Daniel Vetter
> > Date: Tue Jun 5 11:03:40 2012 +0200
> >
> > drm/i91
On Mon, 10 Sep 2012 21:58:30 +0200
Daniel Vetter wrote:
> While reworking the modeset sequence, this got lost in
>
> commit 25c5b2665fe4cc5a93edd29b62e7c05c1526
> Author: Daniel Vetter
> Date: Sun Jul 8 22:08:04 2012 +0200
>
> drm/i915: implement new set_mode code flow
>
> I've noti
On Wed, Sep 12, 2012 at 08:04:42AM -0700, Jesse Barnes wrote:
> On Tue, 11 Sep 2012 12:37:55 +0200
> Daniel Vetter wrote:
>
> > Otherwise things migt not work too well.
> >
> > Breakage introduced in
> >
> > commit eb1cbe4848b01f9f073064377875bc7d71eb401b
> > Author: Daniel Vetter
> > Date:
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, sh
On Mon, 10 Sep 2012 21:58:29 +0200
Daniel Vetter wrote:
> This has been added in
>
> commit de9a35abb3b343a25065449234e47a76c4f3454a
> Author: Daniel Vetter
> Date: Tue Jun 5 11:03:40 2012 +0200
>
> drm/i915: assert that the IBX port transcoder select w/a is implemented
>
> Unfortunatel
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
> o
On Tue, 11 Sep 2012 12:37:55 +0200
Daniel Vetter wrote:
> Otherwise things migt not work too well.
>
> Breakage introduced in
>
> commit eb1cbe4848b01f9f073064377875bc7d71eb401b
> Author: Daniel Vetter
> Date: Wed Mar 28 23:12:16 2012 +0200
>
> drm/i915: split PLL update code out of i9x
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 state
On Wed, Sep 12, 2012 at 10:06:35AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This is all the code responsible for setting the PCH PLLs.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 260
> --
> 1 file changed, 153 ins
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
> >
> > Signed-off-by: Paulo Zanoni
> Queued for -next, thanks for the patch. I've needed to resolve some
> conflicts since I didn't pick up all p
On Wed, Sep 12, 2012 at 10:06:34AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
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 to
onerous.
-Daniel
--
Daniel Vetter
Software
On Wed, Sep 12, 2012 at 10:06:33AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The set_m_n code was spread all over the mode_set function.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 152
> --
> 1 file changed, 89 ins
On Wed, Sep 12, 2012 at 10:06:32AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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.
>
> Signed-off-by: Paulo Zanoni
Qu
On Wed, Sep 12, 2012 at 10:06:31AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
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 identical
safe for:
- vsyncshift is only gen4
On Wed, Sep 12, 2012 at 10:06:29AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
> ---
> drivers/gpu/drm/i915/intel_display.c |
On Wed, Sep 12, 2012 at 10:06:30AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
I have a slightly more
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
> Cc: Dave Airlie
One nitpick below.
> @@ -99,6
Hi
2012/9/6 Daniel Vetter :
> 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 that would require
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
> Cc: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_mm.c | 49
> +
On Mon, Sep 10, 2012 at 05:34:48PM +0100, Chris Wilson wrote:
> On Thu, 6 Sep 2012 18:49:24 -0700, Ben Widawsky wrote:
> > On Tue, 4 Sep 2012 21:02:57 +0100
> > Chris Wilson wrote:
> >
> > > Rather than have multiple data structures for describing our page layout
> > > in conjunction with the a
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
On Thu, Sep 06, 2012 at 05:07:58PM -0700, Ben Widawsky wrote:
> On Tue, 4 Sep 2012 21:02:55 +0100
> Chris Wilson 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 us, and so we c
From: Paulo Zanoni
They are actually set but not used [-Wunused-but-set-variable].
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drive
From: Paulo Zanoni
This is all the code responsible for setting the PCH PLLs.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 260 --
1 file changed, 153 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
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
b/drivers/gpu/drm/i915/intel_display.c
index 8d3b9d6..dc4132a
From: Paulo Zanoni
The set_m_n code was spread all over the mode_set function.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 152 --
1 file changed, 89 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b
From: Paulo Zanoni
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.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 file changed, 3 i
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
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
b/drivers/gpu/drm/i915/intel_display.c
index cf1e628..5a4e363
From: Paulo Zanoni
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
---
drivers/gpu/drm/i915/intel_display.c | 37 ++---
drivers/gpu/drm/i915
From: Paulo Zanoni
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
---
drivers/gpu/drm/i915/intel_display.c | 88 --
1 file changed, 52 insertions(+), 36 d
From: Paulo Zanoni
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
ironlake_crtc_mode_set
Hello
AFAIK I don't use wayland. I guess GTKperf, is more relevant, I use gtk+
applications.
Regards,
Roberth Sjonøy
On 12. sep. 2012, at 11:59, Chris Wilson wrote:
> On Wed, 12 Sep 2012 11:12:02 +0200, Roberth Sjonøy
> wrote:
>> Hello
>>
>> Are you psychologist? /joke
>
> I just want t
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.
On Wed, 12 Sep 2012 11:12:02 +0200, Roberth Sjonøy
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 performance
> it works
On Thu, Sep 13, 2012 at 1:43 AM, Wang Xingchao 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 intel_hdmi->has_audio
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, Chri
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 wrote:
> On Wed
On Wed, 12 Sep 2012 10:29:20 +0200, Roberth Sjonøy
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 Wilson, Intel Open Source
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
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 unso
> -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 dr
62 matches
Mail list logo
