On Sun, Jul 19, 2009 at 10:18 PM, Mark Lord<lkml@xxxxxx> wrote: > Devin Heitmueller wrote: >> >> Yeah, the situation with the seven second firmware load time is well >> known. It's actually a result of the i2c's implementation in the >> au0828 hardware not properly supporting i2c clock stretching. Because >> of some bugs in the hardware, I have it clocked down to something like >> 30KHz as a workaround. I spent about a week investigating the i2c bus >> issue with my logic analyzer, and had to move on to other things. I >> documented the gory details here back in March if you really care: > > .. > > From your livejournal comments, it sounded like the slow clock might > not be necessary until *after* the firmware transfer. > > Mmm.. I wonder if perhaps a higher clock speed could be used > during the firmware download, and then switch to the slower 30KHz > speed afterward ? > > This could reduce the firmware transfer to a couple of seconds, > much better than the current 6-7 second pause. I did experiment with introducing a tuner callback to inform the bridge to enter a high speed mode, which in theory would have allowed the firmware load at 250Khz (and then revert to the slower speed after the load finished). However, for some unknown reason the tuner would not work after the load. I would see i2c errors on the bus when doing the tune, and I was not able to identify the cause. I spent a couple of nights playing with the idea, but didn't have more time to spend on it. 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
