Re: Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

Re: Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

[niraj kulkarni]

Removing these 3 usleep ranges is working now. Although I have a doubt for
applying this patch on all chips. There have been a number of boards
released after this particular board, but nobody else is facing this
problem. Since spec does not specify a max on deasserting RST, some boards
might actually take more than 100uS to reset. Will this patch work for
those boards?

@@ -1149,7 +1149,7 @@
        timeout = jiffies + msecs_to_jiffies(100);
        while ((azx_readb(chip, GCTL) & ICH6_GCTL_RESET) &&
                        time_before(jiffies, timeout))
-               usleep_range(500, 1000);
+               cpu_relax();
 }

 /* exit link reset */
@@ -1162,7 +1162,7 @@
        timeout = jiffies + msecs_to_jiffies(100);
        while (!azx_readb(chip, GCTL) &&
                        time_before(jiffies, timeout))
-               usleep_range(500, 1000);
+               cpu_relax();
 }

 /* reset codec link */
@@ -1180,7 +1180,7 @@
        /* delay for >= 100us for codec PLL to settle per spec
         * Rev 0.9 section 5.5.1
         */
-       usleep_range(500, 1000);
+       //usleep_range(500, 1000);

        /* Bring controller out of reset */
        azx_exit_link_reset(chip);

Re: Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

[Takashi Iwai]

At Mon, 10 Feb 2014 11:35:41 +0530,
niraj kulkarni wrote:
> 
> Removing these 3 usleep ranges is working now. Although I have a doubt for
> applying this patch on all chips. There have been a number of boards
> released after this particular board, but nobody else is facing this
> problem. Since spec does not specify a max on deasserting RST, some boards
> might actually take more than 100uS to reset. Will this patch work for
> those boards?
> 
> @@ -1149,7 +1149,7 @@
>         timeout = jiffies + msecs_to_jiffies(100);
>         while ((azx_readb(chip, GCTL) & ICH6_GCTL_RESET) &&
>                         time_before(jiffies, timeout))
> -               usleep_range(500, 1000);
> +               cpu_relax();
>  }
> 
>  /* exit link reset */
> @@ -1162,7 +1162,7 @@
>         timeout = jiffies + msecs_to_jiffies(100);
>         while (!azx_readb(chip, GCTL) &&
>                         time_before(jiffies, timeout))
> -               usleep_range(500, 1000);
> +               cpu_relax();
>  }
> 
>  /* reset codec link */
> @@ -1180,7 +1180,7 @@
>         /* delay for >= 100us for codec PLL to settle per spec
>          * Rev 0.9 section 5.5.1
>          */
> -       usleep_range(500, 1000);
> +       //usleep_range(500, 1000);

Why didn't you change as I suggested?  In my patch, I placed udelay(2)
since the spec tells so.  Didn't it interfere?

Replacing usleep_range() with cpu_relax() should make still working on
other boards because it doesn't change the length of the timeout
itself.  The timeout is set to very long (100ms).  The only drawback
would be a higher CPU usage at probing, but the impact should be
negligible.


Takashi

Re: Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

[niraj kulkarni]

Sorry, I did not see that part earlier. Putting udelay(2) is also working
fine.

Niraj


On Mon, Feb 10, 2014 at 2:31 PM, Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 10 Feb 2014 11:35:41 +0530,
> niraj kulkarni wrote:
> >
> > Removing these 3 usleep ranges is working now. Although I have a doubt
> for
> > applying this patch on all chips. There have been a number of boards
> > released after this particular board, but nobody else is facing this
> > problem. Since spec does not specify a max on deasserting RST, some
> boards
> > might actually take more than 100uS to reset. Will this patch work for
> > those boards?
> >
> > @@ -1149,7 +1149,7 @@
> >         timeout = jiffies + msecs_to_jiffies(100);
> >         while ((azx_readb(chip, GCTL) & ICH6_GCTL_RESET) &&
> >                         time_before(jiffies, timeout))
> > -               usleep_range(500, 1000);
> > +               cpu_relax();
> >  }
> >
> >  /* exit link reset */
> > @@ -1162,7 +1162,7 @@
> >         timeout = jiffies + msecs_to_jiffies(100);
> >         while (!azx_readb(chip, GCTL) &&
> >                         time_before(jiffies, timeout))
> > -               usleep_range(500, 1000);
> > +               cpu_relax();
> >  }
> >
> >  /* reset codec link */
> > @@ -1180,7 +1180,7 @@
> >         /* delay for >= 100us for codec PLL to settle per spec
> >          * Rev 0.9 section 5.5.1
> >          */
> > -       usleep_range(500, 1000);
> > +       //usleep_range(500, 1000);
>
> Why didn't you change as I suggested?  In my patch, I placed udelay(2)
> since the spec tells so.  Didn't it interfere?
>
> Replacing usleep_range() with cpu_relax() should make still working on
> other boards because it doesn't change the length of the timeout
> itself.  The timeout is set to very long (100ms).  The only drawback
> would be a higher CPU usage at probing, but the impact should be
> negligible.
>
>
> Takashi
>

