At Tue, 18 Jun 2013 10:41:53 +0800,
Wang Xingchao wrote:
Haswell converters maybe in wrong power state before usage.
i.e. only converter 0 is in D0, converter 1/2 are in D3.
When pin choose converter 1/2, there's no audio output, this
cause dependency when playing differnt stream on pins.
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and
cried.
Fixing up the console_lock mess around the fbdev
Hi
On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and cried.
Fixing up the console_lock mess around the fbdev notifier will be real work,
semanatically the fbdev layer does lots of
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and cried.
Fixing up the console_lock mess around the fbdev notifier will be real work,
semanatically the fbdev layer does lots of stupid things (like
Hi
On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote:
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and
cried.
Fixing up the console_lock mess around the fbdev notifier will be real work,
On Mon, Jun 17, 2013 at 12:52:41PM +, Wang, Xingchao wrote:
Hi Daniel,
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Saturday, June 15, 2013 3:18 AM
To: Wang Xingchao
Cc: Takashi Iwai; alsa-de...@alsa-project.org; intel-gfx; David Henningsson;
This patch series seems ok for me.
Reviewed-by: Zoltan Nyul zoltan.n...@intel.com
Hi
This week I sent a patch called drm/i915: propagate errors from
intel_dp_init_connector to fix a Haswell bug that was preventing my machine
from booting. Chris provided a nice suggestion for it, so this
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0
Hi Takashi/Daniel,
This patch could be used to replace below two:
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029076.html
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029077.html
It could avoid lots of changes in gfx side.
I test the patch and it could fix the same
Hi Daniel,
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Tuesday, June 18, 2013 3:13 PM
To: Wang, Xingchao
Cc: Daniel Vetter; Wang Xingchao; Takashi Iwai; alsa-de...@alsa-project.org;
intel-gfx; David Henningsson
On Tue, Jun 18, 2013 at 10:29:58AM +0300, Dan Carpenter wrote:
This macro doesn't need a semi-colon.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Queued for -next, thanks for the patch.
-Daniel
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
On Tue, Jun 18, 2013 at 09:03:05AM +, Wang, Xingchao wrote:
Hi Takashi/Daniel,
This patch could be used to replace below two:
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029076.html
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029077.html
It could avoid lots
Chris Wilson ch...@chris-wilson.co.uk writes:
The default context is always supported (as it contains the global
hangcheck stats) and the contexts for hangcheck are not limited
to any ring.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65845
Signed-off-by: Chris Wilson
At Tue, 18 Jun 2013 16:32:01 +0800,
Wang Xingchao wrote:
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter
Hi Takashi,
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, June 18, 2013 8:07 PM
To: Wang Xingchao
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Wang, Xingchao
Subject: Re: [PATCH] ALSA: hda - Avoid choose
On Sun, Dec 23, 2012 at 2:51 PM, G.R. firemet...@users.sourceforge.net wrote:
Hi Jesse, I think I need to resend the patch with proper comment to
have it formally accepted.
Any guide line for formal patch submission? Do I need to start a
separate thread?
No, just cc Daniel Vetter.
--
Hi all,
So apparently I've failed to send the -testing update mail last Friday.
But that tree turned out to be seriously broken anyway, so seems I've been
lucky. Anyway, a big one with quite some patches:
- more hangcheck work from Mika and Chris to prepare for arb robustness
- trickle feed fixes
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0
At Tue, 18 Jun 2013 21:42:14 +0800,
Wang Xingchao wrote:
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, June 18, 2013 10:14 PM
To: Wang Xingchao
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Wang, Xingchao
Subject: Re: [PATCH V1] ALSA: hda - Avoid choose same
---
intel/intel_bufmgr_gem.c | 91 +++-
1 file changed, 43 insertions(+), 48 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3c73068..b06c99a 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@
There is a very tiny change (-120 bytes) in compiled code size as a
result.
---
intel/intel_bufmgr_gem.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b72a30b..ee73857 100644
---
Saves another 4 bytes on a drm_intel_bo.
---
intel/intel_bufmgr_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index f068df6..5e087bc 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -174,11
It comes in to us as a u32, and goes to the kernel as a u32, so
storing as a long in between is silly.
---
intel/intel_bufmgr_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b06c99a..f068df6 100644
---
---
intel/intel_bufmgr_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5e087bc..b72a30b 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -200,7 +200,8 @@ struct _drm_intel_bo_gem {
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
aren't meant to be modified, so make them all const. The exception is
Hello,
On Wednesday 08 May 2013 15:52:10 Laurent Pinchart wrote:
On Wednesday 08 May 2013 16:40:54 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly.
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
28 matches
Mail list logo
