Hey, don't pick on me. The cx25840-registers stuff was written to support my I2C parser, I then used it as a fast way of converting the captures into working code. My code has never been presented as production worthy. It did however work better then one the original.
Yes the register file is auto generated from a datasheet, the datasheet contained a lot of inconsistencies. Some register had different addresses in different lists. Binary numbers was mixed with hex numbers, which is very hard for a parser to detect... The code is written so that all debug stuff can be compile time removed be changing the macro definitions. So the debug info size should not be an issue. Setting all registers to a default value was the only way I could think of to put the card into a known state, since the datasheets didn't present a reset-mechanism that guarantied a known state. This is critical when different generations of the code are run on non-rebooted machines. The shadow copy of all registers is kept to speed up the configuration process, i.e. don't set the same value several times. We need to address bits in bytes. I don't like to waist CPU time on bit banging unnecessary I2C codes. My intention was to tag all volatile/auto-updating registers as such and handle them specially, I didn't have time for that though. Yes you could go for an all anonymous "set address to byte" based driver, but I don't think that is a good idea if you want maintainability. Then again I don't claim that my code is ready or even maintainable. /Ulf. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