Re: Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

[Takashi Iwai]

At Mon, 10 Feb 2014 17:10:16 +0530,
niraj kulkarni wrote:
> 
> Sorry, I did not see that part earlier. Putting udelay(2) is also working
> fine.

OK, thanks for testing.  I'm going to test the patch with other
machines and then merge to the upstream.


Takashi

> 
> Niraj
> 
> 
> On Mon, Feb 10, 2014 at 2:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Mon, 10 Feb 2014 11:35:41 +0530,
> > niraj kulkarni wrote:
> > >
> > > Removing these 3 usleep ranges is working now. Although I have a doubt
> > for
> > > applying this patch on all chips. There have been a number of boards
> > > released after this particular board, but nobody else is facing this
> > > problem. Since spec does not specify a max on deasserting RST, some
> > boards
> > > might actually take more than 100uS to reset. Will this patch work for
> > > those boards?
> > >
> > > @@ -1149,7 +1149,7 @@
> > >         timeout = jiffies + msecs_to_jiffies(100);
> > >         while ((azx_readb(chip, GCTL) & ICH6_GCTL_RESET) &&
> > >                         time_before(jiffies, timeout))
> > > -               usleep_range(500, 1000);
> > > +               cpu_relax();
> > >  }
> > >
> > >  /* exit link reset */
> > > @@ -1162,7 +1162,7 @@
> > >         timeout = jiffies + msecs_to_jiffies(100);
> > >         while (!azx_readb(chip, GCTL) &&
> > >                         time_before(jiffies, timeout))
> > > -               usleep_range(500, 1000);
> > > +               cpu_relax();
> > >  }
> > >
> > >  /* reset codec link */
> > > @@ -1180,7 +1180,7 @@
> > >         /* delay for >= 100us for codec PLL to settle per spec
> > >          * Rev 0.9 section 5.5.1
> > >          */
> > > -       usleep_range(500, 1000);
> > > +       //usleep_range(500, 1000);
> >
> > Why didn't you change as I suggested?  In my patch, I placed udelay(2)
> > since the spec tells so.  Didn't it interfere?
> >
> > Replacing usleep_range() with cpu_relax() should make still working on
> > other boards because it doesn't change the length of the timeout
> > itself.  The timeout is set to very long (100ms).  The only drawback
> > would be a higher CPU usage at probing, but the impact should be
> > negligible.
> >
> >
> > Takashi
> >
> [2  <text/html; ISO-8859-1 (quoted-printable)>]
> 

[alsa-devel] Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

[Niraj Kulkarni]

Let me try to explain my findings:



> How does this magic sequence come?

By dumping Win7 driver's init sequence and reproducing it through ALSA driver.



>why does it need to set UNSOL flag at first?

No such need, I've put it after regular init so that only affected chipsets are reset again. Putting this anywhere around init code works (tried it).



>Is the while loop guaranteed to quit for a reasonable time?

Being household user, I can only confirm on my chipset. Only a thorough testing may ensure sanity.



>Can't it be simply calling azx_reset() twice?

It is interesting hardware bug which kicks in only during first init after power-on. So if  Win7 driver in qemu inits the board, and I simply plugin "unchanged" hda_intel afterwards, it still detects codecs. But multiple normal resets do not have any effect. Being no hardware expert, I can only speculate that tight spin loop after reset has the crux. A normal delay call there does not detect codec.



>And, yet another question comes up: doesn't S4 need the similar workaround? If S4 works, what's the difference?

Haven't tried with sleep-wake or hibernate-restore sequence yet.



-- 

You received this bug notification because you are subscribed to the bug

report.

https://bugs.launchpad.net/bugs/1155202



