Hans, > >Note: Murali made a new function that will fill in the v4l2_dv_enum_preset >based on the preset value. It's not yet in the v4l-dvb repository although >I hope that the timing patches will go in soon. The only thing I'm waiting >for is the revised documentation patch. > I will try to spend some time on these this week. >BTW: I think we need a g_dv_preset ops as well. That seems to be missing. >Murali, >is there any reason why we do not have that? One reason is we don't have a g_std() ops since core maintains the current norm. Other reason is at this point I don't see why we need this since bridge device driver is going to save the current std or current dv_preset set by application if s_std() or s_dv_preset() is successful. So if application calls G_DV_PRESET, bridge device driver will return the last successful std or dv_preset value. If we really need it for some reason, we could add it later when we integrate the vpfe/vpif drivers with this driver. > >> + } > >Did you check whether it is really needed to power the chip off and on >here? > >It still makes no sense to me that you have to do this. Can we make this a TODO item which can be addressed later? This driver is holding up my vpfe enhancements to support HD. This works functionally and we can always enhance the driver as required. So I suggest to keep this as a TODO item and address later using another patch. >> > Murali -- 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
