Re: [alsa-devel] Fw: [Bug 1155202] [Intel DZ77SL-50K, Intel PantherPoint HDMI, Digital Out, HDMI] No sound at all
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);
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
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
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)>]
participants (2)
-
niraj kulkarni -
Takashi Iwai