Title:

  [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No

  sound at all



Status in “alsa-driver” package in Ubuntu:

  Incomplete



Bug description:

  I am using ubuntu 10.04



  I expected sound



  Got no sound at all



  I am very new to ubuntu so I have no idea how to find the version of

  the package I am using



  ProblemType: Bug

  DistroRelease: Ubuntu 12.04

  Package: alsa-base 1.0.25+dfsg-0ubuntu1.1

  ProcVersionSignature: Ubuntu 3.2.0-38.61-generic-pae 3.2.37

  Uname: Linux 3.2.0-38-generic-pae i686

  AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.

  AplayDevices:

   **** List of PLAYBACK Hardware Devices ****

   card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]

     Subdevices: 1/1

     Subdevice #0: subdevice #0

  ApportVersion: 2.0.1-0ubuntu17.1

  Architecture: i386

  ArecordDevices: **** List of CAPTURE Hardware Devices ****

  AudioDevicesInUse:

   USER        PID ACCESS COMMAND

   /dev/snd/controlC0:  jan        1750 F.... pulseaudio

  Card0.Amixer.info:

   Card hw:0 'PCH'/'HDA Intel PCH at 0xf7c30000 irq 45'

     Mixer name   : 'Intel PantherPoint HDMI'

     Components   : 'HDA:80862806,80860101,00100000'

     Controls      : 7

     Simple ctrls  : 2

  CurrentDmesg: [   24.291482] eth0: no IPv6 routers present

  Date: Thu Mar 14 08:53:13 2013

  InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release i386 (20120817.3)

  MarkForUpload: True

  PackageArchitecture: all

  ProcEnviron:

   TERM=xterm

   PATH=(custom, no user)

   LANG=en_US.UTF-8

   SHELL=/bin/bash

  SourcePackage: alsa-driver

  Symptom: audio

  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed

  Symptom_Card: Built-in Audio - HDA Intel PCH

  Symptom_DevicesInUse:

   1750  jan       F.... pulseaudio

       PID ACCESS COMMAND

  Symptom_Jack: Digital Out, HDMI

  Symptom_Type: No sound at all

  Title: [, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

  UpgradeStatus: No upgrade log present (probably fresh install)

  dmi.bios.date: 03/19/2012

  dmi.bios.vendor: Intel Corporation

  dmi.bios.version: SLZ7710H.86A.0055.2012.0319.2140

  dmi.board.name: DZ77SL-50K

  dmi.board.vendor: Intel Corporation

  dmi.board.version: AAG55115-300

  dmi.chassis.type: 3

  dmi.modalias: dmi:bvnIntelCorporation:bvrSLZ7710H.86A.0055.2012.0319.2140:bd03/19/2012:svn:pn:pvr:rvnIntelCorporation:rnDZ77SL-50K:rvrAAG55115-300:cvn:ct3:cvr:



To manage notifications about this bug go to:

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1155202/+subscriptions

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all

[Takashi Iwai]

At 22 Jan 2014 14:20:23 -0000,
Niraj Kulkarni wrote:
> 
> Let me try to explain my findings:
> 
> 
> 
> > How does this magic sequence come?
> 
> By dumping Win7 driver's init sequence and reproducing it through ALSA driver.
> 
> 
> 
> >why does it need to set UNSOL flag at first?
> 
> No such need, I've put it after regular init so that only affected chipsets are reset again. Putting this anywhere around init code works (tried it).

OK.

> >Is the while loop guaranteed to quit for a reasonable time?
> 
> Being household user, I can only confirm on my chipset. Only a thorough testing may ensure sanity.

Then you must put a timeout not to lock up the machine.

> >Can't it be simply calling azx_reset() twice?
> 
> It is interesting hardware bug which kicks in only during first init after power-on. So if Win7 driver in qemu inits the board, and I simply plugin "unchanged" hda_intel afterwards, it still detects codecs. But multiple normal resets do not have any effect. Being no hardware expert, I can only speculate that tight spin loop after reset has the crux. A normal delay call there does not detect codec.

This is doubtful.  Here we see the behavior of the PCI controller, and
there shouldn't be difference by CPU instructions.

The difference in the code between azx_reset() and your code are:

- Use of azx_writeb() and azx_writel()
- Limited loop time for GCTL_RESET bit check

For the first one, you can try the code change like below:
-- 8< --
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index fa2879a21a50..03525cff565a 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1143,10 +1143,10 @@ static void azx_enter_link_reset(struct azx *chip)
 	unsigned long timeout;
 
 	/* reset controller */
-	azx_writel(chip, GCTL, azx_readl(chip, GCTL) & ~ICH6_GCTL_RESET);
+	azx_writel(chip, GCTL, 0);
 
 	timeout = jiffies + msecs_to_jiffies(100);
-	while ((azx_readb(chip, GCTL) & ICH6_GCTL_RESET) &&
+	while (azx_readl(chip, GCTL) &&
 			time_before(jiffies, timeout))
 		usleep_range(500, 1000);
 }
@@ -1156,10 +1156,10 @@ static void azx_exit_link_reset(struct azx *chip)
 {
 	unsigned long timeout;
 
-	azx_writeb(chip, GCTL, azx_readb(chip, GCTL) | ICH6_GCTL_RESET);
+	azx_writel(chip, GCTL, ICH6_GCTL_RESET);
 
 	timeout = jiffies + msecs_to_jiffies(100);
-	while (!azx_readb(chip, GCTL) &&
+	while (!azx_readl(chip, GCTL) &&
 			time_before(jiffies, timeout))
 		usleep_range(500, 1000);
 }
-- 8< --

For the second point, you can increase the timeout value e.g.
	timeout = jiffies + msecs_to_jiffies(500);

> &gt;And, yet another question comes up: doesn't S4 need the similar workaround? If S4 works, what's the difference?
> 
> Haven't tried with sleep-wake or hibernate-restore sequence yet.

Please check it.  I guess S4 is broken with your patch.


Takashi