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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox