From: Wu Fengguang <fengguang.wu@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] hda - delayed ELD repoll
Date: Tue, 22 Nov 2011 16:00:38 +0800 [thread overview]
Message-ID: <20111122080038.GA22354@localhost> (raw)
In-Reply-To: <s5hr510397z.wl%tiwai@suse.de>
On Tue, Nov 22, 2011 at 03:30:24PM +0800, Takashi Iwai wrote:
> At Mon, 21 Nov 2011 14:48:11 +0800,
> Wu Fengguang wrote:
> >
> > On Wed, Nov 16, 2011 at 04:29:47PM +0800, Wu, Fengguang wrote:
> > > The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
> > > between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
> > > actually readable. During the time the ELD buffer is mysteriously all 0.
> > >
> > > Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
> >
> > Just FYI.
> >
> > Up to now the 300ms looks sufficient. But if ever there comes longer
> > delays, I've already prepared a patch for retrying it for several times ;)
>
> Thanks. I think it's safer to have a repoll mechanism.
> But, looking at the patch, one question remains:
>
> > @@ -989,10 +990,9 @@ static void hdmi_present_sense(struct hd
> > if (eld_valid) {
> > if (!snd_hdmi_get_eld(eld, codec, pin_nid))
> > snd_hdmi_show_eld(eld);
> > - else if (retry) {
> > + else if (repoll) {
> > queue_delayed_work(codec->bus->workq,
> > - &per_pin->work,
> > - msecs_to_jiffies(300));
> > + &per_pin->work, repoll * HZ / 3);
>
> Do you really want to wait longer with a higher repoll number?
I think it would be good to keep constant repoll intervals (it's cheap
after all), but at the same time lift the retry time from 3 to 6.
I did this patch when I got the graphics driver side wrong and
triggered the hotplug event rather early. At the time I find that it
failed until the 3rd repoll (300ms + 600ms + 900ms).
Thanks,
Fengguang
---
Subject: hda - repoll ELD content for multiple times
Date: Fri Nov 18 16:59:32 CST 2011
Improve the one-shot ELD repoll to up to 6 retries.
Up to now the 300ms looks sufficient for the test boxes. However
I'm a bit worried about how well it can fit the wider user base.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
sound/pci/hda/patch_hdmi.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-22 15:50:21.000000000 +0800
+++ linux/sound/pci/hda/patch_hdmi.c 2011-11-22 15:50:41.000000000 +0800
@@ -69,6 +69,7 @@ struct hdmi_spec_per_pin {
struct hda_codec *codec;
struct hdmi_eld sink_eld;
struct delayed_work work;
+ int repoll_count;
};
struct hdmi_spec {
@@ -748,7 +749,7 @@ static void hdmi_setup_audio_infoframe(s
* Unsolicited events
*/
-static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, bool retry);
+static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll);
static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
{
@@ -766,7 +767,7 @@ static void hdmi_intrinsic_event(struct
if (pin_idx < 0)
return;
- hdmi_present_sense(&spec->pins[pin_idx], true);
+ hdmi_present_sense(&spec->pins[pin_idx], 1);
}
static void hdmi_non_intrinsic_event(struct hda_codec *codec, unsigned int res)
@@ -960,7 +961,7 @@ static int hdmi_read_pin_conn(struct hda
return 0;
}
-static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, bool retry)
+static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll)
{
struct hda_codec *codec = per_pin->codec;
struct hdmi_eld *eld = &per_pin->sink_eld;
@@ -989,7 +990,7 @@ static void hdmi_present_sense(struct hd
if (eld_valid) {
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
- else if (retry) {
+ else if (repoll) {
queue_delayed_work(codec->bus->workq,
&per_pin->work,
msecs_to_jiffies(300));
@@ -1004,7 +1005,10 @@ static void hdmi_repoll_eld(struct work_
struct hdmi_spec_per_pin *per_pin =
container_of(to_delayed_work(work), struct hdmi_spec_per_pin, work);
- hdmi_present_sense(per_pin, false);
+ if (per_pin->repoll_count++ > 6)
+ per_pin->repoll_count = 0;
+
+ hdmi_present_sense(per_pin, per_pin->repoll_count);
}
static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
@@ -1235,7 +1239,7 @@ static int generic_hdmi_build_jack(struc
if (err < 0)
return err;
- hdmi_present_sense(per_pin, false);
+ hdmi_present_sense(per_pin, 0);
return 0;
}
next prev parent reply other threads:[~2011-11-22 8:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 8:29 [PATCH 0/3] ELD fixes for 3.2 Wu Fengguang
2011-11-16 8:29 ` Wu Fengguang
2011-11-16 8:29 ` [PATCH 1/3] hda - fix ELD memory leak Wu Fengguang
2011-11-16 8:29 ` Wu Fengguang
2011-11-16 8:29 ` [PATCH 2/3] hda - delayed ELD repoll Wu Fengguang
2011-11-16 8:29 ` Wu Fengguang
2011-11-21 6:48 ` Wu Fengguang
2011-11-22 7:30 ` Takashi Iwai
2011-11-22 8:00 ` Wu Fengguang [this message]
2011-11-16 8:29 ` [PATCH 3/3] hda - move eld->spk_alloc fixup to hdmi_update_eld() Wu Fengguang
2011-11-16 8:29 ` Wu Fengguang
2011-11-16 9:54 ` [PATCH 0/3] ELD fixes for 3.2 Takashi Iwai
2011-11-16 9:54 ` Takashi Iwai
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=20111122080038.GA22354@localhost \
--to=fengguang.wu@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/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.