Hi Guennadi, <snip> > Well, I think, both of you will agree, that these register value lists > look horrible and actually have little to do with open-source software, > but I don't know what to do about them either. We could just reject them > and only accept drivers, properly describing what they do with the > hardware, or request to move this into one of firmware loading options... > But I'm not sure any of these options would actually do us any good. Just > sayin'. Any further thoughts on what to do about this driver? Based on what I have seen, we aren't going to get the info to properly describe _all_ of the registers. It's a shame the camera's registers don't default to usable settings, but that's what we have. In the case of this driver, there are a number of registers that are programmed based on the required resolution, framerate and format. Extracting that from the material I had was rather painful and the result is useful for anyone wanting to use this camera. Any register written to outside ov10635_regs_default[] should be programmed in some meaningful way, whereas those in ov10635_regs_default[] should be treated like firmware. However, even those registers accessed outside of ov10635_regs_default[] could still do with better descriptions. I should note that some of the values written to registers are empirically derived since they are based on device timing. I don't have any details about the device timing, just the values that were written for a number of different modes (resolution and framerate). Maybe the pragmatic approach is to use firmware for all those in ov10635_regs_default[], and the rest of the registers have to be well documented. I was asked to remove some comments about register names/functionality by OmniVision, but I can ask again if it helps. Thanks Phil -- 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
