Fix regression introduced which broke the Hauppauge USBLive 2

Commit Message

Palash Bandyopadhyay July 25, 2011, 5:48 a.m. UTC

Mauro/Devin,

  Can someone give steps to reproduce the problem? Also if we need any particular h/w board to reproduce this problem. I dont seem to recall any delay requirement on the chip at power up/cycle time. Any I also dont recall seeing any problems with the Conexant evk boards. Mauro, have you been able to see this issue with a Conexant board?

Thanks,
Palash

Comments

Devin Heitmueller July 25, 2011, 10:24 a.m. UTC | #1

On Mon, Jul 25, 2011 at 1:48 AM, Palash Bandyopadhyay
<[e-mail]> wrote:
> Mauro/Devin,
>
>  Can someone give steps to reproduce the problem? Also if we need any particular h/w board to reproduce this problem. I dont seem to recall any delay requirement on the chip at power up/cycle time. Any I also dont recall seeing any problems with the Conexant evk boards. Mauro, have you been able to see this issue with a Conexant board?

Hello Palash,

The problem occurs if the kernel is configured for CONFIG_HZ to 1000
and on the Hauppauge USBLIve 2 hardware design.  I'm assuming it's
tied to two factors:

1.  Some aspect of the power supply tied to the Mako core being a
little slow to startup.  I haven't compared the schematic to the EVK,
but I could do that if we *really* think that is a worthwhile
exercise.
2.  On typical kernels which have CONFIG_HZ set to 100, a call to
msleep(5) will actually take approximately 10ms (due to the clock
resolution).  However, if you have CONFIG_HZ set to 1000 then the call
*actually* takes 5ms which is too short for this design.  In other
words, you would be unlikely to notice the issue unless you had
CONFIG_HZ set to a high enough resolution for the msleep(5) to
actually take 5ms.

The changed as proposed should be very low impact.  For users who have
CONFIG_HZ set to 100 (which is typical), there will be no visible
increase in time (since the call was already taking 10ms).  For users
who have CONFIG_HZ set to 1000, the net effect is that it takes an
extra 20ms to switch hardware modes (since the #define in question is
used at most four times in sequence).

Devin

Patch

diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c b/drivers/media/video/cx231xx/cx231xx-avcore.c
index cf50faf..cf412cd 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -2412,7 +2412,7 @@  int cx231xx_set_power_mode(struct cx231xx *dev, enum AV_MODE mode)
                break;
        }

-       msleep(PWR_SLEEP_INTERVAL);
+       msleep(PWR_SLEEP_INTERVAL * 10);

        /* For power saving, only enable Pwr_resetout_n
           when digital TV is selected. */