Bryan Mayland wrote:
> Bryan Mayland wrote:
> > of that, ~4.5 seconds are spent uploading the audio firmware
>
> You might find this interesting. When uploading the firmware in the
> hauppauge windows driver, the i2c algo udelay is set to 3us instead of
> the normal 10us. Adding this quick function:
> static void cx25840_set_i2c_delay(struct i2c_client *client, int delay)
> {
> struct i2c_algo_bit_data *algod = client->adapter->algo_data;
> algod->udelay = delay;
> }
Yeah, the code could just be put into start/end_fw_load().
> and setting it to 3 during the firmware load reduces my module load time
> from ~7.9s to ~5.2s. After the firmware is sent, I return the udelay to
> 10. Any reason we shoudn't do this like the windows driver does?
If it's possible that anything else -using that instance of ivtv as
its i2c adapter- will do something during that interval where the
faster send will mess it up, there would need to be some locking done.
--
Tyler Trafford
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
