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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to