On Mon, Jul 25, 2011 at 1:48 AM, Palash Bandyopadhyay <Palash.Bandyopadhyay@xxxxxxxxxxxx> 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html