From: Wu Fengguang <fengguang.wu@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "Wang, Zhenyu Z" <zhenyu.z.wang@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Barnes, Jesse" <jesse.barnes@intel.com>,
Jeremy Bush <contractfrombelow@gmail.com>,
Christopher White <c.white@pulseforce.com>,
"Bossart, Pierre-louis" <pierre-louis.bossart@intel.com>
Subject: Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Date: Fri, 11 Nov 2011 19:12:57 +0800 [thread overview]
Message-ID: <20111111111257.GA7118@localhost> (raw)
In-Reply-To: <s5hy5vn7yl4.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
(snip)
> > > One note that we don't rely on PD bit because not all (non-Intel)
> > > hardware report it correctly.
> >
> > Oops. Do you imply ELDV is reliable on all platforms? ;-)
>
> Oh hell, no :)
> The driver tries to probe explicitly via GET_PIN_SENSE HD-audio verb.
Yeah the below "HDMI status:..." line. Can we rely on it then?
> > > > [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B
> > > > [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1
> > > > [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0
> > > > [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port
> > > > [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2
> > > >
> > > > The HDA spec even mentioned doing some timeout mechanism for the
> > > > "Presence_Detect=1 ELD_Valid=0" state. Well it may help some corner
> > > > cases, but perhaps not an urgent feature.
> > >
> > > Yeah, this sounds like the workaround for such a case.
> >
> > Yeah, your mentioned DVI case may be always in state
> >
> > "Presence_Detect=1 ELD_Valid=0"
> >
> > where audio playback should be denied.
> >
> > And there might be the error case that the 2nd event is lost or not
> > generated at all for changing
> >
> > "Presence_Detect=1 ELD_Valid=0"
> > to
> > "Presence_Detect=1 ELD_Valid=1"
> >
> > > > > We might end up with some delayed probe with a dedicated work_struct
> > > > > (because it's bad to have a too long delay in unsol event handler
> > > > > that run on a single workq).
> > > >
> > > > Understand. What if the graphics driver can delay the ELD writing (I
> > > > can try that), so that the audio driver only need to wait for
> > > > something like 10ms?
> > >
> > > Or, we can introduce a dirty flag, and set it when ELD is changed,
> > > but don't prase ELD contents yet. First upon the next access, the
> > > driver updates the status, and clear the dirty flag. We may put a
> > > small delay at this update, too.
> >
> > It should work fine for "cat /proc/asound/card0/eld*" and other
> > interfaces, however it could still delay the printks' significantly.
>
> Well, this reminds me of another question -- do we need these printks
> unconditionally?
Maybe not. How about the attached patch to remove them all?
> > And it feels not good that accessing ELD may be blocked for some time..
>
> Understood.
>
> > So I now prefer to avoid the msleep totally and schedule a delayed
> > work for parsing ELD.
>
> OK, let me know if you have some test material.
OK!
Thanks,
Fengguang
[-- Attachment #2: alsa-hdmi-remove-printk --]
[-- Type: text/plain, Size: 1970 bytes --]
Subject: alsa: hide HDMI/ELD printks unless in debug kernels
Date: Fri Nov 11 19:09:36 CST 2011
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
sound/pci/hda/hda_eld.c | 6 +++---
sound/pci/hda/patch_hdmi.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
--- linux.orig/sound/pci/hda/hda_eld.c 2011-11-11 19:08:21.000000000 +0800
+++ linux/sound/pci/hda/hda_eld.c 2011-11-11 19:09:35.000000000 +0800
@@ -410,7 +410,7 @@ static void hdmi_show_short_audio_desc(s
else
buf2[0] = '\0';
- printk(KERN_INFO "HDMI: supports coding type %s:"
+ snd_printdd("HDMI: supports coding type %s:"
" channels = %d, rates =%s%s\n",
cea_audio_coding_type_names[a->format],
a->channels,
@@ -434,14 +434,14 @@ void snd_hdmi_show_eld(struct hdmi_eld *
{
int i;
- printk(KERN_INFO "HDMI: detected monitor %s at connection type %s\n",
+ snd_printdd("HDMI: detected monitor %s at connection type %s\n",
e->monitor_name,
eld_connection_type_names[e->conn_type]);
if (e->spk_alloc) {
char buf[SND_PRINT_CHANNEL_ALLOCATION_ADVISED_BUFSIZE];
snd_print_channel_allocation(e->spk_alloc, buf, sizeof(buf));
- printk(KERN_INFO "HDMI: available speakers:%s\n", buf);
+ snd_printdd("HDMI: available speakers:%s\n", buf);
}
for (i = 0; i < e->sad_count; i++)
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-11 19:07:15.000000000 +0800
+++ linux/sound/pci/hda/patch_hdmi.c 2011-11-11 19:08:16.000000000 +0800
@@ -757,7 +757,7 @@ static void hdmi_intrinsic_event(struct
int pin_idx;
struct hdmi_eld *eld;
- printk(KERN_INFO
+ snd_printdd(
"HDMI hot plug event: Codec=%d Pin=%d Presence_Detect=%d ELD_Valid=%d\n",
codec->addr, pin_nid, pd, eldv);
@@ -989,7 +989,7 @@ static void hdmi_present_sense(struct hd
else
eld->eld_valid = 0;
- printk(KERN_INFO
+ snd_printdd(
"HDMI status: Codec=%d Pin=%d Presence_Detect=%d ELD_Valid=%d\n",
codec->addr, pin_nid, eld->monitor_present, eld->eld_valid);
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2011-11-11 11:13 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-02 8:14 [PATCH v4] drm/i915: pass ELD to HDMI/DP audio driver Wu Fengguang
2011-09-02 8:29 ` Wu Fengguang
2011-09-03 21:15 ` [PATCH v5] " Wu Fengguang
2011-09-04 10:57 ` James Cloos
2011-09-05 1:19 ` Wu Fengguang
2011-09-04 11:11 ` [Intel-gfx] " Paul Menzel
2011-09-05 1:06 ` Wu Fengguang
2011-09-04 12:08 ` Chris Wilson
2011-09-05 1:14 ` Wu Fengguang
2011-09-05 11:04 ` Chris Wilson
2011-09-05 12:31 ` Wu Fengguang
[not found] ` <4E64C41B.5090309@pulseforce.com>
[not found] ` <20110905124730.GB794@localhost>
[not found] ` <4EA82DBD.9020301@pulseforce.com>
2011-10-27 19:57 ` Christopher White
2011-11-09 6:59 ` Wu Fengguang
2011-11-09 9:00 ` Christopher White
2011-11-09 9:30 ` Christopher White
2011-11-09 13:01 ` Wu Fengguang
[not found] ` <4EA9B6EF.9040305@pulseforce.com>
2011-11-01 11:36 ` Wu Fengguang
2011-11-01 17:00 ` Christopher White
2011-11-02 1:45 ` Wu Fengguang
2011-11-02 6:10 ` Sander Jansen
2011-11-02 7:35 ` Paul Menzel
2011-11-02 11:17 ` Sander Jansen
2011-11-02 14:26 ` Sander Jansen
2011-11-02 8:52 ` Wu Fengguang
2011-11-02 17:41 ` Keith Packard
2011-11-04 0:21 ` Tony Olivo
2011-11-05 0:20 ` Christopher White
2011-11-09 13:12 ` Wu Fengguang
2011-11-10 2:25 ` Christopher White
2011-11-10 3:27 ` Wu Fengguang
2011-11-10 4:10 ` Christopher White
2011-11-10 7:06 ` Wu Fengguang
2011-11-10 7:33 ` Wu Fengguang
2011-11-10 7:55 ` Wu Fengguang
2011-11-10 8:50 ` Wu Fengguang
2011-11-10 8:55 ` Christopher White
2011-11-10 11:00 ` Christopher White
2011-11-10 11:22 ` Takashi Iwai
2011-11-10 11:50 ` Christopher White
2011-11-10 11:53 ` Takashi Iwai
2011-11-10 12:39 ` Christopher White
2011-11-10 13:01 ` Takashi Iwai
2011-11-10 12:56 ` Wu Fengguang
2011-11-10 13:01 ` Christopher White
2011-11-10 13:17 ` Wu Fengguang
2011-11-10 13:34 ` Christopher White
2011-11-10 13:47 ` Wu Fengguang
2011-11-10 14:12 ` Wu Fengguang
2011-11-10 13:41 ` Takashi Iwai
2011-11-10 13:51 ` Wu Fengguang
2011-11-10 13:53 ` Wu Fengguang
2011-11-10 14:28 ` Takashi Iwai
2011-11-11 2:29 ` Wu Fengguang
2011-11-11 7:40 ` Takashi Iwai
2011-11-11 8:22 ` Wu Fengguang
2011-11-11 8:49 ` Takashi Iwai
2011-11-11 9:24 ` Wu Fengguang
2011-11-11 10:17 ` Takashi Iwai
2011-11-11 11:12 ` Wu Fengguang [this message]
2011-11-11 11:23 ` Takashi Iwai
2011-11-11 11:32 ` Wu Fengguang
2011-11-12 2:27 ` Wu Fengguang
2011-11-14 9:45 ` Takashi Iwai
2011-11-14 13:25 ` Wu Fengguang
2011-11-15 17:18 ` Purushothaman, Vijay A
2011-11-10 6:59 ` Wu Fengguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111111111257.GA7118@localhost \
--to=fengguang.wu@intel.com \
--cc=c.white@pulseforce.com \
--cc=contractfrombelow@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jesse.barnes@intel.com \
--cc=pierre-louis.bossart@intel.com \
--cc=tiwai@suse.de \
--cc=zhenyu.z.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.