Re: Please test the gspca-stv06xx branch

[Hans de Goede <j.w.r.degoede@hhs.nl>]

Erik Andrén wrote:
> 2008/11/27 Hans de Goede <hdegoede@redhat.com>:

<snip>

>> I've solved this be creating 2 separate stv06xx_write_sensor functions:
>> typedef u8 u8_pair[2];
>> typedef u16 u16_pair[2];
>>
>> int stv06xx_write_sensor_bytes(struct sd *sd, const u8_pair *data, int len);
>> int stv06xx_write_sensor_words(struct sd *sd, const u16_pair *data, int
>> len);
>>
>> These functions get passed one or more u8 / u16  pairs where pair[0] is an
>> register-address and pair[1] is the value to write to that register, note
>> that for stv06xx_write_sensor_words() the addresses are in reality still 8
>> bits, they are gettings stored in an u16 for easier coding.
> 
> This is an alternate way of solving the same problem. I think this
> approach is more convoluted without any real gain.
> First you must multiplex the data and addresses by putting them
> together and then demultiplex them in the function.
> Not ideal but also not a big deal.
> 


The gain here is that it is easy to define a single table with address, value 
pairs to init the sensor. Like you've done in stv06xx_vv6410.h, my patch now 
uses that table directly and unmodifed. Imagine what this table would look like 
if you had 2 separate tables for addresses and values, then the resulting table 
declaration_S_ in stv06xx_vv6410.h would make it very hard to see which value 
gets written to which register, so IMHO there is a real and big gain here.

<snip>

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list